Re: goal: booting with an empty /etc

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2023 at 08:20:25PM -0500, DJ Delorie wrote:
> Lennart Poettering  writes:
> > That said, I would certainly enjoy more if glibc would natively
> > fallback to /usr/lib/glibc/nsswitch.conf or something like that if
> > /etc/nsswitch.conf does not exist.
> 
> glibc has an internal default for nsswitch.conf if one isn't found.
> Putting a custom nsswitch.conf in yet another non-standard directory is
> not needed.

That built-in would be enough only if it enabled all the modules
that we need it to support.

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

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

[Bug 2243747] Please branch and build perl-XML-RSS for EPEL9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2243747

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #3 from Fedora Update System  ---
FEDORA-EPEL-2023-b5f96f92a8 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b5f96f92a8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2243747

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202243747%23c3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[EPEL-devel] Fedora EPEL 7 updates-testing report

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-259055935d   
chromium-120.0.6099.62-1.el7


The following builds have been pushed to Fedora EPEL 7 updates-testing

nodejs-16.20.2-1.el7
seamonkey-2.53.18-1.el7

Details about builds:



 nodejs-16.20.2-1.el7 (FEDORA-EPEL-2023-8ea1dafefe)
 JavaScript runtime

Update Information:

Update to final 16.20.2 release

ChangeLog:

* Fri Dec  8 2023 Stephen Gallagher  - 1:16.20.2-1
- Update to 16.20.2

References:

  [ 1 ] Bug #2253524 - Upgrade to last supported NodeJS 16 version
https://bugzilla.redhat.com/show_bug.cgi?id=2253524




 seamonkey-2.53.18-1.el7 (FEDORA-EPEL-2023-fd36857b5e)
 Web browser, e-mail, news, IRC client, HTML editor

Update Information:

Update to 2.53.18

ChangeLog:

* Fri Dec  8 2023 Dmitry Butskoy  2.53.18-1
- update to 2.53.18
- add patch for binutils >= 2.36


--
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Package some perl modules (to really get one)

[Chris Adams]

I'd like to get WWW::Mechanize::Chrome into Fedora.  I've packaged the
dependencies, and the deps of deps, and build deps of deps... that's 20
new packages total (8 are just build/test deps).  I can make a bunch of
new package tickets, but I'd rather have some help with maintaining
these (and have that lined up before getting them in).

Any takers or suggestions?

The packages:

   perl-AnyEvent-Connector-0.04-1.fc39
   perl-AnyEvent-Future-0.05-1.fc39
   perl-AnyEvent-WebSocket-Client-0.55-1.fc39
   perl-Filter-signatures-0.19-1.fc39
   perl-Future-HTTP-0.16-1.fc39
   perl-Future-Mojo-1.002-1.fc39
   perl-HTTP-Tiny-Paranoid-0.07-1.fc39
   perl-IO-Async-Loop-Mojo-0.07-1.fc39
   perl-IO-Async-SSL-0.25-1.fc39
   perl-Module-Build-Prereqs-FromCPANfile-0.02-1.fc39
   perl-MooX-Role-EventEmitter-0.04-1.fc39
   perl-Net-Async-HTTP-0.49-1.fc39
   perl-Net-Async-HTTP-Server-0.14-1.fc39
   perl-Net-Async-SOCKS-0.003-1.fc39
   perl-Net-Async-WebSocket-0.13-1.fc39
   perl-Net-DNS-Paranoid-0.08-1.fc39
   perl-Object-Import-1.005-1.fc39
   perl-Protocol-SOCKS-0.003-1.fc39
   perl-Test-HTTP-LocalServer-0.75-1.fc39
   perl-WWW-Mechanize-Chrome-0.72-1.fc39

-- 
Chris Adams 
--
___
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]

Lennart Poettering  writes:
> That said, I would certainly enjoy more if glibc would natively
> fallback to /usr/lib/glibc/nsswitch.conf or something like that if
> /etc/nsswitch.conf does not exist.

glibc has an internal default for nsswitch.conf if one isn't found.
Putting a custom nsswitch.conf in yet another non-standard directory is
not needed.
--
___
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: rpmbuild sagemath 10.1 on Fedora 38

[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.

Right, this is always part of updating to a new sagemath version.  You
have to determine which of the patches are still needed, and whether
they need to be revised.  It's tedious work for sure.  And of course,
it's always a good idea to push as many patches upstream as possible
so that someday they can be dropped from the Fedora build altogether.

> I can't apply the patches sagemath-maxima.patch sagemath-python3.patch and
> sagemath-intersphinx.patch beacause the original files have changed a lot
> and I even don't know how to patch the files manually.

The question is whether the problems those patches address have been
fixed upstream.  If not, the patches will have to be ported to the new
sources.

> Now the process of buiding the package runs, but at the end I get the errors

Ignore the warnings.  Those symlinks are needed and correct.  This is the error:

> RPM build errors:
> File not found: 
> /root/rpmbuild/BUILDROOT/sagemath-10.1-1.fc38.x86_64/usr/share/doc/sagemath/index.html
> Directory not found: 
> /root/rpmbuild/BUILDROOT/sagemath-10.1-1.fc38.x86_64/usr/share/doc/sagemath/html

So either the documentation building step failed or the documentation
is installed in a different location now.  You will have to look in
the build log to determine which of those is the case.

> If I am able to buid the sagemath package, I'm interested in being the 
> mantainer of it.

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

Regards,
-- 
Jerry James
http://www.jamezone.org/
--
___
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: rpmbuild sagemath 10.1 on Fedora 38

[Jerry James]

Hi Rafel,

On Fri, Dec 8, 2023 at 1:35 PM Rafel Amer Ramon  wrote:
> I'm trying to rpmbild  sagemath 10.1 on Fedora 38, but I gave an error.
> See the attached files sagemath.spec and sagemath.log.
>
> Any help would be appreciated.

I see you threw away all of the patches.  I think you're going to find
that you need most of them.  In particular, you discarded the patch to
use flexiblas.  The error you are getting indicates that sagemath did
not find a usable blas implementation.

Updating the sagemath package to a new version is a pretty involved
process.  It would take me hours every time a new version came out to
update it, one reason why I ultimately decided to stop doing it.

--
Jerry James
http://www.jamezone.org/
--
___
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

[Lennart Poettering]

On Fr, 08.12.23 10:25, Stephen Gallagher (sgall...@redhat.com) wrote:

> That being said, there are files like /etc/nsswitch.conf,
> /etc/pam.d/*

So for /etc/nsswitch.conf (and some degree of /etc/pam.d/) a
short-term half-way fix is this I guess:

https://github.com/authselect/authselect/issues/355

(hopefully @pbrezina merges my two PRs soon).

With that if you boot up with an empty /etc/, you'll get a proper
/etc/nsswitch.conf set up automatically, like you would on a regular
Fedora install.

That said, I would certainly enjoy more if glibc would natively
fallback to /usr/lib/glibc/nsswitch.conf or something like that if
/etc/nsswitch.conf does not exist.

Lennart

--
Lennart Poettering, Berlin
--
___
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

[Lennart Poettering]

On Fr, 08.12.23 17:23, Florian Weimer (fwei...@redhat.com) 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).

I'd always suggest going for .d/ style drop-in dirs
(i.e. /etc/services.d/*.conf, /usr/share/services.d/*.conf,
/etc/protocols.d/*.conf, /usr/share/protocols.d/*.conf and similar)
rather than include logic, for the simple reason that ensuring
includes don't result in potentially endless recursion is a bit
nasty. Moreover, it's kinda nice if the conceptual logic that allows
users to split things up doesn't leak into the contents of the files,
but remains in the structure of the file system.

That said, if you give me an "include" style logic in glibc's database
handling I'd also be happy. Beggars can't be choosers, after all.

Lennart

--
Lennart Poettering, Berlin
--
___
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

Building the boot.iso with dnf5

[Brian C. Lane]

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.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
--
___
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: Should we retire the mailx package?

[Adam Williamson]

On Fri, 2023-12-08 at 10:38 -0800, Kevin Fenzi wrote:
> I'm definitely in favor. I hit this broken step a while back myself. ;( 
> 
> Hopefully the current maintainers are on board with this?

Yeah, honestly, I'm not sure a Change is the right way to go about
this, it seems like it could just be handled between maintainers.
nforro - who maintains mailx - has not committed to it for two years,
but is very active on other packages (adding him to CC). If he is OK
with the change, I would think you could just go ahead and do it (have
nforro retire mailx) without needing to go through the Change process.

If you file a Change, I think all that will happen is that a lot more
bureaucracy will happen before somebody says "hey, we'd better ask
nforro about this" anyway. :D
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
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: Should we retire the mailx package?

[Kevin Fenzi]

I'm definitely in favor. I hit this broken step a while back myself. ;( 

Hopefully the current maintainers are on board with this?

kevin


signature.asc
Description: PGP signature
--
___
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: Should we retire the mailx package?

[Martin Jackson]

On Fri, 2023-12-08 at 13:18 -0500, Neal Gompa wrote:
> > 
> > Can we retire the mailx package, and then update s-nail with:
> > 
> > Provides: mailx = %{version}-%{release}
> > 
> > (this would work fine because mailx is at 12.5 and s-nail forked
> > from
> > that and is now at 14.9, so upgrading would be straightforward)
> > 
> > Should I submit a self-contained change proposal to do this?
> 
> Yes, please!

I'm also +1 for this proposal. When I came back to Fedora after some
dalliance with Debian (a few years ago now), the difference in mailx
implementations caused me some heartburn. And then I found s-nail and
it was fine. But it was not clear (then) that they were compatible. I
was just looking for something simple to send something via SMTP from
the command line.

thanks,


-- 
Martin Jackson 
--
___
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

[Florian Weimer]

* 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.

> 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 …

Thanks,
Florian
--
___
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: Should we retire the mailx package?

[Neal Gompa]

On Fri, Dec 8, 2023 at 12:34 PM Jonathan Wakely
 wrote:
>
> Today I learned (the hard way) that Fedora's mailx package (aka
> Heirloom mailx) is ancient and buggy. Upstream has been dead for over
> a decade and features documented in its man page don't work. The good
> news is that Fedora (and RHEL and CentOS) already have s-nail, which
> was forked from it ages ago and is still actively developed. They both
> provide the POSIX mailx command, configurable via
> /etc/alternatives/mailx, and support almost the same options/config
> etc.
>
> But 'dnf install mailx' gives you the bad version, and 'dnf search
> mailx' doesn't show s-nail at all. So unless you happen to know s-nail
> exists, or spend a while googling to see if Heirloom mailx is still
> maintained, you'll never learn about the good one.
>
> Is there any reason to keep both packages, when one is old and buggy
> and the other is an improved version of the same thing?
>
> Can we retire the mailx package, and then update s-nail with:
>
> Provides: mailx = %{version}-%{release}
>
> (this would work fine because mailx is at 12.5 and s-nail forked from
> that and is now at 14.9, so upgrading would be straightforward)
>
> Should I submit a self-contained change proposal to do this?

Yes, please!



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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:
> 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.

> 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?

> 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.

> The same is also true for /etc/bash_completion.d/

I delete this package completely, so I don't care where its config goes.

> 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.

> 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.

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

Please don't.
--
___
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

[Bug 2243747] Please branch and build perl-XML-RSS for EPEL9

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2243747

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #2 from Fedora Update System  ---
FEDORA-EPEL-2023-b5f96f92a8 has been submitted as an update to Fedora EPEL 9.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b5f96f92a8


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2243747

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202243747%23c2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Should we retire the mailx package?

[Jonathan Wakely]

Today I learned (the hard way) that Fedora's mailx package (aka
Heirloom mailx) is ancient and buggy. Upstream has been dead for over
a decade and features documented in its man page don't work. The good
news is that Fedora (and RHEL and CentOS) already have s-nail, which
was forked from it ages ago and is still actively developed. They both
provide the POSIX mailx command, configurable via
/etc/alternatives/mailx, and support almost the same options/config
etc.

But 'dnf install mailx' gives you the bad version, and 'dnf search
mailx' doesn't show s-nail at all. So unless you happen to know s-nail
exists, or spend a while googling to see if Heirloom mailx is still
maintained, you'll never learn about the good one.

Is there any reason to keep both packages, when one is old and buggy
and the other is an improved version of the same thing?

Can we retire the mailx package, and then update s-nail with:

Provides: mailx = %{version}-%{release}

(this would work fine because mailx is at 12.5 and s-nail forked from
that and is now at 14.9, so upgrading would be straightforward)

Should I submit a self-contained change proposal to do this?
--
___
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

[Steve Grubb]

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 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.

-Steve

--
___
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

[Adam Williamson]

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?

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).
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
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

[Steve Grubb]

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. 

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 able report all permissions used or set all permissions used. And then 
there is the SE Linux labeling...

There would probably need to be some written standard on how to assess the 
system security posture in this kind of world. This way tools can be adjusted 
using the standards.

-Steve

--
___
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 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. 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.

Yet another approach is to allow *multiple* files, like with sysusers.d
or tmpfiles.d. For '/etc/services', this would make a lot of sense,
because users generally would want to override or add a few lines,
and keep the rest of the config unchanged.

The case of glibc is very special. It'd be great to move its files
out of /etc too, but each file might need some custom mechanism and
discussion about the best approach.

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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 08, 2023 at 10:25:34AM -0500, Stephen Gallagher wrote:
> On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Hi,
> >
> > There is a long-term goal of moving packaged files out of /etc, so that
> > only actual local configuration remains in /etc. This has some advantages:
> >
> > - Local configuration, i.e. the result of local administrative actions,
> >   is nicely split from static configuration that is part of package payload.
> >   'find /etc' will show what is special to this local system, while
> >   'find /usr' lists stuff that is part of packages and the same between
> >   systems.
> > - We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
> >   to return everything to distro defaults. We're not there _yet_, but it
> >   works with a surprisingly large subset of packages.
> > - We can support "factory reset" at a package level, by removing all the
> >   configuration and state of an individual package, without reinstalling it
> >   (possibly combined with some tmpfiles.d config to recreate things
> >   automatically.)
> > - It becomes easier to build systems which are delivered as a stand-alone
> >   /usr-partition. This could be ostree-style systems, or image-based systems
> >   with the /usr-partition read-only and protected by dm-verity. We're not
> >   there _yet_, but many people are experimenting with this.
> >
> > When one looks in /etc, many of the files there are not "configuration".
> > For example, /etc/services is a list of port:service mappings, and people
> > maybe used to edit that twenty years ago, but now it's just a static file
> > that just as well may be somewhere under /usr/lib/. The same is also
> > true for /etc/bash_completion.d/ — people do not edit completion scripts.
> > Most of those have been moved to /usr/share/bash-completion/completions/,
> > but there's still a dozen or so in /etc.
> >
> 
> One thing that is becoming much more common is for us to ship such
> static files in /usr/lib and include a default symlink in /etc for
> those packages whose presence there is effectively API (for example
> /etc/os-release is a symlink to /usr/lib/os-release, similarly
> /etc/resolv.conf). I think this is a very good approach and one that
> we should probably look at formalizing in the packaging guidelines.

Those two are not great examples. Those files are widely used, so we
cannot really move them. But:
/etc/os-release does not have to exist at all. The API is "check for
/etc/os-release, and if that doesn't exist, read /usr/lib/os-release".
/etc/resolv.conf nowadays is not really a config file, because it's
dynamically managed (by systemd-resolved or NetworkManager or some
cloud config or config mgmt system).
Both of those symlinks are recreated automatically by tmpfiles on boot.

But also, a symlink is not great. The admin is likely to open the
editor on the symlink and edit the wrong thing by mistkae.

Symlinks are a compatiblity machinism. We should do those if there's
no other choice. But for majority of programs, the only consumer of
that config is one program or a few closely related programs, and
we should just teach them to support multiple locations and move the
file.

> 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.

/etc/fstab is local configuration, so it actually belong in /etc.
Also, most systems don't need /etc/fstab at all, location of the
basic partitions is autodetected.

Neal answered about PAM.

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.

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

[Florian Weimer]

* 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).

Thanks,
Florian
--
___
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

[Steve Grubb]

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?  Also,

USE_OPENMP=OFF

So, no threading? What about at least enabling BLAS? Maybe it is by default. 
Not seeing it in the specfile. Without a CUDA version of this, it can't be 
used the way it was meant to be. We still need to use pip install to get an 
accelerated version:

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.

Best Regards,
-Steve

--
___
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

[Neal Gompa]

On Fri, Dec 8, 2023 at 10:26 AM Stephen Gallagher  wrote:
>
> On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek
>  wrote:
> >
> > Hi,
> >
> > There is a long-term goal of moving packaged files out of /etc, so that
> > only actual local configuration remains in /etc. This has some advantages:
> >
> > - Local configuration, i.e. the result of local administrative actions,
> >   is nicely split from static configuration that is part of package payload.
> >   'find /etc' will show what is special to this local system, while
> >   'find /usr' lists stuff that is part of packages and the same between
> >   systems.
> > - We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
> >   to return everything to distro defaults. We're not there _yet_, but it
> >   works with a surprisingly large subset of packages.
> > - We can support "factory reset" at a package level, by removing all the
> >   configuration and state of an individual package, without reinstalling it
> >   (possibly combined with some tmpfiles.d config to recreate things
> >   automatically.)
> > - It becomes easier to build systems which are delivered as a stand-alone
> >   /usr-partition. This could be ostree-style systems, or image-based systems
> >   with the /usr-partition read-only and protected by dm-verity. We're not
> >   there _yet_, but many people are experimenting with this.
> >
> > When one looks in /etc, many of the files there are not "configuration".
> > For example, /etc/services is a list of port:service mappings, and people
> > maybe used to edit that twenty years ago, but now it's just a static file
> > that just as well may be somewhere under /usr/lib/. The same is also
> > true for /etc/bash_completion.d/ — people do not edit completion scripts.
> > Most of those have been moved to /usr/share/bash-completion/completions/,
> > but there's still a dozen or so in /etc.
> >
>
> One thing that is becoming much more common is for us to ship such
> static files in /usr/lib and include a default symlink in /etc for
> those packages whose presence there is effectively API (for example
> /etc/os-release is a symlink to /usr/lib/os-release, similarly
> /etc/resolv.conf). I think this is a very good approach and one that
> we should probably look at formalizing in the packaging guidelines.
>
> 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.

PAM configuration has been able to move to /usr/share/pam.d
(%_pam_vendordir) since Fedora 33. It is part of RHEL 9 too. That's
seriously good low-hanging fruit to move.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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

[Stephen Gallagher]

On Fri, Dec 8, 2023 at 9:58 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> Hi,
>
> There is a long-term goal of moving packaged files out of /etc, so that
> only actual local configuration remains in /etc. This has some advantages:
>
> - Local configuration, i.e. the result of local administrative actions,
>   is nicely split from static configuration that is part of package payload.
>   'find /etc' will show what is special to this local system, while
>   'find /usr' lists stuff that is part of packages and the same between
>   systems.
> - We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
>   to return everything to distro defaults. We're not there _yet_, but it
>   works with a surprisingly large subset of packages.
> - We can support "factory reset" at a package level, by removing all the
>   configuration and state of an individual package, without reinstalling it
>   (possibly combined with some tmpfiles.d config to recreate things
>   automatically.)
> - It becomes easier to build systems which are delivered as a stand-alone
>   /usr-partition. This could be ostree-style systems, or image-based systems
>   with the /usr-partition read-only and protected by dm-verity. We're not
>   there _yet_, but many people are experimenting with this.
>
> When one looks in /etc, many of the files there are not "configuration".
> For example, /etc/services is a list of port:service mappings, and people
> maybe used to edit that twenty years ago, but now it's just a static file
> that just as well may be somewhere under /usr/lib/. The same is also
> true for /etc/bash_completion.d/ — people do not edit completion scripts.
> Most of those have been moved to /usr/share/bash-completion/completions/,
> but there's still a dozen or so in /etc.
>

One thing that is becoming much more common is for us to ship such
static files in /usr/lib and include a default symlink in /etc for
those packages whose presence there is effectively API (for example
/etc/os-release is a symlink to /usr/lib/os-release, similarly
/etc/resolv.conf). I think this is a very good approach and one that
we should probably look at formalizing in the packaging guidelines.

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.
--
___
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

goal: booting with an empty /etc

[Zbigniew Jędrzejewski-Szmek]

Hi,

There is a long-term goal of moving packaged files out of /etc, so that
only actual local configuration remains in /etc. This has some advantages:

- Local configuration, i.e. the result of local administrative actions,
  is nicely split from static configuration that is part of package payload.
  'find /etc' will show what is special to this local system, while
  'find /usr' lists stuff that is part of packages and the same between
  systems.
- We can support "factory reset" at the system level, i.e. do 'rm -rf /etc'
  to return everything to distro defaults. We're not there _yet_, but it
  works with a surprisingly large subset of packages.
- We can support "factory reset" at a package level, by removing all the
  configuration and state of an individual package, without reinstalling it
  (possibly combined with some tmpfiles.d config to recreate things
  automatically.)
- It becomes easier to build systems which are delivered as a stand-alone
  /usr-partition. This could be ostree-style systems, or image-based systems
  with the /usr-partition read-only and protected by dm-verity. We're not
  there _yet_, but many people are experimenting with this.

When one looks in /etc, many of the files there are not "configuration".
For example, /etc/services is a list of port:service mappings, and people
maybe used to edit that twenty years ago, but now it's just a static file
that just as well may be somewhere under /usr/lib/. The same is also
true for /etc/bash_completion.d/ — people do not edit completion scripts.
Most of those have been moved to /usr/share/bash-completion/completions/,
but there's still a dozen or so in /etc.

Another common case is "empty" configuration files, i.e. templates that show the
default configuration. E.g. systemd has files that show commented-out defaults,
so if the file is removed, there is no change in behaviour.

Other distributions are ahead of us in supporting empty /etc. In particular,
OpenSUSE has done a lot of work with libeconf, which adds support for
systemd-style config in /usr/lib, /etc, and /run, and has convinced various
projects to switch to libeconf and allow empty /etc. There is a specification
codifying best practices in this area at:
https://uapi-group.org/specifications/specs/configuration_files_specification/

systemd-255-3.fc40 that was just built for rawhide moves "empty" config files
from /etc/systemd to /usr/lib/systemd. Systemd programs look in both locations,
so there should be no change in behaviour. Ideally, when administrators want
to make local modifications, they will use a drop-in file, instead of editing
the main config file, so the location of the main config file doesn't matter.
(To make this all nicer, we have
  systemd-analyze cat-config
which will display all config files in priority order, including drop-ins, and
we now added
  systemd-analyze cat-config --tldr
which will suppress "empty" stuff (empty lines and comments).)

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.

If you are a maintainer of an upstream project, make sure that it supports
loading files from under /usr, so that the distro can put its config files 
there.

See https://github.com/uapi-group/specifications/issues/76 for a tracker
bug with a list of usptream projects which don't support this.

At some point, I think we should make this an explicit goal in Fedora.
I don't think we're at the point yet where it'd be feasible to put this
in Packaging Guidelines, but we can already convert individual packages.

Zbyszek
(on behalf of various folks working on this)
--
___
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

[Bug 2253501] perl-HTTP-Cookies-6.11 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2253501

Michal Josef Spacek  changed:

   What|Removed |Added

 Resolution|--- |RAWHIDE
   Fixed In Version||perl-HTTP-Cookies-6.11-1.fc
   ||40
 Status|ASSIGNED|CLOSED
Last Closed||2023-12-08 13:16:03




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253501
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [ELN] Mass-rebuild to import packages to CentOS Stream 10 starts today

[Stephen Gallagher]

Re-adding Fedora Devel for awareness.


On Fri, Dec 8, 2023 at 7:35 AM Michal Pospíšil (he / him) <
mposp...@redhat.com> wrote:

> Hello Stephen,
>
> Does this mean that any changes in rawhide after the rebuild will not get
> into CentOS Stream 10? I wanted to add a new subpackage to pcs next week so
> that it can be imported to CentOS Stream 10.
>
>
> Kind regards
> Michal
>
> On Thu, 7 Dec 2023 at 15:46, Stephen Gallagher 
> wrote:
>
>> First, let me apologize for the short notice on this. We've been
>> discussing it at the public ELN meetings over the last month, but I
>> only just now realized that I forgot to send out one of these general
>> announcements.
>>
>> Over the last few months, you've probably seen a number of Fedora ELN
>> packages preliminarily imported into Gitlab for CentOS Stream 10 as we
>> get the machinery working. As of today, we've finally cleared the
>> remaining blockers to perform the full import of both runtime and
>> buildroot-only packages.
>>
>> We are going to trigger a mass-rebuild of those packages included in
>> Fedora ELN later today in a side-tag, which will likely continue
>> through the weekend. All of the packages that successfully rebuild
>> will be automatically imported into CentOS Stream 10 via automation
>> and we will look into any and all failures over the course of next
>> week. This mass-rebuild will be performed with "background" priority
>> in Koji to minimize the impact on other builds, but there is still a
>> high likelihood that you may have a longer-than-usual waiting time for
>> your package builds. Fortunately, Fedora ELN is a relatively small
>> subset of Fedora packages (~2,500 vs Fedora's ~37,000), so it
>> shouldn't be too bad.
>>
>> This mass-rebuild will automatically retry failed builds at least once
>> (to help rule out test-flakes/infra hiccoughs) and possibly numerous
>> times, since they are all being submitted to the automation as a
>> single, large batch. Please do not panic if you see your package being
>> submitted and failing repeatedly. For more information on the rebuild
>> strategy we use, please see
>>
>> https://sgallagh.wordpress.com/2023/10/13/sausage-factory-fedora-eln-rebuild-strategy/
>>
> --
>> ___
>> 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
>>
>
>
> --
>
> MICHAL POSPÍŠIL
> He / Him / His
>
> Software Engineer
>
> RHEL HA Cluster - PCS
>
> Red Hat Czech, s.r.o. 
> Purkyňova 97b, 612 00 Brno
> 
>
> mposp...@redhat.comIRC: mpospisi
> 
>

No, the sync from Rawhide to CentOS Stream continues until the Fedora 40
branching event on February 6th. The purpose of this mass rebuild is to get
the remaining pieces in place and ensure that the sync is properly set up
for all of the packages.

There will be additional announcements made as we get closer to February.
--
___
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

[rpms/perl-HTTP-Cookies] PR #2: 6.11 bump

[Michal Josef Špaček]

mspacek merged a pull-request against the project: `perl-HTTP-Cookies` that you 
are following.

Merged pull-request:

``
6.11 bump
``

https://src.fedoraproject.org/rpms/perl-HTTP-Cookies/pull-request/2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[rpms/perl-HTTP-Cookies] PR #2: 6.11 bump

[Michal Josef Špaček]

mspacek opened a new pull-request against the project: `perl-HTTP-Cookies` that 
you are following:
``
6.11 bump
``

To reply, visit the link below
https://src.fedoraproject.org/rpms/perl-HTTP-Cookies/pull-request/2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2253501] perl-HTTP-Cookies-6.11 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=2253501

Michal Josef Spacek  changed:

   What|Removed |Added

   Doc Type|--- |If docs needed, set a value
 Status|NEW |ASSIGNED



--- Comment #1 from Michal Josef Spacek  ---
Changes:

6.11  2023-12-07 16:36:52Z
- Replace "Test" with "Test::More" (GH#70) (James Raspass)

Only for rawhide.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253501

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253501%23c1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [Review-request] rsms-inter-fonts

[Neal Gompa]

On Fri, Dec 8, 2023 at 4:05 AM Luya Tshimbalanga  wrote:
>
> Hello team,
>
> I am looking for a packager to review the package rsms-inter-fonts used as 
> default by Blender 3D software.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2253619
>
> The spec is straightforward as it uses the fonts template.
>

I grabbed it. :)




--
真実はいつも一つ！/ Always, there's only one truth!
--
___
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

[Review-request] rsms-inter-fonts

[Luya Tshimbalanga]

Hello team,

I am looking for a packager to review the package rsms-inter-fonts used 
as default by Blender 3D software.


https://bugzilla.redhat.com/show_bug.cgi?id=2253619

The spec is straightforward as it uses the fonts template.

Thanks in advance

--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
--
___
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: python packaging assistance sought for xgboost

[Sandro]

On 08-12-2023 07:22, Nathan Scott wrote:

ValueError: Globs did not match any module: xgboost


This sounds like the module is not installed where you think it is. In 
other words %{pyproject_files} would be empty because the glob (xgboost) 
after %pyproject_save_files doesn't match anything.


What do you have in 
build/BUILDROOT/*/usr/lib64/python3.12/site-packages/ inside your mock 
changeroot?


-- Sandro
--
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-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/python-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue