Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/10/20 11:25 PM, David C. Rankin wrote: > On 8/10/20 10:10 PM, Eli Schwartz via arch-general wrote: >> After that many errors, why did you try rebooting without fixing things >> first? The obvious first step is to try rerunning all of those hooks >> using a modern pacman. >> >> (Do not do a year's worth of updates in one go like that, it's not >> tested and might break. It is preferred instead to do incremental >> updates via https://wiki.archlinux.org/index.php/Arch_Linux_Archive in >> e.g. monthly increments, but if you insist on doing the whole thing in >> one shot then at least use the latest version of pacman via my >> pacman-static binaries, or the install media + pacman --sysroot /mnt -Syu) > > Thank you Eli, > > Well, to be honest, I knew pacman had been updated and I thought rebooting > would fix it :) -- Oh well, maybe not > > pacman is fully updated now, right? So if I take that list and go back and > try re-running the hooks -- that may be one way to fix it? Worse come to > worse, I'll just wipe /root and reinstall... Depends on the hook. Some of them use NeedsTargets, so the Exec command needs to receive the list of triggering files on stdin. Reinstalling all currently installed packages would have the same effect, no need to wipe anything. If you have the list of packages which were updated at that time, you could just update them alone. Otherwise it might take a bit of fiddling to ensure every hook runs correctly. > So for my edification -- what happened was after update, the new pacman was > installed along with the new hooks, but since the pacman I ran the update from > was too old, it croaked trying to run the new hooks from the updated pacman? > > Will we give it a go. Correct. Again, using https://aur.archlinux.org/packages/pacman-static#pinned-666894 renders this concern irrelevant since you'd end up running the most recent pacman in order to perform the update and run hooks. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/10/20 10:10 PM, Eli Schwartz via arch-general wrote: > After that many errors, why did you try rebooting without fixing things > first? The obvious first step is to try rerunning all of those hooks > using a modern pacman. > > (Do not do a year's worth of updates in one go like that, it's not > tested and might break. It is preferred instead to do incremental > updates via https://wiki.archlinux.org/index.php/Arch_Linux_Archive in > e.g. monthly increments, but if you insist on doing the whole thing in > one shot then at least use the latest version of pacman via my > pacman-static binaries, or the install media + pacman --sysroot /mnt -Syu) Thank you Eli, Well, to be honest, I knew pacman had been updated and I thought rebooting would fix it :) -- Oh well, maybe not pacman is fully updated now, right? So if I take that list and go back and try re-running the hooks -- that may be one way to fix it? Worse come to worse, I'll just wipe /root and reinstall... So for my edification -- what happened was after update, the new pacman was installed along with the new hooks, but since the pacman I ran the update from was too old, it croaked trying to run the new hooks from the updated pacman? Will we give it a go. -- David C. Rankin, J.D.,P.E. signature.asc Description: OpenPGP digital signature
Re: [arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
On 8/10/20 10:58 PM, David C. Rankin wrote: > All, > > I was updating an arch install on a platter drive for my laptop that had not > been updated since June 2019. The update was uneventful, only dependency issue > was lib86xxdga a dependency for mplayer that was installed as a dependency of > ogmrip. So, before update I uninstalled ogmrip, mplayer and dependencies that > removed the issue. > > Update of 1568 packages proceeded normally, until the post-install hooks > started to run. A /usr/share/libalpm/hooks path problem occurred. The > following is the output from pacman: > > ... > (1568/1568) upgrading zsh > [] 100% > error: hook /usr/share/libalpm/hooks/30-systemd-tmpfiles.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/20-systemd-sysusers.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/70-dkms-install.hook line 4: invalid > value Path > error: hook /usr/share/libalpm/hooks/glib-compile-schemas.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/gtk-update-icon-cache.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/update-desktop-database.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/dconf-update.hook line 2: invalid value > Path > error: hook /usr/share/libalpm/hooks/30-systemd-catalog.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/30-systemd-update.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/detect-old-perl-modules.hook line 4: > invalid value Path > error: hook /usr/share/libalpm/hooks/texinfo-remove.hook line 2: invalid value > Path > error: hook /usr/share/libalpm/hooks/30-systemd-udev-reload.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/update-appstream-cache.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/dbus-reload.hook line 2: invalid value > Path > error: hook /usr/share/libalpm/hooks/update-vlc-plugin-cache.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/30-systemd-sysctl.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/70-dkms-upgrade.hook line 3: invalid > value Path > error: hook /usr/share/libalpm/hooks/fontconfig.hook line 2: invalid value > Path > error: hook /usr/share/libalpm/hooks/30-systemd-binfmt.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/gio-querymodules.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/vimdoc.hook line 5: invalid value Path > error: hook /usr/share/libalpm/hooks/xorg-mkfontscale.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/texinfo-install.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/30-systemd-daemon-reload.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/gdk-pixbuf-query-loaders.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/gtk-query-immodules-2.0.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/40-update-ca-trust.hook line 5: invalid > value Path > error: hook /usr/share/libalpm/hooks/30-systemd-hwdb.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/update-mime-database.hook line 2: invalid > value Path > error: hook /usr/share/libalpm/hooks/gtk-query-immodules-3.0.hook line 2: > invalid value Path > error: hook /usr/share/libalpm/hooks/71-dkms-remove.hook line 3: invalid value > Path > :: Running post-transaction hooks... > (1/3) Updating module dependencies... > (2/3) Restarting cronie for libc upgrade... > (3/3) Updating linux initcpios... > > Now when I attempt to boot, After that many errors, why did you try rebooting without fixing things first? The obvious first step is to try rerunning all of those hooks using a modern pacman. (Do not do a year's worth of updates in one go like that, it's not tested and might break. It is preferred instead to do incremental updates via https://wiki.archlinux.org/index.php/Arch_Linux_Archive in e.g. monthly increments, but if you insist on doing the whole thing in one shot then at least use the latest version of pacman via my pacman-static binaries, or the install media + pacman --sysroot /mnt -Syu) > it shows systemd 246.1 and then "root clean ..." > and then tty1 appears to hang, no network is started and for all practical > purposes it just appears to be hung. "Alt + ->" switches to tty2 and the > normal login prompt is displayed and I can login just fine, su to root, and > the system appears to be working (but without any network and attempting to > restart the netctl service for wireless fails) > > The journal shows /boot and /home mounted fine and systemd started and > targets Multi-User and Graphical reached and sddm start and Startup finishes: > > Aug 10 17:11:28 seidr systemd[1]: Reached target Multi-User System. > Aug 10 17:11:28 seidr dbus-daemon[481]: [system] Activating
[arch-general] pacman -Syu ~ 1 yr. of packages, tty1 hangs after root clean, tty2 console login OK - how to fix?
All, I was updating an arch install on a platter drive for my laptop that had not been updated since June 2019. The update was uneventful, only dependency issue was lib86xxdga a dependency for mplayer that was installed as a dependency of ogmrip. So, before update I uninstalled ogmrip, mplayer and dependencies that removed the issue. Update of 1568 packages proceeded normally, until the post-install hooks started to run. A /usr/share/libalpm/hooks path problem occurred. The following is the output from pacman: ... (1568/1568) upgrading zsh [] 100% error: hook /usr/share/libalpm/hooks/30-systemd-tmpfiles.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/20-systemd-sysusers.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/70-dkms-install.hook line 4: invalid value Path error: hook /usr/share/libalpm/hooks/glib-compile-schemas.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/gtk-update-icon-cache.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/update-desktop-database.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/dconf-update.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-catalog.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-update.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/detect-old-perl-modules.hook line 4: invalid value Path error: hook /usr/share/libalpm/hooks/texinfo-remove.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-udev-reload.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/update-appstream-cache.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/dbus-reload.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/update-vlc-plugin-cache.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-sysctl.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/70-dkms-upgrade.hook line 3: invalid value Path error: hook /usr/share/libalpm/hooks/fontconfig.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-binfmt.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/gio-querymodules.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/vimdoc.hook line 5: invalid value Path error: hook /usr/share/libalpm/hooks/xorg-mkfontscale.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/texinfo-install.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-daemon-reload.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/gdk-pixbuf-query-loaders.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/gtk-query-immodules-2.0.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/40-update-ca-trust.hook line 5: invalid value Path error: hook /usr/share/libalpm/hooks/30-systemd-hwdb.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/update-mime-database.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/gtk-query-immodules-3.0.hook line 2: invalid value Path error: hook /usr/share/libalpm/hooks/71-dkms-remove.hook line 3: invalid value Path :: Running post-transaction hooks... (1/3) Updating module dependencies... (2/3) Restarting cronie for libc upgrade... (3/3) Updating linux initcpios... Now when I attempt to boot, it shows systemd 246.1 and then "root clean ..." and then tty1 appears to hang, no network is started and for all practical purposes it just appears to be hung. "Alt + ->" switches to tty2 and the normal login prompt is displayed and I can login just fine, su to root, and the system appears to be working (but without any network and attempting to restart the netctl service for wireless fails) The journal shows /boot and /home mounted fine and systemd started and targets Multi-User and Graphical reached and sddm start and Startup finishes: Aug 10 17:11:28 seidr systemd[1]: Reached target Multi-User System. Aug 10 17:11:28 seidr dbus-daemon[481]: [system] Activating via systemd: service ... Aug 10 17:11:28 seidr systemd[1]: Reached target Graphical Interface. ... Aug 10 17:11:29 seidr sddm[486]: Initializing... Aug 10 17:11:29 seidr sddm[486]: Starting... Aug 10 17:11:29 seidr sddm[486]: Logind interface found ... Aug 10 17:11:29 seidr systemd[1]: Startup finished in 6.449s (kernel) + 13.784s (userspace) = 20.233s. There seem to be problems with kde .desktop files, but the system tries to proceed: Aug 10 17:13:20 seidr systemd[500]: /etc/xdg/autostart/org.kde.kgpg.desktop:8: Unknown key name 'MimeType' in section 'Desktop Entry', ignoring. Aug 10 17:13:20 seidr systemd[500]: /etc/xdg/autostart/kmix_autostart.desktop:6: Unknown key name 'MimeType' in section 'Desktop Entry', ignoring. Aug 10 17:13:20 seidr systemd[500]: Configuration file
Re: [arch-general] Pros/Cons of Python zipapp packaging
On Mon, Aug 10, 2020, 6:46 PM Filipe Laíns via arch-general < arch-general@archlinux.org> wrote: > On Mon, 2020-08-10 at 21:49 +0100, Daan De Meyer via arch-general wrote: > > Hi, > > > > We've been discussing the distribution mechanism for mkosi ( > > https://github.com/systemd/mkosi) and one of the ideas is using Python > > zipapp (https://docs.python.org/3/library/zipapp.html) to allow us to > split > > mkosi up into multiple files for easier development without complicating > > the packaging process. zipapp takes all source files in a directory and > > bundles them up into a single executable python zip archive so after > > building the zip you can simply call ./mkosi to run mkosi and can put it > > anywhere in the PATH to simply run mkosi wherever you want. Are there any > > issues with this approach from a distro packaging perspective? Zipapp > > doesn't bundle a specific python version (uses system python and system > > python stdlib) and we don't intend on bundling any dependencies in the > > zipapp. I don't think I've ever seen a python application packaged this > way > > which is why I'm asking. > > > > Cheers, > > > > Daan > > Hi Daan, > > This approach works, although I am not a fan. Are there any reasons for > you to want to do it this way? Which problem are you trying to solve? > > Python packaging is pretty standardized and I would say that most > likely all the problem you will ever find have been solved already. Why > not adopt the usual approach? > > I do not think this packaging method it would be an issue from a distro > POV, unless some distro specifically has a guideline against this kind > of approach, but it might be an issue for Python standalone packaging. > It is something that can be worked around, but definitely troublesome. > > If you want to support this distribution mechanism *in addition* to the > standard Python packaging, that would be okay. But a distro like arch > would most probably package it the normal way. > > In which case I would ask, who is the user for this? Maybe just as > standalone? That would make some sense, but given the Python ecosystem > has decent tooling nowadays, as an upstream I would probably just tell > users to pip/pipx install mkosi. > > I would say that in spirit it goes against the FHS[1], but that is a > very opinionated and subjective take from my part. Feel free to ignore. > > [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html > > Cheers, > Filipe Laíns > It looks like he wants to make an executable, instead of a module that you import or install Yash >
Re: [arch-general] Pros/Cons of Python zipapp packaging
On 8/10/20 4:49 PM, Daan De Meyer via arch-general wrote: > Hi, > > We've been discussing the distribution mechanism for mkosi ( > https://github.com/systemd/mkosi) and one of the ideas is using Python > zipapp (https://docs.python.org/3/library/zipapp.html) to allow us to split > mkosi up into multiple files for easier development without complicating > the packaging process. zipapp takes all source files in a directory and > bundles them up into a single executable python zip archive so after > building the zip you can simply call ./mkosi to run mkosi and can put it > anywhere in the PATH to simply run mkosi wherever you want. Are there any > issues with this approach from a distro packaging perspective? Zipapp > doesn't bundle a specific python version (uses system python and system > python stdlib) and we don't intend on bundling any dependencies in the > zipapp. I don't think I've ever seen a python application packaged this way > which is why I'm asking. This is more or less the same as adding a zip file to the PYTHONPATH, and importing from it -- it works, from a python perspective, no different from unzipping the files into site-packages. The difference is it is only available when you run the file (plus special considerations for __main__). As you say, this isn't trying to bundle dependencies. It's not really functionally different from just having all code in one script file. On the other hand, this introduces size overhead for packaging due to multiple layers of compression (and zip is not very good at this anyway), probably doesn't play nice with bytecode generation, and reduces the effectiveness of a nice side effect of scripted languages, which is that users can trivially read the script, edit it, etc. Minor niggles, really. I wouldn't consider it a real blocker, personally. That being said, I'd guess the only specific advantage this has over installing as a PEP 376-style Installed Python Distribution is the fact that a single file can reliably locate itself when invoked with sudo, rather than losing track of a 'pip install --user' installed version with a builtin user-specific sys.path that isn't preserved by sudo. Do they necessarily need to be incompatible? You could have a pip-installable mkosi/ which can be used with 'python3 -m mkosi' due to possessing a __main__.py, but which can *also* be zipapp'ed for portability. It might behave very weirdly in the pip install --user case, but on the other hand Arch users will always use the bleeding-edge package, while Debian customizes their distro python package with an elaborate hack to make "sudo pip install" be officially supported and not touch dpkg-managed files. I'm not positive what guidance to give you beyond "I don't think this violates the packaging guidelines in the slightest, so have no fear on that count". -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: [arch-general] Pros/Cons of Python zipapp packaging
On Mon, 2020-08-10 at 21:49 +0100, Daan De Meyer via arch-general wrote: > Hi, > > We've been discussing the distribution mechanism for mkosi ( > https://github.com/systemd/mkosi) and one of the ideas is using Python > zipapp (https://docs.python.org/3/library/zipapp.html) to allow us to split > mkosi up into multiple files for easier development without complicating > the packaging process. zipapp takes all source files in a directory and > bundles them up into a single executable python zip archive so after > building the zip you can simply call ./mkosi to run mkosi and can put it > anywhere in the PATH to simply run mkosi wherever you want. Are there any > issues with this approach from a distro packaging perspective? Zipapp > doesn't bundle a specific python version (uses system python and system > python stdlib) and we don't intend on bundling any dependencies in the > zipapp. I don't think I've ever seen a python application packaged this way > which is why I'm asking. > > Cheers, > > Daan Hi Daan, This approach works, although I am not a fan. Are there any reasons for you to want to do it this way? Which problem are you trying to solve? Python packaging is pretty standardized and I would say that most likely all the problem you will ever find have been solved already. Why not adopt the usual approach? I do not think this packaging method it would be an issue from a distro POV, unless some distro specifically has a guideline against this kind of approach, but it might be an issue for Python standalone packaging. It is something that can be worked around, but definitely troublesome. If you want to support this distribution mechanism *in addition* to the standard Python packaging, that would be okay. But a distro like arch would most probably package it the normal way. In which case I would ask, who is the user for this? Maybe just as standalone? That would make some sense, but given the Python ecosystem has decent tooling nowadays, as an upstream I would probably just tell users to pip/pipx install mkosi. I would say that in spirit it goes against the FHS[1], but that is a very opinionated and subjective take from my part. Feel free to ignore. [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs.html Cheers, Filipe Laíns signature.asc Description: This is a digitally signed message part
[arch-general] Pros/Cons of Python zipapp packaging
Hi, We've been discussing the distribution mechanism for mkosi ( https://github.com/systemd/mkosi) and one of the ideas is using Python zipapp (https://docs.python.org/3/library/zipapp.html) to allow us to split mkosi up into multiple files for easier development without complicating the packaging process. zipapp takes all source files in a directory and bundles them up into a single executable python zip archive so after building the zip you can simply call ./mkosi to run mkosi and can put it anywhere in the PATH to simply run mkosi wherever you want. Are there any issues with this approach from a distro packaging perspective? Zipapp doesn't bundle a specific python version (uses system python and system python stdlib) and we don't intend on bundling any dependencies in the zipapp. I don't think I've ever seen a python application packaged this way which is why I'm asking. Cheers, Daan
