[Bug 1799807] [NEW] Sphinx documentation no longer available online (apt.alioth.debian.org unavailable)
Public bug reported:
While working on the development of a Python package I created (deb-pkg-
tools) that uses python-apt and refers to its documentation I noticed
that the online documentation seems to have disappeared...
This makes it impossible for my project to cross-reference the python-
apt documentation, something that used to work fine a few months ago
:-(. Here's what Sphinx has to say on the matter:
$ make docs
Running Sphinx v1.8.1
loading translations [en]... done
loading pickled environment... done
loading intersphinx inventory from
https://apt.alioth.debian.org/python-apt-doc/objects.inv...
WARNING: failed to reach any of the inventories with the following issues:
WARNING: intersphinx inventory
'https://apt.alioth.debian.org/python-apt-doc/objects.inv' not fetchable due to
: ('intersphinx inventory %r not
fetchable due to %s: %s',
'https://apt.alioth.debian.org/python-apt-doc/objects.inv', , ConnectionError(...))
When I look at https://readthedocs.org/projects/deb-pkg-
tools/builds/6801480/ I can see that in February 2018 this was still
working fine, but the domain apt.alioth.debian.org no longer resolves.
It might be that the documentation has moved somewhere else, without a
redirect in place, however I spent more than an hour looking and
couldn't find the new location (if it exists):
1. https://pypi.org/project/python-apt/ links to the broken domain.
2. http://www.sphinx-doc.org/en/master/examples.html also links to the broken
domain.
Would it be possible to make the Sphinx based documentation on python-
apt available online again? Personally I have good experiences with Read
The Docs and I'd love to see https://python-apt.readthedocs.io/ be
brought into existence 😇.
** Affects: python-apt (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799807
Title:
Sphinx documentation no longer available online (apt.alioth.debian.org
unavailable)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1799807/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1799807] Re: Sphinx documentation no longer available online (apt.alioth.debian.org unavailable)
For whatever it's worth: I wouldn't mind spending a bit of time trying to set up https://python-apt.readthedocs.io/ based on the git repository at https://git.launchpad.net/ubuntu/+source/python-apt, although I can't tell if this plan will actually work without trying it (for example I don't know if the dependencies of the documentation build will be available in the RTD environment). PS. The "information type" change was unintended, which explains why I reverted it; I didn't realize that my (accidental) mouse click would change the bug report without some form of confirmation... -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1799807 Title: Sphinx documentation no longer available online (apt.alioth.debian.org unavailable) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1799807/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1363482] Re: ubuntu-keyring includes 1024D keys
It's a shame I can't edit comments on Launchpad: Please disregard my last comment, I seem to have misread the pbuilder issue, sorry for the noise. That doesn't change the validity of my point about updating debootstrap though. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1363482 Title: ubuntu-keyring includes 1024D keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1363482/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 599394] Re: Release signed by unknown key (key id 40976EAF437D05B5)
It's a shame I can't edit comments on Launchpad: Please disregard my previous comment, I seem to have misread the issue, sorry for the noise. The error message noted in the title of this issue exactly matches the problem that I ran into last weekend, which explains how this issue popped up rather prominently in the search results I got when I searched for the error message. The cause is different though. Hopefully my pointer to the ubuntu-keyring issue will help some folks arriving here via Google :-). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/599394 Title: Release signed by unknown key (key id 40976EAF437D05B5) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/599394/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 599394] Re: Release signed by unknown key (key id 40976EAF437D05B5)
For posterity: I believe this to be a bug in debootstrap that was caused by an update to the ubuntu-keyring package [1] that received no corresponding update to the debootstrap 'configuration' files [2]. To summarize: - This affects Ubuntu <= 12.04 chroots on Ubuntu >= 17.04 hosts. - The best workaround that I know of is the following command: sudo debootstrap --keyring=/usr/share/keyrings/ubuntu-archive-removed- keys.gpg precise /tmp/precise http://old-releases.ubuntu.com/ubuntu/ The important bit is the non-default --keyring argument. [1] https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1363482 [2] https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bug/1363482/comments/7 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/599394 Title: Release signed by unknown key (key id 40976EAF437D05B5) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/599394/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1363482] Re: ubuntu-keyring includes 1024D keys
Going over my notes on this topic I realized that I hadn't pointed out in my previous message that the issue I've pointed out has already triggered a workaround (that shouldn't be necessary IMHO) in the pbuilder project: https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/599394 In my opinion neither pbuilder nor apt-mirror-updater should be implementing workarounds for this issue, because there's lots more use cases for debootstrap than just these two projects, and each will require a workaround until my suggested change to debootstrap is implemented. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1363482 Title: ubuntu-keyring includes 1024D keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1363482/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1363482] Re: ubuntu-keyring includes 1024D keys
> Precise archive is only signed with the old key. To support using the precise archive in newer releases, such as with debootstrap, we need to do the following ... This comment implied to me that the use of debootstrap to create an Ubuntu 12.04 chroot on e.g. Ubuntu 18.04 (which includes the ubuntu- keyring package update discussed here) should work, however I recently found out that it doesn't: $ sudo debootstrap precise /tmp/precise http://old-releases.ubuntu.com/ubuntu/ I: Retrieving InRelease I: Retrieving Release I: Checking Release signature E: Release signed by unknown key (key id 40976EAF437D05B5) At this point debootstrap exits with status code 1. My use case is based on a Python package (maintained by me) that automates the creation of Debian and Ubuntu chroots by discovering and ranking available mirrors, automatically picking a good mirror and then running debootstrap with the appropriate command line options. Based on this Launchpad issue I realized that I needed to use 'ubuntu-archive-removed-keys.gpg' and indeed then things work as expected: $ sudo debootstrap --keyring=/usr/share/keyrings/ubuntu-archive-removed-keys.gpg precise /tmp/precise http://old-releases.ubuntu.com/ubuntu/ I: Retrieving InRelease I: Retrieving Release I: Checking Release signature I: Valid Release signature (key id 630239CC130E1A7FD81A27B140976EAF437D05B5) I: Validating Packages I: Resolving dependencies of required packages... The tricky thing for me was that my Python package needs to decide this for the user, since it abstracts away the call to debootstrap, so I needed an exact understanding of the situation (the terseness of this Launchpad issue wasn't explicit enough for me, given a lack of knowledge about Ubuntu internals). I created the following overview of Ubuntu signing keys to help me understand the situation: warty: 0x40976EAF437D05B5 hoary: 0x40976EAF437D05B5 breezy: 0x40976EAF437D05B5 dapper: 0x40976EAF437D05B5 edgy: 0x40976EAF437D05B5 feisty: 0x40976EAF437D05B5 gutsy: 0x40976EAF437D05B5 hardy: 0x40976EAF437D05B5 intrepid: 0x40976EAF437D05B5 jaunty: 0x40976EAF437D05B5 karmic: 0x40976EAF437D05B5 lucid: 0x40976EAF437D05B5 maverick: 0x40976EAF437D05B5 natty: 0x40976EAF437D05B5 oneiric: 0x40976EAF437D05B5 precise: 0x40976EAF437D05B5 quantal: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 raring: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 saucy: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 trusty: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 utopic: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 vivid: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 wily: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 xenial: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 yakkety: 0x40976EAF437D05B5, 0x3B4FE6ACC0B21F32 zesty: 0x3B4FE6ACC0B21F32 artful: 0x3B4FE6ACC0B21F32 bionic: 0x3B4FE6ACC0B21F32 cosmic: 0x3B4FE6ACC0B21F32 The issue that I created to track this issue "on my side" contains a lot more details (including the script that was used to create the overview of signing keys) and is available here: https://github.com/xolox/python- apt-mirror-updater/issues/8 Now that I've implemented a workaround for this issue it's no longer very pressing for me, however wouldn't it be prudent to update the debootstrap package so that it automatically picks the 'removed' keyring for Ubuntu <= 12.04 chroots on Ubuntu >= 17.04 hosts? The variable to do so already exists, the value just needs to be changed: $ grep keyring /usr/share/debootstrap/scripts/precise keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg If this were updated to /usr/share/keyrings/ubuntu-archive-removed- keys.gpg it should work. This would avoid every single user of debootstrap having to work around this issue by themselves, like I've had to. This has affected at least some users (before me) already, as you can see by searching for the phrase "Release signed by unknown key (key id 40976EAF437D05B5)": https://www.google.com/search?q="Release+signed+by+unknown+key+%28key+id+40976EAF437D05B5%29"; ** Bug watch added: github.com/xolox/python-apt-mirror-updater/issues #8 https://github.com/xolox/python-apt-mirror-updater/issues/8 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1363482 Title: ubuntu-keyring includes 1024D keys To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-cdimage/+bug/1363482/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
Thanks to everyone involved in getting this fixed! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
Proving that the original issue still exists: peter@mbp> sudo apt install supervisor Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: supervisor-doc The following NEW packages will be installed: supervisor 0 upgraded, 1 newly installed, 0 to remove and 3 not upgraded. Need to get 252 kB of archives. After this operation, 1,398 kB of additional disk space will be used. Get:1 http://nl.archive.ubuntu.com/ubuntu xenial/universe amd64 supervisor all 3.2.0-2 [252 kB] Fetched 252 kB in 0s (625 kB/s) Selecting previously unselected package supervisor. (Reading database ... 241488 files and directories currently installed.) Preparing to unpack .../supervisor_3.2.0-2_all.deb ... Unpacking supervisor (3.2.0-2) ... Processing triggers for systemd (229-4ubuntu16) ... Processing triggers for ureadahead (0.100.0-19) ... Processing triggers for man-db (2.7.5-1) ... Setting up supervisor (3.2.0-2) ... Processing triggers for systemd (229-4ubuntu16) ... Processing triggers for ureadahead (0.100.0-19) ... peter@mbp> ps auxw | grep '[s]upervisor' peter@mbp> No output, Supervisor is not running. Now I enable the xenial-proposed archive, opt-out of upgrading my main system from xenial-proposed and selectively install the fixed supervisor package from the proposed archive: peter@mbp> sudo apt install supervisor/xenial-proposed Reading package lists... Done Building dependency tree Reading state information... Done Selected version '3.2.0-2ubuntu0.1' (Ubuntu:16.04/xenial-proposed [all]) for 'supervisor' Suggested packages: supervisor-doc The following packages will be upgraded: supervisor 1 upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 253 kB of archives. After this operation, 1,024 B of additional disk space will be used. Get:1 http://archive.ubuntu.com/ubuntu xenial-proposed/universe amd64 supervisor all 3.2.0-2ubuntu0.1 [253 kB] Fetched 253 kB in 1s (242 kB/s) (Reading database ... 241609 files and directories currently installed.) Preparing to unpack .../supervisor_3.2.0-2ubuntu0.1_all.deb ... Unpacking supervisor (3.2.0-2ubuntu0.1) over (3.2.0-2) ... Processing triggers for systemd (229-4ubuntu16) ... Processing triggers for ureadahead (0.100.0-19) ... Processing triggers for man-db (2.7.5-1) ... Setting up supervisor (3.2.0-2ubuntu0.1) ... peter@mbp> ps auxw | grep '[s]upervisor' root 15688 1.8 0.2 59148 18796 ?Ss 21:50 0:00 /usr/bin/python /usr/bin/supervisord -n -c /etc/supervisor/supervisord.conf As you can see in the 'ps auxw' output the Supervisor daemon is now running. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
@nacc: After installation of the buggy package: peter@mbp> sha1sum /lib/systemd/system/supervisor.service 88b0121e625b8ffe1cf6b0df3cf555bee8e7d3e9 /lib/systemd/system/supervisor.service After applying the manual workarounds (just being thorough, of course I would expect 'systemctl' to just create the symlink and not touch anything in /lib): peter@mbp> sha1sum /lib/systemd/system/supervisor.service 88b0121e625b8ffe1cf6b0df3cf555bee8e7d3e9 /lib/systemd/system/supervisor.service After upgrading to the fixed package from the PPA: peter@mbp> sha1sum /lib/systemd/system/supervisor.service 88b0121e625b8ffe1cf6b0df3cf555bee8e7d3e9 /lib/systemd/system/supervisor.service -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
After carefully rereading @nacc's question I realized I missed an
essential detail ("does it end up using the same systemd file"). I
believe this is indeed the case, as intended (I assume?).
Here's what I get after a clean install of the fixed package:
peter@mbp> ls -ld /etc/systemd/system/multi-user.target.wants/supervisor.service
lrwxrwxrwx 1 root root 38 Mar 13 23:53
/etc/systemd/system/multi-user.target.wants/supervisor.service ->
/lib/systemd/system/supervisor.service
Here's what I get after upgrading from the buggy version to the fixed
version:
peter@mbp> ls -ld /etc/systemd/system/multi-user.target.wants/supervisor.service
lrwxrwxrwx 1 root root 38 Mar 13 23:55
/etc/systemd/system/multi-user.target.wants/supervisor.service ->
/lib/systemd/system/supervisor.service
The target of the symlink is the same in both cases. The timestamps
differ but that's just the creation time of the symlink AFAIK (from the
moment 'systemctl enable' or an equivalent command is invoked).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1594740
Title:
Supervisor not enabled or started in Ubuntu 16.04 after installation
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
@nacc With regards to the other way to answer your question, I've now also tested the following sequence of events: 1. Purged the supervisor package, 2. removed the PPA `nacc/lp1594740', 3. ran `apt-get update', 4. ensured the symbolic link /etc/systemd/system/multi-user.target.wants/supervisor.service doesn't exist (indeed it doesn't, as expected), 5. reinstalled the supervisor package from Ubuntu's official repository (verified using `apt-cache policy supervisor'), 6. checked if the Supervisor daemon was started (it wasn't, because I just installed the buggy package), 7. ran `systemctl enable supervisor && systemctl start supervisor' as the documented workaround (this started and enabled the Supervisor daemon as expected), 7. reactivated the PPA `nacc/lp1594740', 8. ran `apt-get update && apt-get install supervisor', this upgraded the supervisor package to the version from the PPA. After step 8 the Supervisor daemon has been restarted (its PID has changed, as I would expect from an upgrade to a package that contains a system daemon) but during the upgrade there were no conflicts, warnings or complaints about Supervisor having already been manually enabled previously. Again, this looks good to me! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
@nacc There are two ways to interpret your question :-) and both are valid inquiries with regards to regression potential, so I'll just check and answer both. Just now I performed the following steps: 1. Purged the supervisor package, 2. removed the PPA `nacc/lp1594740', 3. ran `apt-get update', 4. ensured the symbolic link /etc/systemd/system/multi-user.target.wants/supervisor.service doesn't exist (indeed it doesn't, as expected), 5. reinstalled the supervisor package from Ubuntu's official repository (verified using `apt-cache policy supervisor'), 6. checked if the Supervisor daemon was started (it wasn't, because I just installed the buggy package), 7. reactivated the PPA `nacc/lp1594740', 8. ran `apt-get update && apt-get install supervisor', this upgraded the supervisor package to the version from the PPA. After step 6 the Supervisor daemon is not running, but after step 8 it is running. Theoretically there could be users out there who never noticed that Supervisor wasn't running after installation and after the upgrade to your fixed package Supervisor would `suddenly' be running for the first time on their system. But of course the whole point is for Supervisor to be running after installation! So this seems good to me. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
A minor follow up to my previous comment for anyone else testing this: Correctly testing the fixed package is a bit subtle because if you simply run 'apt purge supervisor' the symbolic link /etc/systemd/system /multi-user.target.wants/supervisor.service (which was created by a previous manual invocation of 'systemctl enable supervisor') will remain and the next installation of the buggy 'supervisor' package will (confusingly enough) correctly start Supervisor after installation. To summarize, I used the following commands to test this: sudo apt purge supervisor sudo rm /etc/systemd/system/multi-user.target.wants/supervisor.service sudo apt install supervisor # At this point, with a `clean re-installation' of the _buggy_ # package, the old and broken behavior that I originally reported can # be reproduced. This was to verify that I could still reproduce the # issue with up to date packages. It also confirmed that my manual # `systemctl enable' invocation hadn't left any state behind on the # filesystem. sudo apt purge supervisor sudo add-apt-repository ppa:nacc/lp1594740 sudo apt update sudo apt install supervisor # At this point the Supervisor daemon is correctly running straight # after installation, without requiring `systemctl' commands from the # operator. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
Hi Nish and thank you so much for backporting a fix to xenial! I can confirm that with the version of Supervisor in your PPA the original issue I reported is resolved, i.e. by the time 'apt install supervisor' returns, the Supervisor daemon has been started. Also both of the commands I mentioned in my opening post confirm the correct configuration: peter@mbp> systemctl --quiet is-enabled supervisor && echo OK || echo ER OK peter@mbp> systemctl --quiet is-active supervisor && echo OK || echo ER OK Apart from this the Supervisor daemon seems to be working fine, as expected. ** Description changed: Expected behavior = In Ubuntu 10.04, 12.04 and 14.04 after running "apt-get install supervisor" the Supervisor daemon is automatically enabled (to start on boot) and started (so that Supervisor is running by the time apt-get returns). What actually happens = In Ubuntu 16.04 the Supervisor daemon is not automatically enabled nor is it started during installation. This breaks compatibility with previous and expected behavior. Why this is a problem = I've built dozens of tools that use Supervisor for process supervision and these tools are deployed using custom Debian packages. Each of these packages has a dependency on the supervisor package with the expectation that Supervisor will be installed, enabled and started so that my post- installation scripts can call "supervisorctl" and expect it to work (instead of complaining about a missing UNIX socket file and exiting with a nonzero status code, thereby breaking my automated server provisioning). Known workaround Create a shim package with a dependency on supervisor and a post- installation script that runs the following commands: - # On Ubuntu 16.04 the installation of Supervisor does not - # enable and start the Supervisor daemon which breaks - # compatibility with previous Ubuntu releases. - if [ $(lsb_release --short --codename) = xenial ]; then - # Make sure the daemon is enabled. - if ! systemctl --quiet is-enabled supervisor; then - systemctl enable supervisor - fi - # Make sure the daemon is started. - if ! systemctl --quiet is-active supervisor; then - systemctl start supervisor - fi - fi + # On Ubuntu 16.04 the installation of Supervisor does not + # enable and start the Supervisor daemon which breaks + # compatibility with previous Ubuntu releases. + if [ $(lsb_release --short --codename) = xenial ]; then + # Make sure the daemon is enabled. + if ! systemctl --quiet is-enabled supervisor; then + systemctl enable supervisor + fi + # Make sure the daemon is started. + if ! systemctl --quiet is-active supervisor; then + systemctl start supervisor + fi + fi Alternatively one can obviously just run these commands by hand to rectify the situation. It's kind of nasty that I have to create a shim package like this to compensate for a break in backwards compatibility that is -as far as I know- undocumented and most likely unintentional. What's more is that a lot of people will lack the means to create shim packages like this, so thousands of Ubuntu users / integrators / system administrators worldwide will need to repeat these shenanigans manually. Affected versions = - peter@template-xenial:~$ lsb_release --short --description - Ubuntu 16.04 LTS + peter@template-xenial:~$ lsb_release --short --description + Ubuntu 16.04 LTS - peter@template-xenial:~$ apt-cache policy supervisor - supervisor: - Installed: 3.2.0-2 - Candidate: 3.2.0-2 - Version table: - *** 3.2.0-2 500 - 500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe amd64 Packages - 500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe i386 Packages - 100 /var/lib/dpkg/status + peter@template-xenial:~$ apt-cache policy supervisor + supervisor: + Installed: 3.2.0-2 + Candidate: 3.2.0-2 + Version table: + *** 3.2.0-2 500 + 500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe amd64 Packages + 500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe i386 Packages + 100 /var/lib/dpkg/status Root cause analysis === In Ubuntu 16.04 Supervisor is managed by systemd however the post- installation script is using update-rc.d and invoke-rc.d to enable and start Supervisor. As far as I know these commands are remnants of the old daemon management infrastructure and they don't integrate with systemd, hence the breakage: - peter@template-xenial:~$ cat /var/lib/dpkg/info/supervisor.postinst - #!/bin/sh - set -e + peter@template-xenial:~$ cat /var/lib/dpkg/info/super
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
I contacted ubuntu-devel-disc...@lists.ubuntu.com to inquire whether it's possible to get the bug fix in the Debian package backported to Ubuntu 16.04, here's my message: https://lists.ubuntu.com/archives/ubuntu-devel- discuss/2016-September/016866.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] Re: Supervisor not enabled or started in Ubuntu 16.04 after installation
Hi Orestis and thanks for following up here even though you're a _Debian_ package maintainer and not an _Ubuntu_ package maintainer :-). Am I assuming correctly that the Debian bug report you are referring to is the following? https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=827729 I will investigate tomorrow morning whether there is any chance of getting your fix into Ubuntu 16.04. Like you I am not intimately familiar with the Ubuntu release management process, it's not even clear to me whether non-security bug fixes can be backported to LTS releases. I suppose they _might_ if 1) there are no backwards incompatible changes, 2) the bug is considered critical enough and 3) enough people make their voice heard that they consider it a critical bug :-). Will follow up here soon! ** Bug watch added: Debian Bug tracker #827729 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827729 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1594740 Title: Supervisor not enabled or started in Ubuntu 16.04 after installation To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/supervisor/+bug/1594740/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1594740] [NEW] Supervisor not enabled or started in Ubuntu 16.04 after installation
Public bug reported: Expected behavior = In Ubuntu 10.04, 12.04 and 14.04 after running "apt-get install supervisor" the Supervisor daemon is automatically enabled (to start on boot) and started (so that Supervisor is running by the time apt-get returns). What actually happens = In Ubuntu 16.04 the Supervisor daemon is not automatically enabled nor is it started during installation. This breaks compatibility with previous and expected behavior. Why this is a problem = I've built dozens of tools that use Supervisor for process supervision and these tools are deployed using custom Debian packages. Each of these packages has a dependency on the supervisor package with the expectation that Supervisor will be installed, enabled and started so that my post- installation scripts can call "supervisorctl" and expect it to work (instead of complaining about a missing UNIX socket file and exiting with a nonzero status code, thereby breaking my automated server provisioning). Known workaround Create a shim package with a dependency on supervisor and a post- installation script that runs the following commands: # On Ubuntu 16.04 the installation of Supervisor does not # enable and start the Supervisor daemon which breaks # compatibility with previous Ubuntu releases. if [ $(lsb_release --short --codename) = xenial ]; then # Make sure the daemon is enabled. if ! systemctl --quiet is-enabled supervisor; then systemctl enable supervisor fi # Make sure the daemon is started. if ! systemctl --quiet is-active supervisor; then systemctl start supervisor fi fi Alternatively one can obviously just run these commands by hand to rectify the situation. It's kind of nasty that I have to create a shim package like this to compensate for a break in backwards compatibility that is -as far as I know- undocumented and most likely unintentional. What's more is that a lot of people will lack the means to create shim packages like this, so thousands of Ubuntu users / integrators / system administrators worldwide will need to repeat these shenanigans manually. Affected versions = peter@template-xenial:~$ lsb_release --short --description Ubuntu 16.04 LTS peter@template-xenial:~$ apt-cache policy supervisor supervisor: Installed: 3.2.0-2 Candidate: 3.2.0-2 Version table: *** 3.2.0-2 500 500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe amd64 Packages 500 http://mirror.nl.leaseweb.net/ubuntu xenial/universe i386 Packages 100 /var/lib/dpkg/status Root cause analysis === In Ubuntu 16.04 Supervisor is managed by systemd however the post- installation script is using update-rc.d and invoke-rc.d to enable and start Supervisor. As far as I know these commands are remnants of the old daemon management infrastructure and they don't integrate with systemd, hence the breakage: peter@template-xenial:~$ cat /var/lib/dpkg/info/supervisor.postinst #!/bin/sh set -e # Automatically added by dhpython: if which pycompile >/dev/null 2>&1; then pycompile -p supervisor fi # End automatically added section # Automatically added by dh_installinit if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then if [ -x "/etc/init.d/supervisor" ]; then update-rc.d supervisor defaults >/dev/null fi if [ -x "/etc/init.d/supervisor" ] || [ -e "/etc/init/supervisor.conf" ]; then invoke-rc.d supervisor start || exit $? fi fi # End automatically added section Conclusion == Is there a remote chance of getting this fixed in Ubuntu 16.06, maybe in a later point release? On the one hand I get that fixing this now is a big change compared to the original release of Ubuntu 16.04, on the other hand I have found dozens of unsuspecting users (see below) being bitten by this change in behavior and I haven't found a single user who appreciated it :-). If there is no chance of fixing this it should at least be documented in the release notes as a known regression, because I haven't been able to find any proper documentation about this change and I have found dozens of people being bitten by the break in backwards compatibility. External references === Some random reports of people running into (what I believe is) this exact issue: Here's an upstream bug report, where nothing can be fixed: https://github.com/Supervisor/supervisor/issues/735 Here's an unhappy user wondering how to restore expected behavior: http://unix.stackexchange.com/questions/281774/ubuntu-server-16-04-cannot-get-supervisor-to-start-automatically ** Affects: supervisor (Ubuntu) Importance: Undecided Status: New ** Tags: supervisor systemd xenial -- You received this bug notification because you are a mem
[Bug 790538] Re: pam update causes cron to stop working with "Module is unknown" error
@ubuntu devs: Since this has the potential to break lots servers in various nasty ways it might (?) be wise to post a heads up to a mailing list that's (hopefully) followed by lots of sysadmins like ubuntu- security-announce. I'm guessing there's a whole policy about what should and should not be submitted to ubuntu-security-announce but, well, it was just a suggestion :-). PS. If such a message has already been sent but I didn't see it because I'm only following ubuntu-security-announce please ignore my suggestion. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/790538 Title: pam update causes cron to stop working with "Module is unknown" error -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 491615] Re: Using arrow keys in vim-tiny while in Insert mode introduces A, B, C, D into text
@Will: You're right. The arrow keys also work when I log-in as a user without a ~/.vimrc file and manually :set nocompatible after starting Vim. Sorry for the noise I guess. One thing though, the above implies to me that the problem is inside my own ~/.vimrc script (correct?) but I don't understand what kind of setting could cause this, and how the workaround I posted above could possibly restore the cursor key functionality?! -- Using arrow keys in vim-tiny while in Insert mode introduces A,B,C,D into text https://bugs.launchpad.net/bugs/491615 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 491615] Re: Using arrow keys in vim-tiny while in Insert mode introduces A, B, C, D into text
I'm pretty sure there's a real bug somewhere deep inside of Ubuntu (maybe some system wide thing like termcap or whatever it's called) causing this behavior. I've used Ubuntu's Vim packages for years, always getting annoyed about the described bug. 1. I've created ~/.vimrc, it's nonempty and it's readable. 2. I always start Vim using the "vim" executable (hard link, symlink, whatever), never as "vi". 3. I've verified that, when the bug occurs, ":set compatible?" prints "set nocompatible". 4. The bug occurs when running Vim in either gnome-terminal or xterm (this is why it seems to be a system wide problem to me). 5. Recently I've started compiling Vim 7.3 based on the Mercurial repository at https://vim.googlecode.com/hg/ and even these builds exhibit the same exact problem. 6. I've found a workaround, though I still don't understand how the hell it works after using it for several months: Add the following lines to your ~/.vimrc script: if $TERM =~ 'xterm\|screen' " None of the cursor keys work out of the box in Vim while in insert mode " using gnome-terminal/xterm but once I manually fix the other cursor " keys start working magically?! imap [A endif One last thing, I'm still running Ubuntu 9.10 (Karmic) so can't confirm whether this problem still exists for newer releases. -- Using arrow keys in vim-tiny while in Insert mode introduces A,B,C,D into text https://bugs.launchpad.net/bugs/491615 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 591280] Re: The package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1.
The attachments above were added automatically by apport and I just noticed that DpkgTerminalLog.txt contains a few irrelevant entries from a few hours *before* this happened, but no entries that are relevant to this bug report... I'm attaching /var/log/dpkg.log in the hope that it will be more useful, though it doesn't seem to contain any warnings/errors. ** Attachment added: "dpkg.log" http://launchpadlibrarian.net/49953718/dpkg.log -- The package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1. https://bugs.launchpad.net/bugs/591280 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 591280] Re: The package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1.
** Attachment added: "AptOrdering.txt" http://launchpadlibrarian.net/49943773/AptOrdering.txt ** Attachment added: "Dependencies.txt" http://launchpadlibrarian.net/49943774/Dependencies.txt ** Attachment added: "Dmesg.gz" http://launchpadlibrarian.net/49943775/Dmesg.gz ** Attachment added: "DpkgTerminalLog.txt" http://launchpadlibrarian.net/49943776/DpkgTerminalLog.txt -- The package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1. https://bugs.launchpad.net/bugs/591280 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 591280] [NEW] The package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1.
Public bug reported: Binary package hint: openoffice.org I guess this happened during an automatic security update because I wasn't running any update manager at the time that I noticed the apport bug report popping up in Gnome's notification area. I was however running OpenOffice writer, which might have something to do with it?! ProblemType: Package Architecture: amd64 Date: Tue Jun 8 14:11:15 2010 DistroRelease: Ubuntu 9.10 ErrorMessage: subprocess new pre-installation script returned error exit status 1 Package: openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 PackageArchitecture: all ProcVersionSignature: Ubuntu 2.6.31-22.60-generic SourcePackage: openoffice.org Title: package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1 Uname: Linux 2.6.31-22-generic x86_64 ** Affects: openoffice.org (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-package -- The package openoffice.org-emailmerge 1:3.1.1-5ubuntu1.1 failed to install/upgrade: subprocess new pre-installation script returned error exit status 1. https://bugs.launchpad.net/bugs/591280 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 374246] Re: Menue "File" opens unexpected in Writer
I can confirm (for what it is worth) that running BlueProximity and OpenOffice Writer at the same time causes the File menu in OpenOffice writer to open unexpectedly every N seconds, where N is the "Command interval" configured in BlueProximity. For those who don't know BlueProximity, it locks your screen when you walk away from your computer (your Bluetooth phone goes out of range) and unlocks the screen when you return (your Bluetooth phone gets back in range). It also simulates user activity every N seconds using the command "gnome- screensaver-command -p" for as long as your Bluetooth phone is in range, which is what is causing this problem. So this bug has nothing to do with Totem or BlueProximity, but rather the interaction between "gnome-screensaver-command -p" and OpenOffice writer. To demonstrate this, open a terminal, execute the command "while sleep 1; do gnome-screensaver-command -p; done" and focus the OpenOffice Writer window. The File menu will now open and close itself every single second... A temporary workaround for those who want to use BlueProximity and OpenOffice Writer at the same time: Clear the textbox "Proximity command" in the configuration dialog of BlueProximity. ** Changed in: openoffice.org (Ubuntu) Status: Invalid => New -- Menue "File" opens unexpected in Writer https://bugs.launchpad.net/bugs/374246 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
