IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The MSI file can contain different content with each change in build ID,
but the filename never changes. This creates confusion as to whether the
MSI is actually up to date or not. It requires the looking inside the
MSI to see the encoded version.
The RPM uses 2 components from the %release field as input for the build
ID value. Use these as two parts of the filename, separated from the
version with a "-" similar to how RPM version/release are separated.
IOW, an RPM
mingw32-virt-viewer-msi-9.0-1.fc33.noarch.rpm
will result in
virt-viewer-x64-9.0-1.0.msi
while
mingw32-virt-viewer-msi-9.0-1.fc33.1.noarch.rpm
will result in
virt-viewer-x64-9.0-1.1.msi
Essentially we've just stripped the %dist part (".fc33") out of
the release, and default the second component to "0" if omitted.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
(cherry picked from commit 044534899b)
The project primary git repo has moved from pagure.io to
gitlab.com/virt-viewer/virt-viewer. We want users to submit
code contributions, bug reports and support questions to the
gitlab project, not the mailing list, nor bugzilla, nor the
virt-manager.org site.
We're still using virt-manager.org for hosting downloads of
source and pagure.io for MSIs, but we'll aim to change that
too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The error code returned by virt_viewer_session_open_fd() and
virt_viewer_session_channel_open_fd() were not checked. The file
descriptor passed to them could then be left opened even if the function
failed, causing a leak of resources.
This was reported by a Coverity scan, logged under
https://bugzilla.redhat.com/show_bug.cgi?id=1655792
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Julien Ropé <jrope@redhat.com>
When doing a screenshot, if the user provides a filename without a file
extension, an error occurs because the image format could not be determined.
This patch adds a .png extension to such filenames, so that there is a default
file format for screenshots.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1752514
Reviewed-by: Victor Toso <victortoso@redhat.com>
Signed-off-by: Julien Ropé <jrope@redhat.com>
When the application is stopped, if the windows are in fullscreen, their
position on the client will be remembered.
This change uses the existing option 'monitor-mapping' in the settings
file to save the position and reuse it on next launch.
This implements part of the requirement from
https://bugzilla.redhat.com/show_bug.cgi?id=1179070
NOTE: this feature is effective only with GTK >= 3.22
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Julien Ropé <jrope@redhat.com>
When remote-viewer is started from terminal, CTRL-C sends a SIGINT
signal to the program causing immediate termination. On linux clients
usb redirected devices are left without any kernel driver attached,
causing them to appear as no more available to the host.
Add a SIGINT handler to allow a clean exit, in particular to allow
the kernel to attach back the host driver.
The issue is present on linux only.
To perform usb device redirection, virt-viewer leverages spice-gtk
library, which in turn relies on usbredir library, which uses libusb.
In order to take control of the usb device the auto-loaded kernel
driver must be detached. This is achieved (in the very end) with
libusb_detach_kernel_driver(). Then the device interfaces can be claimed
with libusb_claim_interface() and get in control to the application.
During normal application termination, the usb channel is teared down,
performing a reset of the usb device and giving back the control of the
device to the kernel (libusb_attach_kernel_driver()).
If the application quits without doing this, the device interfaces will
end up with no driver attached, making them not usable in the host
system.
Note that enabling libusb_set_auto_detach_kernel_driver() does not solve
the issue, as this is just a convenient API from libusb: libusb will
take care of detaching/attaching the driver to the interfaces of the usb
device each time a call to libusb_release_interface() and
libusb_claim_interface() is performed. An unexpected quit of the
application will skip the libusb_release_interface() call too, leaving
the interfaces without any driver attached.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1713311
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Francesco Giudici <fgiudici@redhat.com>
Since oVirt engine version 4.3.2.1, the API returns certificate data for
display connection in the VM XML, so users do not need to specify it
from the command line anymore. The certificate obtained from the XML
gets precedence over the one from the command line, which is still kept
to keep compatibility of older versions of oVirt.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1402909
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
On remote_viewer_session_connected() we are passing a dup of URI of
connection and freeing it afterwards. Problem is, we don't disconnect
from listening "session-connected" and on an eventual second emission
of this signal, remote-viewer crashes as seen in the backtrace below.
This can happen over switch-host migration message from
SpiceMainChannel.
A fix trying to use VirtViewerApp URI avoid the crash but introduces
regression while running remote-viewer with ovirt so, keeping the
changes to a minimum to avoid it, just use g_intern_string() for now.
Found it while improving migrate.py from spice/tests (server):
| Invalid free() / delete / delete[] / realloc()
| at 0x4839A0C: free (vg_replace_malloc.c:540)
| by 0x56EBD8C: g_free (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x11DED0: remote_viewer_session_connected (remote-viewer.c:658)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566AF68: g_signal_emit_by_name (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x135E5D: virt_viewer_session_spice_main_channel_event (virt-viewer-session-spice.c:699)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x53149E3: emit_main_context (gio-coroutine.c:198)
| Address 0x18f1ecc0 is 0 bytes inside a block of size 23 free'd
| at 0x4839A0C: free (vg_replace_malloc.c:540)
| by 0x56EBD8C: g_free (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x11DED0: remote_viewer_session_connected (remote-viewer.c:658)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566AF68: g_signal_emit_by_name (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x135E5D: virt_viewer_session_spice_main_channel_event (virt-viewer-session-spice.c:699)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x56614F3: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x53149E3: emit_main_context (gio-coroutine.c:198)
| Block was alloc'd at
| at 0x483880B: malloc (vg_replace_malloc.c:309)
| by 0x56EBC98: g_malloc (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x5705C43: g_strdup (in /usr/lib64/libglib-2.0.so.0.6000.6)
| by 0x11EB80: remote_viewer_initial_connect (remote-viewer.c:696)
| by 0x11EB80: remote_viewer_start (remote-viewer.c:790)
| by 0x1250D3: virt_viewer_app_start (virt-viewer-app.c:1727)
| by 0x127108: virt_viewer_app_on_application_startup (virt-viewer-app.c:1870)
| by 0x564D741: g_closure_invoke (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x5661638: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A34D: g_signal_emit_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x566A972: g_signal_emit (in /usr/lib64/libgobject-2.0.so.0.6000.6)
| by 0x553ECA1: g_application_register (in /usr/lib64/libgio-2.0.so.0.6000.6)
| by 0x553F41D: g_application_run (in /usr/lib64/libgio-2.0.so.0.6000.6)
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Error caught by valgrind, the OvirtCollection object created in function
ovirt_foreign_menu_fetch_vm_async() was never freed.
433 (40 direct, 393 indirect) bytes in 1 blocks are definitely lost in loss record 16,708 of 17,677
at 0x5868FDF: g_type_create_instance (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x584B42C: ??? (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x584D347: g_object_new_valist (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x584D69C: g_object_new (in /usr/lib64/libgobject-2.0.so.0.6000.6)
by 0x558E823: ovirt_collection_new (ovirt-collection.c:304)
by 0x558E98C: ovirt_sub_collection_new_from_resource_search (ovirt-collection.c:375)
by 0x42D510: ovirt_foreign_menu_fetch_vm_async (ovirt-foreign-menu.c:994)
by 0x42D510: ovirt_foreign_menu_next_async_step (ovirt-foreign-menu.c:316)
by 0x42D70D: api_fetched_cb (ovirt-foreign-menu.c:1025)
by 0x570BC19: ??? (in /usr/lib64/libgio-2.0.so.0.6000.6)
by 0x570C7EC: ??? (in /usr/lib64/libgio-2.0.so.0.6000.6)
by 0x559005D: call_async_cb (ovirt-proxy.c:279)
by 0x55B5A07: ??? (in /usr/lib64/librest-0.7.so.0.0.0)
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
In the case of having a valid storage domain without any ISO files, this
variable can be reset to FALSE again in the next iteration of the loop,
resulting in a misleading error message presented to the user.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
gmaovirt-foreign-menu.c: In function 'storage_domains_fetched_cb':
ovirt-foreign-menu.c:721:9: error: format not a string literal and no format arguments [-Werror=format-security]
721 | g_debug(msg);
| ^~~~~~~
ovirt-foreign-menu.c:722:9: error: format not a string literal and no format arguments [-Werror=format-security]
722 | g_task_return_new_error(task, OVIRT_ERROR, OVIRT_ERROR_FAILED, msg);
| ^~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
gmake[3]: *** [Makefile:963: libvirt_viewer_la-ovirt-foreign-menu.lo] Error 1
gmake[2]: *** [Makefile:647: all] Error 2
gmake[1]: *** [Makefile:482: all-recursive] Error 1
make: *** [Makefile:410: all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.f14Lmj (%build)
Errors have been caught by https://ci.centos.org/job/virt-viewer-rpm/systems=libvirt-fedora-rawhide/589/
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Instead of fetching toplevel REST API query, we use the one relative
from the data center, which returns more detailed information,
especially the status of the storage domain.
This fixes https://bugzilla.redhat.com/show_bug.cgi?id=1427467
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
This patch improves the error shown to the user when a file transfer
fails.
The previous behavior was to create a simple message dialog box, with
the error description and the full list of the files that failed to be
transferred. When the list of files was long, the dialog box would
grow bigger than the screen.
Now, the file list is inserted inside a scrollable widget, whose
height is limited to 170px.
NB: these two calls would be more adapted, but they require GTK >=
3.22:
> gtk_scrolled_window_set_max_content_height(GTK_SCROLLED_WINDOW(scrolled_window), 170);
> gtk_scrolled_window_set_propagate_natural_height(GTK_SCROLLED_WINDOW(scrolled_window), TRUE);
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1496356
Signed-off-by: Kevin Pouget <kpouget@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
With this change one can get list of domains on the command line:
$ virt-viewer -c qemu:///system <TAB><TAB>
dom1 dom2 ... domN
The list of domains is fetched using virsh, hence the dependency
on libvirt-client recorded in the spec file. I think it's fair
to assume that Linux hosts with virt-viewer will have virsh
available too. If they don't, nothing breaks and no error message
is printed.
The completer script is inspired by libvirt.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com>
Reviewed-by: Jonathon Jongsma <jjongsma@redhat.com>
Use saved CFLAGS and LIBS to avoid errors in the check programs.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Due to changes in commit 65ef66e4, when the initial connection fails,
virt-viewer just sat quietly and didn't indicate what was wrong. It also
did not exit as it did before. This is because we were using
virt_viewer_session_spice_channel_destroy() incorrectly. This function
was intended to be a callback that is called to clean up the VV session
when the SpiceSession tells us that a channel has been destroyed. It
does not actually destroy the channel, it only cleans up references to
that channel within virt-viewer. After calling this function, the
channel is not affected in any way. If the channel object was valid
before calling the function, it will be valid and unchanged after
calling the function as well.
The problem is that before commit 65ef66e4, this function
(_channel_destroy()) also had a side-effect of emitting a signal that
made us think that the SpiceSession was disconnected when it was not.
The application responded to this signal by exiting even though the
session was not properly disconnected and cleaned up.
We now no longer exit the application until the SpiceSession is properly
disconnected and cleaned up. So we need to make sure that this happens
when our initial connection fails. Therefore, when the main channel
receives an error channel-event, we should not call
virt_viewer_session_spice_channel_destroy(). This function should only
be called when a channel has actually been destroyed, and the channel is
not destroyed at this point. We should instead explicitly disconnect
the session, which will result in the channels being destroyed properly.
After the session destroys all of the channels, the 'channel-destroy' signal
will be emitted by SpiceSession, so the _channel_destroy() function will
eventually get called by the signal handler.
To make the proper use of the function more obvious, I also changed the
function name from _channel_destroy() to _channel_destroyed() and added
a comment.
Fixes: rhbz#1666869
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Similar to the virt-viewer.pot, .po files contain line numbers and file
names identifying where in the source a translatable string comes from.
The source locations in the .po files are thrown away and replaced with
content from the virt-viewer.pot whenever msgmerge is run, so this is not
precious information that needs to be stored in git.
When msgmerge processes a .po file, it will add in any msgids from the
virt-viewer.pot that were not already present. Thus, if a particular msgid
currently has no translation, it can be considered redundant and again
does not need storing in git.
When msgmerge processes a .po file and can't find an exact existing
translation match, it will try todo fuzzy matching instead, marking such
entries with a "# fuzzy" comment to alert the translator to take a
look and either discard, edit or accept the match. Looking at the
existing fuzzy matches in .po files shows that the quality is awful,
with many having a completely different set of printf format specifiers
between the msgid and fuzzy msgstr entry. Fortunately when msgfmt
generates the .gmo, the fuzzy entries are all ignored anyway. The fuzzy
entries could be useful to translators if they were working on the .po
files directly from git, but Virt-Viewer outsourced translation to the
Fedora Zanata system, so keeping fuzzy matches in git is not much help.
Finally, by default msgids are sorted based on source location. Thus, if
a bit of code with translatable text is moved from one file to another,
it may shift around in the .po file, despite the msgid not itself changing.
If the msgids were sorted alphabetically, the .po files would have
stable ordering when code is refactored.
This patch takes advantage of the above observations to canonicalize
and minimize the content stored for .po files in git. Instead of storing
the real .po files, we now store .mini.po files.
The .mini.po files are the same file format as .po files, but have no
source location comments, are sorted alphabetically, and all fuzzy
msgstrs and msgids with no translation are discarded. This cuts the size
of content in the po directory.
Users working from a virt-viewer git checkout who need the full .po files
can run "make update-po", which merges the virt-viewer.pot and .mini.po
file to create a .po file containing all the content previously stored
in git.
Conversely if a full .po file has been modified, for example, by
downloading new content from Zanata, the .mini.po files can be updated
by running "make update-mini-po". The resulting diffs of the .mini.po
file will clearly show the changed translations without any of the noise
that previously obscured content. Being able to see content changes
clearly actually identified a bug in the zanata python client where it
was adding bogus "fuzzy" annotations to many messages:
https://bugzilla.redhat.com/show_bug.cgi?id=1564497
Users working from virt-viewer releases should not see any difference in
behaviour, since the tarballs only contain the full .po files, not the
.mini.po files.
As an added benefit, generating tarballs with "make dist", will no
longer cause creation of dirty files in git, since it won't touch the
.mini.po files, only the .po files which are no longer kept in git.
The languages are minimized in the following commit since it is a
large mechanical process.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add rules to handle pushing virt-viewer.pot to zanata, and refreshing .po
files with new content from zanata.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The <locales> element in zanata.xml is no longer relevant as this info
is recorded server side.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically we have relied on intltool to install a standard
po/Makefile.in.in which has very limited scope for customization.
intltool is deprecated in favour of standard gettextize tools,
but these share the same disadvantages.
Writing make rules for po file management is no more difficult
than any other rules virt-viewer has, so stop using intltool
and don't use gettextize ether.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The native glib2-devel package is needed for mingw builds in order to
get the glib-compile-schemas binary.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no reason for this object to define a private structure, so it
is fine to make everything private to the dialog itself.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
For proper compliance with the GPL and other licenses we need to be
clear about exactly what toolchain and dependent packages we used in
order to build the MSI installer we distribute.
Historically we've done this by including a "deps.txt" file which
provides a list of all the mingw{32,64}-* RPMs on the host system.
This is not sufficient information, however, because the build system
will in fact use various native packages too from the toolchain too,
notably including any program run by "configure" which covers various
shell utilities, and pkg-config, and then of course make & msitools
itself.
Rather than try to figure out which subset of host RPMs are used,
just list every single host RPM that is installed.
A key implication of this is that formal release builds should always
be done in a pristine build root populated with the minimal content
required for the build.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
