Re: [systemd-devel] mkosi question: third party repos + dnf modules
Hi, --repositories in mkosi is currently a bit limited. For Fedora and CentOS, we only support passing names of existing repositories that should be enabled. https://github.com/systemd/mkosi/issues/536 reported a similar problem. We should definitely make this work better than it does now but it's going to require a bit of thinking on how to properly support this in a way that works for all major supported distros. For now, I think postinst is the best solution. Cheers, Daan On Mon, 7 Dec 2020 at 10:28, Colin Guthrie wrote: > > Hiya, > > Trying to create some CentOS 8 images with mkosi 8 > > Is it possible to use the --repositories argument to mkosi to enable a > third party repository? If so can you tell me the secret syntax? > > I've tried: > > --repositories=https:///mirrorlist > --repositories=https:///directlink > > both say: unknown repo > > > I've tried copying in the appropriate *.repo files via > mkosi.skeleton/etc/yum.repos.d/*.repo and then referring to the repo by > name rather than URL and it doesn't work either (also tried full path > within container and file:// prefixed path) with the same unknown repo > error. > > > I know I could do this with a postinst script but I feel like this > should be possible via the --repositories argument! > > (NB, I'm actually using Repositories= in the [Distribution] section of > an mkosi.default file rather than the command line directly but this > /shouldn't/ make a difference!] > > The next question is: can we setup dnf modules as part of the initial > install? If not, then I'll likely have to go down the postinst route > anyway in this case, but the above is still interesting for e.g. custom > COPR repos etc. > > Cheers > > Col > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: add instruction on clearing file descriptors
I'm not sure if it's more portable. I recall FreeBSD only exposing 0–2 in its /dev/fd by default unless you mounted a separate virtual filesystem there. NetBSD seems to always have 64 devnodes no matter how many fds. I don't think there's a *good* portable method (which is why closerange() is being added) and besides that I'm not sure if that is even in scope for this systemd-centric manpage...the whole idea is that under systemd, a daemon shouldn't need that. On Mon, Dec 7, 2020, 19:30 Petar Kapriš wrote: > In the daemon.7 manpage, I added an instruction on closing open file > descriptors, an important step in daemon startup, showing an option to > close them using the files in /dev/fd (a more portable alternative > across systems to using /proc/self/fd) > --- > man/daemon.xml | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/man/daemon.xml b/man/daemon.xml > index db95d2f75b..4bae6ebb82 100644 > --- a/man/daemon.xml > +++ b/man/daemon.xml > @@ -47,12 +47,13 @@ > Close all open file descriptors except > standard input, output, and error (i.e. the first three file > descriptors 0, 1, 2). This ensures that no accidentally passed > -file descriptor stays around in the daemon process. On Linux, > -this is best implemented by iterating through > -/proc/self/fd, with a fallback of > -iterating from file descriptor 3 to the value returned by > +file descriptor stays around in the daemon process. On most > +modern systems, this is best implemented by iterating through > +/dev/fd, or > +/proc/self/fd on Linux, with a fallback > +of iterating from file descriptor 3 to the value returned by > getrlimit() for > -RLIMIT_NOFILE. > +RLIMIT_NOFILE. > > Reset all signal handlers to their default. > This is best done by iterating through the available signals > -- > 2.29.2 > > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/systemd-devel > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: add instruction on clearing file descriptors
In the daemon.7 manpage, I added an instruction on closing open file descriptors, an important step in daemon startup, showing an option to close them using the files in /dev/fd (a more portable alternative across systems to using /proc/self/fd) --- man/daemon.xml | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/man/daemon.xml b/man/daemon.xml index db95d2f75b..4bae6ebb82 100644 --- a/man/daemon.xml +++ b/man/daemon.xml @@ -47,12 +47,13 @@ Close all open file descriptors except standard input, output, and error (i.e. the first three file descriptors 0, 1, 2). This ensures that no accidentally passed -file descriptor stays around in the daemon process. On Linux, -this is best implemented by iterating through -/proc/self/fd, with a fallback of -iterating from file descriptor 3 to the value returned by +file descriptor stays around in the daemon process. On most +modern systems, this is best implemented by iterating through +/dev/fd, or +/proc/self/fd on Linux, with a fallback +of iterating from file descriptor 3 to the value returned by getrlimit() for -RLIMIT_NOFILE. +RLIMIT_NOFILE. Reset all signal handlers to their default. This is best done by iterating through the available signals -- 2.29.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [FIX] SANE udev rules processing performance
W dniu 07.12.2020 o 11:25, Lennart Poettering pisze: On So, 06.12.20 11:13, Marcin Kocur (marcin2...@gmail.com) wrote: The concern is: "Recalling #341 (closed), I do have some concerns about efficiency now that those 650+ USB rules get processed for every non-removal event rather than only for additions." If you could answer in the MR comments, that would also be fine: https://gitlab.com/sane-project/backends/-/merge_requests/541 Sorry for the stupid request, but I'm just a SANE user who tries to fix his (and everyone's else) scanners. I don't have much knowledge about udev rules processing performance. Replied there now. Lennart Thanks a thousand! I guess there will be a major rules refactor at some day on SANE's side... -- Pozdrawiam / Greetings Marcin Kocur █ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [FIX] SANE udev rules processing performance
On So, 06.12.20 11:13, Marcin Kocur (marcin2...@gmail.com) wrote: > The concern is: > "Recalling #341 (closed), I do have some concerns about efficiency now that > those 650+ USB rules get processed for every non-removal event rather than > only for additions." > > If you could answer in the MR comments, that would also be fine: > > https://gitlab.com/sane-project/backends/-/merge_requests/541 > > Sorry for the stupid request, but I'm just a SANE user who tries to fix his > (and everyone's else) scanners. I don't have much knowledge about udev rules > processing performance. Replied there now. Lennart -- Lennart Poettering, Berlin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
