Re: goal: booting with an empty /etc

[Zbigniew Jędrzejewski-Szmek]

I'm not entirely sure if you're just doing Friday trolling or if
you're serious. I'll reply for real, apologies if this was meant as
a joke.

On Fri, Dec 08, 2023 at 12:59:22PM -0500, DJ Delorie wrote:
> Zbigniew Jędrzejewski-Szmek  writes:
> > There is a long-term goal of moving packaged files out of /etc,
> 
> I will note that I'm opposed to this goal as a goal per-se.
> 
> If you want an empty directory, "mkdir /etc2" should work for you.
> 
> I fear this will end like the /tmp fiasco where one /tmp became many tmp
> directories, and no consistent rule about which one to use.

/tmp is generally backed by RAM and does not survive a reboot.
/var/tmp is backed by disk and survives a reboot.
The general rule is pretty clear: ISOs go to /var/tmp, quick
temporary files go to /tmp.

> > so that only actual local configuration remains in /etc.
> 
> This can be achieved without "empty /etc" as a goal.  For example, why
> can't we use podman's overlay filesystem to mount /usr/etc under /etc so
> that all the configuration appears in /etc but installed vs changed
> files are kept segregatable?

(FTR, not "podman's". The filesystem is a kernel thing.)

If the goal was to just move everything wholesale, that'd be a
possible solution. But we actually want to keep things that are local
configuration and move things that are not. So the distinction between
the two types of files still needs to be made. At least at the
packaging level, we would need to put files in a different place. And
then the software that reads the files would occasionally want to
distinguish the two types of config (e.g. to present to the user
whether it's the packaged default or local config, or to merge with
other configuration sources with different priority). So the split
would "leak" into the software anyway, and then it'd need to be
prepared to handle the overlay, and possibly go into the lower layers.
So now we have a much higher level of complexity (three locations,
upper, lower, and combined) to achieve essentially the same functionality.

(Another problem is that this scheme only works "live". If you want
to look *into* an image from the outside, the overlay wouldn't be
assembled, so the tools need to know how to handle the config split
manually.)

> > For example, /etc/services is a list of port:service mappings, and people
> > maybe used to edit that twenty years ago,
> 
> I still edit this one.

Great for you. So you can be the one person who uses the override
mechanism for this file.

> > The same is also true for /etc/bash_completion.d/
> 
> I delete this package completely, so I don't care where its config goes.

YMMV.

> > Another common case is "empty" configuration files, i.e. templates
> > that show the default configuration.
> 
> I find these VERY helpful when trying to fix configuration issues on my
> machines.

Right. I'm not saying that those should go away. Quite the opposite.
My first email had a long paragraph about how to display those files
for systemd in a nice way (with priority sorting, highlighting, and
other niceties.)

Please note that the proposed scheme makes those files *more* useful:
the user can have a local copy with changes. Before, when the package
was updated, we wouldn't override the user's copy, so at best there'd
be a .rpmnew file. Now, the package copy is in a different location
and can be updated freely.

> > Other distributions are ahead of us in supporting empty /etc.
> 
> "Be like everyone else" is not one of our goals.
> 
> > If you are a maintainer of a package with files in /etc, please consider
> > whether they are strictly necessary, and if possible, move stuff to /usr.
> 
> Unless such file could be changed by a user, in which case it belongs in
> /etc.

The option of modifying a package file in place doesn't work great.
The package updates the file and then the user is left with a copy that
stops being updated. The approach of only overriding the parts that
should be overriden is better.

> > At some point, I think we should make this an explicit goal in Fedora.
> 
> Please don't.

You seem to like the current scheme. But it was designed in the times where
people did much more manual tweaking of their systems. We now care a lot
about clean and automatic upgrades. Having to resolve three-way differences
between a bunch of config files conflicts with that.

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[Richard W.M. Jones]

On Sat, Dec 09, 2023 at 08:03:48AM +, Zbigniew Jędrzejewski-Szmek wrote:
> I'm not entirely sure if you're just doing Friday trolling or if
> you're serious. I'll reply for real, apologies if this was meant as
> a joke.

DJ has been hacking on free software since I was still at school, so
no, he's not trolling.

> On Fri, Dec 08, 2023 at 12:59:22PM -0500, DJ Delorie wrote:
> > Zbigniew Jędrzejewski-Szmek  writes:
> > > There is a long-term goal of moving packaged files out of /etc,
> > 
> > I will note that I'm opposed to this goal as a goal per-se.
> > 
> > If you want an empty directory, "mkdir /etc2" should work for you.
> > 
> > I fear this will end like the /tmp fiasco where one /tmp became many tmp
> > directories, and no consistent rule about which one to use.
> 
> /tmp is generally backed by RAM and does not survive a reboot.

And that's a really bad idea, which I always turn off in any computer
or server I manage.  Limiting /tmp to using RAM + swap and having it
erase at reboot is pointless additional complexity.  This caused us to
go through countless lines of code deciding if a temporary file is
"small" (how small? don't know!) and whether it should live in /tmp or
/var/tmp for people who have to suffer this configuration.

Filesystems already use RAM for caching when necessary, and I want
temporary directories with a controlled lifetime, not "whenever the
power happens to go off".  Plus more typing.

> > > At some point, I think we should make this an explicit goal in Fedora.
> > 
> > Please don't.
> 
> You seem to like the current scheme. But it was designed in the times where
> people did much more manual tweaking of their systems. We now care a lot
> about clean and automatic upgrades. Having to resolve three-way differences
> between a bunch of config files conflicts with that.

People use their systems in different ways.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora rawhide compose report: 20231209.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231207.n.1
NEW: Fedora-Rawhide-20231209.n.0

= SUMMARY =
Added images:0
Dropped images:  2
Added packages:  5
Dropped packages:2
Upgraded packages:   67
Downgraded packages: 0

Size of added packages:  336.44 KiB
Size of dropped packages:1.06 MiB
Size of upgraded packages:   9.60 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   60.66 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =

= DROPPED IMAGES =
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231207.n.1.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231207.n.1.iso

= ADDED PACKAGES =
Package: pdqsort-0-2.20210314gitb1ef26a.fc40
Summary: Pattern-defeating quicksort library
RPMs:pdqsort-devel
Size:14.75 KiB

Package: rust-fast-srgb8-1.0.0-1.fc40
Summary: Very fast conversions between linear float and 8-bit sRGB
RPMs:rust-fast-srgb8+default-devel rust-fast-srgb8-devel
Size:31.00 KiB

Package: rust-memmap2_0.7-0.7.1-1.fc40
Summary: Cross-platform Rust API for memory-mapped file IO
RPMs:rust-memmap2_0.7+default-devel 
rust-memmap2_0.7+stable_deref_trait-devel rust-memmap2_0.7-devel
Size:49.51 KiB

Package: rust-palette0.6-0.6.0-1.fc40
Summary: Convert and manage colors with a focus on correctness, flexibility and 
ease of use
RPMs:rust-palette0.6+bytemuck-devel rust-palette0.6+default-devel 
rust-palette0.6+libm-devel rust-palette0.6+named-devel 
rust-palette0.6+named_from_str-devel rust-palette0.6+named_gradients-devel 
rust-palette0.6+phf-devel rust-palette0.6+rand-devel 
rust-palette0.6+random-devel rust-palette0.6+serde-devel 
rust-palette0.6+serializing-devel rust-palette0.6+std-devel 
rust-palette0.6-devel
Size:210.20 KiB

Package: rust-palette_derive0.6-0.6.0-1.fc40
Summary: Automatically implement traits from the palette crate
RPMs:rust-palette_derive0.6+default-devel rust-palette_derive0.6-devel
Size:30.97 KiB


= DROPPED PACKAGES =
Package: intelone-mono-fonts-1.2.1-2.fc39
Summary: An expressive monospaced font family
RPMs:intelone-mono-fonts
Size:262.19 KiB

Package: python-openopt-0.5629-13.fc39
Summary: A python module for numerical optimization
RPMs:python3-openopt
Size:826.96 KiB


= UPGRADED PACKAGES =
Package:  Agda-2.6.4.1-43.fc40
Old package:  Agda-2.6.4-41.fc40
Summary:  A dependently typed functional programming language and proof 
assistant
RPMs: Agda Agda-common ghc-Agda ghc-Agda-devel ghc-Agda-doc 
ghc-Agda-prof ghc-murmur-hash ghc-murmur-hash-devel ghc-murmur-hash-doc 
ghc-murmur-hash-prof ghc-peano ghc-peano-devel ghc-peano-doc ghc-peano-prof 
ghc-vector-hashtables ghc-vector-hashtables-devel ghc-vector-hashtables-doc 
ghc-vector-hashtables-prof
Size: 436.59 MiB
Size change:  91.72 MiB
Changelog:
  * Tue Oct 17 2023 Jens Petersen  - 2.6.4-42
  - F40: enable optimise-heavily flag

  * Thu Dec 07 2023 Jens Petersen  - 2.6.4.1-43
  - https://hackage.haskell.org/package/Agda-2.6.4.1/changelog
  - update peano to 0.1.0.2


Package:  Agda-stdlib-1.7.3-2.fc40
Old package:  Agda-stdlib-1.7.3-1.fc40
Summary:  Agda standard libraries
RPMs: Agda-stdlib Agda-stdlib-docs
Size: 126.45 MiB
Size change:  311.74 KiB
Changelog:
  * Thu Dec 07 2023 Jens Petersen  - 1.7.3-2
  - bump for Agda-2.6.4.1


Package:  MySQL-zrm-3.0-38.fc40
Old package:  MySQL-zrm-3.0-36.fc39
Summary:  MySQL backup manager
RPMs: MySQL-zrm
Size: 146.16 KiB
Size change:  184 B
Changelog:
  * Thu Oct 12 2023 Orion Poplawski  - 3.0-37
  - Require /usr/bin/mail instead of mailx

  * Fri Dec 08 2023 Orion Poplawski  - 3.0-38
  - Add patch to fix tar complaining that ". changed as we read it"


Package:  adw-gtk3-theme-5.2-1.fc40
Old package:  adw-gtk3-theme-5.1-1.fc40
Summary:  The theme from libadwaita ported to GTK-3
RPMs: adw-gtk3-theme
Size: 145.15 KiB
Size change:  64 B
Changelog:
  * Fri Dec 08 2023 Pavel Solovev  - 5.2-1
  - version 5.2


Package:  cargo2rpm-0.1.15-1.fc40
Old package:  cargo2rpm-0.1.14-1.fc40
Summary:  Translation layer between cargo and RPM
RPMs: cargo2rpm
Size: 182.85 KiB
Size change:  235 B
Changelog:
  * Fri Dec 08 2023 Fabio Valentini  - 0.1.15-1
  - Update to version 0.1.15; Fixes RHBZ#2253432


Package:  chkrootkit-0.57-4.fc40
Old package:  chkrootkit-0.57-3.fc40
Summary:  Tool to locally check for signs of a rootkit
RPMs: chkrootkit
Size: 1.41 MiB
Size change:  405 B
Changelog:
  * Thu Dec 07 2023 Gwyn Ciesla  - 0.57-4
  - Drop polkit requirement.


Package:  chromium-120.0.6099.71-1.fc40
Old package:  chromium-120.0.6099.62-1.fc40
Summary:  A WebKit (Blink) powered web browser that Google doesn't want you 
to use
RPMs: chromedriver chromium chromium-common chromium-headless
Size: 

Re: rpmbuild sagemath 10.1 on Fedora 38

[Michael J Gruber]

Am Fr., 8. Dez. 2023 um 23:58 Uhr schrieb Jerry James :

> Please keep your replies on the public mailing list where the
> conversation started.
>
> On Fri, Dec 8, 2023 at 3:39 PM Rafel Amer Ramon 
> wrote:
> > As a first attempt, I didn't use the patches beacuse a lot of them
> failed.
> > Today I have revised and modified some of the patches and I can apply 20
> > of them.
>
> ...

> That would be great.  Hopefully upstream makes good progress on
> supporting python 3.12.
>

 Are there any packages in Fedora which depend on sagemath?

I don't want to discourage anyone from packaging sagemath. But I do think
that sagemath is a prime example of an "app", something that is best
installed as a user (not system wide) via a package manager such as
pip+venv/conda and the like, in particular isolating dependencies (exact
requirements) for that app.

I also think that we have too many leaf packages in Fedora and packagers'
time is better spent on a solid base, not fighting the dependency hell of
an app. Just my 2cents, and no, I'm not a flatpak fanboy either, but no
matter how you run "apps", a solid Fedora base rocks ;-)

Cheers,
Michael
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2023 at 12:14:09PM -0500, Steve Grubb wrote:
> On Friday, December 8, 2023 11:57:55 AM EST Adam Williamson wrote:
> > On Fri, 2023-12-08 at 11:49 -0500, Steve Grubb wrote:
> > > On Friday, December 8, 2023 11:23:29 AM EST Zbigniew Jędrzejewski-Szmek 
> > > wrote:
> > > 
> > > > But yeah, there'll always be a few "special" files. But that's fine,
> > > > we have mechanisms to handle those. For the other 99%, we should
> > > > move them out of /etc.
> > > 
> > > 
> > > The problem is that there would need to be a standard that all upstream 
> > > authors agree on. There are some like systemd which have a [SECTION_NAME]
> > > 
>  followed by config items. Others do not make sections. What if the
> > > config is in yaml, json, or XML? How can you see the end result? We
> > > would need to have a standard library that everyone can use. From that,
> > > we need a utility to compile the actual configuration that would be
> > > consumed by the service so we can inspect it during troubleshooting.
> > 
> > Eh? What does the format of the files have to do with where they live?
> 
> At face value, it shouldn't matter. But when you have the first override, now 
> you need to have a reproducible, correct assembly of the configuration. Each 
> format has peculiarities about how to place the override in the correct spot.

I think that there's a misunderstanding because there are two separate
ideas in play:

1. moving of the default "main" config file from /etc or somewhere
   under /usr and allowing the the file in /etc as an override.
2. allowing extensions of that configuration with additional "drop-ins".

Systemd implements both, so people tend to think of them together, but
strictly speaking, they are completely orthgonal. Systemd has it easy,
because its INI config files can be just contatenated. As AdamW said,
there are formats like XML or JSON where this wouldn't work. *Some*
custom mechanism of extension may be defined, but it won't be a trivial
sort-and-concatenate.

Points 1 and 2 each separately are beneficial. 1. has all the advantages that I
described in the initial mail, 2. has the advantage that it's much becomes
trivial to insert and remove "edits" to the configuration, and it's easy to
combine configuration from multiple sources, e.g. main package, extension
packages, and local overrides. If we don't have that, we must do some scripting
to "merge" additional config, but in many cases this is very brittle.
1. + 2. together gives the most benefits.
  
> > I don't see any reason we can have heterodox config file formats in
> > /etc, but not in /usr. (Indeed, practically speaking, we already have
> > lots of different formats in both places).
> 
> Because it's in one place and not expected to be built up by looking all over 
> the place for the pieces. Making this easy for security scanner and upstream 
> developer adoption really needs to be considered. Don't misunderstand that 
> I'm against the idea...I'm just trying to say we need to consider the 
> ramifications across the broader ecosystem.

If a given program only supports item 1. above, then there's no merging. 
But I agree with the more general premise: security scanners and other
software needs to "understand" and support the effective configuration
mechanism.

In an earlier mail, Steve Grubb wrote:
> The problem is that there would need to be a standard that all upstream
> authors agree on. There are some like systemd which have a [SECTION_NAME]
> followed by config items. Others do not make sections. What if the config is 
> in
> yaml, json, or XML? How can you see the end result? We would need to have a
> standard library that everyone can use. From that, we need a utility to
> compile the actual configuration that would be consumed by the service so we
> can inspect it during troubleshooting.

All those problems already exist. We have hundreds of custom file formats
in play. Even the same software can change over time, adding new syntax.
So to make *any* inference about some piece of configuration, the scanner
or other tool needs to support that specific configuration format.
What's even harder, it must understand the implicit defaults.
If frobnicator-1.0 defaults to "allow everything", and
frobnicator-2.0 defaults ot "deny everything", a scanner that supports
the syntax of the configuration, but doesn't know this, is not very useful.
All of that is already true, and the additional complication of multiple config
file locations is just a small addition on top.

> Without this, security scanners are going to have a hard time determining
> what the security posture of a system is. And the Security Content everywhere
> will need to be changed, STIG, Common Criteria, CIS, USGCB, etc. Some of
> these are very opinionated about the file permissions. Something would have to
> check all files everywhere that make up a configuration. Again, security
> scanners are not going to like this. So, the library would also probably need
> to be ab

Re: Building the boot.iso with dnf5

[Peter Robinson]

On Fri, Dec 8, 2023 at 7:35 PM Brian C. Lane  wrote:
>
> With the approval of
> https://fedoraproject.org/wiki/Changes/BuildWithDNF5 it seems like a
> good time to move Lorax over to using dnf5 to create the boot.iso. My
> current plan is to merge my dnf5 branch do a new build on Monday
> (12/11). You can preview this here:
> https://github.com/weldr/lorax/pull/1319
>
> (the test is currently failing due to an issue with the rawhide
> container image, I've testing it locally and via a temporary switch to
> using fedora:39 container).
>
> The resulting image is the same content and size as the current rawhide
> boot.iso, so that's good :)
>
> To be clear, this change uses libdnf5 to *build* the boot.iso but it
> does not have dnf5 on the iso or the systems installed using it.

It was my understanding the switch to dnf5 was delayed until F-41 so I
don't think we should be using it for this either until it's the
default in Fedora as well.

Peter
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2023 at 07:25:08PM +0100, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> > On Fri, Dec 08, 2023 at 05:23:08PM +0100, Florian Weimer wrote:
> >> * Stephen Gallagher:
> >> 
> >> > That being said, there are files like /etc/nsswitch.conf, /etc/pam.d/*
> >> > and /etc/fstab which are both API *and* sometimes see manual updates.
> >> > These are some of the cases that are going to make getting to an empty
> >> > /etc very hard to finish off. There's a lot of low-hanging fruit we
> >> > can take care of in the meantime, but getting the last 1% of packages
> >> > done is going to take a lot of inter-distro conversations.
> >> 
> >> We could add some sort of :include: processing to glibc, but that's
> >> going to impact much more than just glibc in the end (Go has its own
> >> parser for /etc/passwd, I believe others have their own for
> >> /etc/nsswitch.conf).
> >
> > IIUC, you mean that e.g. /etc/services would still exist, but
> > would contain ":include:/usr/etc/services". That's not a great answer,
> > because you still need /etc/services to exist.
> 
> No, it would be the other way round.  We might have a
> /usr/share/glibc/services which contains :include: /etc/services
> somewhere in it.

Ah, OK. I understand how the format would look, but I don't understand
why you'd want to implement it rather than something simpler.

/etc/services is essentially a flat file that is scanned from top to
bottom until a matching entry is found. In the proposed syntax, it'd
need to have ':include: /etc/services' at the very top, so that the local
config in /etc/services has higher priority.

Consider the following alternative: each of [/etc/services, /usr/etc/services]
is scanned in order, if the file exists. This is simpler to implement and allows
either of the files to exist independently of the other.
A stanza like ':include:' also opens the door for additional complications like
different paths on different distros and include loops. It is _possible_,
but the simpler scheme has the properties that we want.

> > It's also a rather complex solution, because special parsing is
> > needed… It's both easier and more powerful to say "check for
> > /etc/services, and if doesn't exist, fall back to
> > /usr/etc/services". It's:
> > - simple to implement and understand,
> > - backwards compatible in the sense that a local system that has
> >   the file modified will work without changes,
> > - and as discussed in another part of the thread, we can add
> >   optionally add tmpfiles.d config to symlink /etc/services → 
> > /usr/etc/services
> >   on boot if there are other consumers that don't yet support the new
> >   location.
> 
> Are you sure you mean check “for /etc/services, and if doesn't exist,
> fall back to /usr/etc/services”?  That suggests that in order to edit
> the file, you have to make a copy, and that means that the system won't
> receive any services added to the system file.  “Look for the service in
> /etc/services, and if it's not there, check /usr/etc/services” would
> make more sense to me.  But that's not so far off from :include:
> processing …

Yeah, I see the misunderstanding now. With config files, we generally
want the behaviour that _only one_ file is used. Either /etc/foobar.conf
or /usr/lib/foobar.conf, but not both. But for /etc/services, we want
to combine both parts, and doing it as you describe (or as I wrote above
before reading part of your mail ;) ), is better.

(Of course, there's always the option of allowing both, i.e. having
a main config file that is fully overriden by a file with the same
name, and allowing drop-ins to extend the configuration.)

Zbyszek
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Building the boot.iso with dnf5

[Miroslav Suchý]

Dne 09. 12. 23 v 12:57 Peter Robinson napsal(a):

It was my understanding the switch to dnf5 was delayed until F-41 so I
don't think we should be using it for this either until it's the
default in Fedora as well.


It was delayed because it was not ready for general usage. E.g. some functionality were missing. But most of the 
functionality is there for lng time. One of the missing piece is 'system-upgrade' command. Do you need it for 
creating iso image? No. Are you missing something else? If not then I encourage to try using DNF5 for your workflow. You 
may discover some issue that stops you. But sooner you discover it, sooner the DNF will fix it.


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Fedora Review Service and setting the AutomationTriaged keyword

[Jakub Kadlcik]

Hello,
a year ago I announced

and
launched the Fedora Review Service
.
Nobody complained that it is annoying, and I am getting pings from people
when there is an outage, so I consider this endeavor to be a success :-)

Since its last release, the service parses and shows recommendations based
on the fedora-review.json
 output. There is
a nice secondary use of this feature - we can do something when no errors
are found. My plan is to set the `AutomationTriaged` Bugzilla keyword for
such tickets. Or any other keyword that you would prefer. As a follow-up, I
want to unleash the service on all open review tickets, so that even
tickets that predate the service can obtain the `AutomationTriaged` keyword.

RFE https://github.com/FrostyX/fedora-review-service/issues/13

The endgame will be adding "CI passing tickets" section to the Cached
Package Review Tracker  and/or
adding some special row color for tickets that passed the automated review
to already existing sections
.

My motivation for this feature is to make life easier for reviewers. They
will be able to focus on tickets that passed an automated review and
therefore are more likely to be in an (almost) acceptable state.

What do you think?
Jakub
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Fedora Review Service and setting the AutomationTriaged keyword

[Dominik 'Rathann' Mierzejewski]

On Saturday, 09 December 2023 at 19:32, Jakub Kadlcik wrote:
> Hello,
> a year ago I announced
> 
> and
> launched the Fedora Review Service
> .
> Nobody complained that it is annoying, and I am getting pings from people
> when there is an outage, so I consider this endeavor to be a success :-)

Yes, it is very useful. I like it a lot.

> Since its last release, the service parses and shows recommendations based
> on the fedora-review.json
>  output. There is
> a nice secondary use of this feature - we can do something when no errors
> are found. My plan is to set the `AutomationTriaged` Bugzilla keyword for
> such tickets. Or any other keyword that you would prefer. As a follow-up, I
> want to unleash the service on all open review tickets, so that even
> tickets that predate the service can obtain the `AutomationTriaged` keyword.
> 
> RFE https://github.com/FrostyX/fedora-review-service/issues/13

Cool! Go for it.

> The endgame will be adding "CI passing tickets" section to the Cached
> Package Review Tracker  and/or
> adding some special row color for tickets that passed the automated review
> to already existing sections
> .

Great idea.

> My motivation for this feature is to make life easier for reviewers. They
> will be able to focus on tickets that passed an automated review and
> therefore are more likely to be in an (almost) acceptable state.
> 
> What do you think?

This is excellent work. Thank you so much for doing this.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> That built-in would be enough only if it enabled all the modules
> that we need it to support.

It enables the ones that *glibc* needs to run at a minimum.  Your case
is different, which is why you modify /etc/nsswitch.conf.

> I tried to figure out what the default is, but could find that info.
> Is is documented somewhere?

Yes.  It's in the glibc manual, section "Notes on the NSS Configuration
File".  It boils down to either "files dns" or "files" for most entries.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Help packaging PyTorch dependencies for Fedora

[Dominik 'Rathann' Mierzejewski]

On Friday, 08 December 2023 at 16:34, Steve Grubb wrote:
> On Friday, December 8, 2023 12:41:59 AM EST Jun Aruga (he / him) wrote:
> > Congratulations for the PyTorch package!
> > https://src.fedoraproject.org/rpms/python-torch
> > 
> > I hope someone will announce this great achievement to the Fedora
> > community too, and update the following page too.
> > https://fedoraproject.org/wiki/SIGs/PyTorch/packagingStatus
> 
> Yes, this is nice that we have pytorch in Fedora. Looking at the specfile...
> 
> USE_CUDA=OFF
> USE_ROCM=OFF
> 
> Which does not align with:
> 
> %description
> PyTorch is a Python package that provides two high-level features:
>  * Tensor computation (like NumPy) with strong GPU acceleration
> 
> GPU acceleration?

Indeed. We have ROCM in Fedora already:
$ sudo dnf list rocm\*devel
Last metadata expiration check: 0:00:24 ago on Sat 09 Dec 2023 22:42:19.
Available Packages
rocm-comgr-devel.x86_64   16.1-2.fc38   
updates
rocm-hip-devel.x86_64 5.5.1-10.fc38 
updates
rocm-opencl-devel.x86_64  5.5.1-10.fc38 
updates
rocm-runtime-devel.x86_64 5.5.0-2.fc38  
updates
rocm-smi-devel.x86_64 5.5.1-3.fc38  
updates

At least the OpenCL part works quite well for me.

[...]
> pip install torch
> python3
> >>> import torch
> >>> torch.__config__.show()
> 
> The config listed there should be compared with the config in the spec file 
> to 
> get as close to the expected feature set as possible so that people can just 
> switch. This is a positive step and I would love to switch one day.

Good idea.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[DJ Delorie]

Zbigniew Jędrzejewski-Szmek  writes:
> I'm not entirely sure if you're just doing Friday trolling or if
> you're serious.

Serious.  I have many machines and VMs, and every time I do a Fedora
install, I have a list of your choices I have to revert because they
don't work for me.  It's tiring.

>> I fear this will end like the /tmp fiasco where one /tmp became many tmp
>> directories, and no consistent rule about which one to use.
>
> /tmp is generally backed by RAM and does not survive a reboot.

Not on any of my machines.  I want tmp files around after a reboot so I
can figure out what caused the reboot.

>> This can be achieved without "empty /etc" as a goal.  For example, why
>> can't we use podman's overlay filesystem to mount /usr/etc under /etc so
>> that all the configuration appears in /etc but installed vs changed
>> files are kept segregatable?
>
> (FTR, not "podman's". The filesystem is a kernel thing.)
>
> If the goal was to just move everything wholesale, that'd be a

I meant, rpms install into the lower fs, and the user edits the upper
fs.  You can "revert" to "factory settings" by wiping just the upper fs.

You can expose the two layers elsewhere (like /usr/etc) if that helps
with the merging.

> (Another problem is that this scheme only works "live". If you want
> to look *into* an image from the outside, the overlay wouldn't be
> assembled, so the tools need to know how to handle the config split
> manually.)

If you get your way, /etc would be empty anyway ;-)

>> > For example, /etc/services is a list of port:service mappings, and people
>> > maybe used to edit that twenty years ago,
>> 
>> I still edit this one.
>
> Great for you. So you can be the one person who uses the override
> mechanism for this file.

That you assume I'm the only one is part of the problem.

>> > Another common case is "empty" configuration files, i.e. templates
>> > that show the default configuration.
>> 
>> I find these VERY helpful when trying to fix configuration issues on my
>> machines.
>
> Right. I'm not saying that those should go away. Quite the opposite.

If you move them away from where I expect to find them, effectively
they've gone away.  Instead of having everything I need in the one spot,
I have to go hunting for it.  If history is right, everyone will choose
a different spot and finding info will become very difficult.  Even
*documenting* where to find this information will become difficult,
because everyone puts their docs in different places.

Please figure out a way to make upgrades more reliable without having to
retrain millions of Linux users or turn Fedora into Windows.  I'm not
sure I'm exaggerating here.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: goal: booting with an empty /etc

[Daniel Walsh]

On 12/9/23 16:55, DJ Delorie wrote:

Zbigniew Jędrzejewski-Szmek  writes:

I'm not entirely sure if you're just doing Friday trolling or if
you're serious.

Serious.  I have many machines and VMs, and every time I do a Fedora
install, I have a list of your choices I have to revert because they
don't work for me.  It's tiring.


I fear this will end like the /tmp fiasco where one /tmp became many tmp
directories, and no consistent rule about which one to use.

/tmp is generally backed by RAM and does not survive a reboot.

Not on any of my machines.  I want tmp files around after a reboot so I
can figure out what caused the reboot.


This can be achieved without "empty /etc" as a goal.  For example, why
can't we use podman's overlay filesystem to mount /usr/etc under /etc so
that all the configuration appears in /etc but installed vs changed
files are kept segregatable?

(FTR, not "podman's". The filesystem is a kernel thing.)

If the goal was to just move everything wholesale, that'd be a

I meant, rpms install into the lower fs, and the user edits the upper
fs.  You can "revert" to "factory settings" by wiping just the upper fs.

You can expose the two layers elsewhere (like /usr/etc) if that helps
with the merging.


(Another problem is that this scheme only works "live". If you want
to look *into* an image from the outside, the overlay wouldn't be
assembled, so the tools need to know how to handle the config split
manually.)

If you get your way, /etc would be empty anyway ;-)


For example, /etc/services is a list of port:service mappings, and people
maybe used to edit that twenty years ago,

I still edit this one.

Great for you. So you can be the one person who uses the override
mechanism for this file.

That you assume I'm the only one is part of the problem.


Another common case is "empty" configuration files, i.e. templates
that show the default configuration.

I find these VERY helpful when trying to fix configuration issues on my
machines.

Right. I'm not saying that those should go away. Quite the opposite.

If you move them away from where I expect to find them, effectively
they've gone away.  Instead of having everything I need in the one spot,
I have to go hunting for it.  If history is right, everyone will choose
a different spot and finding info will become very difficult.  Even
*documenting* where to find this information will become difficult,
because everyone puts their docs in different places.

Please figure out a way to make upgrades more reliable without having to
retrain millions of Linux users or turn Fedora into Windows.  I'm not
sure I'm exaggerating here.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


ostree does something like this. Having a lower /usr/etc and a upper 
/var/etc mapped at /etc, would be interesting. although there would be 
no ability to merge, the upper overrides the lower.

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue