[Touch-packages] [Bug 1776622] Re: snapd updates on focal never finish installing. Can't install any other updates.
I also hit this today while running 'do-release-upgrade --dev' to upgrade a system from eoan to focal. I was hesitant to kill the release upgrade and restart it, so I used a different workaround: - opened a second terminal - Run 'ps -A fwww', notice the following line: 2629 ?Ssl0:00 /usr/bin/snap wait system seed.loaded - Kill that process After doing this, the release upgrade continued. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1776622 Title: snapd updates on focal never finish installing. Can't install any other updates. Status in snapd: Confirmed Status in snapd package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: snapd (2.33+18.10ubuntu3) cosmic never finishes installing. Can't install any other updates. The first time I gave up waiting and killed it. Then... $ sudo apt full-upgrade E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem. $ sudo dpkg --configure -a Setting up snapd (2.33+18.10ubuntu3) ... snapd.snap-repair.service is a disabled or a static unit, not starting it. << never ends >> All the while the snap and snapd process use about 0.3% CPU (which is more than usual). WORKAROUND: sudo killall apt dpkg sudo dpkg -r snapd gnome-software-plugin-snap sudo apt update sudo apt full-upgrade --- ProblemType: Bug DistroRelease: Ubuntu 18.10 Package: snapd 2.33+18.10ubuntu3 ProcVersionSignature: Ubuntu 4.15.0-22.24-generic 4.15.17 Uname: Linux 4.15.0-22-generic x86_64 ApportVersion: 2.20.10-0ubuntu3 Architecture: amd64 Date: Wed Jun 13 16:49:20 2018 InstallationDate: Installed on 2018-05-26 (17 days ago) InstallationMedia: Ubuntu 18.10 "Cosmic Cuttlefish" - Alpha amd64 (20180525) ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_AU.UTF-8 SHELL=/bin/bash SourcePackage: snapd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1776622/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1588562] Re: Please add ~/.local/bin to the default $PATH
@doko: This still needs to be re-fixed in Debian, right? -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1588562 Title: Please add ~/.local/bin to the default $PATH Status in bash package in Ubuntu: Fix Released Status in bash source package in Xenial: Fix Released Status in bash package in Debian: Fix Released Bug description: Starting in Xenial, 'pip install' by default places executables into ~/.local/bin. This is the de-facto standard place to put per-user executables -- for example, Fedora/Redhat puts it on the $PATH by default, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts. But unfortunately, Ubuntu's does *not* add this directory to $PATH by default, which means that 'pip install' doesn't actually work -- any scripts that are installed are inaccessible, and every user has to manually add this to their PATH. Ubuntu should put ~/.local/bin onto PATH by default. Minor details (discussed with @doko at the PyCon sprints): - this should go at the beginning of PATH rather than the end, in accordance with Debian policy saying that more-local paths go before more-upstream paths. (This is inconsistent with how Fedora/RH do it, but consistent with how Python itself searches for packages.) - this will be added to /etc/skel/profile, so that it won't change any existing user accounts; it will only be applied to user accounts created *after* this change lands - unlike ~/bin (which Debian/Ubuntu have supported for ages), it will be added to PATH unconditionally, even if the directory doesn't exist. This is important to avoid a nasty trap for new users, where the first time they try to install a Python package they have to restart their shell. Since this only applies to new accounts, the directory will always start out nonexistent/empty, so having it in $PATH won't cause any unexpected changes in behavior. - possibly it would make sense to set this in /etc/environment or /etc/skel/.gnomerc or similar, so that it would also apply to non-shell processes (e.g. if the user wants to add a global key-binding to launch a Python program, then generally ~/.profile *doesn't* affect the environment where this command gets executed, and that can frustrate and confuse users if a command works fine from the terminal but not from a keybinding). But we should defer this discussion for the future, because even if this is a good idea, it isn't a good idea in a Xenial stable update. Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820856 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1588562/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1588562] [NEW] Please add ~/.local/bin to the default $PATH
Public bug reported: Starting in Xenial, 'pip install' by default places executables into ~/.local/bin. This is the de-facto standard place to put per-user executables -- for example, Fedora/Redhat puts it on the $PATH by default, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts. But unfortunately, Ubuntu's does *not* add this directory to $PATH by default, which means that 'pip install' doesn't actually work -- any scripts that are installed are inaccessible, and every user has to manually add this to their PATH. Ubuntu should put ~/.local/bin onto PATH by default. Minor details (discussed with @doko at the PyCon sprints): - this should go at the beginning of PATH rather than the end, in accordance with Debian policy saying that more-local paths go before more-upstream paths. (This is inconsistent with how Fedora/RH do it, but consistent with how Python itself searches for packages.) - this will be added to /etc/skel/profile, so that it won't change any existing user accounts; it will only be applied to user accounts created *after* this change lands - unlike ~/bin (which Debian/Ubuntu have supported for ages), it will be added to PATH unconditionally, even if the directory doesn't exist. This is important to avoid a nasty trap for new users, where the first time they try to install a Python package they have to restart their shell. Since this only applies to new accounts, the directory will always start out nonexistent/empty, so having it in $PATH won't cause any unexpected changes in behavior. - possibly it would make sense to set this in /etc/environment or /etc/skel/.gnomerc or similar, so that it would also apply to non-shell processes (e.g. if the user wants to add a global key-binding to launch a Python program, then generally ~/.profile *doesn't* affect the environment where this command gets executed, and that can frustrate and confuse users if a command works fine from the terminal but not from a keybinding). But we should defer this discussion for the future, because even if this is a good idea, it isn't a good idea in a Xenial stable update. Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820856 ** Affects: bash (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to bash in Ubuntu. https://bugs.launchpad.net/bugs/1588562 Title: Please add ~/.local/bin to the default $PATH Status in bash package in Ubuntu: New Bug description: Starting in Xenial, 'pip install' by default places executables into ~/.local/bin. This is the de-facto standard place to put per-user executables -- for example, Fedora/Redhat puts it on the $PATH by default, and PEP 370 makes it the standard place for unprivileged installs of Python packages to put their scripts. But unfortunately, Ubuntu's does *not* add this directory to $PATH by default, which means that 'pip install' doesn't actually work -- any scripts that are installed are inaccessible, and every user has to manually add this to their PATH. Ubuntu should put ~/.local/bin onto PATH by default. Minor details (discussed with @doko at the PyCon sprints): - this should go at the beginning of PATH rather than the end, in accordance with Debian policy saying that more-local paths go before more-upstream paths. (This is inconsistent with how Fedora/RH do it, but consistent with how Python itself searches for packages.) - this will be added to /etc/skel/profile, so that it won't change any existing user accounts; it will only be applied to user accounts created *after* this change lands - unlike ~/bin (which Debian/Ubuntu have supported for ages), it will be added to PATH unconditionally, even if the directory doesn't exist. This is important to avoid a nasty trap for new users, where the first time they try to install a Python package they have to restart their shell. Since this only applies to new accounts, the directory will always start out nonexistent/empty, so having it in $PATH won't cause any unexpected changes in behavior. - possibly it would make sense to set this in /etc/environment or /etc/skel/.gnomerc or similar, so that it would also apply to non-shell processes (e.g. if the user wants to add a global key-binding to launch a Python program, then generally ~/.profile *doesn't* affect the environment where this command gets executed, and that can frustrate and confuse users if a command works fine from the terminal but not from a keybinding). But we should defer this discussion for the future, because even if this is a good idea, it isn't a good idea in a Xenial stable update. Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820856 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1588562/+subscriptions -- Mailing list:
