Re: [arch-general] pacman -Syu -- Applying kernel sysctl settings... Not setting ... Worry?
I fixed a bug in systemd where its binaries would output to the journal instead of stdout when invoked as a child process by pacman. This output was always there, you just didn't see it until now because it went to the journal instead of stdout. I get the same messages so I wouldn't worry about it. Cheers, Daan On Sat, Aug 22, 2020, 5:12 AM David C. Rankin < drankina...@suddenlinkmail.com> wrote: > Arch devs, > > For the past several updates, I have noticed the kernel sysctl settings > messages saying: > > ( 5/17) Applying kernel sysctl settings... > Not setting net/ipv4/conf/all/rp_filter (explicit setting exists). > Not setting net/ipv4/conf/default/rp_filter (explicit setting exists). > Not setting net/ipv4/conf/all/accept_source_route (explicit setting > exists). > Not setting net/ipv4/conf/default/accept_source_route (explicit setting > exists). > Not setting net/ipv4/conf/all/promote_secondaries (explicit setting > exists). > Not setting net/ipv4/conf/default/promote_secondaries (explicit setting > exists). > > After the recent netctl message issue, I want to nail down what set > these in > /proc and whether it is something I need to do something about. I didn't > set > any of these specifically, so I presume they are either explicit settings > made > during the kernel build or they were set somewhere long ago by some > previous > Arch default. In either case, if there were no issues, I wouldn't expect > pacman to go out of its way to tell me about them if nothing needs to be > done. > > Though I can also see the messages just being some default behavior of > whatever the kernel sysctl hook is warning about choices that are > explicitly set. > > Do I need to do anything about these? > > > -- > David C. Rankin, J.D.,P.E. >
Re: [arch-general] Pros/Cons of Python zipapp packaging
I was evaluating whether we could simply avoid pip altogether and get by with zipapp only as it's quite simple and avoids pip altogether. As Eli deduced correctly, the big advantage is getting an executable that you put anywhere and run with sudo without python having trouble finding the corresponding python module. This would let you put the archive in ~/.local/bin (assuming that is in the PATH) and let you run sudo mkosi without getting import errors because python can't find the mkosi modules. To get that working with pip it seems you're forced to write a bash script that adds the user's site packages directory to PYTHONPATH before invoking mkosi itself with python which works but feels a bit hacky. I guess if it didn't have issues python would likely do it by default. Anyway, thanks for the discussion. For now, we'll support both approaches so users and distro packagers have the final choice in what they decide to use. Daan On Tue, 11 Aug 2020 at 01:25, karx via arch-general < arch-general@archlinux.org> wrote: > 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 > > > >
[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
Re: [arch-general] Locale packages
Alright, thanks for all the info. I'll leave this be for now until the C.UTF-8 support in upstream glibc is released. If they manage to reduce the size sufficiently to have it built-in, there might not even be anything to change on Arch's side. Daan
Re: [arch-general] Locale packages
> Very firm -1 to any approach that involves creating hundreds of new > packages which each provide a tiny file. You're right, this would be overkill. Even when limiting to only UTF-8 we'd still have 313 packages. > This is not about locale-gen. locale-gen (and /etc/locale.gen) are > Arch-specific custom scripts which IIRC were copied from Debian once > upon a time, which just run localedef. I actually use a much simpler > locale-gen program which uses flag files e.g. /etc/locales/en_US (file > contents can contain a charset but are otherwise assumed to be UTF-8). > It's not hard to hack your own. Running localedef directly doesn't really solve any of the issues I mentioned either though. What if we make do with a single locale package? I just found out there's some progress on the C.UTF-8 locale upstream support in glibc ( https://sourceware.org/pipermail/libc-alpha/2020-June/115224.html). It doesn't look like it will be built-in though unless they manage to get the size down significantly. If it isn't built-in, maybe we could add a single package just for the C.UTF-8 locale? That should be sufficient for 95% of the "I'm building an Arch container/vm image for development/server/any other development stuff" use cases which generally will be using an english locale and avoids all the problems I mentioned earlier without requiring the addition of 300+ packages. It'll have to wait until we have C.UTF-8 in glibc though. I guess we could add a package for en_US.UTF-8 as a stopgap but that doesn't seem worth the effort assuming C.UTF-8 gets merged in a reasonable timeframe. As an example of why one would need a UTF-8 locale specifically in a container/vm image, meson (actually python) does not like running under a non UTF-8 locale at all. (I don't use mailing lists very often, I hope I didn't mess up the reply etiquette) Daan On Mon, 22 Jun 2020 at 22:31, Eli Schwartz via arch-general < arch-general@archlinux.org> wrote: > On 6/22/20 3:11 PM, Daan De Meyer via arch-general wrote: > > Hi, > > > > While working on locale-gen support for systemd-firstboot ( > > https://github.com/systemd/systemd/pull/15994), I started wondering if > it > > wouldn't be simpler to delegate the installation of locales to pacman > > instead. I haven't been following the mailing lists for very long so I > > don't know if this has ever been discussed. I'd imagine Arch could > provide > > a package for each locale supported by glibc and users would install the > > ones they need. > > Very firm -1 to any approach that involves creating hundreds of new > packages which each provide a tiny file. > > > The PKGBUILD would use localedef to generate separate folders of compiled > > locale files for each locale that would be stored in /usr/lib/locale. > This > > approach is already implemented by distros such as Fedora (and co) and > > Ubuntu. > > > > The main advantage of this approach is that there's no need to set up an > > entire chroot to run locale-gen when pacstrapping a new Arch system > image. > > This might seem easy but becomes trickier when the image uses a different > > architecture than the host system since emulation of that architecture > has > > to be set up first. Even if locale-gen had a --root option so using the > > host's locale-gen would be an option, I'm not sure if there's any > guarantee > > that compiled locale definitions generated by the host system's > locale-gen > > would work with the glibc version used by the image (less of a problem > with > > Arch but the glibc on the host could still potentially be out-of-date > > compared to the one installed in the image). Being able to install > locales > > with pacman would solve all these problems. > > > > Any interest in something like this from the Arch developers? I'd be > > willing to try my hand at a PKGBUILD for this but I'm not a TU so I'd > need > > some support to get this implemented (if there is any interest at all). > > > > (This also doesn't imply that locale-gen wouldn't work anymore, > locale-gen > > stores everything in /usr/lib/locale/locale-archive which would be > > independent from the files installed by the locale packages, so both > > approaches should work side-by-side) > > This is not about locale-gen. locale-gen (and /etc/locale.gen) are > Arch-specific custom scripts which IIRC were copied from Debian once > upon a time, which just run localedef. I actually use a much simpler > locale-gen program which uses flag files e.g. /etc/locales/en_US (file > contents can contain a charset but are otherwise assumed to be UTF-8). > It's not hard to hack your own. > > IIRC Fedora follows the "hundreds of packages which each
[arch-general] Locale packages
Hi, While working on locale-gen support for systemd-firstboot ( https://github.com/systemd/systemd/pull/15994), I started wondering if it wouldn't be simpler to delegate the installation of locales to pacman instead. I haven't been following the mailing lists for very long so I don't know if this has ever been discussed. I'd imagine Arch could provide a package for each locale supported by glibc and users would install the ones they need. The PKGBUILD would use localedef to generate separate folders of compiled locale files for each locale that would be stored in /usr/lib/locale. This approach is already implemented by distros such as Fedora (and co) and Ubuntu. The main advantage of this approach is that there's no need to set up an entire chroot to run locale-gen when pacstrapping a new Arch system image. This might seem easy but becomes trickier when the image uses a different architecture than the host system since emulation of that architecture has to be set up first. Even if locale-gen had a --root option so using the host's locale-gen would be an option, I'm not sure if there's any guarantee that compiled locale definitions generated by the host system's locale-gen would work with the glibc version used by the image (less of a problem with Arch but the glibc on the host could still potentially be out-of-date compared to the one installed in the image). Being able to install locales with pacman would solve all these problems. Any interest in something like this from the Arch developers? I'd be willing to try my hand at a PKGBUILD for this but I'm not a TU so I'd need some support to get this implemented (if there is any interest at all). (This also doesn't imply that locale-gen wouldn't work anymore, locale-gen stores everything in /usr/lib/locale/locale-archive which would be independent from the files installed by the locale packages, so both approaches should work side-by-side) Cheers, Daan De Meyer
[arch-general] Disable pam_securetty.so
Hi, I don't want to come across as impatient but I was wondering how I can accelerate handling of this particular issue: https://bugs.archlinux.org/task/45903?project=1=pam I've listed examples in the issue that pam_securetty has been disabled on other major distros. The main issue is that it prevents root login on systemd-nspawn containers. It should be easy to remove and there's a precedence in other distros. Any tips on how to proceed to get this fixed? Regards, Daan
[arch-general] Cannot create account on bugs.archlinux.org
Hi, When trying to create an account on bugs.archlinux.org, I get the following error message: Completely unexpected exception: Connection could not be established with > host 127.0.0.1:10027 [Connection refused #111] > This should never happend, please inform Flyspray Developers > Have I missed a downtime announcement somewhere or is something wrong with Flyspray? Best regards, Daan De Meyer
