Re: Self Introduction: Rafel Amer

[Dominik 'Rathann' Mierzejewski]

Welcome to Fedora, Rafel!

On Sunday, 10 December 2023 at 22:17, Rafel Amer Ramon wrote:
>Hi,
>my name is Rafel Amer and I'm professor at the Technical University of
>Catalonia [1]https:/www.upc.edu. I teach Maths
>and I use sagemath for my classes. After the sagemath package is
>orphandend, I would like to be a maintainer or
>co-maintainer this package.
>I have successfully build sagemath 10.1 packages for Fedora 38 in
>x86_64 and aarch64 architectures, so I think that
>I could maintain this package.

Maintaining packages is a little more involved than just being able to
build them, but I'm sure you'll get there. See:
https://docs.fedoraproject.org/en-US/fesco/Package_maintainer_responsibilities/

Since you posted this introduction, I assume you've reached
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#introduce_yourself

If you want to maintain sagemath, which has been retired, you need to
prepare an unretirement review:
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

And you need to get sponsored:
https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package_Maintainers/#_understand_the_sponsorship_model

We have quite a few people interested in scientific software at Fedora:
https://fedoraproject.org/wiki/Category:SciTech_SIG and man other SIGs
at
https://fedoraproject.org/wiki/Category:Fedora_special-interest_groups

Feel free to reach out for help.

>I started using Linux in  1995 with Slackware and I have administered
>server with Debian and CentOS.

Nice! I also started with Slackware around that time.

>At house and for my classes I use Fedora 28.

I really hope that was a typo and you meant 38.

Regards,
Dominik
-- 
Fedora   https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The 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: python packaging assistance sought for xgboost

[Nathan Scott]

Thanks Miro - that size pointer was helpful.  Indeed, the only thing in the 
wheel are 3 metadata files.

Things seem to be OK up to this point in the upstream hatchling build:
https://github.com/dmlc/xgboost/blob/43897b829680d241491abe1ecd46b2ba9d338967/python-package/packager/pep517.py#L86

... that temporary directory is populated with all the python files in what 
looks like a good format, but the generated wheel is essentially empty.  Is 
there any way to see what's happening inside that hatchling.build.build_wheel 
call I wonder?

In related news, a setup.py based build works correctly.  Perhaps it would be 
simpler to just give up on the upstream python build bits?  (already having to 
patch them a fair bit since they don't supported versioned soname on 
libxgboost).

Thanks for all the insights.

cheers.

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

Re: Fedora Review Service and setting the AutomationTriaged keyword

[Benson Muite]

Many thanks Jakub. It is a helpful tool.  Hopefully it will also
encourage more community contributions to help improve and update Fedora
Review as well.
--
___
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 2254117] New: perl-Dancer2-1.1.0 is available

[bugzilla]

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

Bug ID: 2254117
   Summary: perl-Dancer2-1.1.0 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Dancer2
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.1.0
Upstream release that is considered latest: 1.1.0
Current version/release in rawhide: 1.0.0-1.fc40
URL: https://metacpan.org/release/Dancer2

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/5847/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Dancer2


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254117%23c0
--
___
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 2252479] perl-Date-Manip-6.93 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-c6885fca46 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2023-c6885fca46`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2023-c6885fca46

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=2252479

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252479%23c4
--
___
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 2252479] perl-Date-Manip-6.93 is available

[bugzilla]

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

Fedora Admin user for bugzilla script actions 
 changed:

   What|Removed |Added

   Assignee|jpazdzi...@redhat.com   |jples...@redhat.com



--- Comment #3 from Fedora Admin user for bugzilla script actions 
 ---
This package has changed maintainer in Fedora. Reassigning to the new
maintainer of this component.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252479%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

Re: goal: booting with an empty /etc

[Colin Walters]

On Mon, Dec 11, 2023, at 12:31 PM, Neal Gompa wrote:
> 
> We're currently not allowed to use /usr/etc (not that I like that path
> anyway) because it breaks RPM-OSTree. My understanding is that this
> directory is reserved by RPM-OSTree for storing pristine copies of
> /etc content for each OSTree commit.

If there was general consensus on using /usr/etc in upstreams/OSes/distros 
outside of having it be an implementation detail of ostree (mostly today) then 
we could certainly figure out how to support having content from RPMs (and 
other sources) in /usr/etc.  But consensus has been for projects to use other 
places (/usr/share or /usr/lib) - which I agree with too - so there's no need 
to keep bringing this up AFAICS.
--
___
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

OCaml 5.1.1 rebuild in Rawhide

[Richard W.M. Jones]

.. is under way:

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

Shouldn't take more than a day or two, with any luck!

In terms of the new version, nothing much to see here.  There a three
important regressions that are fixed, and one breaking change that is
unlikely to be noticed:

https://discuss.ocaml.org/t/ocaml-5-1-1-released/13592

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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

[David Cantrell]

On 12/11/23 12:31, Neal Gompa wrote:
> On Mon, Dec 11, 2023 at 11:36 AM David Cantrell  wrote:
>>
>> On 12/8/23 10:25, 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.
>>
>> I'd rather see defaults under somewhere in /usr/share rather than /usr/lib.
>>
> 
> I agree with this. I really would rather it be in /usr/share.
> 
>>> 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 just have an /etc tree like we see now but in /usr/share/etc
>> (or /usr/etc, but then I get IRIX nightmares) and your local overrides
>> exist in /etc.  Things like fstab will probably just have to always be
>> host-dependent so they will always exist in /etc.
>>
> 
> We're currently not allowed to use /usr/etc (not that I like that path
> anyway) because it breaks RPM-OSTree. My understanding is that this
> directory is reserved by RPM-OSTree for storing pristine copies of
> /etc content for each OSTree commit.

Right, my mention of /usr/etc in parens was merely to mention some
directory I remember from IRIX.  The documentation noted that /usr/etc
was for "Critical system configuration files and
maintenance commands" which was not to be confused with /etc on IRIX
which was for "Critical system configuration files and
maintenance commands".  :)

I think /usr/share/etc would be appropriate for Fedora.

>> For this to be really clean and nice, everything that drops a file in
>> /etc needs to handle the "read in the default; then read in the optional
>> local overrides" model.  I know a lot of stuff already does this, but
>> some things don't.  It would be a nice goal to aim for and maybe we can
>> submit patches to upstream projects where the functionality is missing.
>>
> 
> Indeed.
> 
> 
> 
> 
> 
> --
> 真実はいつも一つ！/ 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

-- 
David Cantrell 
Red Hat, 

armadillo soname bump to version 12

[Ryan Curtin]

Hello there,

I plan to bump the major version of the Armadillo linear algebra library
to version 12 for rawhide next week; this will be an ABI/API change.  I
will rebuild the package and its dependencies (looks like gdal and
mlpack only) in the side tag 'f40-build-side-79101'.

Thanks!

Ryan

-- 
Ryan Curtin| "I just ran out of it, you see."
r...@ratml.org |   - Howard Beale
--
___
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

[EPEL-devel] Re: cloud-utils-growpart package conflict

[Leon Fauster via epel-devel]

Am 11.12.23 um 20:29 schrieb Neal Gompa:

On Mon, Dec 11, 2023 at 2:19 PM Leon Fauster via epel-devel
 wrote:


While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL
and RHEL8?

cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms

cloud-utils-growpart noarch 0.33-3.el8 epel

Subpackage conflict?



This is definitely a mistake, can you please file a bug against
cloud-utils in EPEL 8? In RHEL 8, cloud-utils-growpart was packaged
individually, but in RHEL 9, it's done using the cloud-utils
packaging. That is likely how it was missed, since the source packages
don't match.



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

--
Leon

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

Re: Should we retire the mailx package?

[Nikola Forró]

I've opened [1], please take a look. After it is merged, I'll start the
package retirement process for mailx.

Thanks,
Nikola

[1] https://src.fedoraproject.org/rpms/s-nail/pull-request/3
--
___
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 2254072] New: perl-JSON-Path-1.0.4 is available

[bugzilla]

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

Bug ID: 2254072
   Summary: perl-JSON-Path-1.0.4 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-JSON-Path
  Keywords: FutureFeature, Triaged
  Assignee: emman...@seyman.fr
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: emman...@seyman.fr, perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 1.0.4
Upstream release that is considered latest: 1.0.4
Current version/release in rawhide: 1.0.3-3.fc39
URL: https://metacpan.org/release/JSON-Path/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/15651/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-JSON-Path


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202254072%23c0
--
___
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] Re: cloud-utils-growpart package conflict

[Neal Gompa]

On Mon, Dec 11, 2023 at 2:19 PM Leon Fauster via epel-devel
 wrote:
>
> While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL
> and RHEL8?
>
> cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms
>
> cloud-utils-growpart noarch 0.33-3.el8 epel
>
> Subpackage conflict?
>

This is definitely a mistake, can you please file a bug against
cloud-utils in EPEL 8? In RHEL 8, cloud-utils-growpart was packaged
individually, but in RHEL 9, it's done using the cloud-utils
packaging. That is likely how it was missed, since the source packages
don't match.



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

[EPEL-devel] cloud-utils-growpart package conflict

[Leon Fauster via epel-devel]

While updating to EL8.9 I noticed that cloud-utils-growpart is in EPEL 
and RHEL8?


cloud-utils-growpart noarch 0.33-0.el8 rhel-8-for-x86_64-appstream-rpms

cloud-utils-growpart noarch 0.33-3.el8 epel

Subpackage conflict?

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

Re: goal: booting with an empty /etc

[Stephen Smoogen]

On Mon, 11 Dec 2023 at 12:34, Neal Gompa  wrote:

> On Mon, Dec 11, 2023 at 11:36 AM David Cantrell 
> wrote:
> >
> > On 12/8/23 10:25, 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.
> >
> > I'd rather see defaults under somewhere in /usr/share rather than
> /usr/lib.
> >
>
> I agree with this. I really would rather it be in /usr/share.
>
> > > 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 just have an /etc tree like we see now but in /usr/share/etc
> > (or /usr/etc, but then I get IRIX nightmares) and your local overrides
> > exist in /etc.  Things like fstab will probably just have to always be
> > host-dependent so they will always exist in /etc.
> >
>
> We're currently not allowed to use /usr/etc (not that I like that path
> anyway) because it breaks RPM-OSTree. My understanding is that this
> directory is reserved by RPM-OSTree for storing pristine copies of
> /etc content for each OSTree commit.
>
>
My other problem with using /usr/etc is if we decide in N years that we
want to get rid of /usr altogether (reverse usrmerge so /usr/sbin -> /sbin,
/usr/bin -> /bin etc) and put everything at top-level.. we have to then
figure out where we would put all this content anyway.

At some point I think we are also looking at large enough changes that we
need to 'update FHS' and similar guidelines mainly so that third party
standards and tools can know where things 'should' go.


> > For this to be really clean and nice, everything that drops a file in
> > /etc needs to handle the "read in the default; then read in the optional
> > local overrides" model.  I know a lot of stuff already does this, but
> > some things don't.  It would be a nice goal to aim for and maybe we can
> > submit patches to upstream projects where the functionality is missing.
> >
>
> Indeed.
>
>
>
>
>
> --
> 真実はいつも一つ！/ 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: 

Re: Proven to be sickened

[Kevin Fenzi]

On Mon, Dec 11, 2023 at 08:28:31AM -0500, Stephen Gallagher wrote:
> 
> While I generally agree that a merge request is a more polite and
> elegant solution, if a package is listed as FTBFS (having had a bug
> automatically opened) and some reasonable amount of time (two, three
> weeks?) has passed, then I think it's perfectly reasonable to assume
> that the maintainer is vacant (either entirely or because they lack
> the available time to deal with it at this point). In that case, I
> don't see it as a problem to jump in and fix the package as a
> provenpackager if the fix is relatively minor (yes, this is
> subjective). I'd hesitate at rebasing to a new version, but if the
> issue is that a dependency changed its name or the newest gcc made a
> warning into an error, I think that's a perfectly acceptable fix to
> make. The ideal case is for it to go through a merge request, but if
> the package happens to be blocking other work, I think expediency is
> completely warranted.

I think the key here is that everyone needs to make sure and communicate
with others. 

If there's a FTBFS bugzilla bug and you are working on a good fix with
upstream, say so in the bug. If you are a provenpackager and you need to
fix a FTBFS quickly for some reason, look at the bug, if you see the
maintainer(s) mentioning they were working on it, ask in bug if you
could push a quick fix now and explain why you need it. Use good commit
messages. "Fix FTBFS" is not a good commit message, "Fix FTBFS with a
quick fix to xyz because we need to rebuild the package for rebuild of
package X, this may not be the final fix". Use the
packagename-maintainers aliases and notify when you are doing things. 
Even if everyone doesn't have time to react to communications, just
making the effort helps everyone know what happened and whats going on. 

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: Fedora Review Service and setting the AutomationTriaged keyword

[Kevin Fenzi]

Thanks for working on this Jakub. I think it's quite useful. :)

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: goal: booting with an empty /etc

[Neal Gompa]

On Mon, Dec 11, 2023 at 11:36 AM David Cantrell  wrote:
>
> On 12/8/23 10:25, 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.
>
> I'd rather see defaults under somewhere in /usr/share rather than /usr/lib.
>

I agree with this. I really would rather it be in /usr/share.

> > 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 just have an /etc tree like we see now but in /usr/share/etc
> (or /usr/etc, but then I get IRIX nightmares) and your local overrides
> exist in /etc.  Things like fstab will probably just have to always be
> host-dependent so they will always exist in /etc.
>

We're currently not allowed to use /usr/etc (not that I like that path
anyway) because it breaks RPM-OSTree. My understanding is that this
directory is reserved by RPM-OSTree for storing pristine copies of
/etc content for each OSTree commit.

> For this to be really clean and nice, everything that drops a file in
> /etc needs to handle the "read in the default; then read in the optional
> local overrides" model.  I know a lot of stuff already does this, but
> some things don't.  It would be a nice goal to aim for and maybe we can
> submit patches to upstream projects where the functionality is missing.
>

Indeed.





--
真実はいつも一つ！/ 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: Help packaging PyTorch dependencies for Fedora

[Steve Grubb]

On Monday, December 11, 2023 4:59:45 AM EST Tim Flink wrote:
> On 12/8/23 08: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? Also,
> 
> GPU acceleration is not enabled for the pytorch packages and that is
> intentional, for now. pytorch has a mess of third party dependencies which
> are managed upstream using git subrepos that point to external
> dependencies that may or may not be easy to package for Fedora.

Yes, I am familiar with the orignal LUA version which I had to build locally.

> From the beginning, our plan has been to get pytorch packaged for CPU only
> first and add accelerator support as we can. Perhaps the description for
> pytorch needs to be changed but our intent is to enable ROCm support for
> F40.

If you are doing CPU only, you really should enable a BLAS backend. Fedora 
has flexiblas available.
 
> I don't have the exact list of packages remaining before we can enable ROCm
> support for pytorch in front of me but I believe that we're down into the
> single digits and the biggest hurdle at the moment is ROCm's miopen due to
> some incompatibility with Fedora's llvm or hipcc.
 
> 
> > 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:
> 
> I'm not familiar with OpenMP or what might be required there, Tom (cc'd)
> would know more on that exact detail.

GCC should natively support it - unless it uses something brand new GCC 
hasn't adopted yet.
 
> I doubt that a CUDA version of pytorch will ever be packagable for the
> Fedora repos - the licensing on CUDA would have to change before that
> happens and while it's possible, it doesn't seem likely in the foreseeable
> future.

> It would be great to enable support for Intel accelerators but that is a
> different project for a different day. ROCm is the only accelerator
> support that we have scoped out at this point.
 
> 
> > 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.
> 
> In general, there are two reasons why a torch feature is not enabled in the
> Fedora package:
 
> 1. The license of a dependency for that feature is incompatible with
> Fedora
> 2. One or more dependencies are not yet packaged for Fedora

I think you can add OpenMP and BLAS support easily. That should be a small 
win.

-Steve 

> Obviously, features that fall into (1) are very difficult, if not
> impossible for us to work around. Features that fall into (2) will likely
> need more time - the first build for PyTorch was about a week ago and we
> still have work to do.
 
> We are working to get the pytorch packages in Fedora to be as complete as
> we can make them. If anyone is interested in helping, please join us on
> discourse (#ai-ml-sig) or Matrix (#ai-ml:fedoraproject.org).
 
> Tim
> 
> 
> > 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
> --
> ___
> 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/de...@lists.fedoraproject.or
> g Do not reply to spam, report it:
> 

Re: goal: booting with an empty /etc

[David Cantrell]

On 12/8/23 10:25, 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.

I'd rather see defaults under somewhere in /usr/share rather than /usr/lib.

> 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 just have an /etc tree like we see now but in /usr/share/etc
(or /usr/etc, but then I get IRIX nightmares) and your local overrides
exist in /etc.  Things like fstab will probably just have to always be
host-dependent so they will always exist in /etc.

For this to be really clean and nice, everything that drops a file in
/etc needs to handle the "read in the default; then read in the optional
local overrides" model.  I know a lot of stuff already does this, but
some things don't.  It would be a nice goal to aim for and maybe we can
submit patches to upstream projects where the functionality is missing.

-- 
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
--
___
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 2246934] perl-Mail-Box-3.010-1.fc40 FTBFS with perl-Mail-Message-3.014: t/505parser-bodymp.t tests fails

[bugzilla]

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

Paul Howarth  changed:

   What|Removed |Added

 CC||p...@city-fan.org



--- Comment #1 from Paul Howarth  ---
Mail::Message version 3.015 (in Rawhide now) fixes this.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202246934%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: goal: booting with an empty /etc

[DJ Delorie]

Lennart Poettering  writes:
> Well, as you might be aware many distributions these days do more than
> "files dns" for "hosts", and similar for the other databases, and
> hence a built-in default in glibc is great, but most distributions and
> image builders probably want to pick different defaults without having
> to patch glibc for this.

I agree.  My point was that (1) glibc has a built-in default, and (2)
most distros/users/installers customize it anyway, so storing a
"default" version anywhere other than /etc 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: goal: booting with an empty /etc

[Chris Adams]

Once upon a time, Peter Boy  said:
> I would like to go even further and also separate distribution default code 
> and locally installed code in the /usr tree. OpenSuse has developed a good 
> proposal for this some time ago.  

More separation than /usr vs. /usr/local?
-- 
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

[Bug 2253828] perl-Code-TidyAll-0.84 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Code-TidyAll-0.84-1.fc
   ||40
Last Closed||2023-12-11 16:08:08



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-b46ea19ed4 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253828%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

[Bug 2253828] perl-Code-TidyAll-0.84 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-b46ea19ed4 has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-b46ea19ed4


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253828%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

[Bug 2253828] perl-Code-TidyAll-0.84 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253828
--
___
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 2253785] perl-App-Cme-1.039 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
   Fixed In Version||perl-App-Cme-1.039-1.fc40
 Resolution|--- |ERRATA
Last Closed||2023-12-11 15:17:02



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-db74851f90 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253785%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

[Bug 2253770] perl-Math-BigInt-2.002001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Math-BigInt-2.0020.01-
   ||1.fc40
 Resolution|--- |ERRATA
 Status|MODIFIED|CLOSED
Last Closed||2023-12-11 14:53:02



--- Comment #2 from Fedora Update System  ---
FEDORA-2023-5ae8309a74 has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253770%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

Re: goal: booting with an empty /etc

[Daniel Walsh]

On 12/11/23 09:55, Peter Boy wrote:



Am 11.12.2023 um 15:09 schrieb David Both :

What is the objective of achieving this "boot with empty /etc"? What
does it accomplish? What problem does it solve?

For me, from a sysadmin POV, the great advantage is the clear separation of 
sysadmin made configuration and distribution provided (default) configuration. 
It makes the life of a sysadmin much easier, easier backup and selective 
restore, easier hunting for the cause of issues in a local app configuration, 
easier recovery and easier rebuild of a system that has become completely 
unusable. And all this for an RPM-based system and has nothing to do with 
containers.

However, I would consider a simple and unmistakable structure, i.e. 2 separate 
directories with XFS or BTRFS file system, to be reasonable and not an overlay 
file system. This only makes the recovery in emergency mode and limited tool 
availability prone to errors.

I would like to go even further and also separate distribution default code and 
locally installed code in the /usr tree. OpenSuse has developed a good proposal 
for this some time ago.

The nice thing about the overlay solution is that individual commands 
would not need to be modified to understand the new configuration.

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



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



--
___
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 2253785] perl-App-Cme-1.039 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-db74851f90 has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-db74851f90


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253785%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: goal: booting with an empty /etc

[Peter Boy]

> Am 11.12.2023 um 15:09 schrieb David Both :
> 
> What is the objective of achieving this "boot with empty /etc"? What
> does it accomplish? What problem does it solve?

For me, from a sysadmin POV, the great advantage is the clear separation of 
sysadmin made configuration and distribution provided (default) configuration. 
It makes the life of a sysadmin much easier, easier backup and selective 
restore, easier hunting for the cause of issues in a local app configuration, 
easier recovery and easier rebuild of a system that has become completely 
unusable. And all this for an RPM-based system and has nothing to do with 
containers. 

However, I would consider a simple and unmistakable structure, i.e. 2 separate 
directories with XFS or BTRFS file system, to be reasonable and not an overlay 
file system. This only makes the recovery in emergency mode and limited tool 
availability prone to errors.

I would like to go even further and also separate distribution default code and 
locally installed code in the /usr tree. OpenSuse has developed a good proposal 
for this some time ago.  


--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast



--
___
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 2253770] perl-Math-BigInt-2.002001 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED



--- Comment #1 from Fedora Update System  ---
FEDORA-2023-5ae8309a74 has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-5ae8309a74


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253770%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

[Bug 2253785] perl-App-Cme-1.039 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

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




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253785
--
___
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: goal: booting with an empty /etc

[Zbigniew Jędrzejewski-Szmek]

On Mon, Dec 11, 2023 at 09:09:33AM -0500, David Both wrote:
> 
> I think I understand the immediate goal here, but I am still confused.
> What is the objective of achieving this "boot with empty /etc"? What
> does it accomplish? What problem does it solve? Is it a solution for a
> small use case such as containers or something else? What problem does
> it solve for me - a sysadmin with a few servers and some workstations?
> 
> If the answer is in one of the early bits of this thread, could you
> point me to it please?

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UCVYQVWHYPGYRB7U47WJWJP5CRLFSLCZ/
I'd be happy to talk more about this, if this is not clear.

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

[David Both]

I think I understand the immediate goal here, but I am still confused.
What is the objective of achieving this "boot with empty /etc"? What
does it accomplish? What problem does it solve? Is it a solution for a
small use case such as containers or something else? What problem does
it solve for me - a sysadmin with a few servers and some workstations?

If the answer is in one of the early bits of this thread, could you
point me to it please?


Thanks!


--


*
David P. Both, RHCE
He/Him/His
*
www.both.org - My personal web site
www.Linux-Databook.info - Home of the DataBook for Linux
DataBook is a Registered Trademark of David Both
*
The value of any software lies in its usefulness
not in its price.

— Linus Torvalds
*

On Mon, 11 Dec 2023, Zbigniew Jędrzejewski-Szmek wrote:


Date: Mon, 11 Dec 2023 08:35:08
From: Zbigniew Jędrzejewski-Szmek 
Reply-To: Development discussions related to Fedora

To: Florian Weimer 
Cc: Development discussions related to Fedora 
Subject: SPAM (302.2) Re: goal: booting with an empty /etc

On Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote:

* Zbigniew Jędrzejewski-Szmek:


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.


I want to replace nss_wrapper with a simple set of environment
variables.  Once we have a multi-file search path, it's no longer so
simple because it's not clear if the default search path is amended or
replaced when the environment variable is set.


nss_wrapper currently fully overrides the system config. I think it'd
be reasonable to keep that behaviour. But anyway: having to make that
choice here is not a great argument against having multiple files, we
just have to remember about the issue and implement and document one
of the possibilities, whatever makes the most sense.


Loop detection on traditional file systems wouldn't be very difficult to
implement, except that we increasingly have file systems which have
dev_t/ino_t values that are not unique.  But that impacts any form of
loop detection, so I'm not overly concerned.


Yes, it certainly _can_ be done…

The systemd-style drop-in mechanism works well and is at this point widely
documented and understood. We also have cases where alternative mechanisms based
on 'include' were implemented, and, at least in my opinion, they have proven to
work less well. (E.g. sshd, sudo).

Anyway, I think that at this point the technical arguments have been laid out,
and we're down to questions of style. I _like_ the proposal with a fixed set of
file paths better, but I'd be happy to take the version with include directives
too, if it means we move some files 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

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

Heads up: dnf5 cannot handle BuildRequires with Python extras

[Miro Hrončok]

Hello Pythonistas.

In case you upgraded to mock-core-configs-39.3 and see failures like this in 
rawhide mockbuilds with %pyproject_buildrequires:


  No match for argument: python3dist(setuptools-scm[toml]) >= 5
  No match for argument: python3dist(raven[flask])
  No match for argument: python3dist(ini2toml[lite]) >= 0.9

Note that the issue is known and reported:

  https://github.com/rpm-software-management/dnf5/issues/1084
  https://github.com/rpm-software-management/mock/issues/1267

This should block the deployment of 
https://fedoraproject.org/wiki/Changes/BuildWithDNF5


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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

[Bug 2253770] perl-Math-BigInt-2.002001 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 CC|jples...@redhat.com,|
   |mspa...@redhat.com, |
   |ppi...@redhat.com   |
 Status|NEW |ASSIGNED
   Doc Type|--- |If docs needed, set a value




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2253770
--
___
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: Help packaging PyTorch dependencies for Fedora

[Tom Rix]

On 12/8/23 7:34 AM, 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?  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


I made the choice to focus on doing cpu first believing it would be a 
good base to build out from.


To be useful, PyTorch needs to be accelerated, but acceleration is 
complicated.  The acceleration stack as well as the hw drivers must be 
in Fedora.  This work is tracked on the HC sig page. Unfortunately CUDA 
is not open source. But ROCm is.  There is a parallel effort as Tim has 
said to enable the ROCm packages that PyTorch needs.  Most of them are 
in Fedora, but we are missing a couple of them.


Tom


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

--
___
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 Mon, Dec 11, 2023 at 09:58:04AM +0100, Florian Weimer wrote:
> * Zbigniew Jędrzejewski-Szmek:
> 
> >> 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.
> 
> I want to replace nss_wrapper with a simple set of environment
> variables.  Once we have a multi-file search path, it's no longer so
> simple because it's not clear if the default search path is amended or
> replaced when the environment variable is set.

nss_wrapper currently fully overrides the system config. I think it'd
be reasonable to keep that behaviour. But anyway: having to make that
choice here is not a great argument against having multiple files, we
just have to remember about the issue and implement and document one
of the possibilities, whatever makes the most sense.

> Loop detection on traditional file systems wouldn't be very difficult to
> implement, except that we increasingly have file systems which have
> dev_t/ino_t values that are not unique.  But that impacts any form of
> loop detection, so I'm not overly concerned.

Yes, it certainly _can_ be done…

The systemd-style drop-in mechanism works well and is at this point widely
documented and understood. We also have cases where alternative mechanisms based
on 'include' were implemented, and, at least in my opinion, they have proven to
work less well. (E.g. sshd, sudo).

Anyway, I think that at this point the technical arguments have been laid out,
and we're down to questions of style. I _like_ the proposal with a fixed set of
file paths better, but I'd be happy to take the version with include directives
too, if it means we move some files 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: Proven to be sickened

[Stephen Gallagher]

On Sun, Dec 10, 2023 at 9:49 PM Gary Buhrmaster
 wrote:
...
>
> FTBFS issues are, admittedly, complicated, but
> such updates SHOULD be via a PR.  If a PP wants
> to claim they cannot follow that process, they need
> to demonstrate that a particular packager is not
> responsive (there is a process for that) rather
> then just deciding themselves it is too much trouble.

While I generally agree that a merge request is a more polite and
elegant solution, if a package is listed as FTBFS (having had a bug
automatically opened) and some reasonable amount of time (two, three
weeks?) has passed, then I think it's perfectly reasonable to assume
that the maintainer is vacant (either entirely or because they lack
the available time to deal with it at this point). In that case, I
don't see it as a problem to jump in and fix the package as a
provenpackager if the fix is relatively minor (yes, this is
subjective). I'd hesitate at rebasing to a new version, but if the
issue is that a dependency changed its name or the newest gcc made a
warning into an error, I think that's a perfectly acceptable fix to
make. The ideal case is for it to go through a merge request, but if
the package happens to be blocking other work, I think expediency is
completely warranted.
--
___
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?

[Tomas Korbar]

Hi guys, I am ok with retiring the mailx package so s-nail can become the
primary
supplier of the mailx command.

On Mon, Dec 11, 2023 at 1:05 PM Jonathan Wakely  wrote:

> On Mon, 11 Dec 2023 at 12:03, Jonathan Wakely  wrote:
> >
> > On Fri, 8 Dec 2023 at 18:47, Adam Williamson 
> wrote:
> > >
> > > 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.
> >
> > I CC'd him (and tkorbar) on the first mail in this thread, and I only
> > started this thread after emailing them directly to discuss it (I
> > probably should have mentioned that I'd already run it by them).
> > Nikola suggested in that private discussion that retiring mailx was
> > probably the way to go, so I started this thread.
> >
> > > 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
> >
> > I think he's already on board with the change, and I think everybody
> > would be happier to Just Do It without a change proposal. I just
> > wanted to start a discussion and make sure the right process was
> > followed.
>
> ... and of course to check that nobody would object, on the grounds
> that they need the crufty mailx for some reason.
>
> > It sounds like I'm not the only person to waste time scratching my
> > head at the heirloom-mailx fossil, and so we should just retire it!
> --
> ___
> 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
>
--
___
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 2253976] perl-Mail-Message-3.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-Mail-Message-3.015-1.f
   ||c40
 Status|MODIFIED|CLOSED
 Resolution|--- |ERRATA
Last Closed||2023-12-11 12:26:07



--- Comment #4 from Fedora Update System  ---
FEDORA-2023-8b72e89bbe has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253976%23c4
--
___
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 2253976] perl-Mail-Message-3.015 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|NEW |MODIFIED



--- Comment #3 from Fedora Update System  ---
FEDORA-2023-8b72e89bbe has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2023-8b72e89bbe


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253976%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

[Bug 2252479] perl-Date-Manip-6.93 is available

[bugzilla]

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



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


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202252479%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

Re: Should we retire the mailx package?

[Jonathan Wakely]

On Mon, 11 Dec 2023 at 12:03, Jonathan Wakely  wrote:
>
> On Fri, 8 Dec 2023 at 18:47, Adam Williamson  
> wrote:
> >
> > 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.
>
> I CC'd him (and tkorbar) on the first mail in this thread, and I only
> started this thread after emailing them directly to discuss it (I
> probably should have mentioned that I'd already run it by them).
> Nikola suggested in that private discussion that retiring mailx was
> probably the way to go, so I started this thread.
>
> > 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
>
> I think he's already on board with the change, and I think everybody
> would be happier to Just Do It without a change proposal. I just
> wanted to start a discussion and make sure the right process was
> followed.

... and of course to check that nobody would object, on the grounds
that they need the crufty mailx for some reason.

> It sounds like I'm not the only person to waste time scratching my
> head at the heirloom-mailx fossil, and so we should just retire it!
--
___
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?

[Jonathan Wakely]

On Fri, 8 Dec 2023 at 18:47, Adam Williamson  wrote:
>
> 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.

I CC'd him (and tkorbar) on the first mail in this thread, and I only
started this thread after emailing them directly to discuss it (I
probably should have mentioned that I'd already run it by them).
Nikola suggested in that private discussion that retiring mailx was
probably the way to go, so I started this thread.

> 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

I think he's already on board with the change, and I think everybody
would be happier to Just Do It without a change proposal. I just
wanted to start a discussion and make sure the right process was
followed.

It sounds like I'm not the only person to waste time scratching my
head at the heirloom-mailx fossil, and so we should just retire it!
--
___
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 Linux 39 Elections Voting are now Open!

[Aoife Moloney]

Hi all,

The F39 elections voting period has now opened for FESCo
,
Mindshare
 and
Council 
.
Voting closes on Thursday, December 21st.


Thanks!
Aoife
-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
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 Linux 39 Elections Voting are now Open!

[Aoife Moloney]

Hi all,

The F39 elections voting period has now opened for FESCo
,
Mindshare
 and
Council 
.
Voting closes on Thursday, December 21st.


Thanks!
Aoife
-- 

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

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

Re: Change of cronie and crontabs CIS compliance

[Petr Lautrbach]

Ondrej Pohorelsky  writes:

> I've removed cron.allow from my PR[0] and reverted to cron.deny approach.
> As this was the only disputed change in these PRs so far, I plan on merging
> both of them into rawhide at the end of this week.
> However, if you see any issue with merging this "middle ground" change,
> feel free to discuss.
>

```
- %attr(4755,root,root) %{_bindir}/crontab
+ %attr(600,root,root) %{_bindir}/crontab
```

From
https://docs.fedoraproject.org/en-US/fedora/latest/system-administrators-guide/monitoring-and-automation/Automating_System_Tasks/

"""
To create a crontab as a specific user, login as that user and type the
command crontab -e to edit the user’s crontab with the editor specified
in the VISUAL or EDITOR environment variable.
"""

If you want to change this you should push the change via Fedora
Change process so it's clearly announced and documented.





> [0]https://src.fedoraproject.org/rpms/cronie/pull-request/12
>
> On Sun, Dec 10, 2023 at 3:37 PM Chuck Anderson  wrote:
>
>> On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
>> > The main effect of the permissions change on these files is that non-root
>> > users can't see any env variables set against the commands scheduled to
>> run.
>> > The actual command lines are still all visible in the proces listing when
>> > the command runs.
>>
>> I think this part alone is worthwhile in a general distro like Fedora,
>> irrespective of any CIS requirements.  Env vars can contain secret
>> data and they are no longer readble by all users in process lists, so
>> changing permissions on cron files fixes a real potential information
>> leak.
>>
>> Also, it is hard to keep file and directory permissions changed from
>> how they are packaged.  The files will become exposed during package
>> updates until some other script comes by and fixes them again.  So it
>> is worthwhile to fix this in the packaging.
>>
>> I agree that the correct middle ground is to fix the permissions, but
>> leave the other parts about cron.allow/cron.deny alone.
>> --
>> ___
>> 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
>>
>
>
> -- 
>
> Ondřej Pohořelský
>
> Software Engineer
>
> Red Hat 
>
> opoho...@redhat.com
> 
> --
> ___
> 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
--
___
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 2253979] perl-WWW-Splunk-2.09 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-WWW-Splunk-2.09-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=110179132


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253979%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

Re: Fedora Review Service and setting the AutomationTriaged keyword

[Jakub Kadlcik]

Thank you for the feedback Dominik,

> Cool! Go for it.
> Great idea.

I am going for it then :-)

On Sat, Dec 9, 2023 at 10:20 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Saturday, 09 December 2023 at 19:32, Jakub Kadlcik wrote:
> > Hello,
> > a year ago I announced
> > <
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/E4TT2PEOSITJ4PJP44L2GQUU4CA6R6B3/#ZJGYOMU6I7LEETQ4YEH6ZJBSC5VEM653
> >
> > 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
>
--
___
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 2253979] New: perl-WWW-Splunk-2.09 is available

[bugzilla]

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

Bug ID: 2253979
   Summary: perl-WWW-Splunk-2.09 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-WWW-Splunk
  Keywords: FutureFeature, Triaged
  Assignee: mspa...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: lkund...@v3.sk, mspa...@redhat.com,
perl-devel@lists.fedoraproject.org
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 2.09
Upstream release that is considered latest: 2.09
Current version/release in rawhide: 2.08-19.fc39
URL: http://search.cpan.org/dist/WWW-Splunk/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3510/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-WWW-Splunk


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253979%23c0
--
___
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 2253979] perl-WWW-Splunk-2.09 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 2003719
  --> https://bugzilla.redhat.com/attachment.cgi?id=2003719=edit
Update to 2.09 (#2253979)


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253979%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

[Bug 2253976] perl-Mail-Message-3.015 is available

[bugzilla]

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



--- Comment #2 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Mail-Message-3.015-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=110178719


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253976%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

[Bug 2253976] perl-Mail-Message-3.015 is available

[bugzilla]

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



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 2003706
  --> https://bugzilla.redhat.com/attachment.cgi?id=2003706=edit
Update to 3.015 (#2253976)


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253976%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

[Bug 2253976] New: perl-Mail-Message-3.015 is available

[bugzilla]

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

Bug ID: 2253976
   Summary: perl-Mail-Message-3.015 is available
   Product: Fedora
   Version: rawhide
Status: NEW
 Component: perl-Mail-Message
  Keywords: FutureFeature, Triaged
  Assignee: spo...@gmail.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: p...@city-fan.org, perl-devel@lists.fedoraproject.org,
spo...@gmail.com
  Target Milestone: ---
Classification: Fedora



Releases retrieved: 3.015
Upstream release that is considered latest: 3.015
Current version/release in rawhide: 3.014-1.fc40
URL: http://search.cpan.org/dist/Mail-Message/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/13324/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Mail-Message


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202253976%23c0
--
___
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: python packaging assistance sought for xgboost

[Miro Hrončok]

On 10. 12. 23 23:05, Nathan Scott wrote:

Thanks for the assistance Miro.

I've uploaded a local build log here:  
https://nathans.fedorapeople.org/xgboost/build.log

AFAICS the python parts of the %install step seemed to have worked, but based 
on Sandro's pointer I can see many files are missing.


Building wheels for collected packages: xgboost
  Building wheel for xgboost (pyproject.toml): started
  Running command Building wheel for xgboost (pyproject.toml)
  Building wheel for xgboost (pyproject.toml): finished with status 'done'
  Created wheel for xgboost: filename=xgboost-2.0.2-py3-none-linux_aarch64.whl 
size=1413 sha256=e77e7765ce58907708363f8e60bf96ba11abd5f66bb78c1804f59bccdd4df36d


There's not much information here, but size 1413 indicates the built wheel does 
not really have any Python modules in it.



--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
--
___
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

Re: Change of cronie and crontabs CIS compliance

[Ondrej Pohorelsky]

I've removed cron.allow from my PR[0] and reverted to cron.deny approach.
As this was the only disputed change in these PRs so far, I plan on merging
both of them into rawhide at the end of this week.
However, if you see any issue with merging this "middle ground" change,
feel free to discuss.

[0]https://src.fedoraproject.org/rpms/cronie/pull-request/12

On Sun, Dec 10, 2023 at 3:37 PM Chuck Anderson  wrote:

> On Wed, Dec 06, 2023 at 12:18:48PM +, Daniel P. Berrangé wrote:
> > The main effect of the permissions change on these files is that non-root
> > users can't see any env variables set against the commands scheduled to
> run.
> > The actual command lines are still all visible in the proces listing when
> > the command runs.
>
> I think this part alone is worthwhile in a general distro like Fedora,
> irrespective of any CIS requirements.  Env vars can contain secret
> data and they are no longer readble by all users in process lists, so
> changing permissions on cron files fixes a real potential information
> leak.
>
> Also, it is hard to keep file and directory permissions changed from
> how they are packaged.  The files will become exposed during package
> updates until some other script comes by and fixes them again.  So it
> is worthwhile to fix this in the packaging.
>
> I agree that the correct middle ground is to fix the permissions, but
> leave the other parts about cron.allow/cron.deny alone.
> --
> ___
> 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
>


-- 

Ondřej Pohořelský

Software Engineer

Red Hat 

opoho...@redhat.com

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

[Tim Flink]

On 12/9/23 14:47, Dominik 'Rathann' Mierzejewski wrote:

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.


We have made a lot of progress towards getting ROCm packaged in Fedora but 
we're not quite done and I know there are a few yet-unpackaged ROCm components 
which are required before ROCm support can be enabled for pytorch.

The current status list of ROCm packages is in the wiki: 
https://fedoraproject.org/wiki/SIGs/HC#Package_status

The current plan is to have ROCm 6.0.0 in F40 before branch, assuming that the 
release dates line up. As far as I know, AMD has not given an exact release 
date for 6.0 but ROCm 6.0 was announced last week and it seems likely to 
release well before F40 branch.

Tim


[...]

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

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

[Tim Flink]

On 12/8/23 08: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? Also,


GPU acceleration is not enabled for the pytorch packages and that is 
intentional, for now. pytorch has a mess of third party dependencies which are 
managed upstream using git subrepos that point to external dependencies that 
may or may not be easy to package for Fedora. From the beginning, our plan has 
been to get pytorch packaged for CPU only first and add accelerator support as 
we can. Perhaps the description for pytorch needs to be changed but our intent 
is to enable ROCm support for F40.

I don't have the exact list of packages remaining before we can enable ROCm 
support for pytorch in front of me but I believe that we're down into the 
single digits and the biggest hurdle at the moment is ROCm's miopen due to some 
incompatibility with Fedora's llvm or hipcc.


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:


I'm not familiar with OpenMP or what might be required there, Tom (cc'd) would 
know more on that exact detail.

I doubt that a CUDA version of pytorch will ever be packagable for the Fedora 
repos - the licensing on CUDA would have to change before that happens and 
while it's possible, it doesn't seem likely in the foreseeable future.

It would be great to enable support for Intel accelerators but that is a 
different project for a different day. ROCm is the only accelerator support 
that we have scoped out at this point.


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.


In general, there are two reasons why a torch feature is not enabled in the 
Fedora package:

1. The license of a dependency for that feature is incompatible with Fedora
2. One or more dependencies are not yet packaged for Fedora

Obviously, features that fall into (1) are very difficult, if not impossible 
for us to work around. Features that fall into (2) will likely need more time - 
the first build for PyTorch was about a week ago and we still have work to do.

We are working to get the pytorch packages in Fedora to be as complete as we 
can make them. If anyone is interested in helping, please join us on discourse 
(#ai-ml-sig) or Matrix (#ai-ml:fedoraproject.org).

Tim


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

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

[Tim Flink]

On 12/7/23 22:41, 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


PyTorch packages in Fedora are still a work in progress - torchvision and 
torchdata are still in review, for example.  We are definitely planning to 
announce it once we've made more progress and are also planning to make a F40 
change proposal for PyTorch.

I didn't realize that the dependency packaging list was out of date but I'll 
review it this week and make sure it has been updated.

Tim



Jun

On Wed, Oct 11, 2023 at 11:55 PM Kaitlyn Abdo  wrote:


Hello everyone,

I hope this email finds everyone well. We are currently packaging PyTorch for 
Fedora and we are actively packaging the dependencies. We’re reaching out to 
see if anyone is interested in joining the project. If you’re interested in 
more information, our meeting notes are in a GitHub repo and we have the AI/ML 
SIG discussion page where we’ve hosted all of our post meeting discussions. We 
have a WikiPage for our package assignment list if you would like to see what 
needs packaging or just to see the status of the project. Our next meeting is 
tomorrow, October 11th at 9AM EST and it’s on the FedoCal under the SIG 
calendar. All lists are found below. If you’re interested in joining, have any 
questions, or want to get a calendar invite for our reoccurring meeting, please 
feel free to email me at ka...@redhat.com or Teng at t...@redhat.com.

AI/ML SIG Discussion Page: https://discussion.fedoraproject.org/tag/ai-ml-sig
Meeting Notes: https://github.com/kaitlynabdo/pytorch-fedora-meeting-notes
Packaging Assignment List: 
https://fedoraproject.org/wiki/SIGs/PyTorch/packagingStatus
FedoCal: https://calendar.fedoraproject.org/SIGs/

Thank you!
Kaitlyn Abdo
___
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





--
___
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: 20231211.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20231210.n.0
NEW: Fedora-Rawhide-20231211.n.0

= SUMMARY =
Added images:4
Dropped images:  2
Added packages:  3
Dropped packages:0
Upgraded packages:   26
Downgraded packages: 0

Size of added packages:  179.08 MiB
Size of dropped packages:0 B
Size of upgraded packages:   2.05 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Onyx dvd-ostree x86_64
Path: Onyx/x86_64/iso/Fedora-Onyx-ostree-x86_64-Rawhide-20231211.n.0.iso
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-Rawhide-20231211.n.0.iso
Image: Kinoite dvd-ostree x86_64
Path: Kinoite/x86_64/iso/Fedora-Kinoite-ostree-x86_64-Rawhide-20231211.n.0.iso
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20231211.n.0.iso

= DROPPED IMAGES =
Image: Sericea dvd-ostree x86_64
Path: Sericea/x86_64/iso/Fedora-Sericea-ostree-x86_64-Rawhide-20231210.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231210.n.0.iso

= ADDED PACKAGES =
Package: obs-cef-5060^cr103.0.5060.134~git20231010.17f8588-2.fc40
Summary: OBS fork of the Chromium Embedded Framework
RPMs:obs-cef obs-cef-devel
Size:176.76 MiB

Package: wlroots0.16-0.16.2-1.fc40
Summary: A modular Wayland compositor library
RPMs:wlroots0.16 wlroots0.16-devel
Size:2.28 MiB

Package: xwayland-run-0.0.2-2.fc40
Summary: Set of utilities to run headless X/Wayland clients
RPMs:xwayland-run
Size:41.64 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  blender-1:4.0.2-1.fc40
Old package:  blender-1:4.0.1-2.fc40
Summary:  3D modeling, animation, rendering and post-production
RPMs: blender blender-rpm-macros
Size: 245.91 MiB
Size change:  -47.88 KiB
Changelog:
  * Sun Dec 10 2023 Luya Tshimbalanga  - 1:4.0.2-1
  - Update to 4.0.2 (fedora#2253092)


Package:  borgbackup-1.2.7-1.fc40
Old package:  borgbackup-1.2.6-3.fc40
Summary:  A deduplicating backup program with compression and authenticated 
encryption
RPMs: borgbackup
Size: 5.85 MiB
Size change:  9.10 KiB
Changelog:
  * Sun Dec 10 2023 Felix Schwarz  - 1.2.7-1
  - update to 1.2.7


Package:  containers-common-4:1-101.fc40
Old package:  containers-common-4:1-100.fc40
Summary:  Common configuration and documentation for containers
RPMs: containers-common containers-common-extra
Size: 110.18 KiB
Size change:  670 B
Changelog:
  * Sun Dec 10 2023 Daniel J Walsh  - 4:1-101
  - local build


Package:  cpuid-20230614-2.fc40
Old package:  cpuid-20230614-1.fc40
Summary:  Dumps information about the CPU(s)
RPMs: cpuid
Size: 151.85 KiB
Size change:  -724 B
Changelog:
  * Sun Dec 10 2023 Fabian Affolter  - 20230614-2
  - Add missing run-time requirement (fixes rhbz#2238868)


Package:  fakeroot-1.32.2-1.fc40
Old package:  fakeroot-1.32.1-1.fc40
Summary:  Gives a fake root environment
RPMs: fakeroot fakeroot-libs
Size: 602.42 KiB
Size change:  28.45 KiB
Changelog:
  * Mon Nov 06 2023 Fedora Release Monitoring 
 - 1.32.2-1
  - Update to 1.32.2 (#2248160)


Package:  goldendict-ng-23.12.07-1.fc40
Old package:  goldendict-ng-23.11.08-3.fc40
Summary:  The Next Generation GoldenDict
RPMs: goldendict-ng
Size: 5.99 MiB
Size change:  12.61 KiB
Changelog:
  * Mon Dec 11 2023 topazus  - 23.12.07-1
  - update to 23.12.07


Package:  java-1.8.0-openjdk-1:1.8.0.392.b08-6.fc40
Old package:  java-1.8.0-openjdk-1:1.8.0.392.b08-5.fc40
Summary:  OpenJDK 8 Runtime Environment
RPMs: java-1.8.0-openjdk java-1.8.0-openjdk-demo 
java-1.8.0-openjdk-demo-fastdebug java-1.8.0-openjdk-demo-slowdebug 
java-1.8.0-openjdk-devel java-1.8.0-openjdk-devel-fastdebug 
java-1.8.0-openjdk-devel-slowdebug java-1.8.0-openjdk-fastdebug 
java-1.8.0-openjdk-headless java-1.8.0-openjdk-headless-fastdebug 
java-1.8.0-openjdk-headless-slowdebug java-1.8.0-openjdk-javadoc 
java-1.8.0-openjdk-javadoc-zip java-1.8.0-openjdk-openjfx 
java-1.8.0-openjdk-openjfx-devel java-1.8.0-openjdk-openjfx-devel-fastdebug 
java-1.8.0-openjdk-openjfx-devel-slowdebug java-1.8.0-openjdk-openjfx-fastdebug 
java-1.8.0-openjdk-openjfx-slowdebug java-1.8.0-openjdk-slowdebug 
java-1.8.0-openjdk-src java-1.8.0-openjdk-src-fastdebug 
java-1.8.0-openjdk-src-slowdebug
Size: 1.63 GiB
Size change:  -28.83 KiB
Changelog:
  * Sat Dec 09 2023 Jiri Vanek  - 1:1.8.0.392.b08-6
  - repacking renamed portable tarballs, thus making the regex more geenric 
again


Package:  libhandy-1.8.2-5.fc40
Old package:  libhandy-1.8.2-4.fc40
Summary:  Building blocks for modern adaptive GNOME apps
RPMs: libhandy libhandy-devel
Size: 5.06 MiB
Size change:  15.89 KiB
Changelog:
  * Sun Dec 10 2023 Kalev Lember  - 1.8.2-5
  - Backport

Re: goal: booting with an empty /etc

[Lennart Poettering]

On Fr, 08.12.23 20:20, DJ Delorie (d...@redhat.com) 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.

Well, as you might be aware many distributions these days do more than
"files dns" for "hosts", and similar for the other databases, and
hence a built-in default in glibc is great, but most distributions and
image builders probably want to pick different defaults without having
to patch glibc for this.

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

[Florian Weimer]

* Zbigniew Jędrzejewski-Szmek:

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

I want to replace nss_wrapper with a simple set of environment
variables.  Once we have a multi-file search path, it's no longer so
simple because it's not clear if the default search path is amended or
replaced when the environment variable is set.

Loop detection on traditional file systems wouldn't be very difficult to
implement, except that we increasingly have file systems which have
dev_t/ino_t values that are not unique.  But that impacts any form of
loop detection, so I'm not overly concerned.

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