Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDebian Template: in place update ('apt-get dist-upgrade') leads to broken X server #1095
Comments
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Jul 31, 2015
Member
Looks like X server is started by some native Debian service (looking at
config file used), not qubes-gui-agent. Try to find out which one and
disable it. How properly blacklist such services in Debian?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Looks like X server is started by some native Debian service (looking at Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 1, 2015
Member
How do I do that? I tried echoing $(pstree) for the /usr/bin/Xorg
binary, but that didn't reveal by whom it was started.
kdm, lightdm, gdm, xdm, etc. could be it. I am not aware of other
starting X. Since only kdm is installed, I systemctl mastedk kdm.
Still no desktop after shutdown/start VM.
Also no X server was was started. (Exited.) So I should be able to
manually start qubes-gui-agent?
Can I try to manually start qubes-gui-agent to get further debug output?
systemd reports qubes-gui-agent is running. (But not working.)
|
How do I do that? I tried echoing $(pstree) for the /usr/bin/Xorg kdm, lightdm, gdm, xdm, etc. could be it. I am not aware of other Still no desktop after shutdown/start VM. Also no X server was was started. (Exited.) So I should be able to Can I try to manually start qubes-gui-agent to get further debug output? systemd reports qubes-gui-agent is running. (But not working.) |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 1, 2015
Member
First of all you can access VM console using sudo xl console VMNAME.
This should ease debugging.
When you find out what starts X server (and disable it), try to restart
qubes-gui-agent - it should automatically start its own instance (using
the right config file).
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
First of all you can access VM console using When you find out what starts X server (and disable it), try to restart Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 1, 2015
Member
Thart helps with debugging indeed.
I deleted the X log /var/log/Xorg.0.log. No new X log is being created. It was only created by mistake by me since I tried manually starting kdm for debugging. So it looks like nothing is starting X.
Yet, same gui app start issue. Any idea?
|
Thart helps with debugging indeed. I deleted the X log Yet, same gui app start issue. Any idea? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 1, 2015
Member
Do you have any X server running in that VM? Check /tmp for X log (when
X server is started as non-root user, the log is there). It should be
started by gui-agent. If not - you should see some info in logs
(journalctl, systemctl status qubes-gui-agent).
Check also ~user/.xsession-errors.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Do you have any X server running in that VM? Check /tmp for X log (when Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 1, 2015
Member
Does the following help?
/tmp/Xorg.0.log:
[ 3.412]
X.Org X Server 1.16.4
Release Date: 2014-12-20
[ 3.412] X Protocol Version 11, Revision 0
[ 3.412] Build Operating System: Linux 3.16.0-4-amd64 x86_64 Debian
[ 3.412] Current Operating System: Linux host 3.18.17-5.pvops.qubes.x86_64 #1 SMP Sun Jul 12 23:43:31 UTC 2015 x86_64
[ 3.412] Kernel command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH 3 nopat
[ 3.412] Build Date: 11 February 2015 12:32:02AM
[ 3.412] xorg-server 2:1.16.4-1 (http://www.debian.org/support)
[ 3.412] Current version of pixman: 0.32.6
[ 3.412] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 3.412] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 3.412] (++) Log file: "/tmp/Xorg.0.log", Time: Sat Aug 1 23:20:22 2015
[ 3.413] (++) Using config file: "/etc/X11/xorg-qubes.conf"
[ 3.413] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[ 3.413] (==) ServerLayout "Default Layout"
[ 3.413] (**) |-->Screen "Screen0" (0)
[ 3.413] (**) | |-->Monitor "Monitor0"
[ 3.414] (**) | |-->Device "Videocard0"
[ 3.414] (**) |-->Input Device "qubesdev"
[ 3.414] (==) Automatically adding devices
[ 3.414] (==) Automatically enabling devices
[ 3.414] (==) Automatically adding GPU devices
[ 3.414] (WW) The directory "/usr/share/fonts/X11/misc" does not exist.
[ 3.414] Entry deleted from font path.
[ 3.414] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[ 3.414] Entry deleted from font path.
[ 3.414] (==) FontPath set to:
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 3.414] (==) ModulePath set to "/usr/lib/xorg/modules"
[ 3.414] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 3.415] (II) Loader magic: 0x7f0c2ebead80
[ 3.415] (II) Module ABI versions:
[ 3.415] X.Org ANSI C Emulation: 0.4
[ 3.415] X.Org Video Driver: 18.0
[ 3.415] X.Org XInput driver : 21.0
[ 3.415] X.Org Server Extension : 8.0
[ 3.415] (II) no primary bus or device found
[ 3.415] (II) LoadModule: "glx"
[ 3.416] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 3.420] (II) Module glx: vendor="X.Org Foundation"
[ 3.420] compiled for 1.16.4, module version = 1.0.0
[ 3.420] ABI class: X.Org Server Extension, version 8.0
[ 3.420] (==) AIGLX enabled
[ 3.420] (II) LoadModule: "dummyqbs"
[ 3.420] (II) Loading /usr/lib/xorg/modules/drivers/dummyqbs_drv.so
[ 3.420] (II) Module dummyqbs: vendor="X.Org Foundation"
[ 3.420] compiled for 1.12.4, module version = 0.3.6
[ 3.420] Module class: X.Org Video Driver
[ 3.420] ABI class: X.Org Video Driver, version 12.1
[ 3.420] (EE) module ABI major version (12) doesn't match the server's version (18)
[ 3.420] (II) UnloadModule: "dummyqbs"
[ 3.420] (II) Unloading dummyqbs
[ 3.420] (EE) Failed to load module "dummyqbs" (module requirement mismatch, 0)
[ 3.420] (II) LoadModule: "qubes"
[ 3.420] (II) Loading /usr/lib/xorg/modules/drivers/qubes_drv.so
[ 3.420] (II) Module qubes: vendor="X.Org Foundation"
[ 3.421] compiled for 1.12.4, module version = 0.0.1
[ 3.421] Module class: X.Org XInput Driver
[ 3.421] ABI class: X.Org XInput driver, version 16.0
[ 3.421] (EE) module ABI major version (16) doesn't match the server's version (21)
[ 3.421] (II) UnloadModule: "qubes"
[ 3.421] (II) Unloading qubes
[ 3.421] (EE) Failed to load module "qubes" (module requirement mismatch, 0)
[ 3.421] (EE) No drivers available.
[ 3.421] (EE)
Fatal server error:
[ 3.421] (EE) no screens found(EE)
[ 3.421] (EE)
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 3.421] (EE) Please also check the log file at "/tmp/Xorg.0.log" for additional information.
[ 3.421] (EE)
|
Does the following help?
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2015
Member
On Sat, Aug 01, 2015 at 04:25:16PM -0700, Patrick Schleizer wrote:
3.420 LoadModule: "dummyqbs"
3.420 Loading /usr/lib/xorg/modules/drivers/dummyqbs_drv.so
3.420 Module dummyqbs: vendor="X.Org Foundation"
[ 3.420] compiled for 1.12.4, module version = 0.3.6
[ 3.420] Module class: X.Org Video Driver
[ 3.420] ABI class: X.Org Video Driver, version 12.1
3.420 module ABI major version (12) doesn't match the server's version (18)
3.420 UnloadModule: "dummyqbs"
3.420 Unloading dummyqbs
3.420 Failed to load module "dummyqbs" (module requirement mismatch, 0)
3.420 LoadModule: "qubes"
3.420 Loading /usr/lib/xorg/modules/drivers/qubes_drv.so
3.420 Module qubes: vendor="X.Org Foundation"
[ 3.421] compiled for 1.12.4, module version = 0.0.1
[ 3.421] Module class: X.Org XInput Driver
[ 3.421] ABI class: X.Org XInput driver, version 16.0
3.421 module ABI major version (16) doesn't match the server's version (21)
3.421 UnloadModule: "qubes"
3.421 Unloading qubes
Ok, so here is the problem.
You have gui agent compiled for older Debian release, so it is compiled
for older X server. Note that there is no Qubes packages for stretch
(yet), at least no in our repository.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Sat, Aug 01, 2015 at 04:25:16PM -0700, Patrick Schleizer wrote:
Ok, so here is the problem. You have gui agent compiled for older Debian release, so it is compiled Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 2, 2015
Member
|
The log is actually from a wheezy -> jessie (Whonix) template.
(jessie has X 1.16, stretch has atm X 1.17)
Anyhow. Your explanation would explain why there are issues with
stretch. But not with wheezy.
The problem is, the system still had qubes-gui-agent 3.0.8+wheezy1
installed. And apt-get did not offer to install qubes-gui-agent
3.0.8+jessie1. Even 'sudo apt-get install --reinstall qubes-gui-agent'
did not work. (No issues with sources.list. Didn't forget to run 'sudo
apt-get update'.) Therefore manually 'apt-get purge'ed and re'apt-get
install'ed the package. That fixed the gui issues.
Same goes for other Qubes packages ('dpkg -l | grep qubes'). Still has
the wheezy versions installed. 'sudo apt-get install
qubes-core-agent=3.0.13+jessie1' works for forcing an upgrade. apt
thinks it's a downgrade.
So there is an issue with packaging and the repository here.
This is a Whonix templates in place update blocker.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2015
Member
Any ideas how to fix that? It looks like debian tools do not like the
same package version available for multiple debian releases - the same
issue applies to reprepro tool - it rejects to have the same package
version (but different builds) for different target distributions. This
is why +DIST suffix was added. @nrgaway, maybe you have some idea?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Any ideas how to fix that? It looks like debian tools do not like the Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 2, 2015
Member
Did you compile/build the jessie packages on jessie? While you can create a repository using wheezy to create jessie packages, I know this will be causing issues. Because while doing so, you will be using older wheezy based packaging tools. Not the supposed jessie based packaging tools. Then jessie's apt won't like this.
Not just the qubes* packages are affected, also the xen* specific ones.
I don't know the solution yet, but I know non-solutions to be avoided:
- apt preferences (hack, hated by Debian)
- Adding a +DIST suffix is non-standard. On my Debian jessie template with lots of packages, 'dpkg -l | grep jessie' reveals that exactly no other package is using +DIST suffix. Only qubes/xen ones. I suggest avoiding reinventing the wheel.
Okayish, workaround a like solution:
- Bumping the package's upstream version. But if neither upstream code nor Debian packaging code has changed, I don't know yet what the real, clean solution would be for just compiling/packaging the package for a newer suite (jessie).
Real solution:
- I suggest we find out how Debian deals with this. They have some older software, which was not updated during wheezy/jessie transition. Stlll same package version. Those are recompiled on new releases such as jessie. (So those are linked against updated libraries.) Example: pacman.
|
Did you compile/build the jessie packages on jessie? While you can create a repository using wheezy to create jessie packages, I know this will be causing issues. Because while doing so, you will be using older wheezy based packaging tools. Not the supposed jessie based packaging tools. Then jessie's apt won't like this. Not just the qubes* packages are affected, also the xen* specific ones. I don't know the solution yet, but I know non-solutions to be avoided:
Okayish, workaround a like solution:
Real solution:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2015
Member
On Sun, Aug 02, 2015 at 04:09:05AM -0700, Patrick Schleizer wrote:
Did you compile/build the jessie packages on jessie? While you can create a repository using wheezy to create jessie packages, I know this will be causing issues. Because while doing so, you will be using older wheezy based packaging tools. Not the supposed jessie based packaging tools. Then jessie's apt won't like this.
Of course - jessie packages are created in jessie environment.
Not just the qubes* packages are affected, also the xen* specific ones.
Probably every package build by us.
I don't know the solution yet, but I know non-solutions to be avoided:
- apt preferences (hack, hated by Debian)
- Adding a +DIST suffix is non-standard. On my Debian jessie template with lots of packages, 'dpkg -l | grep jessie' reveals that exactly no other package is using +DIST suffix. Only qubes/xen ones. I suggest avoiding reinventing the wheel.
+DIST suffix is used in Debian, for example for security updates - check
for example in squeeze. jessie uses +deb7 suffix - see below.
Answer here also suggests using revision number to insert debian release
version:
http://unix.stackexchange.com/questions/97289/debian-package-naming-convention
If you need to compile the same version of a package for multiple
distributions, you will change the version field (in the
debian/changelog and debian/control file). Some people use the
distribution name in the version field. for example openssl:0.9.8o-4squeeze14
1.0.1e-2+deb7u14
1.0.1k-1If that's what you want to do, make sure to read debian-policy about
debian_revision in version.
Maybe +debNUMBER would be better because of sorting (deb7 > deb6)? I
guess this is the problem with the current approach: squeeze < wheezy.
Okayish, workaround a like solution:
- Bumping the package's upstream version. But if neither upstream code nor Debian packaging code has changed, I don't know yet what the real, clean solution would be for just compiling/packaging the package for a newer suite (jessie).
This is very similar idea to the one with +debNUMBER.
Real solution:
- I suggest we find out how Debian deals with this. They have some older software, which was not updated during wheezy/jessie transition. Stlll same package version. Those are recompiled on new releases such as jessie. (So those are linked against updated libraries.) Example: pacman.
Are such packages really updated during in-place upgrade? Looks like the
version is exactly the same...
Fedora has 'yum distro-sync', which forces to install exactly the
versions of packages that are in configured repositories, even it that
means downgrade. But I don't see anything like this in Debian.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Sun, Aug 02, 2015 at 04:09:05AM -0700, Patrick Schleizer wrote:
Of course - jessie packages are created in jessie environment.
Probably every package build by us.
+DIST suffix is used in Debian, for example for security updates - check Answer here also suggests using revision number to insert debian release
Maybe +debNUMBER would be better because of sorting (deb7 > deb6)? I
This is very similar idea to the one with +debNUMBER.
Are such packages really updated during in-place upgrade? Looks like the Fedora has 'yum distro-sync', which forces to install exactly the Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 2, 2015
Member
Of course - jessie packages are created in jessie environment.
Good.
Probably every package build by us.
Yes.
Are such packages really updated during in-place upgrade? Looks like the version is exactly the same...
Indeed. I was wrong about that.
Looking at the debdiff. Wondering if that would have justified bumping the upstream version.
user@host:~$ debdiff /home/user/qubes-gui-agent_3.0.6+wheezy1_amd64.deb /home/user/qubes-gui-agent_3.0.6+jessie1_amd64.deb
[The following lists of changes regard files as different if they have
different names, permissions or owners.]
Files in second .deb but not in first
-------------------------------------
-rw-r--r-- root/root /usr/lib/pulse-5.0/modules/module-vchan-sink.so
Files in first .deb but not in second
-------------------------------------
-rw-r--r-- root/root /usr/lib/pulse-2.0/modules/module-vchan-sink.so
Control files: lines which differ (wdiff format)
------------------------------------------------
Depends: gnome-keyring, pulseaudio, xserver-xorg-core, xinit, x11-xserver-utils, xenstore-utils, qubes-core-agent, libpulse0, libxdamage1 (>= 1:1.1), libxcomposite1 (>= 1:0.3-1), libxt6, libx11-6, libc6 (>= [-2.4),-] {+2.15),+} libxen-4.4, dconf-gsettings-backend | gsettings-backend, init-system-helpers (>= 1.18~)
Installed-Size: [-247-] {+246+}
Version: [-3.0.6+wheezy1-] {+3.0.6+jessie1+}
debdiff "is not so comprehensive".
Looking at the debbindiff (from Debian stretch).
debbindiff /home/user/qubes-gui-agent_3.0.6+wheezy1_amd64.deb /home/user/qubes-gui-agent_3.0.6+jessie1_amd64.deb
--- /home/user/qubes-gui-agent_3.0.6+wheezy1_amd64.deb
+++ /home/user/qubes-gui-agent_3.0.6+jessie1_amd64.deb
├── control.tar.gz
│ ├── metadata
│ │ @@ -1 +1 @@
│ │ -gzip compressed data, max compression, from Unix
│ │ +gzip compressed data, max speed, from Unix
│ ├── control.tar
│ │ ├── ./conffiles
│ │ │ @@ -1,15 +1,15 @@
│ │ │ -/etc/xdg/Xresources
│ │ │ -/etc/xdg/xsettingsd
│ │ │ -/etc/xdg/autostart/qubes-pulseaudio.desktop
│ │ │ -/etc/xdg/fonts.conf
│ │ │ -/etc/xdg/Trolltech.conf
│ │ │ -/etc/pulse/qubes-default.pa
│ │ │ -/etc/qubes-rpc/qubes.SetMonitorLayout
│ │ │ -/etc/X11/xorg-qubes.conf.template
│ │ │ -/etc/X11/Xsession.d/25xdg-qubes-settings
│ │ │ /etc/X11/Xsession.d/20qt-x11-no-mitshm
│ │ │ +/etc/X11/Xsession.d/25xdg-qubes-settings
│ │ │ /etc/X11/Xsession.d/90qubes-keymap
│ │ │ /etc/X11/Xsession.d/98qubes-session
│ │ │ +/etc/X11/xorg-qubes.conf.template
│ │ │ /etc/profile.d/qubes-gui.csh
│ │ │ -/etc/profile.d/qubes-session.sh
│ │ │ /etc/profile.d/qubes-gui.sh
│ │ │ +/etc/profile.d/qubes-session.sh
│ │ │ +/etc/pulse/qubes-default.pa
│ │ │ +/etc/qubes-rpc/qubes.SetMonitorLayout
│ │ │ +/etc/xdg/Trolltech.conf
│ │ │ +/etc/xdg/Xresources
│ │ │ +/etc/xdg/autostart/qubes-pulseaudio.desktop
│ │ │ +/etc/xdg/fonts.conf
│ │ │ +/etc/xdg/xsettingsd
│ │ ├── ./control
│ │ │ @@ -1,13 +1,13 @@
│ │ │ Package: qubes-gui-agent
│ │ │ -Version: 3.0.6+wheezy1
│ │ │ +Version: 3.0.6+jessie1
│ │ │ Architecture: amd64
│ │ │ Maintainer: Davíð Steinn Geirsson <david@dsg.is>
│ │ │ -Installed-Size: 247
│ │ │ -Depends: gnome-keyring, pulseaudio, xserver-xorg-core, xinit, x11-xserver-utils, xenstore-utils, qubes-core-agent, libpulse0, libxdamage1 (>= 1:1.1), libxcomposite1 (>= 1:0.3-1), libxt6, libx11-6, libc6 (>= 2.4), libxen-4.4, dconf-gsettings-backend | gsettings-backend, init-system-helpers (>= 1.18~)
│ │ │ +Installed-Size: 246
│ │ │ +Depends: gnome-keyring, pulseaudio, xserver-xorg-core, xinit, x11-xserver-utils, xenstore-utils, qubes-core-agent, libpulse0, libxdamage1 (>= 1:1.1), libxcomposite1 (>= 1:0.3-1), libxt6, libx11-6, libc6 (>= 2.15), libxen-4.4, dconf-gsettings-backend | gsettings-backend, init-system-helpers (>= 1.18~)
│ │ │ Recommends: qt4-qtconfig
│ │ │ Provides: x-display-manager
│ │ │ Section: admin
│ │ │ Priority: extra
│ │ │ Homepage: http://www.qubes-os.org/
│ │ │ Description: Makes X11 windows available to qubes dom0
│ │ │ The Qubes GUI agent allows the forwarding of running app windows to the
│ │ ├── md5sums
│ │ │┄ Files in package differs
│ │ ├── metadata
│ │ │ @@ -1,8 +1,8 @@
│ │ │ --rwxr-xr-x root/root 0 2015-06-11 16:06:09 ./
│ │ │ --rw-r--r-- root/root 760 2015-06-11 16:06:09 ./control
│ │ │ --rw-r--r-- root/root 1081 2015-06-11 16:06:09 ./md5sums
│ │ │ --rwxr-xr-x root/root 1716 2015-06-11 16:06:09 ./prerm
│ │ │ --rwxr-xr-x root/root 614 2015-06-11 16:06:09 ./postrm
│ │ │ +-rwxr-xr-x root/root 0 2015-06-11 16:05:28 ./
│ │ │ +-rw-r--r-- root/root 761 2015-06-11 16:05:28 ./control
│ │ │ +-rw-r--r-- root/root 1081 2015-06-11 16:05:28 ./md5sums
│ │ │ +-rwxr-xr-x root/root 1716 2015-06-11 16:05:28 ./prerm
│ │ │ +-rwxr-xr-x root/root 614 2015-06-11 16:05:28 ./postrm
│ │ │ -rw-r--r-- root/root 40 2015-04-28 11:28:48 ./triggers
│ │ │ --rw-r--r-- root/root 468 2015-06-11 16:06:09 ./conffiles
│ │ │ --rwxr-xr-x root/root 2848 2015-06-11 16:06:09 ./postinst
│ │ │ +-rw-r--r-- root/root 468 2015-06-11 16:05:28 ./conffiles
│ │ │ +-rwxr-xr-x root/root 2848 2015-06-11 16:05:28 ./postinst
│ │ ╵
│ ╵
├── metadata
│ @@ -1,3 +1,3 @@
│ -rw-r--r-- 0/0 4 Jun 11 16:06 2015 debian-binary
│ -rw-r--r-- 0/0 3007 Jun 11 16:06 2015 control.tar.gz
│ -rw-r--r-- 0/0 52227 Jun 11 16:06 2015 data.tar.gz
│ +rw-r--r-- 0/0 4 Jun 11 16:05 2015 debian-binary
│ +rw-r--r-- 0/0 3318 Jun 11 16:05 2015 control.tar.gz
│ +rw-r--r-- 0/0 40848 Jun 11 16:05 2015 data.tar.xz
╵
Good.
Yes.
Indeed. I was wrong about that. Looking at the debdiff. Wondering if that would have justified bumping the upstream version. debdiff "is not so comprehensive". Looking at the debbindiff (from Debian stretch). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 2, 2015
Member
Are we there yet to distinguish between upstream package version number and debian packaging revision version number? That would be the case, if we had a package, that might only fix the Debian packaging, but not touching the upstream tarball. The one with the Debian packaging hat would not be allowed to touch the upstream source while wearing that hat. Instead, that person would have to use Debian packaging's patching mechanism.
I don't think we are there. I also think that would be overkill at this stage. Also overkill, because of close cooperation. There is no upstream, that doesn't care in the slightest about packaging. Instead of adding Debian packaging, stuff can just be fixed directly "upstream".
Therefore I am suggesting something simpler. Use very simple Debian packaging revision numbers. Keep it always 1. (But not abolishing Debian package revision numbers. I find non-native Debian packages better. Simpler to keep those. More future proof.)
If you compile packages for a newer Debian suite, just make sure to bump the package upstream version beforehand.
Let's say your version number was 0:1.6-1 on wheezy, make that 0.1.7-1 for jessie.
This comes with an disadvantage, though. When releasing bug fix or security fix releases for wheezy, you can't call it 0.1.7-1 to avoid conflicts on suite wheezy -> jessie upgrade. You would have to name it 0.1.6.1-1, 0.1.7.2-1 etc. This is how it's handled in Whonix.
|
Are we there yet to distinguish between upstream package version number and debian packaging revision version number? That would be the case, if we had a package, that might only fix the Debian packaging, but not touching the upstream tarball. The one with the Debian packaging hat would not be allowed to touch the upstream source while wearing that hat. Instead, that person would have to use Debian packaging's patching mechanism. I don't think we are there. I also think that would be overkill at this stage. Also overkill, because of close cooperation. There is no upstream, that doesn't care in the slightest about packaging. Instead of adding Debian packaging, stuff can just be fixed directly "upstream". Therefore I am suggesting something simpler. Use very simple Debian packaging revision numbers. Keep it always If you compile packages for a newer Debian suite, just make sure to bump the package upstream version beforehand. Let's say your version number was This comes with an disadvantage, though. When releasing bug fix or security fix releases for wheezy, you can't call it |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2015
Member
On Sun, Aug 02, 2015 at 06:29:38AM -0700, Patrick Schleizer wrote:
Looking at the debdiff. Wondering if that would have justified bumping the upstream version.
There is not a single source line different. Also how do you think of
it? Odd versions are built for jessie, even built for wheezy? That's at least
weird...
I think we need to make some difference in debian_release part of
package version.
user@host:~$ debdiff /home/user/qubes-gui-agent_3.0.6+wheezy1_amd64.deb /home/user/qubes-gui-agent_3.0.6+jessie1_amd64.deb [The following lists of changes regard files as different if they have different names, permissions or owners.] Files in second .deb but not in first ------------------------------------- -rw-r--r-- root/root /usr/lib/pulse-5.0/modules/module-vchan-sink.so Files in first .deb but not in second ------------------------------------- -rw-r--r-- root/root /usr/lib/pulse-2.0/modules/module-vchan-sink.so
This is exactly result of building for different pulseaudio version.
Control files: lines which differ (wdiff format)
Depends: gnome-keyring, pulseaudio, xserver-xorg-core, xinit, x11-xserver-utils, xenstore-utils, qubes-core-agent, libpulse0, libxdamage1 (>= 1:1.1), libxcomposite1 (>= 1:0.3-1), libxt6, libx11-6, libc6 (>= [-2.4),-] {+2.15),+} libxen-4.4, dconf-gsettings-backend | gsettings-backend, init-system-helpers (>= 1.18~)
Installed-Size: [-247-] {+246+}
Version: [-3.0.6+wheezy1-] {+3.0.6+jessie1+}
Same here.
Looking at the debbindiff (from Debian stretch).
(...)
Besides above differences, I see only different files order...
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Sun, Aug 02, 2015 at 06:29:38AM -0700, Patrick Schleizer wrote:
There is not a single source line different. Also how do you think of I think we need to make some difference in debian_release part of
This is exactly result of building for different pulseaudio version.
Same here.
(...) Besides above differences, I see only different files order... Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 2, 2015
Member
So now we have:
- debian packaging revision version number simplification proposal by me: #1095 (comment)
- +debNUMBER proposal
Both should work.
Do you have any thoughts on which one is better, pros and cons, reasons etc. why one should be preferred?
|
So now we have:
Both should work. Do you have any thoughts on which one is better, pros and cons, reasons etc. why one should be preferred? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2015
Member
On Sun, Aug 02, 2015 at 06:42:02AM -0700, Patrick Schleizer wrote:
Therefore I am suggesting something simpler. Use very simple Debian packaging revision numbers. Keep it always
1. (But not abolishing Debian package revision numbers. I find non-native Debian packages better. Simpler to keep those. More future proof.)
Yep, we already have something like this. If package is in non-native
format (most of them), release number is always 1.
If you compile packages for a newer Debian suite, just make sure to bump the package upstream version beforehand.
Let's say your version number was
0:1.6-1on wheezy, make that0.1.7-1for jessie.This comes with an disadvantage, though. When releasing bug fix or security fix releases for wheezy, you can't call it
0.1.7-1to avoid conflicts on suite wheezy -> jessie upgrade. You would have to name it0.1.6.1-1,0.1.7.2-1etc. This is how it's handled in Whonix.
I think that's a horrible idea.
This means that you need to commit and tag a new version before every
build - even if not a single change was made. Then you need to guard
that .6 versions are built only for squeeze, even if those are in the
same branch(*). Also surely you'll need to answer questions like "where
is version 1.2.7 for squeeze, why squeeze package is outdated?". In
addition Debian is not the only distribution, so just rebuild of debian
package would mean need to release new packages for other distros (to
have versions in sync).
(*) Also I don't think creating separate branch for every supported
distro (version) would be a wise choice - it would be un-managable mess.
Since close cooperation I think every real change can deserve bumping
upstream version, even if it is in debian packaging part. This leaves
debian_release unused in practice - so we can use it for distinction in
debian target releases. The question is how we should use it. Debian
already uses +DIST for that, so IMHO we just need update it to
+debNUMBER, as done in wheezy (previously lexicographical order was ok:
etch < lenny < squeeze < wheezy).
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Sun, Aug 02, 2015 at 06:42:02AM -0700, Patrick Schleizer wrote:
Yep, we already have something like this. If package is in non-native
I think that's a horrible idea. This means that you need to commit and tag a new version before every (*) Also I don't think creating separate branch for every supported Since close cooperation I think every real change can deserve bumping Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Yes.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nrgaway
Aug 2, 2015
On 2 August 2015 at 10:17, Marek Marczykowski-Górecki <
notifications@github.com> wrote:
On Sun, Aug 02, 2015 at 06:42:02AM -0700, Patrick Schleizer wrote:
Therefore I am suggesting something simpler. Use very simple Debian
packaging revision numbers. Keep it always1. (But not abolishing Debian
package revision numbers. I find non-native Debian packages better. Simpler
to keep those. More future proof.)Yep, we already have something like this. If package is in non-native
format (most of them), release number is always1.If you compile packages for a newer Debian suite, just make sure to bump
the package upstream version beforehand.Let's say your version number was
0:1.6-1on wheezy, make that
0.1.7-1for jessie.This comes with an disadvantage, though. When releasing bug fix or
security fix releases for wheezy, you can't call it0.1.7-1to avoid
conflicts on suite wheezy -> jessie upgrade. You would have to name it
0.1.6.1-1,0.1.7.2-1etc. This is how it's handled in Whonix.I think that's a horrible idea.
This means that you need to commit and tag a new version before every
build - even if not a single change was made. Then you need to guard
that .6 versions are built only for squeeze, even if those are in the
same branch(*). Also surely you'll need to answer questions like "where
is version 1.2.7 for squeeze, why squeeze package is outdated?". In
addition Debian is not the only distribution, so just rebuild of debian
package would mean need to release new packages for other distros (to
have versions in sync).(*) Also I don't think creating separate branch for every supported
distro (version) would be a wise choice - it would be un-managable mess.Since close cooperation I think every real change can deserve bumping
upstream version, even if it is in debian packaging part. This leaves
debian_release unused in practice - so we can use it for distinction in
debian target releases. The question is how we should use it. Debian
already uses +DIST for that, so IMHO we just need update it to
+debNUMBER, as done in wheezy (previously lexicographical order was ok:
etch < lenny < squeeze < wheezy).
I concur; +debNUMBER.
nrgaway
commented
Aug 2, 2015
|
On 2 August 2015 at 10:17, Marek Marczykowski-Górecki <
I concur; +debNUMBER. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nrgaway
Aug 2, 2015
nrgaway
commented
Aug 2, 2015
|
I will update all packages tonight to use +debNUMBER which means will take
effect on next version bump.
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 2, 2015
Member
On Sun, Aug 02, 2015 at 02:23:40PM -0700, nrgaway wrote:
I will update all packages tonight to use +debNUMBER which means will take
effect on next version bump.
Just update a scripts in builder-debian to generate new names. Remember
to update also update-repo and check-repo targets. Otherwise I'll
not be able to upload new packages :)
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Sun, Aug 02, 2015 at 02:23:40PM -0700, nrgaway wrote:
Just update a scripts in builder-debian to generate new names. Remember Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
nrgaway
Aug 2, 2015
On 2 August 2015 at 17:49, Marek Marczykowski-Górecki <
notifications@github.com> wrote:
On Sun, Aug 02, 2015 at 02:23:40PM -0700, nrgaway wrote:
I will update all packages tonight to use +debNUMBER which means will
take
effect on next version bump.Just update a scripts in builder-debian to generate new names. Remember
to update alsoupdate-repoandcheck-repotargets. Otherwise I'll
not be able to upload new packages :)
Yup, got ya!
nrgaway
commented
Aug 2, 2015
|
On 2 August 2015 at 17:49, Marek Marczykowski-Górecki <
Yup, got ya! |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 6, 2015
Member
This is already merged. I'll close the issue when packages with new version format will be released.
|
This is already merged. I'll close the issue when packages with new version format will be released. |
marmarek
added
bug
P: major
C: Debian
labels
Aug 6, 2015
marmarek
added this to the Release 3.0 milestone
Aug 6, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 7, 2015
Member
I'll change +deb7~1 style to +deb7u1. First to match what is already used in Debian. Second to not conflict with devel build style already used (~develX suffix).
|
I'll change |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 7, 2015
Member
Thinking loud here.
+deb7u1
~develX
That should make devel always prefered, because v comes after b in the alphabet.
But why ~ for devel? Is ~ considered a higher priority than +? System would always prefer the devel version then, unless upstream version was pushes? Sounds alight.
|
Thinking loud here. But why |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 7, 2015
Member
On Fri, Aug 07, 2015 at 04:08:24PM -0700, Patrick Schleizer wrote:
Thinking loud here.
+deb7u1
~develX
That should make devel always prefered, becausevcomes afterbin the alphabet.
Actually I was thinking about +deb7u1~develX (yes, both suffixes). We
still needs to be able to build devel packages for multiple versions.
But why
~for devel? Is~considered a higher priority than+? System would always prefer the devel version then, unless upstream version was pushes? Sounds alight.
~ has somehow inverted logic - package with ~ suffix is always older
than the one without it.
So, it doesn't sound right also. Maybe +deb7u1+develX. If two same
type suffixes are allowed...
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Fri, Aug 07, 2015 at 04:08:24PM -0700, Patrick Schleizer wrote:
Actually I was thinking about
So, it doesn't sound right also. Maybe Best Regards, |
added a commit
to marmarek/qubes-builder-debian
that referenced
this issue
Aug 8, 2015
added a commit
to marmarek/qubes-builder-debian
that referenced
this issue
Aug 8, 2015
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 8, 2015
Member
Updated packages are already upload to testing repository. @adrelanos can you confirm they are installed automatically as part of dist-upgrade?
|
Updated packages are already upload to testing repository. @adrelanos can you confirm they are installed automatically as part of |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
Maybe they are not.
Still considered a downgrade:
sudo apt-get install libxen-4.4=4.4.1-9+deb8u1
Running with jessie-testing repository.
user@host:/var/lib/dpkg/info$ dpkg -l | grep qubes
ii libqubesdb 3.0.2-1+wheezy1 amd64 QubesDB libs.
ii qubes-core-agent 3.0.13-1+jessie1 amd64 Qubes core agent
ii qubes-gpg-split 2.0.11-1+wheezy1 amd64 The Qubes service for secure gpg separation
ii qubes-gui-agent 3.0.8+jessie1 amd64 Makes X11 windows available to qubes dom0
ii qubes-pdf-converter 2.0.3-1+wheezy1 amd64 The Qubes service for converting untrusted PDF files into trusted ones
ii qubes-thunderbird 1.2.7-1+wheezy1 amd64 The Qubes extension for Thunderbird
ii qubes-utils 3.0.9+jessie1 amd64 Qubes Linux utilities
ii qubes-whonix 10.0.5-1+wheezy1 all Qubes Configuration for Whonix-Gateway and Whonix-Workstation
ii qubesdb 3.0.2-1+wheezy1 amd64 QubesDB management tools and daemon.
ii qubesdb-vm 3.0.2-1+wheezy1 amd64 QubesDB VM service.
user@host:/var/lib/dpkg/info$ dpkg -l | grep xen
ii libvchan-xen 3.0.6-1+jessie1 amd64 Qubes Xen core libraries
ii libxen-4.4 2001:4.4.2-5+wheezy1 amd64 Libraries for Xen tools
ii libxenstore3.0 2001:4.4.2-5+wheezy1 amd64 Xenstore communications library for Xen
ii xen-utils-common 2001:4.4.2-5+wheezy1 all Xen administrative tools - common files
ii xenstore-utils 2001:4.4.2-5+wheezy1 amd64 Xenstore command line utilities for Xen
Does this look like expected?
|
Maybe they are not. Still considered a downgrade: Running with jessie-testing repository. Does this look like expected? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 9, 2015
Member
Did tou enabled testing repository (commented out line in /etc/apt/sources.list.d/qubes-r3.list)? Above looks exactly like current stable...
|
Did tou enabled testing repository (commented out line in |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
I didn't comment out stable. This is what I got.
deb [arch=amd64] http://deb.qubes-os.org/r3.0/vm jessie main
deb [arch=amd64] http://deb.qubes-os.org/r3.0/vm jessie-testing main
But that should work.
|
I didn't comment out stable. This is what I got. But that should work. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
Commenting stable out also does not help. Nothing happens after apt-get update and apt-get dist-upgrade.
|
Commenting stable out also does not help. Nothing happens after apt-get update and apt-get dist-upgrade. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
No newer version advertised in the repository.
apt-cache show qubes-gui-agent
Package: qubes-gui-agent
Version: 3.0.8+jessie1
Architecture: amd64
Maintainer: Davíð Steinn Geirsson <david@dsg.is>
Installed-Size: 255
Depends: gnome-keyring, pulseaudio, xserver-xorg-core, xinit, x11-xserver-utils, xenstore-utils, qubes-core-agent, libpulse0, libxdamage1 (>= 1:1.1), libxcomposite1 (>= 1:0.3-1), libxt6, libx11-6, libc6 (>= 2.15), libxen-4.4, dconf-gsettings-backend | gsettings-backend, init-system-helpers (>= 1.18~)
Recommends: qt4-qtconfig
Provides: x-display-manager
Homepage: http://www.qubes-os.org/
Priority: extra
Section: admin
Filename: pool/main/q/qubes-gui-agent/qubes-gui-agent_3.0.8+jessie1_amd64.deb
Size: 45112
SHA256: 5b49f3883e74999530d41d05bad921b4d417e3d13e8ab98cbc312199f82e253c
SHA1: 8ea19344df7ec9edfeb19548a2205f71faeab3fc
MD5sum: e40a33d397a5d023b4d06d200e82c89d
Description: Makes X11 windows available to qubes dom0
The Qubes GUI agent allows the forwarding of running app windows to the
qubes dom0. It also includes various extras such as copy/paste support.
Description-md5: aa4947b78cfeae1e3467d1d7cbf677e3
Do you use DNS round robin? Perhaps a stale mirrors?
|
No newer version advertised in the repository. Do you use DNS round robin? Perhaps a stale mirrors? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
Quote
- http://deb.qubes-os.org/r3.0/vm/dists/jessie-testing/main/binary-amd64/Packages
- https://archive.is/VRsIM
Package: qubes-gui-agent
Version: 3.0.8+jessie1
Architecture: amd64
Maintainer: DavÃð Steinn Geirsson <david@dsg.is>
Installed-Size: 255
Depends: gnome-keyring, pulseaudio, xserver-xorg-core, xinit, x11-xserver-utils, xenstore-utils, qubes-core-agent, libpulse0, libxdamage1 (>= 1:1.1), libxcomposite1 (>= 1:0.3-1), libxt6, libx11-6, libc6 (>= 2.15), libxen-4.4, dconf-gsettings-backend | gsettings-backend, init-system-helpers (>= 1.18~)
Recommends: qt4-qtconfig
Provides: x-display-manager
Homepage: http://www.qubes-os.org/
Priority: extra
Section: admin
Filename: pool/main/q/qubes-gui-agent/qubes-gui-agent_3.0.8+jessie1_amd64.deb
Size: 45112
SHA256: 5b49f3883e74999530d41d05bad921b4d417e3d13e8ab98cbc312199f82e253c
SHA1: 8ea19344df7ec9edfeb19548a2205f71faeab3fc
MD5sum: e40a33d397a5d023b4d06d200e82c89d
Description: Makes X11 windows available to qubes dom0
The Qubes GUI agent allows the forwarding of running app windows to the
qubes dom0. It also includes various extras such as copy/paste support.
|
Quote
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Can't work. Repository not updated for some reason. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 9, 2015
Member
Ok, should be better, typo in directory name on server side...
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Ok, should be better, typo in directory name on server side... Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
The following packages will be upgraded:
libqubesdb libvchan-xen libxen-4.4 libxenstore3.0 qubes-core-agent qubes-gui-agent qubes-utils qubesdb qubesdb-vm xen-utils-common xenstore-utils
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 9, 2015
Member
Looks better, what versions (-V)?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Looks better, what versions ( Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
Too late. Already upgraded.
But this should equally do.
user@host:/var/lib/dpkg/info$ dpkg -l | grep qubes
ii libqubesdb 3.0.4-1+deb8u1 amd64 QubesDB libs.
ii qubes-core-agent 3.0.15-1+deb8u1 amd64 Qubes core agent
ii qubes-gpg-split 2.0.11-1+wheezy1 amd64 The Qubes service for secure gpg separation
ii qubes-gui-agent 3.0.9+deb8u1 amd64 Makes X11 windows available to qubes dom0
ii qubes-pdf-converter 2.0.3-1+wheezy1 amd64 The Qubes service for converting untrusted PDF files into trusted ones
ii qubes-thunderbird 1.2.7-1+wheezy1 amd64 The Qubes extension for Thunderbird
ii qubes-utils 3.0.10+deb8u1 amd64 Qubes Linux utilities
ii qubes-whonix 10.0.5-1+wheezy1 all Qubes Configuration for Whonix-Gateway and Whonix-Workstation
ii qubesdb 3.0.4-1+deb8u1 amd64 QubesDB management tools and daemon.
ii qubesdb-vm 3.0.4-1+deb8u1 amd64 QubesDB VM service.
user@host:/var/lib/dpkg/info$ dpkg -l | grep xen
ii libvchan-xen 3.0.7-1+deb8u1 amd64 Qubes Xen core libraries
ii libxen-4.4 2001:4.4.2-6+deb8u1 amd64 Libraries for Xen tools
ii libxenstore3.0 2001:4.4.2-6+deb8u1 amd64 Xenstore communications library for Xen
ii xen-utils-common 2001:4.4.2-6+deb8u1 all Xen administrative tools - common files
ii xenstore-utils 2001:4.4.2-6+deb8u1 amd64 Xenstore command line utilities for Xen
Looks good to me.
|
Too late. Already upgraded. But this should equally do. Looks good to me. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 9, 2015
Member
Yes :)
Does it work now?
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
Yes :) Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
This is going to be tricky... In summary:
If you want a wheezy -> jessie upgrade...
- Upgrade from Qubes wheezy-testing first.
- [Or in other words, upgrade your wheezy first.]
- qubes-core-agent will hang during the upgrade [qrexec hang bug]
[because still running the defect one] - sudo killall qubes-trigger-sync-appmenus.sh
- poweroff, poweron again [so new qrexec gets active]
- upgrade to jessie now
No, you cannot upgrade straight to jessie. Because then you would have
the qrexec hang bug multiple times during upgrade. You also cannot just
dist-upgrade from jessie-testing, because then the still-wheezy version
would have a broken X server. [The bug of this ticket.]
More in user speech, here:
https://www.whonix.org/wiki/Upgrading_Whonix_10_to_Whonix_11#Qubes_Pre_Fixup
Testing this at this moment...
|
This is going to be tricky... In summary: If you want a wheezy -> jessie upgrade...
No, you cannot upgrade straight to jessie. Because then you would have More in user speech, here: Testing this at this moment... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Aug 9, 2015
Member
On Sun, Aug 09, 2015 at 12:55:21PM -0700, Patrick Schleizer wrote:
More in user speech, here:
https://www.whonix.org/wiki/Upgrading_Whonix_10_to_Whonix_11#Qubes_Pre_Fixup
Regarding all those files in /etc/xdg/autostart - maybe its better to
answer "yes" to restore the original content? New qubes-core-agent package
no longer modifies those files.
Testing this at this moment...
BTW installing new gateway template I've found that one icon (for
gateway-firewall30default.desktop) is really huge - 720x720, which is
over 512x512. I think this triggers the qrexec bug.
Why this icon is so huge? Maybe it could be downscaled to not trigger
the bug? Then the upgrade would be much simpler (I think direct
dist-upgrade would simply work).
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
On Sun, Aug 09, 2015 at 12:55:21PM -0700, Patrick Schleizer wrote:
Regarding all those files in
BTW installing new gateway template I've found that one icon (for Why this icon is so huge? Maybe it could be downscaled to not trigger Best Regards, |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
XDG: Ok, changed.
Icon: There is no specific reason for that size. Just found that icon appropriate and wanted to have high quality. Didn't mind about such a few bytes as long as it was reasonable. Will scale down:
https://phabricator.whonix.org/T393
I am wondering if it's the only trigger.
And if we can get away with manual instructions for deleting/replacing it somehow. Without the file being reinstalled during upgrade and start causing qrexec trouble. Otherwise this would require a Whonix stable upgrade. I am inclined to suggest some dpkg-divert command in upgrade documentation and just have this icon scaled down for Whonix 12. While it hopefully won't matter anymore, because the qrexec bug will be fixed by then.
I am also inclined to suggest some other hack for upgrading such as temporarily deactivating the app sync script. Because we're going in circles here. A lot time has been spend on in place upgrades already and I wonder how many are even interested in this.
|
XDG: Ok, changed. Icon: There is no specific reason for that size. Just found that icon appropriate and wanted to have high quality. Didn't mind about such a few bytes as long as it was reasonable. Will scale down: I am wondering if it's the only trigger. And if we can get away with manual instructions for deleting/replacing it somehow. Without the file being reinstalled during upgrade and start causing qrexec trouble. Otherwise this would require a Whonix stable upgrade. I am inclined to suggest some dpkg-divert command in upgrade documentation and just have this icon scaled down for Whonix 12. While it hopefully won't matter anymore, because the qrexec bug will be fixed by then. I am also inclined to suggest some other hack for upgrading such as temporarily deactivating the app sync script. Because we're going in circles here. A lot time has been spend on in place upgrades already and I wonder how many are even interested in this. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
adrelanos
Aug 9, 2015
Member
When upgrades from Qubes' testing are installed, it no longer leads to broken X server. Therefore once these packages migrate into stable, the issue originally reported in this ticket can be considered fixed.
|
When upgrades from Qubes' testing are installed, it no longer leads to broken X server. Therefore once these packages migrate into stable, the issue originally reported in this ticket can be considered fixed. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Packages moved to stable repository. |
adrelanos commentedJul 31, 2015
debian-8,jessie->stretchupdate is broken.whonix-ws,wheezy->jessieupdate is broken.VM still starts, but cannot run gui applications inside it anymore.
If I do that with
konsole, no output.Will attach the X log below.
Any suggestions for a quick fix?
Any idea for the real fix?
/var/log/Xorg.0.log: