Open in DispVM doesn't work for PDF files

[rootkovska]

It works for many other files. But when sending a PDF to open I'm consistently getting an error about not being able to find the proper MIME handler. My DispVM is based on fc23. Fresh 3.1-rc2.

[adrelanos]

Confirmed. Does not work for me in Debian based DispVMs either.

[adrelanos]

Confirmed. Does not work for me in Debian based DispVMs either.

[marmarek]

It looks to be two separate issues for Debian and Fedora

Fedora

The default application is evince-previewer (aka "Print Preview"), which fails with:

$ mimeopen -n test.pdf
Opening "test.pdf" with Print Preview  (application/pdf)
Filename "file:///home/user/test.pdf" does not exist or is not a regular file

Probably we should somehow blacklist evince-previewer, or sth (we can't uninstall it as it is the same package as actual evince)

Debian

There is no PDF viewer installed at all. evince weight 10MB. Probably worth it, to have this basic functionality...

[marmarek]

It looks to be two separate issues for Debian and Fedora

Fedora

The default application is evince-previewer (aka "Print Preview"), which fails with:

$ mimeopen -n test.pdf
Opening "test.pdf" with Print Preview  (application/pdf)
Filename "file:///home/user/test.pdf" does not exist or is not a regular file

Probably we should somehow blacklist evince-previewer, or sth (we can't uninstall it as it is the same package as actual evince)

Debian

There is no PDF viewer installed at all. evince weight 10MB. Probably worth it, to have this basic functionality...

[marmarek]

And BTW, after installing evince in Debian template, it fails the same way as in Fedora...

[marmarek]

And BTW, after installing evince in Debian template, it fails the same way as in Fedora...

[adrelanos]

I have some minimal experience with default applications and mime types on Debian.

• https://github.com/Whonix/tb-default-browser
• https://github.com/Whonix/tb-default-browser/blob/master/debian/tb-default-browser.mime
• https://github.com/Whonix/tb-default-browser/blob/master/debian/tb-default-browser.menu
• Whonix/tb-starter@064fedc
• Whonix/tb-starter@e6d005a
• The file that matters is /usr/share/applications/mimeinfo.cache.
• cat /usr/share/applications/mimeinfo.cache | grep pdf

[adrelanos]

I have some minimal experience with default applications and mime types on Debian.

• https://github.com/Whonix/tb-default-browser
• https://github.com/Whonix/tb-default-browser/blob/master/debian/tb-default-browser.mime
• https://github.com/Whonix/tb-default-browser/blob/master/debian/tb-default-browser.menu
• Whonix/tb-starter@064fedc
• Whonix/tb-starter@e6d005a
• The file that matters is /usr/share/applications/mimeinfo.cache.
• cat /usr/share/applications/mimeinfo.cache | grep pdf

[adrelanos]

Luckily mime priority looks good. (Otherwise increasing the mime priority would not be trivial as writing to /usr/share/applications/mimeinfo.cache directly would perhaps not be a clean/robust solution.)

Is there any reason to stick to mimeopen? After installing evince on debian, xdg-open /path/to/some/file.pdf worked for me, opened the file in evince.

[adrelanos]

Luckily mime priority looks good. (Otherwise increasing the mime priority would not be trivial as writing to /usr/share/applications/mimeinfo.cache directly would perhaps not be a clean/robust solution.)

Is there any reason to stick to mimeopen? After installing evince on debian, xdg-open /path/to/some/file.pdf worked for me, opened the file in evince.

[marmarek]

I remember we've considered it in the past and it fixes some issues, while introducing others. The only thing I can find about it in issues is here: #66

Anyway if xdg-open works for more cases than mimeopen, I think it may be good idea to switch.

[marmarek]

I remember we've considered it in the past and it fixes some issues, while introducing others. The only thing I can find about it in issues is here: #66

Anyway if xdg-open works for more cases than mimeopen, I think it may be good idea to switch.

[adrelanos]

Interestingly, see what xdg-open, which is a shell script, is just doing.

bash -x xdg-open /path/to/file.pdf

It internally uses mimeopen. But it works better. Somehow.

[adrelanos]

Interestingly, see what xdg-open, which is a shell script, is just doing.

bash -x xdg-open /path/to/file.pdf

It internally uses mimeopen. But it works better. Somehow.

[marmarek]

Ok, I've tried on fresh R3.1-rc2 install, Debian template:

1. At first (after installing xdg-utils) it fails with gnome-open: not found. Apparently because of QubesOS/qubes-gui-agent-linux@524fb45
2. When unset GNOME_DESKTOP_SESSION_ID, it calls mimeopen, which then calls evince-previewer (instead of evince), at first it fails with Filename file:///home/user/test.pdf" does not exist or is not a regular file, but for some reason then it displays the pdf then.

On Fedora template, indeed it opens PDF using evince.

Test cases which were problematic in the past:

• pdf
• doc
• pptx
• png
• jpg (.jpg and .jpeg`)
• txt (yes, really!)

[marmarek]

Ok, I've tried on fresh R3.1-rc2 install, Debian template:

1. At first (after installing xdg-utils) it fails with gnome-open: not found. Apparently because of QubesOS/qubes-gui-agent-linux@524fb45
2. When unset GNOME_DESKTOP_SESSION_ID, it calls mimeopen, which then calls evince-previewer (instead of evince), at first it fails with Filename file:///home/user/test.pdf" does not exist or is not a regular file, but for some reason then it displays the pdf then.

On Fedora template, indeed it opens PDF using evince.

Test cases which were problematic in the past:

• pdf
• doc
• pptx
• png
• jpg (.jpg and .jpeg`)
• txt (yes, really!)

[marmarek]

Solved mystery of mimeopen (but not the problem itself). Default application is chosen based on:

• $HOME/.local/share/applications/defaults.list (if present)
• order of entries in /usr/share/applications/mimeinfo.cache for a given file type (first one wins)

There is no support for any global defaults list (like /usr/share/applications/defaults.list). mimeinfo.cache is generated by update-desktop-database tool, order of entries for a given mime type depends on... order of files in the filesystem.

This isn't the first time we have such problem with mimeopen: #423

Lets consider switching to some other tool (xdg-open) again. It is basically a wrapper for different tools for opening files, the algorithm is:

1. If some specific desktop environment is detected, use a tool specific to that environment (gvfs-open/gnome-open, kde-open, exo-open, enlightenment_open, etc)
2. Otherwise, try the following tools, in order:
   • xdg-mime query default (uses /usr/share/applications/mimeapps.list - another file with preferred applications, then fallbacks to defaults.list - handle both user home and global one in /usr/share/applications)
   • run-mailcap
   • mimeopen (Debian xdg-utils package has a patch to prefer mimeopen over run-mailcap)

This results is:

1. Fedora:
   • in default install uses gvfs-open, which correctly uses evince
   • after unsetting $GNOME_DESKTOP_SESSION_ID - uses xdg-mime query default and mimeapps.list does contain evince.desktop for application/pdf so it is used
2. Debian:
   • by default tries to call gvfs-open, then gnome-open - none of them are installed, so it fails (BTW xdg-utils-1.1.1 has a fallback to generic open in that case, but Debian package is too old for that)
   • after unsetting $GNOME_DESKTOP_SESSION_ID:
     • tries xdg-mime query default, but none is set
     • calls mimeopen - which fails (the original problem reported in this ticket - usage of evince-previewer instead of evince)
     • finally calls run-mailcap, which properly calls evince

All of this looks like a big mess... And that is only for PDF, haven't checked other file types.

This is probably the worst time for switching to another tool here, but not sure if some ugly workaround would be better (like messing with defaults.list in user home directory)? Or maybe I'm missing something?

Some other option would be writing own tool for that (which probably would use xdg-mime). But I doubt we are smart enough to cover all the corner cases (apparently lots of people failed here). I guess it would be rather just another buggy tool...

[marmarek]

Solved mystery of mimeopen (but not the problem itself). Default application is chosen based on:

• $HOME/.local/share/applications/defaults.list (if present)
• order of entries in /usr/share/applications/mimeinfo.cache for a given file type (first one wins)

There is no support for any global defaults list (like /usr/share/applications/defaults.list). mimeinfo.cache is generated by update-desktop-database tool, order of entries for a given mime type depends on... order of files in the filesystem.

This isn't the first time we have such problem with mimeopen: #423

Lets consider switching to some other tool (xdg-open) again. It is basically a wrapper for different tools for opening files, the algorithm is:

1. If some specific desktop environment is detected, use a tool specific to that environment (gvfs-open/gnome-open, kde-open, exo-open, enlightenment_open, etc)
2. Otherwise, try the following tools, in order:
   • xdg-mime query default (uses /usr/share/applications/mimeapps.list - another file with preferred applications, then fallbacks to defaults.list - handle both user home and global one in /usr/share/applications)
   • run-mailcap
   • mimeopen (Debian xdg-utils package has a patch to prefer mimeopen over run-mailcap)

This results is:

1. Fedora:
   • in default install uses gvfs-open, which correctly uses evince
   • after unsetting $GNOME_DESKTOP_SESSION_ID - uses xdg-mime query default and mimeapps.list does contain evince.desktop for application/pdf so it is used
2. Debian:
   • by default tries to call gvfs-open, then gnome-open - none of them are installed, so it fails (BTW xdg-utils-1.1.1 has a fallback to generic open in that case, but Debian package is too old for that)
   • after unsetting $GNOME_DESKTOP_SESSION_ID:
     • tries xdg-mime query default, but none is set
     • calls mimeopen - which fails (the original problem reported in this ticket - usage of evince-previewer instead of evince)
     • finally calls run-mailcap, which properly calls evince

All of this looks like a big mess... And that is only for PDF, haven't checked other file types.

This is probably the worst time for switching to another tool here, but not sure if some ugly workaround would be better (like messing with defaults.list in user home directory)? Or maybe I'm missing something?

Some other option would be writing own tool for that (which probably would use xdg-mime). But I doubt we are smart enough to cover all the corner cases (apparently lots of people failed here). I guess it would be rather just another buggy tool...

[adrelanos]

I think the only way to do-this-right(tm) [without opening up for
maintenance hell and new issues] is to report these issues upstream in
generic terms. Then either waiting or applying their patches.

[adrelanos]

I think the only way to do-this-right(tm) [without opening up for
maintenance hell and new issues] is to report these issues upstream in
generic terms. Then either waiting or applying their patches.

[marmarek]

Apparently mimeapps.list is a standard: http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html

Regarding global preferences in mimeopen: mbeijen/File-MimeInfo#20
There is also a bug about using mimeapps.list instead of non-standard defaults.list (mbeijen/File-MimeInfo#8), but apparently it is already implemented (in libxml branch, not master yet).

In Fedora those problems would be solved by switching to xdg-open, which use xdg-mime (so mimeapps.list, including global one), even in case of $GNOME_DESKTOP_SESSION_ID being set but no gvfs-open installed (for example in minimal template).

Regarding Debian problems - almost all of them (besides above mimeopen issue) are solved in xdg-utils-1.1.1, while Debian 8 have xdg-utils-1.1.0-rc1 (so not even 1.1.0 as I thought). AFAIR Debian policy forbids package updates other than security fixes in stable release, am I right @adrelanos ? In that case there is no way to fix the issue in Debian, other than some local workaround, or maintaining xdg-utils backport (both options are not great). Debian 9 (stretch) already have xdg-utils-1.1.1. But obviously waiting for it (with R3.1 stable release) is not an option.

[marmarek]

Apparently mimeapps.list is a standard: http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-1.0.html

Regarding global preferences in mimeopen: mbeijen/File-MimeInfo#20
There is also a bug about using mimeapps.list instead of non-standard defaults.list (mbeijen/File-MimeInfo#8), but apparently it is already implemented (in libxml branch, not master yet).

In Fedora those problems would be solved by switching to xdg-open, which use xdg-mime (so mimeapps.list, including global one), even in case of $GNOME_DESKTOP_SESSION_ID being set but no gvfs-open installed (for example in minimal template).

Regarding Debian problems - almost all of them (besides above mimeopen issue) are solved in xdg-utils-1.1.1, while Debian 8 have xdg-utils-1.1.0-rc1 (so not even 1.1.0 as I thought). AFAIR Debian policy forbids package updates other than security fixes in stable release, am I right @adrelanos ? In that case there is no way to fix the issue in Debian, other than some local workaround, or maintaining xdg-utils backport (both options are not great). Debian 9 (stretch) already have xdg-utils-1.1.1. But obviously waiting for it (with R3.1 stable release) is not an option.

[adrelanos]

Marek Marczykowski-Górecki:

AFAIR
Debian policy forbids package updates other than security fixes in
stable release, am I right @adrelanos ?

Right. [For completeness sake: There might have been an exception
sometime somehwere irrc packages that are otherwise not maintainable -
namely iceweasel or so. But no hope for this case.]

[adrelanos]

Marek Marczykowski-Górecki:

AFAIR
Debian policy forbids package updates other than security fixes in
stable release, am I right @adrelanos ?

Right. [For completeness sake: There might have been an exception
sometime somehwere irrc packages that are otherwise not maintainable -
namely iceweasel or so. But no hope for this case.]

[marmarek]

Hmm, what about creating qubes-open script which would call appropriate tool (like mimeopen or xdg-open)? Having it as a script, instead of hardcoded into /usr/lib/qubes/vm-file-editor (binary program) would make it much easier to customize and test new solutions. Or even different implementations for different distributions.

[marmarek]

Hmm, what about creating qubes-open script which would call appropriate tool (like mimeopen or xdg-open)? Having it as a script, instead of hardcoded into /usr/lib/qubes/vm-file-editor (binary program) would make it much easier to customize and test new solutions. Or even different implementations for different distributions.

[adrelanos]

Yes. Wondering, why /usr/lib/qubes/vm-file-editor is a compiled program
anyhow?

[adrelanos]

Yes. Wondering, why /usr/lib/qubes/vm-file-editor is a compiled program
anyhow?

[marmarek]

Wondering, why /usr/lib/qubes/vm-file-editor is a compiled program anyhow?

To handle qfile-format input stream (binary header, no need to parse anything, just load into struct and use). Probably also possible in python or such, but not sure if easier.

[marmarek]

Wondering, why /usr/lib/qubes/vm-file-editor is a compiled program anyhow?

To handle qfile-format input stream (binary header, no need to parse anything, just load into struct and use). Probably also possible in python or such, but not sure if easier.

[marmarek]

Hmm, actually here is only simplified version of that protocol (just filename, without file attributes). @woju what do you think about converting it into python script (in R4.0)?

[marmarek]

Hmm, actually here is only simplified version of that protocol (just filename, without file attributes). @woju what do you think about converting it into python script (in R4.0)?

[marmarek]

Created some tests for opening different file types. Two types of failures:

1. Really not installed applications (intentional):

• Debian: no PDF viewer, no LibreOffice
• Fedora: no LibreOffice (doc and pptx fails)
  1. Wrong application chosen/failed to open file at all:
• Debian: txt opened with LibreOffice (when installed) - overkill? ; fail to open pdf
• Fedora - fail to open txt and pdf via qvm-open-in-vm but succeed via qvm-open-in-dvm (?!)

There are some minor differences between versions - for example in Debian 7 template opening txt files works properly, in one of Fedora 23 templates all is ok. Those templates are not exactly clean R3.1 install (some of them are upgraded from R3.0).

[marmarek]

Created some tests for opening different file types. Two types of failures:

1. Really not installed applications (intentional):

• Debian: no PDF viewer, no LibreOffice
• Fedora: no LibreOffice (doc and pptx fails)
  1. Wrong application chosen/failed to open file at all:
• Debian: txt opened with LibreOffice (when installed) - overkill? ; fail to open pdf
• Fedora - fail to open txt and pdf via qvm-open-in-vm but succeed via qvm-open-in-dvm (?!)

There are some minor differences between versions - for example in Debian 7 template opening txt files works properly, in one of Fedora 23 templates all is ok. Those templates are not exactly clean R3.1 install (some of them are upgraded from R3.0).

[marmarek]

xdg-open solves some of the problems with qvm-open-in-vm (non-DisposableVM), but completely breaks qvm-open-in-dvm (DisposableVM). Generally because it doesn't wait for the editor to finish. So when xdg-open exits, it doesn't mean user has closed the editor. But after "editor process" (which is xdg-open in this case) is terminated, DisposableVM is destroyed.

This is somehow generic problem with things like D-Bus activation (used by gvfs-open called from xdg-open here). It affects also some other use cases (email client removes temporary saved attachment file after viewer app is closed):

• https://bugzilla.redhat.com/show_bug.cgi?id=653249
• https://bugzilla.gnome.org/show_bug.cgi?id=652262

There is workaround for this is in the first link - set DE=generic to not use any environment-specific tool (even when available) and force usage of xdg-mime and application call directly from xdg-open. Generally it works - the only failure I've got then, is opening txt with LibreOffice. I think it shouldn't be even considered a failure.

But the problem will return, once more and more applications will use D-Bus activation. The issue is already discussed in the second link - an API for notification about application close. But the discussion stalled about a year ago...

[marmarek]

xdg-open solves some of the problems with qvm-open-in-vm (non-DisposableVM), but completely breaks qvm-open-in-dvm (DisposableVM). Generally because it doesn't wait for the editor to finish. So when xdg-open exits, it doesn't mean user has closed the editor. But after "editor process" (which is xdg-open in this case) is terminated, DisposableVM is destroyed.

This is somehow generic problem with things like D-Bus activation (used by gvfs-open called from xdg-open here). It affects also some other use cases (email client removes temporary saved attachment file after viewer app is closed):

• https://bugzilla.redhat.com/show_bug.cgi?id=653249
• https://bugzilla.gnome.org/show_bug.cgi?id=652262

There is workaround for this is in the first link - set DE=generic to not use any environment-specific tool (even when available) and force usage of xdg-mime and application call directly from xdg-open. Generally it works - the only failure I've got then, is opening txt with LibreOffice. I think it shouldn't be even considered a failure.

But the problem will return, once more and more applications will use D-Bus activation. The issue is already discussed in the second link - an API for notification about application close. But the discussion stalled about a year ago...

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc21 has been pushed to the r3.1 testing repository for the Fedora fc21 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc22 has been pushed to the r3.1 testing repository for the Fedora fc22 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc22 has been pushed to the r3.1 testing repository for the Fedora fc22 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc23 has been pushed to the r3.1 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc23 has been pushed to the r3.1 testing repository for the Fedora fc23 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r3.1-current-testing

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb8u1 has been pushed to the r3.1 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb8u1 has been pushed to the r3.1 testing repository for the Debian jessie template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing jessie-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb9u1 has been pushed to the r3.1 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb9u1 has been pushed to the r3.1 testing repository for the Debian stretch template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing stretch-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb7u1 has been pushed to the r3.1 testing repository for the Debian wheezy template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing wheezy-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb7u1 has been pushed to the r3.1 testing repository for the Debian wheezy template.
To test this update, first enable the testing repository in /etc/apt/sources.list.d/qubes-*.list by uncommenting the line containing wheezy-testing, then use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc21 has been pushed to the r3.1 stable repository for the Fedora fc21 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc21 has been pushed to the r3.1 stable repository for the Fedora fc21 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc22 has been pushed to the r3.1 stable repository for the Fedora fc22 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc22 has been pushed to the r3.1 stable repository for the Fedora fc22 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc23 has been pushed to the r3.1 stable repository for the Fedora fc23 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package python2-dnf-plugins-qubes-hooks-3.1.13-1.fc23 has been pushed to the r3.1 stable repository for the Fedora fc23 template.
To install this update, please use the standard update command:

sudo yum update

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb8u1 has been pushed to the r3.1 stable repository for the Debian jessie template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb8u1 has been pushed to the r3.1 stable repository for the Debian jessie template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb9u1 has been pushed to the r3.1 stable repository for the Debian stretch template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb9u1 has been pushed to the r3.1 stable repository for the Debian stretch template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb7u1 has been pushed to the r3.1 stable repository for the Debian wheezy template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[marmarek]

Automated announcement from builder-github

The package qubes-core-agent_3.1.13-1+deb7u1 has been pushed to the r3.1 stable repository for the Debian wheezy template.
To install this update, please use the standard update command:

sudo apt-get update && sudo apt-get dist-upgrade

Changes included in this update

[unman]

@marmarek
I've just pulled down and installed the fedora-23 template and it is still showing this behavior. That template has version 3.0.4-201601120722, so I guess the repo needs to be refreshed.

[unman]

@marmarek
I've just pulled down and installed the fedora-23 template and it is still showing this behavior. That template has version 3.0.4-201601120722, so I guess the repo needs to be refreshed.

[marmarek]

@unman did you installed updates after fetching that template?

[marmarek]

@unman did you installed updates after fetching that template?

[unman]

@marmarek No - my point is that it seems strange that the repo doesn't have an up to date template incorporating fixes, and that one has to do an immediate update. (Yes, installing the updates fixes the issue.)

[unman]

@marmarek No - my point is that it seems strange that the repo doesn't have an up to date template incorporating fixes, and that one has to do an immediate update. (Yes, installing the updates fixes the issue.)

[marmarek]

This isn't anything strange - it is exactly the same with any other Linux distribution, or even different OS (like Windows) - when you install OS, you get package versions from the time of release, even if it is a year(s) ago.

[marmarek]

This isn't anything strange - it is exactly the same with any other Linux distribution, or even different OS (like Windows) - when you install OS, you get package versions from the time of release, even if it is a year(s) ago.

[unman]

I understand this, of course. But this is a package in the repository and people who get it from there would expect it to be more up to date imo. That is, they wouldn't expect the repository to hold out of date packages, and the templates are just packages.
Not a big issue though.

[unman]

I understand this, of course. But this is a package in the repository and people who get it from there would expect it to be more up to date imo. That is, they wouldn't expect the repository to hold out of date packages, and the templates are just packages.
Not a big issue though.