Re: "tunneler" package is broken - should it get removed?

[Vít Ondruch]

Dne 19. 09. 24 v 14:49 Thomas Huth napsal(a):


 Hi everyone!

The "tunneler" game in Fedora is broken since at least Fedora 38.

I reported the issue last year here:

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

... but apparently it is not maintained anymore, since there was no 
reaction to the bug report, though I even attached a patch that fixes 
the problem.


Thus should that broken package maybe simply get removed from Fedora, 
being broken and unmaintained?


 Thanks,
  Thomas



If you have interest in that game, it would be likely better to take 
over the packages. There are probably ways to contact Lubomír:


https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/UOHKYS5ZWSXF2XQAT5GW6SZPCIX7H3BT/



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Old Style Dependency Generators

[Vít Ondruch]

Dne 13. 09. 24 v 21:14 Michael Schwendt napsal(a):

On Fri, 13 Sep 2024 10:35:06 +0200, Vít Ondruch wrote:


$ grep -R filter_setup
audacious-plugins.spec:%filter_setup

A false positive, because such a simple grep doesn't handle the %if/%else
used in that spec file.



I believe that the new dependency generators were introduced by RPM 4.9.0:

https://rpm.org/wiki/Releases/4.9.0

Introduced into guidelines 13 year ago:

https://pagure.io/packaging-committee/issue/76

RHEL 7 shipped with RPM 4.11 and is already EOL for a few months.

Based on the above, is it really false positive? Is there any value in 
such conditional?



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Email when build completes

[Vít Ondruch]

Dne 14. 09. 24 v 9:19 Sandro napsal(a):

On 13-09-2024 18:26, Ron Olson wrote:
Thanks Gary, is there any documentation on how the rules work? I 
_think_ I created the appropriate rule but I haven’t received any 
notification and it’s likely I just did it wrong.


I have set "Tracking Rule" to "My Events" with "Applications" set to 
"Koji". There are probably other options like "Artifacts by user". But 
that rule definition works for me.



Anybody knows what should be the right content for "applications"? Can I 
leave it empty to have notifications from all applicaitons? Or do I need 
to list all applications? I have one empty rule and I don't think I am 
receiving "koji build complete" notifications.


Or should there be `*` for topic pattern or can I leave it empty?

Or maybe I should include "actions I initiated"?


The notifications would certainly deserved at least some basic 
documentation 



Vít




However, yesterday afternoon (UTC+2), I noticed quite some delay in 
the messages being delivered. Some arrived only an hour after the 
build job was actually finished. So, there's that as well.


-- Sandro



OpenPGP_signature.asc
Description: OpenPGP digital 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

Old Style Dependency Generators

[Vít Ondruch]

For ages, I had opened this PR [1] which was recently closed. This made 
me to dig into this a bit and it seems there is still quite a lot of 
packages using the old style dependency generators. I'd suggest to 
update those to the modern generators. The list of the affected packages 
is here:



~~~

$ grep -R filter_setup | wc -l
86

$ grep -R filter_setup
audacious-plugins.spec:%filter_setup
cvs2cl.spec:%{?filter_setup:
dhcp.spec:%{filter_setup}
dmlite.spec:%filter_setup
dyninst.spec:%{?filter_setup:
dyninst.spec:%filter_setup
fcitx-qt5.spec:%filter_setup
get_iplayer.spec:- conditionalise %%filter_setup properly.
glusterfs.spec:# filter_setup exists in RHEL6 only
glusterfs.spec:%filter_setup
gr-osmosdr.spec:%{?filter_setup:
gr-osmosdr.spec:%filter_setup
highlight.spec:%{?filter_setup:
highlight.spec:%filter_setup
hplip.spec:%{?filter_setup:
hplip.spec:%filter_setup
hypre.spec:%{?filter_setup:
hypre.spec:%filter_setup
Io-language.spec:%filter_setup
ldns.spec:%{?filter_setup:
ldns.spec:%filter_setup
libcouchbase.spec:%{?filter_setup}
libdasm.spec:%{?filter_setup:
libdasm.spec:%filter_setup
libkolabxml.spec:%{?filter_setup:
libkolabxml.spec:%filter_setup
libkolabxml.spec:%{?filter_setup:
libkolabxml.spec:%filter_setup
libkolabxml.spec:%{?filter_setup:
libkolabxml.spec:%filter_setup
libpst.spec:%{?filter_setup:
libpst.spec:%filter_setup
libvirt-python.spec:%{?filter_setup}
libxsmm.spec:%{?filter_setup:
libxsmm.spec:%filter_setup
mod_authnz_pam.spec:%{?filter_setup}
mod_intercept_form_submit.spec:%{?filter_setup}
mod_lookup_identity.spec:%{?filter_setup}
mod_perl.spec:- fix missing requirements, add filter_setup macro, remove 
double provides

nant.spec:%filter_setup
omniORB.spec:%{?filter_setup:
omniORB.spec:%filter_setup
opendbx.spec:%{?filter_setup:
opendbx.spec:%filter_setup
perl-AppConfig.spec:%{?filter_setup:
perl-Catalyst-Controller-FormBuilder.spec:%{?filter_setup:
perl-DateTime-Precise.spec:%{?filter_setup:
perl-HTML-TreeBuilder-XPath.spec:%{?filter_setup:
perl-HTML-TreeBuilder-XPath.spec:- update filtering for compatibility 
with older filter_setup macros

perl-IO-InSitu.spec:%filter_setup
perl-MooseX-Types-DateTimeX.spec:%filter_setup
perl-Rose-DateTime.spec:%filter_setup
perl-Rose-Object.spec:%filter_setup
perl-Socket-Netlink.spec:%{?filter_setup:
perl-Socket-Netlink-Route.spec:%{?filter_setup:
perl-Unicode-LineBreak.spec:%{?filter_setup:
perl-Wx.spec:%filter_setup
php.spec:- add filter_setup to not provides extensions as .so
php-phpiredis.spec:%{?filter_setup}
portmidi.spec:%{?filter_setup:
portmidi.spec:%filter_setup
purple-facebook.spec:%filter_setup
purple-facebook.spec:- Properly run %%filter_setup
pymilia.spec:%{?filter_setup:
pymilia.spec:%filter_setup
python3-poppler-qt5.spec:%{?filter_setup:
python3-poppler-qt5.spec:%filter_setup
python-cups.spec:%{?filter_setup:
python-cups.spec:%filter_setup
python-sane.spec:%filter_setup
python-smbc.spec:%{?filter_setup:
python-smbc.spec:%filter_setup
scribus.spec:%filter_setup
scummvm.spec:%{?filter_setup:
scummvm.spec:%filter_setup
smokeping.spec:%{?filter_setup:
smokeping.spec:%filter_setup
uuid.spec:%{?filter_setup}
vdr-femon.spec:- Filter out autoprovided libvdr-*.so.* (if 
%%filter_setup is available).
vdr-osdteletext.spec:- Filter out autoprovided libvdr-*.so.* (if 
%%filter_setup is available).
vdr-remote.spec:- Filter out autoprovided libvdr-*.so.* (if 
%%filter_setup is available).

vym.spec:%{?filter_setup:
whatsup.spec:%{?filter_setup:
whatsup.spec:%filter_setup
xapian-bindings.spec:%{?filter_setup}
uwsgi.spec:%filter_setup

~~~


If you ask why you should remove those, then the reason is that the "old 
style generators" disables the new style generators and therefore your 
package might be missing some commonly used requires/provides and is 
inconsistent with the rest of distribution.



Vít


[1] https://pagure.io/packaging-committee/pull-request/947



OpenPGP_signature.asc
Description: OpenPGP digital 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: Summary/Minutes from today's FESCo Meeting (2024-09-10)

[Vít Ondruch]

Dne 12. 09. 24 v 1:00 Josh Boyer napsal(a):



On Wed, Sep 11, 2024, 3:49 PM Adam Williamson 
 wrote:


On Wed, 2024-09-11 at 19:02 +0200, Fabio Valentini wrote:
> As I said, I have no option to *not* send it with wrapped lines ...
> sorry about that.

You can use real mail clients (Thunderbird, Evolution) with gmail and
they let you wrap your mails however you darn please. :D


Yes, but people could just use HTML mail as well.  I'm far too lazy to 
deal with multiple syncs across devices and phones, and other online 
clients suffer from the same problems.


Or we could stop posting these here entirely and use discourse instead.



This ^^ for me would be pretty sad outcome.


Vít




OpenPGP_signature.asc
Description: OpenPGP digital 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: Summary/Minutes from today's FESCo Meeting (2024-09-10)

[Vít Ondruch]

Dne 11. 09. 24 v 16:41 Fabio Valentini napsal(a):

On Wed, Sep 11, 2024 at 10:26 AM Vít Ondruch  wrote:

Can these reports not be wrapped to 80 lines or wrapped in a way the
wrapping respect the nesting? The wrapping makes them hard to read.

Thank for considering.

I assume you mean 80 columns, not 80 lines?



Ah, right. Sorry




In fact, the email as it was sent by me *was* automatically
line-wrapped (looks like 72 columns):
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7VPWY72SYBMNURE7KNEMEK3RKPBV27X5/

Doing line-wrapping by hand instead of letting my mail client do this
would be a lot of work.



I'd appreciate if *my* email client had a chance to do the work and wrap 
as / if needed. If the formatting of your email client would be 
superior, I'd probably not complained, though.




I agree that it could look better ... but I don't know how to achieve
that without making it more work for the person who runs the meeting.



Not wrapping it when posting would be sufficient for me.




Here's the link to the pretty-formatted HTML minutes, they might be
more to your liking:
https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2024-09-10/fesco.2024-09-10-17.02.html



Nice, but opening external links is not what I am up to. But yes, at 
least my browser can wrap the lines if needed. They are not wrapped in 
the original.



But as I can see your reply, it is also wrapped similarly to the 
original summary, so I am not sure. But looking into history, it seems 
that there is ~ 50:50 split between FESCo members who wrap and don't 
wrap summaries.



Vít



Fabio


OpenPGP_signature.asc
Description: OpenPGP digital 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: Summary/Minutes from today's FESCo Meeting (2024-09-10)

[Vít Ondruch]

Can these reports not be wrapped to 80 lines or wrapped in a way the 
wrapping respect the nesting? The wrapping makes them hard to read.


Thank for considering.


Vít


Dne 10. 09. 24 v 20:20 Fabio Valentini napsal(a):

=
# #meeting:fedoraproject.org: fesco
=

Meeting started by @decathorpe:fedora.im at 2024-09-10 17:02:11

Meeting summary
---
* TOPIC: Init Process (@decathorpe:fedora.im, 17:02:34)
* TOPIC: #3264 Incomplete Changes Report for Fedora Linux 41
(@decathorpe:fedora.im, 17:11:15)
 * INFO: Reviews for TaskWarrior 3 are in progress. The package can
land after Beta. (@zbyszek:fedora.im, 17:13:48)
* TOPIC: Switch to dnf5 (@zbyszek:fedora.im, 17:14:05)
 * INFO: dnf5daemon was postponed to F42. Gnome-software will
continue to use PackageKit + libdnf4. Tracker bug is ON_QA.
(@zbyszek:fedora.im, 17:20:15)
* TOPIC: IPU6 Camera Support  (@zbyszek:fedora.im, 17:21:49)
 * INFO: Change is feature complete, but with some open bugs.
(@zbyszek:fedora.im, 17:23:51)
* TOPIC: Make Tuned the Default Power Profile Management Daemon
(@zbyszek:fedora.im, 17:24:09)
 * INFO: The change seems mostly done, but there's some integration
work missing. We'll revisit after Beta. (@zbyszek:fedora.im, 17:29:30)
* TOPIC: #3266 Fedora 41 Beta Blocker: require the updates-testing
repository (@decathorpe:fedora.im, 17:32:15)
 * INFO: The request to designate active state of updates-testing
repo in F41 Beta as a FESCo blocker is withdrawn.
(@decathorpe:fedora.im, 17:40:23)
* TOPIC: #3267 wolfssl imported to Fedora after skipping MUST policy
requirements for new crypto libraries (@decathorpe:fedora.im,
17:41:06)
 * AGREED: WolfSSL is immediately retired from Fedora. The
maintainers may file a new package review request when WolfSSL
respects the crypto system policy. This review request must be
presented to the FPC, who must approve it before it is added back to
the repositories. (+5, 0, -0) (@decathorpe:fedora.im, 17:50:40)
* TOPIC: Open Floor (@decathorpe:fedora.im, 17:54:06)
* TOPIC: Next Week's Chair (@decathorpe:fedora.im, 17:54:27)
 * ACTION: nirik to chair next week's meeting
(@decathorpe:fedora.im, 17:57:38)
* TOPIC: Open Floor (@decathorpe:fedora.im, 17:57:49)
* TOPIC: Create fedora/fedora-netboot repo on quay.io
(@decathorpe:fedora.im, 18:04:47)
 * LINK: https://pagure.io/fedora-infrastructure/issue/12152
(@decathorpe:fedora.im, 18:04:53)
 * AGREED: FESCo would like to see a Change Proposal for better
visibility of the change and to invite public discussion. (+5, 0, -0)
(@decathorpe:fedora.im, 18:11:42)
* TOPIC: Open Floor (@decathorpe:fedora.im, 18:12:38)

Meeting ended at 2024-09-10 18:14:30

Action items

* nirik to chair next week's meeting

People Present (lines said)
---
* @decathorpe:fedora.im (88)
* @zbyszek:fedora.im (71)
* @nirik:matrix.scrye.com (31)
* @sgallagh:fedora.im (25)
* @zodbot:fedora.im (19)
* @conan_kudo:matrix.org (15)
* @humaton:fedora.im (15)
* @adamwill:fedora.im (6)
* @meetbot:fedora.im (3)


OpenPGP_signature.asc
Description: OpenPGP digital 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: Execute RPM dependency generators on the .spec file which ships them

[Vít Ondruch]

Dne 09. 09. 24 v 16:13 Vít Ondruch napsal(a):


Dne 04. 09. 24 v 22:43 Dridi Boukelmoune napsal(a):

On Wed, Sep 4, 2024 at 12:39 PM Vít Ondruch  wrote:

And the package has been retired in Rawhide, because RPM 4.20+ provides
its own implementation (and there should not be other users to my
knowledge):

I just started using it, it saves me the trouble of bootstrapping a
package



Out of curiosity, where do you use it?

Thx


Vít



, and I was about to sing you my praises for this neat little
hack.



😊




If you don't wish to maintain it, I will unretire 
rpm-local-generator-support

and keep it around until RPM 4.20 becomes the baseline.



I have retired the package in Rawhide and orphaned elsewhere, because 
I don't think it really needs maintenance. So feel free to use it as 
it is.


If your concern is compatibility of .spec files over all supported 
Fedoras, then I'd suggest to have a bit different version for Rawhide. 
I have not tried to find a way to make single .spec file to work 
everywhere. It is likely doable with some conditionals.



Vít




https://rpm-software-management.github.io/rpm/manual/dependency_generators.html#using-file-attributes-in-their-own-package 



The difference in use is minimal:

https://src.fedoraproject.org/rpms/ruby/pull-request/187#request_diff

Neat!

Dridi


OpenPGP_signature.asc
Description: OpenPGP digital 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: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"

[Vít Ondruch]

Dne 09. 09. 24 v 16:00 Miroslav Suchý napsal(a):

Dne 09. 09. 24 v 3:33 odp. Vít Ondruch napsal(a):


Neat. This would allow to slap in some comments, right? E.g:


~~~

License:    %{shrink:
    %dnl src/*.*
    MIT AND
    BSL-1.0 AND %dnl doc/*.*
    BSD-2-Clause AND
    (Apache-2.0 OR MIT OR BSL-1.0)
    } 


Technically yes, but please do not.

There is already

  https://reuse.software/

that has structure, documentation, linters, libraries...



But that is upstream stuff, isn't it?

My idea is to replace blocks like:

~~~

# MIT: src/*.*
# BSL-1.0: doc/*.*
License:    %{shrink:
    MIT AND
    BSL-1.0 AND
    BSD-2-Clause AND
    (Apache-2.0 OR MIT OR BSL-1.0)
    }

~~~


which are hardly any better.





Somehow incorporating this would be great.



Don't disagree, but this is IMHO orthogonal to my proposal.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Execute RPM dependency generators on the .spec file which ships them

[Vít Ondruch]

Dne 04. 09. 24 v 22:43 Dridi Boukelmoune napsal(a):

On Wed, Sep 4, 2024 at 12:39 PM Vít Ondruch  wrote:

And the package has been retired in Rawhide, because RPM 4.20+ provides
its own implementation (and there should not be other users to my
knowledge):

I just started using it, it saves me the trouble of bootstrapping a
package, and I was about to sing you my praises for this neat little
hack.



😊




If you don't wish to maintain it, I will unretire rpm-local-generator-support
and keep it around until RPM 4.20 becomes the baseline.



I have retired the package in Rawhide and orphaned elsewhere, because I 
don't think it really needs maintenance. So feel free to use it as it is.


If your concern is compatibility of .spec files over all supported 
Fedoras, then I'd suggest to have a bit different version for Rawhide. I 
have not tried to find a way to make single .spec file to work 
everywhere. It is likely doable with some conditionals.



Vít





https://rpm-software-management.github.io/rpm/manual/dependency_generators.html#using-file-attributes-in-their-own-package

The difference in use is minimal:

https://src.fedoraproject.org/rpms/ruby/pull-request/187#request_diff

Neat!

Dridi


OpenPGP_signature.asc
Description: OpenPGP digital 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: Donate 1 minute of your time to test upgrades from F40 to F41

[Vít Ondruch]

Dne 04. 09. 24 v 15:36 Leslie Satenstein via devel napsal(a):
I have frustrations with bugzilla, and please, if you can, try the 
following


sudo dnf/dnf5 install meld aisleriot

With every days F41 update the above crashes, and then...



I think you need `meld-3.22.2-5.fc41` from `updates-testing` repo. IOW try:

~~~

$ dnf update --enable-repo=updates-testing

~~~


Vít




dnf update (always fails to fetch updates)

Thanks in advance


Leslie Satenstein



On Wednesday, September 4, 2024 at 06:37:58 a.m. EDT, Ben Beasley 
 wrote:



It looks like most or all of these issues come from the third-party
signal-libringrtc package, which I think must have come from
https://download.opensuse.org/repositories/network:/im:/signal/Fedora_40/x86_64/. 


It would have to be rebuilt for Fedora 41. It doesn’t look like there is
a
https://download.opensuse.org/repositories/network:/im:/signal/Fedora_41/x86_64/ 


yet.

On 9/3/24 8:32 AM, Globe Trotter via devel wrote:
> $ sudo dnf --releasever=41 --enablerepo=updates-testing --assumeno 
distro-sync
> Last metadata expiration check: 0:01:26 ago on Tue 03 Sep 2024 
07:30:01 AM CDT.

> Error:
>   Problem 1: problem with installed package 
signal-libringrtc-2.46.1-1.1.x86_64
>    - package signal-libringrtc-2.46.1-1.1.x86_64 from @System 
requires libabsl_strings.so.2401.0.0()(64bit), but none of the 
providers can be installed
>    - package signal-libringrtc-2.46.1-1.1.x86_64 from @System 
requires libabsl_throw_delegate.so.2401.0.0()(64bit), but none of the 
providers can be installed
>    - package signal-libringrtc-2.46.1-1.1.x86_64 from 
network_im_signal requires libabsl_strings.so.2401.0.0()(64bit), but 
none of the providers can be installed
>    - package signal-libringrtc-2.46.1-1.1.x86_64 from 
network_im_signal requires 
libabsl_throw_delegate.so.2401.0.0()(64bit), but none of the providers 
can be installed
>    - abseil-cpp-20240116.2-1.fc40.x86_64 from @System  does not 
belong to a distupgrade repository
>   Problem 2: problem with installed package 
nodejs-electron-30.4.0-2.3.x86_64
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_cord.so.2401.0.0()(64bit), but none of the providers can be 
installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_cordz_info.so.2401.0.0()(64bit), but none of the providers can 
be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_hash.so.2401.0.0()(64bit), but none of the providers can be 
installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_int128.so.2401.0.0()(64bit), but none of the providers can be 
installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_raw_hash_set.so.2401.0.0()(64bit), but none of the providers 
can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_raw_logging_internal.so.2401.0.0()(64bit), but none of the 
providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_spinlock_wait.so.2401.0.0()(64bit), but none of the providers 
can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_status.so.2401.0.0()(64bit), but none of the providers can be 
installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_statusor.so.2401.0.0()(64bit), but none of the providers can 
be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_str_format_internal.so.2401.0.0()(64bit), but none of the 
providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_strings.so.2401.0.0()(64bit), but none of the providers can be 
installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_synchronization.so.2401.0.0()(64bit), but none of the 
providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_throw_delegate.so.2401.0.0()(64bit), but none of the providers 
can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from @System requires 
libabsl_time.so.2401.0.0()(64bit), but none of the providers can be 
installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from 
network_im_signal requires libabsl_cord.so.2401.0.0()(64bit), but none 
of the providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from 
network_im_signal requires libabsl_cordz_info.so.2401.0.0()(64bit), 
but none of the providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from 
network_im_signal requires libabsl_hash.so.2401.0.0()(64bit), but none 
of the providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from 
network_im_signal requires libabsl_int128.so.2401.0.0()(64bit), but 
none of the providers can be installed
>    - package nodejs-electron-30.4.0-2.3.x86_64 from 
network_im_signal

Re: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"

[Vít Ondruch]

Dne 06. 09. 24 v 13:08 Ben Beasley napsal(a):


There are still packages in this list that appear to have valid 
license expressions, but aren’t amenable to spec-file grepping because 
they use the %shrink macro to split long license expressions across 
multiple lines. Looking at this list:


music  c4core fcitx5-mozc gi-docgen libpri luminance-hdr 
python-pdfminer sequeler usd


I see that this is the case for all but fcitx5-mozc (which I 
co-maintain only in order to patch and rebuild it for abseil-cpp, and 
for which I don’t normally work on updates or other issues). For 
example, c4core has:


License:    %{shrink:
    MIT AND
    BSL-1.0 AND
    BSD-2-Clause AND
    (Apache-2.0 OR MIT OR BSL-1.0)
    }



Neat. This would allow to slap in some comments, right? E.g:


~~~

License:    %{shrink:
    %dnl src/*.*
    MIT AND
    BSL-1.0 AND %dnl doc/*.*
    BSD-2-Clause AND
    (Apache-2.0 OR MIT OR BSL-1.0)
    }

~~~


Vít


I think that packages that have the License spread across more than 
one spec-file line like this are a minority on this list, but there 
are enough of them that identifying and validating them should be a 
worthwhile step to pare down the list a bit.


On 9/6/24 4:49 AM, Miroslav Suchý wrote:


Bellow is list of packages that have licenses that are neither valid 
as Callaway nor as SPDX. I.e. the license cannot be validated neither 
using 'license-validate' nor using 'license-validate --old'.


Some examples I checked (random selection):

aldo.spec:
License:    GPL-2.0-or-later AND GPL-3.0
(typo in GPL-3.0)

plasma-mobile.spec:
License:    CC0 and GPLv2 and GPLv2+ and GPLv3 and GPLv3+ and 
LGPLv2+ and LGPLv2.1 and LGPLv2.1+ and LGPLv3 and LGPLv3 and MIT

( we do not track LGPLv2.1 and LGPLv2.1+ in Callaway system)

qcad.spec
License: GPL-3.0-only AND GPL-2.0-or-later AND MIT AND BSD AND Public 
Domain AND CC-BY-3.0 AND Hershey

(old form of BSD and PD, unknown license Heshey)

zeromq.spec:
License:    MPLv2.0 AND BSD-3-Clause AND MIT
(old form of MPL)

I wonder how to approach this?

Either:

1) Directly change it in dist-git to LicenseRef-Callaway-$OLD_ID with 
a comment that maintainer should revise it. Or


2) Open BZs for these packages.

I will welcome your comments and opinions.

There is 236 such cases in Fedora.

Maintainers by package:
Coin3    corsepiu hobbes1069 jkastner
Mayavi   chedi orion
OpenSceneGraph   smani
ProDy    sagitter
R-IRanges    spot
R-lubridate  qulogic
abi-dumper   hobbes1069 orion
accel-config miaojun0823 yunyings
ags  rathann
aldo hobbes1069
alsa-sof-firmware    perex
angelfish    kkofler thunderbirdtr
api-sanity-checker   hobbes1069
aprsdigi hobbes1069
aqbanking    limb rdieter
audacious-plugins    danfruehauf mschwendt robert
avogadro2-libs   sagitter
bacula   slaanesh
bijiben  mcrha pwalter
bmake    pemensik
bsh  didiksupriadi41 mizdebsk
btop jonathanspw
build2   mkrupcale
c4core   music
calf limb
ceph branto kkeithle ktdreyer
clamav   gnat mstevens nb orion pwouters robert sergiomb 
steve

clementine   eclipseo
cmake    besser82 orion pwalter rdieter
collectl kzak sharkcz
cross-binutils   dhowells lkundrak sharkcz
dcfldd   rebus
dumpasn1 fkooman
fcitx5-mozc  music yanqiyu
fedora-remix-logos   spot
fedora-workstation-backgrounds duffy luya ryanlerch
filebench    hushan
fldigi   hobbes1069
flmsg    hobbes1069
fltk aarem hobbes1069 jchaloup phracek rdieter
frescobaldi  limb
gdb-exploitable  sgrubb
generic-release  bruno mohanboddu spot
ghc-control-monad-free mathstuf petersen
ghc-http-client  qulogic
ghc-hxt-unicode  petersen
ghc-monad-loops  petersen
ghc-polyparse    petersen
ghc-tf-random    petersen
ghc-uglymemo mathstuf
ghostwriter  marcdeop
gi-docgen    music
gl-manpages  ajax yaneti
gmsh hobbes1069 ignatenkobrain jkastner smani
gnote    kalev
gnu-free-fonts   limb
golang-gopkg-retry-1 eclipseo
golang-gopkg-yaml-1  mikelo2
gstreamer1-doc   wtaymans
guayadeque   martinkg
hackrf   cottsay jskarvad stevenfalco
hibernate-jpa-2.0-api jjelen
hydra    rcallicotte rebus
icecat   kengert sagitter
iprutils dwmw2 jcajka sinnykumari
iucode-tool  duck puiterwijk
jam  spot
jbosscache-support   orphan
jsmath-fonts rdieter
julia    nalimilan
julius   spot
kcbench  thl
kclock   thunderbirdt

Re: [SPDX] packages that are "not valid neither as Callaway nor as SPDX"

[Vít Ondruch]

Dne 08. 09. 24 v 17:35 Miroslav Suchý napsal(a):

Dne 08. 09. 24 v 3:54 odp. Barry napsal(a):

$ LC_ALL=C rpmspec -q --qf '%{license}\n' ruby.spec
error: ruby.spec: line 241: failed to load macro file 
/home/msuchy/rpmbuild/SOURCES/macros.ruby

I have hit rslated issues like this in the past, rpmspec needs the rpm macro 
dependencies to be installed.
I assume if you install all the fedora rpm macro packages this will your script 
to run over all spec files.


Nope. If it would be required as build dependency, then it was no 
problem (but then the macros would not be available during building of 
src.rpm)


This issue is because (to speak about this specific case) ruby uses:

Source4: macros.ruby

%{load:%{SOURCE4}}

So rpmbuild looks for macros.ruby in %_sourcedir and that is normally 
~/rpmbuild/SOURCES/




https://github.com/rpm-software-management/rpm/issues/1171


Vít



When I redifine

%_sourcedir .

and then run the `rpmspec` tool in dist-git checkout then it does the 
right thing.


$ rpmspec -q --qf '%{license}\n' --define='_sourcedir .' ruby.spec


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys



OpenPGP_signature.asc
Description: OpenPGP digital 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: Execute RPM dependency generators on the .spec file which ships them

[Vít Ondruch]

And the package has been retired in Rawhide, because RPM 4.20+ provides 
its own implementation (and there should not be other users to my 
knowledge):


https://rpm-software-management.github.io/rpm/manual/dependency_generators.html#using-file-attributes-in-their-own-package

The difference in use is minimal:

https://src.fedoraproject.org/rpms/ruby/pull-request/187#request_diff


Vít



Dne 18. 10. 23 v 16:48 Vít Ondruch napsal(a):

The package is in Fedora now.

The practical demonstration are these two commits:

https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/6d8ecfca02947b5f1ce48cc51943e5f127d93be2 



https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/865f5b3a896ed1b423add7ffe0601707155828ef 



from this PR:

https://src.fedoraproject.org/rpms/ruby/pull-request/159



Vít


Dne 16. 10. 23 v 16:39 Vít Ondruch napsal(a):


Dne 16. 10. 23 v 16:35 Miroslav Suchý napsal(a):

Dne 16. 10. 23 v 16:16 Vít Ondruch napsal(a):
Can somebody help me please with a package review? The package 
can't be simpler.


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

Thx in advance 


Done.

You are welcome.



Thx a lot 🤩


Vít




OpenPGP_signature.asc
Description: OpenPGP digital 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 eln compose report: 20240829.n.1 changes

[Vít Ondruch]

Interesting. I see this for the first time and appreciate the report. 
Thanks to whoever enabled it.



Vít


Dne 29. 08. 24 v 17:27 Fedora ELN Report napsal(a):

OLD: Fedora-ELN-20240828.n.0
NEW: Fedora-ELN-20240829.n.1




... snip ...



OpenPGP_signature.asc
Description: OpenPGP digital 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 package builds with explicit C.UTF-8 locale

[Vít Ondruch]

Dne 28. 08. 24 v 16:45 Jerry James napsal(a):

On Tue, Aug 27, 2024 at 1:28 AM Vít Ondruch  wrote:

Since version 4.19, RPM defaults to C.UTF-8 locale [1]. Here is a list
of 248 packages which explicitly sets the locale and could drop the
setting. The list was generated with:

Thank you for pointing this out.  I have queued up changes for the
packages I maintain, which include all of the gap-pkg-* packages.



Glad you are going to save almost 100 lines of spec files ;)


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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

Fedora package builds with explicit C.UTF-8 locale

[Vít Ondruch]

Hi,

Since version 4.19, RPM defaults to C.UTF-8 locale [1]. Here is a list 
of 248 packages which explicitly sets the locale and could drop the 
setting. The list was generated with:



# strip changelogs
for x in *.spec; do sed -i '/^%changelog$/q' $x; done

grep -E 
'(^|\W)(LANG|LANGUAGE|LC_CTYPE|LC_NUMERIC|LC_TIME|LC_COLLATE|LC_MONETARY|LC_MESSAGES|LC_PAPER|LC_NAME|LC_ADDRESS|LC_TELEPHONE|LC_MEASUREMENT|LC_IDENTIFICATION|LC_ALL)=[Cc]\.[Uu][Tt][Ff]-?8($|\W)'

-r | sed 's/:/ /' | grep -v 'spec #' | sort -u

Credits goes to Mikolaj for pointing this out and preparing the attached 
list.



Vít



[1] https://github.com/rpm-software-management/rpm/pull/2616
Agda-stdlib.spec LANG=C.utf8 %{agda} README.agda
GAPDoc.spec export LC_ALL=C.UTF-8
R-BiocFileCache.spec export LANG=C.UTF-8
R-V8.spec export LANG=C.UTF-8
R-arules.spec export _R_CHECK_FORCE_SUGGESTS_=0 LANG=C.UTF-8
R-cli.spec export LANG=C.UTF-8
R-curl.spec export LANG=C.UTF-8
R-desc.spec export LANG=C.UTF-8
R-diffobj.spec export LANG=C.UTF-8
R-discretization.spec export LANG=C.UTF-8
R-dplyr.spec export LANG=C.UTF-8
R-errors.spec export LANG=C.UTF-8
R-flexiblas.spec export LANG=C.UTF-8
R-fs.spec export LANG=C.UTF-8
R-ggplot2.spec export LANG=C.UTF-8
R-glue.spec export LANG=C.UTF-8
R-gpx.spec export LANG=C.UTF-8
R-htmltools.spec export LANG=C.UTF-8
R-httpuv.spec export LANG=C.UTF-8
R-hunspell.spec export LANG=C.UTF-8
R-ica.spec export LANG=C.UTF-8
R-knitr.spec export LANG=C.UTF-8
R-metaheuristicopt.spec export LANG=C.UTF-8
R-niarules.spec export LANG=C.UTF-8
R-pbapply.spec export LANG=C.UTF-8
R-pillar.spec export LANG=C.UTF-8
R-quantities.spec export LANG=C.UTF-8
R-rJava.spec export LANG=C.UTF-8
R-readr.spec export LANG=C.UTF-8
R-repr.spec export LANG=C.UTF-8
R-reprex.spec export LANG=C.UTF-8
R-rlang.spec export LANG=C.UTF-8
R-roxygen2.spec export LANG=C.UTF-8
R-sessioninfo.spec export LANG=C.UTF-8
R-sfsmisc.spec export LANG=C.UTF-8
R-simmer.spec export LANG=C.UTF-8
R-sourcetools.spec export LANG=C.UTF-8
R-stringr.spec export LANG=C.UTF-8
R-styler.spec export LANG=C.UTF-8
R-svglite.spec export LANG=C.UTF-8
R-sys.spec export LANG=C.UTF-8
R-testthat.spec export _R_CHECK_FORCE_SUGGESTS_=0 LANG=C.UTF-8
R-tibble.spec export LANG=C.UTF-8
R-tikzDevice.spec export LANG=C.utf8
R-timechange.spec export _R_CHECK_FORCE_SUGGESTS_=0 LANG=C.UTF-8
R-units.spec export LANG=C.UTF-8
R-vcd.spec export _R_CHECK_FORCE_SUGGESTS_=0 LANG=C.UTF-8
R-vctrs.spec export LANG=C.UTF-8
R-webutils.spec export LANG=C.UTF-8
R-winch.spec export LANG=C.UTF-8
R-withr.spec export LANG=C.UTF-8
alexandria.spec export LANG=C.utf8
ant.spec LC_ALL=C.UTF-8 %{ant} -Doffline=true test
ardour6.spec export LC_ALL=C.UTF-8
ardour7.spec export LC_ALL=C.UTF-8
ardour8.spec export LC_ALL=C.UTF-8
bash-completion.spec export LANG=C.UTF-8
calls.spec LC_ALL=C.UTF-8 xvfb-run sh <<'SH'
chatty.spec LC_ALL=C.UTF-8 xvfb-run sh <<'SH'
clisp.spec export LC_ALL=C.UTF-8
clover2.spec LANG=C.utf8 make -C clover2 test
diffoscope.spec LC_CTYPE=C.utf8 \
elixir.spec export LANG=C.UTF-8
espeak-ng.spec LC_ALL=C.UTF-8 make docs
fantasdic.spec export LANG=C.UTF-8
fantasdic.spec export LANG=C.utf8
fedscm-admin.spec export LANG=C.UTF-8
fedscm-admin.spec export LC_ALL=C.UTF-8
gap-pkg-4ti2interface.spec export LC_ALL=C.UTF-8
gap-pkg-ace.spec export LC_ALL=C.UTF-8
gap-pkg-aclib.spec export LC_ALL=C.UTF-8
gap-pkg-alnuth.spec export LC_ALL=C.UTF-8
gap-pkg-anupq.spec export LC_ALL=C.UTF-8
gap-pkg-atlasrep.spec export LC_ALL=C.UTF-8
gap-pkg-autodoc.spec export LC_ALL=C.UTF-8
gap-pkg-automata.spec export LC_ALL=C.UTF-8
gap-pkg-autpgrp.spec export LC_ALL=C.UTF-8
gap-pkg-browse.spec export LC_ALL=C.UTF-8
gap-pkg-caratinterface.spec export LC_ALL=C.UTF-8
gap-pkg-circle.spec export LC_ALL=C.UTF-8
gap-pkg-cohomolo.spec export LC_ALL=C.UTF-8
gap-pkg-congruence.spec export LC_ALL=C.UTF-8
gap-pkg-corelg.spec export LC_ALL=C.UTF-8
gap-pkg-crime.spec export LC_ALL=C.UTF-8
gap-pkg-crisp.spec export LC_ALL=C.UTF-8
gap-pkg-crypting.spec export LC_ALL=C.UTF-8
gap-pkg-cryst.spec export LC_ALL=C.UTF-8
gap-pkg-crystcat.spec export LC_ALL=C.UTF-8
gap-pkg-ctbllib.spec export LC_ALL=C.UTF-8
gap-pkg-curlinterface.spec export LC_ALL=C.UTF-8
gap-pkg-cvec.spec export LC_ALL=C.UTF-8
gap-pkg-datastructures.spec export LC_ALL=C.UTF-8
gap-pkg-digraphs.spec export LC_ALL=C.UTF-8
gap-pkg-edim.spec export LC_ALL=C.UTF-8
gap-pkg-factint.spec export LC_ALL=C.UTF-8
gap-pkg-ferret.spec export LC_ALL=C.UTF-8
gap-pkg-fga.spec export LC_ALL=C.UTF-8
gap-pkg-fining.spec export LC_ALL=C.UTF-8
gap-pkg-float.spec export LC_ALL=C.UTF-8
gap-pkg-format.spec export LC_ALL=C.UTF-8
gap-pkg-forms.spec export LC_ALL=C.UTF-8
gap-pkg-fr.spec export LC_ALL=C.UTF-8
gap-pkg-francy.spec export LC_ALL=C.UTF-8
gap-pkg-gbnp.spec export LC_ALL=C.UTF-8
gap-pkg-genss.spec export LC_ALL=C.UTF-8
gap-pkg-grape.spec export LC_ALL=C.UTF-8
gap-pkg-groupoids.spec export LC_ALL=C.UTF-8
gap-pkg-grpconst.spec export LC_ALL=C.UTF-8
gap-pkg-guava.spec export LC_ALL=C.UTF-8
gap-pkg-hap.spec export LC_ALL=C.UTF-8
ga

Re: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Vít Ondruch]

Dne 22. 08. 24 v 14:37 Lennart Poettering napsal(a):

On Mi, 07.08.24 13:09, Vít Ondruch (vondr...@redhat.com) wrote:


With new RPM, I hit the limit in two packages:

https://koschei.fedoraproject.org/package/rubygem-abrt

https://koschei.fedoraproject.org/package/rubygem-pg


I have read:

https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars

https://stackoverflow.com/questions/34829600/why-is-the-maximal-path-length-allowed-for-unix-sockets-on-linux-108


But I still wonder why we should live with such limitation in 21st century.

You don't really have to live with such a limitation. In systemd we
have code that works around this limitation via O_PATH. i.e. when
connect()ing you first open the socket inode with O_PATH, and then you
fire the connect() specifying /proc/self/fd/ as path. That always
fits into the 108ch limit.



This was the workaround I have applied for the rubygem-pg:

https://src.fedoraproject.org/rpms/rubygem-pg/c/8a983a989b28325fc23d650d9c2bd25409785bc5?branch=rawhide

Specifically the `export RUBY_PG_TEST_DIR=%{_builddir}/tmp` line. But 
not sure how would I apply your suggestion. That is something which 
would need to be addressed on PostgreSQL side, right (sorry, O_PATH and 
FDs are not my domain)?


IOW that means workaround the issue in all possible projects, where it 
would be likely enough to change Kernel.



Vít




bind()ing to an overly long unix socket path is also doable, but
harder (since you cannot O_PATH on an inode that doesn't exist
yet). The way I'd do it is via chdir() to the dir of the target path
and binding to a relative path then. But chdir() is of course icky,
since it's a global property of a process, hence will affect all
threads. Hence, maybe do this in a short-lived forked off process.

Lennart

--
Lennart Poettering, Berlin


OpenPGP_signature.asc
Description: OpenPGP digital 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: Adopting and repurposing muon

[Vít Ondruch]

Dne 13. 08. 24 v 19:20 Link Dupont napsal(a):

Hello,

I noticed that the up-and-coming meson-compliant build tool muon[1] is not currently 
available in Fedora. While searching around, I found that a dist-git repository[2] titled 
"muon" already exists, and used to contain a KDE Plasma utility. It has been 
orphaned for a very long time (April 2016). I'm considering submitting muon[1] to Fedora, 
and I'd like to solicit the community opinion on how to reconcile the package names. I 
can think of a few approaches to take.

1) Adopt muon[2], package muon[1] and push it to rawhide. YOLO.
2) Adopt muon[2], package muon[1], submit a New Package Review and reconcile 
the existing dist-git repository with releng when the Review is approved.



The KDE package was renamed:

https://src.fedoraproject.org/rpms/muon/c/6801fe77237982dd214be622a520bb4d5c1c9292?branch=rawhide

Therefore I think it is safe to recycle the name / repository.

BTW not sure how you have already become POC of the `muon` repository, 
but I think you should follow regular new package review process.



Vít



3) Package muon[1] under a new package name (muon-build), submit a New Package Review, etc. Include 
a "Provides" to keep the "muon" name.

Are there any better approaches to take here?

~link

1: https://github.com/muon-build/muon
2: https://src.fedoraproject.org/rpms/muon


OpenPGP_signature.asc
Description: OpenPGP digital 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Vít Ondruch]

Dne 07. 08. 24 v 16:19 Vít Ondruch napsal(a):


Dne 07. 08. 24 v 16:06 Vít Ondruch napsal(a):


Dne 07. 08. 24 v 15:20 Tom Hughes via devel napsal(a):

On 07/08/2024 12:54, Richard W.M. Jones wrote:

On Wed, Aug 07, 2024 at 01:09:01PM +0200, Vít Ondruch wrote:

With new RPM, I hit the limit in two packages:

https://koschei.fedoraproject.org/package/rubygem-abrt

https://koschei.fedoraproject.org/package/rubygem-pg


Is it RPM, or is it "rspec"?  Seems to be some sort of Ruby tool.


The first one is something I assume the test is doing... Perhaps
these ones using deliberately silly paths?

https://github.com/voxik/abrt-ruby/blob/5cd42e6cf6024e80cdccdf8c3ba2128f2717ab69/spec/abrt_handler_spec.rb#L122 



The second one is less clear  - it doesn't seem to be using the
%postgresql_tests_run macro to start a postgres server for testing
so I assume the ruby tests are starting one themselves but in
a directory that has a long enough name that the socket name
is too long?



Yes, this is good analysis. It can hardly be expected that upstream 
test suite could leverage `%postgresql_tests_run` macro



Looking closer at the macro, maybe I should give it try.



That does not really help. It would help with the "random PG port", but 
the DB settings for the test suite is too specific. If the env variables 
set by the macro were upstreamed in Postgres, that would likely be 
different discussion.



Vít





Vít





I think the 107 bytes limitation is much sillier then the paths above.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Vít Ondruch]

Dne 07. 08. 24 v 16:06 Vít Ondruch napsal(a):


Dne 07. 08. 24 v 15:20 Tom Hughes via devel napsal(a):

On 07/08/2024 12:54, Richard W.M. Jones wrote:

On Wed, Aug 07, 2024 at 01:09:01PM +0200, Vít Ondruch wrote:

With new RPM, I hit the limit in two packages:

https://koschei.fedoraproject.org/package/rubygem-abrt

https://koschei.fedoraproject.org/package/rubygem-pg


Is it RPM, or is it "rspec"?  Seems to be some sort of Ruby tool.


The first one is something I assume the test is doing... Perhaps
these ones using deliberately silly paths?

https://github.com/voxik/abrt-ruby/blob/5cd42e6cf6024e80cdccdf8c3ba2128f2717ab69/spec/abrt_handler_spec.rb#L122 



The second one is less clear  - it doesn't seem to be using the
%postgresql_tests_run macro to start a postgres server for testing
so I assume the ruby tests are starting one themselves but in
a directory that has a long enough name that the socket name
is too long?



Yes, this is good analysis. It can hardly be expected that upstream 
test suite could leverage `%postgresql_tests_run` macro



Looking closer at the macro, maybe I should give it try.


Vít





I think the 107 bytes limitation is much sillier then the paths above.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: `Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Vít Ondruch]

Dne 07. 08. 24 v 15:20 Tom Hughes via devel napsal(a):

On 07/08/2024 12:54, Richard W.M. Jones wrote:

On Wed, Aug 07, 2024 at 01:09:01PM +0200, Vít Ondruch wrote:

With new RPM, I hit the limit in two packages:

https://koschei.fedoraproject.org/package/rubygem-abrt

https://koschei.fedoraproject.org/package/rubygem-pg


Is it RPM, or is it "rspec"?  Seems to be some sort of Ruby tool.


The first one is something I assume the test is doing... Perhaps
these ones using deliberately silly paths?

https://github.com/voxik/abrt-ruby/blob/5cd42e6cf6024e80cdccdf8c3ba2128f2717ab69/spec/abrt_handler_spec.rb#L122 



The second one is less clear  - it doesn't seem to be using the
%postgresql_tests_run macro to start a postgres server for testing
so I assume the ruby tests are starting one themselves but in
a directory that has a long enough name that the socket name
is too long?



Yes, this is good analysis. It can hardly be expected that upstream test 
suite could leverage `%postgresql_tests_run` macro


I think the 107 bytes limitation is much sillier then the paths above.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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

`Unix-domain socket path "..." is too long (maximum 107 bytes)` can we change that?

[Vít Ondruch]

With new RPM, I hit the limit in two packages:

https://koschei.fedoraproject.org/package/rubygem-abrt

https://koschei.fedoraproject.org/package/rubygem-pg


I have read:

https://unix.stackexchange.com/questions/367008/why-is-socket-path-length-limited-to-a-hundred-chars

https://stackoverflow.com/questions/34829600/why-is-the-maximal-path-length-allowed-for-unix-sockets-on-linux-108


But I still wonder why we should live with such limitation in 21st century.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Vít Ondruch]

Dne 31. 07. 24 v 17:02 Simon Farnsworth napsal(a):

On Wednesday 31 July 2024 10:53:37 BST Vít Ondruch wrote:

Dne 24. 07. 24 v 20:17 Stephen Gallagher napsal(a):


On Wed, Jul 24, 2024 at 1:46 PM Miroslav Suchý  wrote:


Dne 24. 07. 24 v 12:30 odp. Joe Orton napsal(a):



Having a "majority rule" vote of e.g. packagers or provenpackagers on
major technical decisions would be far superior, in my view. Apache
communities have worked this way forever.



You can always propose this as a change to our process.

For what it's worth, I don't believe that this process will work well.
I'm all for democracy, but direct democracy without compulsory voting
inevitably leads to "grievance-based voting", where the majority of
folks ignore the discussion and a plurality of voters with a strong
opinion effectively stuff the ballot box. The effect is to have a
tyranny of the (loud) minority. The closest we could get to
"compulsory voting" would be to require a quorum of votes to be
considered binding, but even the FESCo and Council elections
traditionally see extremely low voter turnout. I don't think we'd be
able to reach a sensible quorum on a referendum-based system.



Actually, I think that this could help:

https://en.wikipedia.org/wiki/Voting_in_Switzerland#Referendums

E.g. if we figured there are lets say 20 Fedora contributors who are
unhappy with the FESCo voting, all contributors could vote in
"referendum" to (dis)approve.


20 contributors is far too small for the Swiss method to be a fair comparison.

The Swiss system requires 50,000 eligible voters to ask for a referendum
within 100 days, and Switerzland has a bit over 5 million total eligible
voters; that's around 1% (it was increased in the 1970s from 30,000, when the
Swiss franchise went from about 1.5 million to about 3 million).

Fedora has (per 
https://www.redhat.com/en/open-source/articles/fedora-project-open-source-evolved)
 over 24,000 contributors



Of course the number is debatable. I think that as of now, there is 
~1500 sponsored packagers, that is the group which should be IMHO 
relevant to this discussion, because this is the group which proposes 
changes FESCo decides about.



Vít



, so to be comparable, you'd be
looking at at least 200 contributors (if not 250 contributors) all willing to
express unhappiness with FESCo within 100 days of a decision.

And note, based on https://elections.fedoraproject.org/archives, that only
about 1% of Fedora contributors vote at all. If we copy the Swiss model, that
means that the only way to get a referendum going would be to get every
actively voting contributor to ask for one.


Vít





Beyond that, I don't think the current approach is actually broken.
People elected us to make these sorts of decisions on their behalf. If
any of us were to consistently vote in a way that the general
community members felt is not in the interests of Fedora, then I fully
expect and hope that we would not be re-elected.



The current approach is the best one I can think of for our community:
we have an active feedback period where anyone can (and is encouraged)
to chime in on potential changes. I can assure you that I read that
feedback and I expect that the other members of FESCo do the same. If
you look at our meeting notes, you'll notice we often defer our
decisions when a discussion remains highly active.



As for the accusations of "rubber stamping" all Changes, I'd like to
note that FESCo has declined to accept several Changes this cycle
based on feedback. If you look at last week's minutes, you'll note
that we discussed and rejected two proposals and approved another
reluctantly (due to a lack of better options).



By the time issues get to a FESCo vote, they've generally run through
the discussion and have either been agreed to or the disagreement is
clearly not going to reach a compromise, at which point FESCo has to
make a decision. Sometimes that's going to be controversial (as in
this case, apparently). When voting, we don't always restate our
thought process, which admittedly means that the votes - taken in a
vacuum - can lack context and perhaps appear unconsidered.








OpenPGP_signature.asc
Description: OpenPGP digital 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: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Vít Ondruch]

Dne 31. 07. 24 v 15:12 Stephen Gallagher napsal(a):

On Wed, Jul 31, 2024 at 5:54 AM Vít Ondruch  wrote:


Dne 24. 07. 24 v 20:17 Stephen Gallagher napsal(a):

On Wed, Jul 24, 2024 at 1:46 PM Miroslav Suchý  wrote:

Dne 24. 07. 24 v 12:30 odp. Joe Orton napsal(a):

Having a "majority rule" vote of e.g. packagers or provenpackagers on
major technical decisions would be far superior, in my view. Apache
communities have worked this way forever.

You can always propose this as a change to our process.

For what it's worth, I don't believe that this process will work well.
I'm all for democracy, but direct democracy without compulsory voting
inevitably leads to "grievance-based voting", where the majority of
folks ignore the discussion and a plurality of voters with a strong
opinion effectively stuff the ballot box. The effect is to have a
tyranny of the (loud) minority. The closest we could get to
"compulsory voting" would be to require a quorum of votes to be
considered binding, but even the FESCo and Council elections
traditionally see extremely low voter turnout. I don't think we'd be
able to reach a sensible quorum on a referendum-based system.


Actually, I think that this could help:

https://en.wikipedia.org/wiki/Voting_in_Switzerland#Referendums

E.g. if we figured there are lets say 20 Fedora contributors who are
unhappy with the FESCo voting, all contributors could vote in
"referendum" to (dis)approve.

That would be exactly what I described above as "grievance-based voting".



You talk about "tyranny of the (loud) minority", but I think the limits 
are the key. If there needed to be e.g. 20 contributors to raise the 
concern with the voting, that is hardly minority (considering there was 
~200 voters in FESCo elections). But then there is the voting itself, 
where there would e.g. 200 contributors (and there could also be 
required minimal quorum) could express their opinion if the FESCo 
decision was correct/incorrect.



IOW I don't think it would be that easy to find those 20 contributors to 
even start the voting.



I see it as an insurance.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: [SPDX] Mass license change - variety of licenses and compound formulas

[Vít Ondruch]

Dne 31. 07. 24 v 11:58 Miroslav Suchý napsal(a):

Dne 31. 07. 24 v 11:16 dop. Vít Ondruch napsal(a):

I probably don't understand right the first one:

~~~

diff -Naur rpm-specs.orig/aces_container.spec 
rpm-specs/aces_container.spec
--- rpm-specs.orig/aces_container.spec    2024-07-18 
04:00:12.0 +0200

+++ rpm-specs/aces_container.spec    2024-07-31 10:52:00.694637327 +0200
@@ -3,10 +3,11 @@

 Name:   aces_container
 Version:    1.0.2
-Release:    17%{?dist}
+Release:    18%{?dist}
 Summary:    ACES Container Reference

-License:    AMPAS BSD
+# Automatically converted from old format: AMPAS BSD - review is 
highly recommended.

+License:    AMPAS
 URL:    https://github.com/ampas/aces_container
 Source0: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz
 Patch0: Switch-to-CMAKE-default-variables.patch
@@ -73,6 +74,9 @@

~~~


How we could dare to drop the `BSD`?



Callaway string "AMPAS BSD" as whole converts to SPDX "AMPAS". See

https://gitlab.com/fedora/legal/fedora-license-data/-/blob/main/data/AMPAS.toml?ref_type=heads#L17 






Ah, that is one license string 🤦‍♂️ sorry for the noise.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Schedule for Tuesday's FESCo Meeting (2024-07-23)

[Vít Ondruch]

Dne 24. 07. 24 v 20:17 Stephen Gallagher napsal(a):

On Wed, Jul 24, 2024 at 1:46 PM Miroslav Suchý  wrote:

Dne 24. 07. 24 v 12:30 odp. Joe Orton napsal(a):

Having a "majority rule" vote of e.g. packagers or provenpackagers on
major technical decisions would be far superior, in my view. Apache
communities have worked this way forever.

You can always propose this as a change to our process.

For what it's worth, I don't believe that this process will work well.
I'm all for democracy, but direct democracy without compulsory voting
inevitably leads to "grievance-based voting", where the majority of
folks ignore the discussion and a plurality of voters with a strong
opinion effectively stuff the ballot box. The effect is to have a
tyranny of the (loud) minority. The closest we could get to
"compulsory voting" would be to require a quorum of votes to be
considered binding, but even the FESCo and Council elections
traditionally see extremely low voter turnout. I don't think we'd be
able to reach a sensible quorum on a referendum-based system.



Actually, I think that this could help:

https://en.wikipedia.org/wiki/Voting_in_Switzerland#Referendums

E.g. if we figured there are lets say 20 Fedora contributors who are 
unhappy with the FESCo voting, all contributors could vote in 
"referendum" to (dis)approve.



Vít




Beyond that, I don't think the current approach is actually broken.
People elected us to make these sorts of decisions on their behalf. If
any of us were to consistently vote in a way that the general
community members felt is not in the interests of Fedora, then I fully
expect and hope that we would not be re-elected.

The current approach is the best one I can think of for our community:
we have an active feedback period where anyone can (and is encouraged)
to chime in on potential changes. I can assure you that I read that
feedback and I expect that the other members of FESCo do the same. If
you look at our meeting notes, you'll notice we often defer our
decisions when a discussion remains highly active.

As for the accusations of "rubber stamping" all Changes, I'd like to
note that FESCo has declined to accept several Changes this cycle
based on feedback. If you look at last week's minutes, you'll note
that we discussed and rejected two proposals and approved another
reluctantly (due to a lack of better options).

By the time issues get to a FESCo vote, they've generally run through
the discussion and have either been agreed to or the disagreement is
clearly not going to reach a compromise, at which point FESCo has to
make a decision. Sometimes that's going to be controversial (as in
this case, apparently). When voting, we don't always restate our
thought process, which admittedly means that the votes - taken in a
vacuum - can lack context and perhaps appear unconsidered.



OpenPGP_signature.asc
Description: OpenPGP digital 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: [SPDX] Mass license change - variety of licenses and compound formulas

[Vít Ondruch]

I probably don't understand right the first one:

~~~

diff -Naur rpm-specs.orig/aces_container.spec rpm-specs/aces_container.spec
--- rpm-specs.orig/aces_container.spec    2024-07-18 04:00:12.0 
+0200

+++ rpm-specs/aces_container.spec    2024-07-31 10:52:00.694637327 +0200
@@ -3,10 +3,11 @@

 Name:   aces_container
 Version:    1.0.2
-Release:    17%{?dist}
+Release:    18%{?dist}
 Summary:    ACES Container Reference

-License:    AMPAS BSD
+# Automatically converted from old format: AMPAS BSD - review is highly 
recommended.

+License:    AMPAS
 URL:    https://github.com/ampas/aces_container
 Source0: %{url}/archive/v%{version}/%{name}-%{version}.tar.gz
 Patch0: Switch-to-CMAKE-default-variables.patch
@@ -73,6 +74,9 @@

~~~


How we could dare to drop the `BSD`?


Vít




Dne 31. 07. 24 v 11:12 Miroslav Suchý napsal(a):

Hi.

This is a batch of remaining licenses that allows 1:1 conversion [*]. 
It includes leftovers from previous migrations, compound formulas and 
rarely used licenses.


The proposed diff is here https://k00.fr/5i348p12

Affected packages: https://k00.fr/zszrcmgr



Unless somebody stop me, I will do this change directly in dist-git 
after a week.



[*] I still have in queue Firmware, Public Domain and UltraPermissive, 
but they will require special handling.




OpenPGP_signature.asc
Description: OpenPGP digital 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: Packages with problematic license tag (for SPDX conversion)

[Vít Ondruch]

Dne 30. 07. 24 v 16:07 Miroslav Suchý napsal(a):


As the SPDX Change slowly finishes I focused on the license that I 
regularly report as:


  warning: not valid neither as Callaway nor as SPDX, please check



How to reproduce this warning?


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: the sad state of installability tests

[Vít Ondruch]

Dne 15. 07. 24 v 11:22 Michal Srb napsal(a):

Hello,

po 15. 7. 2024 o 10:57 Zbigniew Jędrzejewski-Szmek  
napísal(a):


On Mon, Jul 15, 2024 at 10:39:37AM +0200, Cristian Le via devel wrote:
> Hi Zbyszek,
>
> On 2024/07/14 20:04, Zbigniew Jędrzejewski-Szmek wrote:
> > I'm looking for a solution which doesn't just skip the
installability
> > tests altogether.
>
> On PRs with zuul or FedoraCI automation, the same instability
tests that are
> done for Bodhi are performed. But what would help is to make
these tests as
> required to pass unless they are manually waved. Manually that
can be done
> by setting `gating.yaml`. There was some discussion on making
some of these
> tests as gating by default.
>
> Another issue specific to installability is that the issue is
often further
> down the stream, particularly with the SELinux test. Definitely
these need
> to be tracked down and fixed.

I fully agree. But a test that just does 'dnf install
rpms-from-update/*.rpm'
will predicatably fail.

> > A second problem is that when the tests fail, it's just s
hard to
> > find out why they failed.From the bodhi status page, one has to
> > go to the Jenkins status page, guess that it's useful to look at
> > Console Output, scroll over a few pages of incomrehensible JSON
> > gibberish, guess that it's worth clicking on Testing Farm
Artifacts URL,
> > click that, scroll pages of output to see
> > "guest setup failed: Test environment installation failed:
Install packages".
>
> Weird, when the test is finished, you should have only the final
> testing-farm results page. Here's an example [1]. Maybe in your
case it
> encountered an internal failure?
>
> [1]: https://bodhi.fedoraproject.org/updates/FEDORA-2024-57f489c90d

Maybe I'm doing things wrong. I'd be happy to learn.

I do the following:
1. Look at the bodhi update page
(https://bodhi.fedoraproject.org/updates/FEDORA-2024-3aafcac6a8)
2. Click on 'Automated Tests'
   (There seems to be no URL for the view. This means that it's always
    and extra click after every page load or reload.)
3. I click on one of the pinkish lines, e.g. the first one.
  (Another usability problem here is that the click open a new page in
  new tab/window. Why, oh why? I want to use left-click to open a link
  in the existing tab, and middle-click to open a new tab. The current
  UI breaks navigation.)
4. I switch to the new tab and see

https://osci-jenkins-1.ci.fedoraproject.org/job/fedora-ci/job/dist-git-pipeline/job/master/398487/

   (BTW, I mentioned unrelated scary-looking warnings in my OP.
   Here:
     The following steps that have been detected may have insecure
     interpolation of sensitive variables (click here for an
explanation):

     httpRequest: [TESTING_FARM_API_KEY]
   )
5. Click on 'Console Output'
6. Click on 'Testing Farm Artifacts URL:
https://artifacts.dev.testing-farm.io/25316385-50d8-42b4-b4c1-3eff059034eb'
7. Click on 'build installation'

(https://artifacts.dev.testing-farm.io/25316385-50d8-42b4-b4c1-3eff059034eb/guest-setup-09b7edc6-0b7e-431b-ae68-afac2527fbb1/artifact-installation-09b7edc6-0b7e-431b-ae68-afac2527fbb1)
8. Click on 60-Install-packages.txt

So 8 steps to get to the actual result…


This is not actually the installability test. This is a functional 
test where Testing Farm couldn't prepare the machine and thus the 
actual test didn't even start.


But it's true that figuring out what went wrong and where is an 
impossible task for mere mortals.




This is my old ticket related to this:

https://pagure.io/fedora-ci/general/issue/311

I don't think too much changed in past two years 🤷


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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

Orphaning rubygem-activemodel-serializers-xml

[Vít Ondruch]

rubygem-activemodel-serializers-xml used to be dependency of 
rubygem-activeresource. But since rubygem-activeresource retirement ~18 
ago, it is not used by anything anymore, therefore I am orphaning it.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)

[Vít Ondruch]

Dne 03. 07. 24 v 15:25 Neal Gompa napsal(a):

On Wed, Jul 3, 2024 at 9:17 AM Vít Ondruch  wrote:


Dne 02. 07. 24 v 13:49 Neal Becker napsal(a):



On Tue, Jul 2, 2024 at 5:59 AM Vít Ondruch  wrote:


Dne 01. 07. 24 v 22:58 Aoife Moloney napsal(a):

Wiki - 
https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
This proposal adds a new dedicated `flatpak` group, allowing users to
manage system Flatpaks without needing to be in the `wheel` group.

== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquir...@secure.mailbox.org


== Detailed Description ==
Currently, to install, uninstall and modify apps or repositories,
users need to be in the `wheel` group. Removing a user from the wheel
group would interfere with the currently default (systemwide)
configuration of Flatpaks.

All users can add a `user` repository, and manage their own user
Flatpaks. But a dedicated group to manage system flatpaks, without
relying on `wheel` allows more fine grained privileges.


I am not Flatpak user, but I wonder why Flatpaks are system wide
installed by default? And if it would not be better to make them user
installed instead of this proposal.


Vít




This enables an "admin" permission that is not tied to full root
access on the host system.

It will be a change of the polkit rule `org.freedesktop.Flatpak.rules`
like following:


polkit.addRule(function(action, subject) {
if ((action.id == "org.freedesktop.Flatpak.app-install" ||
action.id == "org.freedesktop.Flatpak.runtime-install"||
action.id == "org.freedesktop.Flatpak.app-uninstall" ||
action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
action.id == "org.freedesktop.Flatpak.modify-repo") &&
subject.active == true && subject.local == true && (
subject.isInGroup("wheel") || subject.isInGroup("flatpak"))) {
return polkit.Result.YES;
}

return polkit.Result.NOT_HANDLED;
});

polkit.addRule(function(action, subject) {
if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
return polkit.Result.AUTH_ADMIN;
}

return polkit.Result.NOT_HANDLED;
});


== Feedback ==
none yet

== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the management of Flatpaks, without needing all the other
privileges that `wheel` users have.

== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `flatpak` group

* Other developers: none

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

* Policies and guidelines: Documentation needs to get an additional
chapter on Flatpak management with the `flatpak` group.

* Trademark approval: N/A (not needed for this Change)

* Alignment with the Fedora Strategy: Yes


== Upgrade/compatibility impact ==
The polkit rule will be overwritten, there will be no changes in
behavior. It just enables a new feature.

== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`.

This will be preferred over the default rule and you can test if it works.

== User Experience ==
By default, Anaconda puts users into the `wheel` group. There will be no change.

But it enables to manage Flatpaks without being in that privileged group.

== Dependencies ==
None


== Contingency Plan ==

* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A


== Documentation ==
Will be added afterwards.

Nonwheel users can be added to the `flatpak` group:


sudo groupadd flatpak
sudo usermod -aG flatpak USERNAME



== Release Notes ==

Permission to manage systemwide flatpaks is now granted to users in
the 'flatpak' group.

Currently wheel is required in order to install packages with dnf/rpm.  Why 
should flatpak be different?


Because Flatpak can do that it seems.

But mainly, for single user computer, it does not really matter, the 
application can be installed in user profile and it won't need any elevated 
privileges. For multi user computer, why the apps installed by one user should 
influence other users? Of course there might be system administrator who might 
install those system wide.

But I also see other be

Re: F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)

[Vít Ondruch]

Dne 02. 07. 24 v 13:49 Neal Becker napsal(a):



On Tue, Jul 2, 2024 at 5:59 AM Vít Ondruch  wrote:


Dne 01. 07. 24 v 22:58 Aoife Moloney napsal(a):
> Wiki -
https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement
> Discussion thread -
>

https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336
>
> This is a proposed Change for Fedora Linux.
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if
approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> This proposal adds a new dedicated `flatpak` group, allowing
users to
> manage system Flatpaks without needing to be in the `wheel` group.
>
> == Owner ==
> * Name: [[User:boredsquirrel| Henning]]
> * Email: boredsquir...@secure.mailbox.org
>
>
> == Detailed Description ==
> Currently, to install, uninstall and modify apps or repositories,
> users need to be in the `wheel` group. Removing a user from the
wheel
> group would interfere with the currently default (systemwide)
> configuration of Flatpaks.
>
> All users can add a `user` repository, and manage their own user
> Flatpaks. But a dedicated group to manage system flatpaks, without
> relying on `wheel` allows more fine grained privileges.


I am not Flatpak user, but I wonder why Flatpaks are system wide
installed by default? And if it would not be better to make them user
installed instead of this proposal.


Vít



> This enables an "admin" permission that is not tied to full root
> access on the host system.
>
> It will be a change of the polkit rule
`org.freedesktop.Flatpak.rules`
> like following:
>
>
>    polkit.addRule(function(action, subject) {
>        if ((action.id <http://action.id> ==
"org.freedesktop.Flatpak.app-install" ||
> action.id <http://action.id> ==
"org.freedesktop.Flatpak.runtime-install"||
> action.id <http://action.id> ==
"org.freedesktop.Flatpak.app-uninstall" ||
> action.id <http://action.id> ==
"org.freedesktop.Flatpak.runtime-uninstall" ||
> action.id <http://action.id> ==
"org.freedesktop.Flatpak.modify-repo") &&
>            subject.active == true && subject.local == true && (
>            subject.isInGroup("wheel") ||
subject.isInGroup("flatpak"))) {
>                return polkit.Result.YES;
>        }
>
>        return polkit.Result.NOT_HANDLED;
>    });
>
>    polkit.addRule(function(action, subject) {
>        if (action.id <http://action.id> ==
"org.freedesktop.Flatpak.override-parental-controls") {
>                return polkit.Result.AUTH_ADMIN;
>        }
>
>        return polkit.Result.NOT_HANDLED;
>    });
>
>
> == Feedback ==
> none yet
>
> == Benefit to Fedora ==
> This is a step towards the Confined Users goal. It enables a
dedicated
> action, the management of Flatpaks, without needing all the other
> privileges that `wheel` users have.
>
> == Scope ==
> * Proposal owners: changing a single rule, testing with nonwheel
users
> in the `flatpak` group
>
> * Other developers: none
>
> * Release engineering: [https://pagure.io/releng/issues #Releng
issue number]
>
> * Policies and guidelines: Documentation needs to get an additional
> chapter on Flatpak management with the `flatpak` group.
>
> * Trademark approval: N/A (not needed for this Change)
>
> * Alignment with the Fedora Strategy: Yes
>
>
> == Upgrade/compatibility impact ==
> The polkit rule will be overwritten, there will be no changes in
> behavior. It just enables a new feature.
>
> == How To Test ==
> On Atomic or traditional Fedora, place the above rule in
> `/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`.
>
> This will be preferred over the default rule and you can test if
it works.
>
> == User Experience ==
> By default, Anaconda puts users into the `wheel` group. There
will be no change.
>
> But it enables to manage Flatpaks without being in that
privileged group.
>
> == Dependencies ==
> None
>
>
> 

Re: [Fedora-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Vít Ondruch]

Dne 01. 07. 24 v 19:45 Miroslav Suchý napsal(a):

Dne 01. 07. 24 v 4:58 odp. Vít Ondruch napsal(a):
If the decision was made to proceed with the `LicenseRef-` prefix, I 
assume you would keep sending us some statistics, how many old 
identifiers remains, right? 


My original plan was to close this with deadline for F41 Changes and 
focus on something else. E.g., to create tool that will give you a 
hint/warning when file with new license (dis)appear in the new tarball.




No worries. I think that having `LicenseRef-` will actually enable to  
more easier query some numbers then it was up until now.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: F42 Change Proposal: Unprivileged management of system Flatpaks (system-wide)

[Vít Ondruch]

Dne 01. 07. 24 v 22:58 Aoife Moloney napsal(a):

Wiki - 
https://fedoraproject.org/wiki/Changes/UnprivilegedSystemFlatpakManagement
Discussion thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-unprivileged-management-of-system-flatpaks-system-wide/124336

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
This proposal adds a new dedicated `flatpak` group, allowing users to
manage system Flatpaks without needing to be in the `wheel` group.

== Owner ==
* Name: [[User:boredsquirrel| Henning]]
* Email: boredsquir...@secure.mailbox.org


== Detailed Description ==
Currently, to install, uninstall and modify apps or repositories,
users need to be in the `wheel` group. Removing a user from the wheel
group would interfere with the currently default (systemwide)
configuration of Flatpaks.

All users can add a `user` repository, and manage their own user
Flatpaks. But a dedicated group to manage system flatpaks, without
relying on `wheel` allows more fine grained privileges.



I am not Flatpak user, but I wonder why Flatpaks are system wide 
installed by default? And if it would not be better to make them user 
installed instead of this proposal.



Vít




This enables an "admin" permission that is not tied to full root
access on the host system.

It will be a change of the polkit rule `org.freedesktop.Flatpak.rules`
like following:


   polkit.addRule(function(action, subject) {
   if ((action.id == "org.freedesktop.Flatpak.app-install" ||
   action.id == "org.freedesktop.Flatpak.runtime-install"||
   action.id == "org.freedesktop.Flatpak.app-uninstall" ||
   action.id == "org.freedesktop.Flatpak.runtime-uninstall" ||
   action.id == "org.freedesktop.Flatpak.modify-repo") &&
   subject.active == true && subject.local == true && (
   subject.isInGroup("wheel") || subject.isInGroup("flatpak"))) {
   return polkit.Result.YES;
   }

   return polkit.Result.NOT_HANDLED;
   });

   polkit.addRule(function(action, subject) {
   if (action.id == "org.freedesktop.Flatpak.override-parental-controls") {
   return polkit.Result.AUTH_ADMIN;
   }

   return polkit.Result.NOT_HANDLED;
   });


== Feedback ==
none yet

== Benefit to Fedora ==
This is a step towards the Confined Users goal. It enables a dedicated
action, the management of Flatpaks, without needing all the other
privileges that `wheel` users have.

== Scope ==
* Proposal owners: changing a single rule, testing with nonwheel users
in the `flatpak` group

* Other developers: none

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]

* Policies and guidelines: Documentation needs to get an additional
chapter on Flatpak management with the `flatpak` group.

* Trademark approval: N/A (not needed for this Change)

* Alignment with the Fedora Strategy: Yes


== Upgrade/compatibility impact ==
The polkit rule will be overwritten, there will be no changes in
behavior. It just enables a new feature.

== How To Test ==
On Atomic or traditional Fedora, place the above rule in
`/etc/polkit-1/rules.d/org.freedesktop.Flatpak.rules`.

This will be preferred over the default rule and you can test if it works.

== User Experience ==
By default, Anaconda puts users into the `wheel` group. There will be no change.

But it enables to manage Flatpaks without being in that privileged group.

== Dependencies ==
None


== Contingency Plan ==

* Contingency mechanism: this is a simple fix, not adding it will keep
the previous wheel need
* Contingency deadline: N/A
* Blocks release? N/A


== Documentation ==
Will be added afterwards.

Nonwheel users can be added to the `flatpak` group:


   sudo groupadd flatpak
   sudo usermod -aG flatpak USERNAME



== Release Notes ==

Permission to manage systemwide flatpaks is now granted to users in
the 'flatpak' group.





OpenPGP_signature.asc
Description: OpenPGP digital 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-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Vít Ondruch]

If the decision was made to proceed with the `LicenseRef-` prefix, I 
assume you would keep sending us some statistics, how many old 
identifiers remains, right?



Vít


Dne 26. 06. 24 v 18:21 Miroslav Suchý napsal(a):
Unfortunatelly I do not see a clear consensus here. I think that 
exactly for such cases we have good instution: FESCO.



I filed https://pagure.io/fesco/issue/3230 and I will follow FESCO 
decision.





OpenPGP_signature.asc
Description: OpenPGP digital 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: RFC: Private installation location for NodeJS modules

[Vít Ondruch]

I don't think that `/var` is the right place for RPM installed content.

If the original directory is `/usr/lib/node_modules`, then why not use 
something like `/usr/lib/node_modules_shared`?



Vít


Dne 01. 07. 24 v 15:53 Jan Staněk napsal(a):

Hello list!

# TL;DR

I'm looking for installation location for node_modules shared
between multiple NodeJS streams without necessarily being visible to
other packages. The current candidate is /var/lib/nodejs/node_modules.

# Longer version

During recent onboarding of nodejs22 package,
we ran into issues with un-bundled WASM dependencies/components
(nodejs-undici/nodejs-cjs-module-lexer packages).
They are currently installed into the default
`%nodejs_sitelib` (/usr/lib/node_modules/);
that directory is a symlink pointing to /usr/lib/node_modules_XY,
where XY is the current default NodeJS stream.

The problem is that I would like to have these components shared between
all streams, without needing for them to be built separately for each stream
unless proven necessary.
But because the un-versioned `/usr/lib/node_modules` is not an actual directory,
I'm forced to use the default stream.
This has several drawbacks:

1.  For other streams, it's tricky (although doable) to point
 the configure script to the un-bundled components.
 Current macros aren't usable, as they are being parametrized by the
 current stream automatically.
2.  Parts of any non-default streams are located in a location owned by
 another stream/package. If you only install non-default stream,
 you would end up with at least 2 `/usr/lib/node_modules_XY` folders on
 your system.
3.  Possibly others. :-)

I can come up with a workaround for most of the drawbacks;
nevertheless, I would prefer coming up with a cleaner solution.

While discussing the problems with more upstream-adjacent colleagues,
they mentioned that exposing the components used by the NodeJS engine
itself fot other packages/apps is generally frowned upon.
While I'm not generally partial to the way any NodeJS application
bundles dependencies, it gave me an idea that could alleviate most of my
problems.

I'm now thinking of making the un-bundled components semi-private,
in the sense that while they will be installed on the system and visible
to any properly configured NodeJS engine, they would not generally be
importable by outside applications:

1.  Instead of /usr/lib/node_modules, use /var/lib/nodejs/node_modules
 for any shared, un-bundled components of NodeJS.
2.  Use that location directly in configure script of any NodeJS engine
 (that part does not use the usual import mechanism for npm modules).
3.  For backward compatibility, the private directories could be
 symlinked to /usr/lib/node_modules_XY, which should make them
 importable by npm.

---

I like this idea, but I would like to hear any opinions
from wider Fedora community.
It's entirely possible I overlooked something important,
and I would rather scrap the idea than commit to something broken.
--
Jan Staněk
Software Engineer, Red Hat
jsta...@redhat.com   irc: jstanek



OpenPGP_signature.asc
Description: OpenPGP digital 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-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Vít Ondruch]

Dne 26. 06. 24 v 16:28 Vít Ondruch napsal(a):


Dne 26. 06. 24 v 11:47 Miro Hrončok napsal(a):

On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok  
wrote:


On 25. 06. 24 22:50, Miroslav Suchý wrote:

Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):


Could you make the comment something like this?

   # Automatically converted from old format: GPLv2
   # TODO check if there are other licenses to be listed
   License: GPL-2.0-only


We (the Change owners) discussed this on a meeting today. And we 
agreed on output:


    # Automatically converted from old format: GPLv2
    # TODO convert to correct SPDX identifier
    # See 
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/

    License:  LicenseRef-Callaway-GPLv2

This is valid SPDX identifier. But not on the list of Fedora's 
allowed

licenses, so any QA tool will remind you to check the license.

What do you think?


I don't understand what is the benefit of doing this at all. Sorry.


The benefit I see is that it immediately causes all license tags to
conform to the SPDX license expression standard, while also making it
very clear what parts of those license expressions are actually legacy
elements that have to be examined and replaced. (This assumes we
wouldn't use `LicenseRef-Callaway-` for any other purpose.)


What is the benefit of that outcome?

I understand the benefit of SPDX in general.

I don't understand the benefit of converting everything to custom 
LicenseRef identifiers.



My original proposal was to basically replace all remaining Callaway 
licenses by something what has become `LicenseRef-Callaway-` prefix. 
The main motivation is to make sure we properly distinguish between 
Callaway MIT and SPDX MIT definitions and similar cases. This IMHO 
should have been done from the start, prior we converted even single 
license.


Also, my intention was to avoid comments such:

~~~

# Automatically converted from old format: GPLv2
# TODO check if there are other licenses to be listed

~~~

This kind of comments are always wrong IMHO.

But if Mirek was talking about modifying all remaining Callaway 
identifiers across the whole Fedora (which was not very clear), then I 
am fine with the proposal as it is (including comment ;) ).



BTW I also don't see the immediate need to convert everything into SPDX. 
But I'll rather have `LicenseRef-Callaway-` prefixed license identifiers 
than having around comments such as the above or `SPDX` in changelog 
entries.



Vít





Vít




We are already making it clear that the expressions are legacy by... 
being legacy.


Clearly, I must miss something. What do we *gain* by causing all 
license tags to conform to the SPDX license expression standard 
despite actually just using the old tag with extra boilerplate?


I am not trying to fight this decision, I am genuinely confused: What 
it is that makes us hurry this. Why cannot we keep the gradual 
conversion?




OpenPGP_signature.asc
Description: OpenPGP digital 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-legal-list] Re: [SPDX] Mass license change GPLv2 to GPL-2.0-only

[Vít Ondruch]

Dne 26. 06. 24 v 11:47 Miro Hrončok napsal(a):

On 26. 06. 24 5:59, Richard Fontana wrote:
On Tue, Jun 25, 2024 at 7:20 PM Miro Hrončok  
wrote:


On 25. 06. 24 22:50, Miroslav Suchý wrote:

Dne 25. 06. 24 v 1:09 odp. Miro Hrončok napsal(a):


Could you make the comment something like this?

   # Automatically converted from old format: GPLv2
   # TODO check if there are other licenses to be listed
   License: GPL-2.0-only


We (the Change owners) discussed this on a meeting today. And we 
agreed on output:


    # Automatically converted from old format: GPLv2
    # TODO convert to correct SPDX identifier
    # See 
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/

    License:  LicenseRef-Callaway-GPLv2

This is valid SPDX identifier. But not on the list of Fedora's allowed
licenses, so any QA tool will remind you to check the license.

What do you think?


I don't understand what is the benefit of doing this at all. Sorry.


The benefit I see is that it immediately causes all license tags to
conform to the SPDX license expression standard, while also making it
very clear what parts of those license expressions are actually legacy
elements that have to be examined and replaced. (This assumes we
wouldn't use `LicenseRef-Callaway-` for any other purpose.)


What is the benefit of that outcome?

I understand the benefit of SPDX in general.

I don't understand the benefit of converting everything to custom 
LicenseRef identifiers.



My original proposal was to basically replace all remaining Callaway 
licenses by something what has become `LicenseRef-Callaway-` prefix. The 
main motivation is to make sure we properly distinguish between Callaway 
MIT and SPDX MIT definitions and similar cases. This IMHO should have 
been done from the start, prior we converted even single license.


Also, my intention was to avoid comments such:

~~~

# Automatically converted from old format: GPLv2
# TODO check if there are other licenses to be listed

~~~

This kind of comments are always wrong IMHO.

But if Mirek was talking about modifying all remaining Callaway 
identifiers across the whole Fedora (which was not very clear), then I 
am fine with the proposal as it is (including comment ;) ).



Vít




We are already making it clear that the expressions are legacy by... 
being legacy.


Clearly, I must miss something. What do we *gain* by causing all 
license tags to conform to the SPDX license expression standard 
despite actually just using the old tag with extra boilerplate?


I am not trying to fight this decision, I am genuinely confused: What 
it is that makes us hurry this. Why cannot we keep the gradual 
conversion?




OpenPGP_signature.asc
Description: OpenPGP digital 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: Guidance on individual packages requiring x86_64-v2 baseline ?

[Vít Ondruch]

Dne 25. 06. 24 v 12:10 Dan Horák napsal(a):

On Tue, 25 Jun 2024 11:57:49 +0200
Vít Ondruch  wrote:


Dne 24. 06. 24 v 20:03 Peter Robinson napsal(a):

On Mon, 24 Jun 2024 at 11:21, Vít Ondruch  wrote:

Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):

On Fri, 21 Jun 2024 at 07:27, Vít Ondruch  wrote:

So what is the reason to not treat x86_64_v2 as different arch then
x86_64_v{1,3}. Why we keep having this discussion instead of fire one
more build? Users would need to choose v1 / v2 / v3 ISO but what else?



I can think of three problems which would need to be dealt with

1. Resource limitations in infrastructure hardware. You are going to
add to the amount of builds on 1 set of hardware which is already
doing x86_64 and i686. You are going to add to the storage issues that
Fedora Infrastructure has to juggle on the maximum 100TB koji
partition (with 90TB causing some amount of degradation) due to extra
packages and composes.
2. Resource limitations in infrastructure staff. Fedora Infra is doing
more with less and each additional architecture and focus increases
that load.
3. Resource limitations on packagers. Packagers will need to add yet
another bug set to cover and determine "is it only on VX" or not.

Yes, understandably. But are there technical limitations?

No, and you could argue to get rid of i686


BTW I guess that e.g. some sort of inheritance reduce the amount of
needed HW.

Well that brings other problems, see i686 as an example here, but
there's a large percentage of noarch packages in the distro so it's
not a full 1:1 package:arch increment.


I was not speaking about noarch. I assume that you can intermix
x86_64_v1 code with x86_64_v3 code on x86_64_v3 capable HW. Is that
correct? IOW there could be build just subset of packages for x86_64_v3
and rest would be inherited.

aka similar to what was done with i386 and i686 back in the day, and
then with ppc64 + ppc64p7 for a short period of time.



That predates my days here 🤷 But yes, that sounds as similar cases, so 
we might have some rusty know how.



Vít





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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Guidance on individual packages requiring x86_64-v2 baseline ?

[Vít Ondruch]

Dne 24. 06. 24 v 20:03 Peter Robinson napsal(a):

On Mon, 24 Jun 2024 at 11:21, Vít Ondruch  wrote:


Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):

On Fri, 21 Jun 2024 at 07:27, Vít Ondruch  wrote:

So what is the reason to not treat x86_64_v2 as different arch then
x86_64_v{1,3}. Why we keep having this discussion instead of fire one
more build? Users would need to choose v1 / v2 / v3 ISO but what else?



I can think of three problems which would need to be dealt with

1. Resource limitations in infrastructure hardware. You are going to
add to the amount of builds on 1 set of hardware which is already
doing x86_64 and i686. You are going to add to the storage issues that
Fedora Infrastructure has to juggle on the maximum 100TB koji
partition (with 90TB causing some amount of degradation) due to extra
packages and composes.
2. Resource limitations in infrastructure staff. Fedora Infra is doing
more with less and each additional architecture and focus increases
that load.
3. Resource limitations on packagers. Packagers will need to add yet
another bug set to cover and determine "is it only on VX" or not.


Yes, understandably. But are there technical limitations?

No, and you could argue to get rid of i686


BTW I guess that e.g. some sort of inheritance reduce the amount of
needed HW.

Well that brings other problems, see i686 as an example here, but
there's a large percentage of noarch packages in the distro so it's
not a full 1:1 package:arch increment.



I was not speaking about noarch. I assume that you can intermix 
x86_64_v1 code with x86_64_v3 code on x86_64_v3 capable HW. Is that 
correct? IOW there could be build just subset of packages for x86_64_v3 
and rest would be inherited.



Vít




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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Guidance on individual packages requiring x86_64-v2 baseline ?

[Vít Ondruch]

Dne 21. 06. 24 v 18:27 Stephen Smoogen napsal(a):

On Fri, 21 Jun 2024 at 07:27, Vít Ondruch  wrote:

So what is the reason to not treat x86_64_v2 as different arch then
x86_64_v{1,3}. Why we keep having this discussion instead of fire one
more build? Users would need to choose v1 / v2 / v3 ISO but what else?



I can think of three problems which would need to be dealt with

1. Resource limitations in infrastructure hardware. You are going to
add to the amount of builds on 1 set of hardware which is already
doing x86_64 and i686. You are going to add to the storage issues that
Fedora Infrastructure has to juggle on the maximum 100TB koji
partition (with 90TB causing some amount of degradation) due to extra
packages and composes.
2. Resource limitations in infrastructure staff. Fedora Infra is doing
more with less and each additional architecture and focus increases
that load.
3. Resource limitations on packagers. Packagers will need to add yet
another bug set to cover and determine "is it only on VX" or not.



Yes, understandably. But are there technical limitations?

BTW I guess that e.g. some sort of inheritance reduce the amount of 
needed HW.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Guidance on individual packages requiring x86_64-v2 baseline ?

[Vít Ondruch]

Dne 12. 06. 24 v 19:14 Neal Gompa napsal(a):

On Wed, Jun 12, 2024 at 4:00 PM Stephen Gallagher  wrote:

On Wed, Jun 12, 2024 at 9:55 AM Daniel P. Berrangé  wrote:

On Wed, Jun 12, 2024 at 09:51:34AM -0400, Stephen Gallagher wrote:

On Wed, Jun 12, 2024 at 8:41 AM Daniel P. Berrangé  wrote:

IOW, if [when] we rebase Fedora to the next QEMU upstream release, users
with older x86_64 hardware would likely be unable to run QEMU, from F41
onwards, unless some TBD action is taken.

Thus I'm wondering whether Fedora has any policy or guidance on handling
such a situation both in general, and more specifically for "critical path"
packages, if that difference is relevant ? The packaging guidelines aren't
especially explicit about this situation, unless I've missed something
beyond the "compiler flags" and "architecture support" sections.


Absent a project-wide decision to move to the newer baseline, I think
the best approach we can take would be to find some way to communicate
to the user that the software isn't usable. In the case of Qemu, does
the application report an error or crash if it's run on hardware
without the requisite baseline?

I've not tested, but I would expect it to crash attempting to execute an
illegal instruction


OK, that's a situation that will lead to annoying and unresolvable bug
reports. Would it be possible to put something in place that would
check processor capabilities early in execution before hitting any of
the affected instructions?

Build the package as x86_64_v2 instead of x86_64.

Not lying about the architecture will ensure that we don't bypass
RPM's own compatible architecture check.





So what is the reason to not treat x86_64_v2 as different arch then 
x86_64_v{1,3}. Why we keep having this discussion instead of fire one 
more build? Users would need to choose v1 / v2 / v3 ISO but what else?



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

Dne 11. 06. 24 v 0:38 Sérgio Basto napsal(a):

On Mon, 2024-05-06 at 13:56 +0200, Florian Festi wrote:

As this change does not affect the resulting binary packages an
immediate rebuild is not needed. The change will "only" ensure the
packages still build with the new version of RPM.

I think you should rebuild the packages because at the moment , koschei
[1] is saying that all that 1800 packages are FTBFS



BTW once the commits are in, any packager can trigger rebuild. No proven 
packager needed anymore.



Vít




[1]
https://koschei.fedoraproject.org/


Best regards,


OpenPGP_signature.asc
Description: OpenPGP digital 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: Macros stored in a separate file

[Vít Ondruch]

Dne 10. 06. 24 v 20:18 Richard W.M. Jones napsal(a):

On Mon, Jun 10, 2024 at 10:09:16AM -0700, Adam Williamson wrote:

On Mon, 2024-06-10 at 18:52 +0200, Vít Ondruch wrote:

Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):

On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:

Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):

On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:

Lately, I noticed that several SPEC files in Fedora use this syntax:

Source:        macros.vlc

And this file defines macros that are loaded by rpmbuild during buildtime and 
are used in the SPEC file.

This makes parsing of the SPEC file harder, because any parser have to have
this maro file in current directory - just reading SPEC file is not enough.

There is also:

~~~

%{load:%{S:1}}

~~~


Which actually loads the file.



I mentioned vlc, but it is used in many other packages: valkey, zig,
typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.

Why are packagers doing this? I am not saying this is bad, it just surprised
me. I am used to put all macros at the top of the SPEC file and this is new
to me. What is the benefit?

I don't know if it is the case for vlc, but the common benefit would be
where the same macros are to be used in both this local spec, and the
specs of other dependent RPMs.

That is precisely the reason I have pioneered this approach and using it
for Ruby.

It might be nice to package the macros, in that case.


They are packaged of course, either in rubygem-devel or in ruby-devel

But then why would spec files be listing them as a source, which is
where this thread started, instead of buildrequiring the appropriate
package?



Because we are using macros such as `%ruby_libdir` during packaging Ruby 
itself as well as packaging its dependencies.


There could in theory be some completely independent `ruby_rpm_macros` 
package but this would have its own tradeoffs. The bootstrap, as Rich 
pints bellow, is certainly easier without such package. Generally, 
having one less independent package is good once we want to productize 
Ruby in RHEL.



Vít



I assume it's to avoid a circular build dependency?  This doesn't
matter that much, but it does make a theoretical bootstrap from
nothing a bit harder.

I didn't know the local "Source: macros.X" was possible before reading
this thread, but we could have used it to avoid a circular dependency
on RPM macros in both supermin and nbdkit.

Rich.



OpenPGP_signature.asc
Description: OpenPGP digital 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: Macros stored in a separate file

[Vít Ondruch]

Dne 10. 06. 24 v 17:35 Adam Williamson napsal(a):

On Mon, 2024-06-10 at 16:38 +0200, Vít Ondruch wrote:

Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):

On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:

Lately, I noticed that several SPEC files in Fedora use this syntax:

Source:        macros.vlc

And this file defines macros that are loaded by rpmbuild during buildtime and 
are used in the SPEC file.

This makes parsing of the SPEC file harder, because any parser have to have
this maro file in current directory - just reading SPEC file is not enough.


There is also:

~~~

%{load:%{S:1}}

~~~


Which actually loads the file.



I mentioned vlc, but it is used in many other packages: valkey, zig,
typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.

Why are packagers doing this? I am not saying this is bad, it just surprised
me. I am used to put all macros at the top of the SPEC file and this is new
to me. What is the benefit?

I don't know if it is the case for vlc, but the common benefit would be
where the same macros are to be used in both this local spec, and the
specs of other dependent RPMs.


That is precisely the reason I have pioneered this approach and using it
for Ruby.

It might be nice to package the macros, in that case.



They are packaged of course, either in rubygem-devel or in ruby-devel



  That's what we do
for other languages like Python, in python-rpm-macros...



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Macros stored in a separate file

[Vít Ondruch]

Dne 10. 06. 24 v 16:24 Daniel P. Berrangé napsal(a):

On Mon, Jun 10, 2024 at 04:18:14PM +0200, Miroslav Suchý wrote:

Lately, I noticed that several SPEC files in Fedora use this syntax:

Source:        macros.vlc

And this file defines macros that are loaded by rpmbuild during buildtime and 
are used in the SPEC file.

This makes parsing of the SPEC file harder, because any parser have to have
this maro file in current directory - just reading SPEC file is not enough.



There is also:

~~~

%{load:%{S:1}}

~~~


Which actually loads the file.




I mentioned vlc, but it is used in many other packages: valkey, zig,
typelib-srpm-macros, ansible-packaging, rakudo, sip and many many other.

Why are packagers doing this? I am not saying this is bad, it just surprised
me. I am used to put all macros at the top of the SPEC file and this is new
to me. What is the benefit?

I don't know if it is the case for vlc, but the common benefit would be
where the same macros are to be used in both this local spec, and the
specs of other dependent RPMs.



That is precisely the reason I have pioneered this approach and using it 
for Ruby.



Vít




With regards,
Daniel


OpenPGP_signature.asc
Description: OpenPGP digital 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: uploading big sources to lookaside cache

[Vít Ondruch]

Dne 09. 06. 24 v 16:12 Mattia Verga via devel napsal(a):

I was just thinking... for users with a limited upload bandwidth it is a
pain to upload big sources to the lookaside cache. What about
implementing a way to avoid the chain "user downloads the source -> user
upload the source to lookaside cache" by having some service running in
the infrastructure which downloads the source file directly in the
lookaside cache?

My idea is that a user could issue a command like "fedpkg
new-sources-download  "



Or rather "fedpkg refresh-lookaside-cache" once the updated source file 
is committed.


BTW this would also help with PRs, where the sources are not uploaded.


Vít



  which triggers some
service running in Fedora infra, near to the system where the lookaside
cache is stored, which downloads the source from ,
check the hash of the downloaded file with the hash provided by user
command and then store the source in lookaside cache.

The user still need to download the source to provide the hash, for
enhanced security, but at least avoids the limits of their upload bandwidth.

This is just an idea, I don't really know how to implement that, where
the backend service could run, etc... just posting to gather some thoughts.

Mattia

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)

[Vít Ondruch]

I wish this proposal included some examples of what might get broken and 
what will keep working. I guess I am not the only one who have very 
vague understanding what is difference between "signatures" and 
"hashing" or other purposes SHA1 can be used for.



Vít


Dne 08. 06. 24 v 0:43 Aoife Moloney napsal(a):

Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-distrust-sha-1-signatures-by-default-system-wide/119457

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
OpenSSL will no longer trust cryptographic signatures using SHA-1 by
default, starting from Fedora 41.

== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: asose...@redhat.com


== Detailed Description ==
We would like to deprecate SHA-1 in signatures, because chosen-prefix
collision attacks on SHA-1 are becoming increasingly feasible.
Specifically, https://sha-mbles.github.io claims a complexity of
2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US
dollars by 2025 to find a chosen-prefix collision for a SHA-1
signature.

With this change accepted and implemented,
OpenSSL will start blocking SHA-1 signature creation and verification
by default.

The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]]
has previously included this change among several others.
This is a second attempt to propose it, two years later, with a narrower scope.

== Feedback ==
This change, when discussed as part of the rejected [[
Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]],
has proved itself controversial.

There seems to be a consensus that the change has to be done sooner or later,
but Fedora is a remarkably conservative distribution
when it comes to deprecating legacy cryptography, even if by-default-only.

The decision to discover code reliant on SHA-1 signatures
by blocking creation/verification has not gathered many fans,
but it's not like many viable alternative proposals have been raised
in return either.
In particular, there is no suitable facility to perform opt-out
logging of the deprecated operation.
Opt-in logging through USDT probes has been implemented the last time
and has been reinstated again to aid testing this change.

The precursor change has received limited testing during Fedora 37 Test Days,
with only a handful of bugs discovered.
The ones that were, though, wouldn't be something realistically
discoverable by other means.

The change has received significant testing in RHEL,
which distrusts SHA-1 signatures by default starting from RHEL-9.
Having this switch flipped in RHEL for ~2 years further enforces our
confidence in the change.

== Benefit to Fedora ==

Fedora's security defaults will inch closer to what is considered
secure in the modern-day cryptographic landscape.

== Scope ==
* Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.

* Other developers:
Test your applications under TEST-FEDORA41 policy.

If the security of your application depends on trusting SHA-1 signatures,
fix this, or it will stop working unless users explicitly opt into
lower security guarantees. See
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].

* Release engineering: [https://pagure.io/releng/issue/12096 #12096]

A change is a runtime change, so the mass rebuild considerations
boil down to %check-time testsuite failures expecting different defaults.
Specifically, reverting the change can be safely done without a mass-rebuild.

* Policies and guidelines:
CryptoPolicies section of the packaging guidelines
will have to be updated to reflect that
SHA-1 signatures must not be trusted by default.

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==

The change is not expected to break upgrades themselves.

The ways people use Fedora are a multitude, and the rare scenarios
relying on trusting SHA-1 signatures will break.

Administrators willing to retain previous behavior and sacrifice security
will be able to apply a compatibility policy or subpolicy
before or after the upgrade.

== How To Test ==

Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.

Proceed to use the system as usual,
identify the workflows which are broken by blocking SHA-1 signature
creation/verification,
ideally also verify that `update-crypto-policies --set DEFAULT` fixes them,
file bug reports against the affected components if not filed already.
Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `,
mention this change page, the version of crypto-policies package
and the poli

Re: Enabling RPM based sysuser handling

[Vít Ondruch]

Dne 06. 06. 24 v 22:25 Zbigniew Jędrzejewski-Szmek napsal(a):

Hi,

I think all the issues wrt. sysusers in systemd and setup have been
resolved.

On Tue, May 14, 2024 at 11:34:51AM +, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, May 14, 2024 at 02:01:09PM +0300, Panu Matilainen wrote:

On 5/14/24 13:39, Zbigniew Jędrzejewski-Szmek wrote:

On Mon, May 13, 2024 at 01:37:11PM +0300, Panu Matilainen wrote:

I outlined the migration process last year in 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/NEFOV236FJYS2RED2SEOV5YHDFLDX7DK/#OYCWXKAMIXEZNYPVOM6VQ3YYXQ76M3DG
but failed to follow-up, so I'm glad to see this getting revisited.

I started looking into this, and I think we need to start at the
bottom, i.e. in the setup package.

It currently provides /etc/{passwd,group} with a bunch of ids (23 groups)
and /usr/lib/sysusers.d/20-setup-{users,groups} with a bunch of entries,
but some of the groups listed in sysusers are not listed in the /etc files.
IIUC, once we enable the rpm stuff, rpm will create /etc/{passwd,group}
automatically, and the file provided by setup will be ignored.
(It's specified as %config(noreplace).)

I was confused here. setup generates its two sysusers files from the
passwd/groups file that it distributes, so they will always match.

We added the missing group defintions that systemd-udev relies on to
default groups file distributed by setup (in setup-2.15.0-3). The next
build of systemd (256~rc4-1) will drop its sysusers.d/basic.conf file.

Please carry on with the enablement of rpm sysusers handling ;)

Zbyszek

P.S. While at it, Martin Osvald and I implemented a move of the
content from the the "upstream" setup repo (https://pagure.io/setup/)
into the dist-git repo (https://src.fedoraproject.org/rpms/pagure).



https://src.fedoraproject.org/rpms/setup

was likely the intended link ...


Vít



The "upstream" was only used by a single "downstream", managed by the
same people, and the separation was just generating busywork.
setup >= 2.15 has all the content in dist-git.
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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: RPM_* env variables vs macros

[Vít Ondruch]

Dne 04. 06. 24 v 9:27 Vít Ondruch napsal(a):


Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a):

On 6/3/24 17:18, Eike Rathke wrote:

Hi Panu,

On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote:


or better yet, ${RPM_BUILD_ROOT}.


Why better?


In general, the RPM_* environment variables available to build 
scriptlets are what should be used instead of macros. Because, macros 
are processed while parsing the spec, which is different from 
actually *building* it. For one, using the environment improves srpm 
reproducibility because the local gunk like number of CPUs, the 
concrete path of %buildroot etc are only visible the scriptlets where 
actually used.


It's a subtle thing, took me 10+ years with rpm to grok the 
recommendation I'd seen long, long, long ago.




I wish this nugget was captured somewhere on more prominent place. 
Because what you say does not really correspond with what we have in 
guidelines:


https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags 



And I have not checked the RPM documentation



There is this section:

https://rpm-software-management.github.io/rpm/manual/spec.html#build-scriptlets

also recommending RPM_ macros for scriptlets:


> Note: many of these have macro counterparts which may seem more 
convenient and consistent with the rest of the spec, but one should 
always use the environment variables inside the scripts. The reason for 
this is that macros are evaluated during spec parse and may not be 
up-to-date, whereas environment variables are evaluated at the time of 
their execution in the script.



Vít



, but I think that the env variables are underdocumented in the FPG.


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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

RPM_* env variables vs macros

[Vít Ondruch]

Dne 04. 06. 24 v 8:11 Panu Matilainen napsal(a):

On 6/3/24 17:18, Eike Rathke wrote:

Hi Panu,

On Monday, 2024-06-03 15:55:09 +0300, Panu Matilainen wrote:


or better yet, ${RPM_BUILD_ROOT}.


Why better?


In general, the RPM_* environment variables available to build 
scriptlets are what should be used instead of macros. Because, macros 
are processed while parsing the spec, which is different from actually 
*building* it. For one, using the environment improves srpm 
reproducibility because the local gunk like number of CPUs, the 
concrete path of %buildroot etc are only visible the scriptlets where 
actually used.


It's a subtle thing, took me 10+ years with rpm to grok the 
recommendation I'd seen long, long, long ago.




I wish this nugget was captured somewhere on more prominent place. 
Because what you say does not really correspond with what we have in 
guidelines:


https://docs.fedoraproject.org/en-US/packaging-guidelines/#_using_buildroot_and_optflags_vs_rpm_build_root_and_rpm_opt_flags

And I have not checked the RPM documentation, but I think that the env 
variables are underdocumented in the FPG.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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 Elections - Voting is now open!

[Vít Ondruch]

Dne 22. 05. 24 v 16:28 Vít Ondruch napsal(a):


Dne 21. 05. 24 v 16:27 Sandro napsal(a):

On 21-05-2024 16:22, Steven A. Falco wrote:

On 5/21/24 10:17 AM, Sandro wrote:

On 21-05-2024 15:47, Vít Ondruch wrote:

Dne 21. 05. 24 v 15:45 Vít Ondruch napsal(a):


Dne 21. 05. 24 v 15:31 Steven A. Falco napsal(a):
I'm getting the "410 Gone" message, too. Tried multiple times 
since yesterday with no luck.



Yes, this is the message.


+

~~~

This resource is no longer available. No forwarding address is given.

That invitation is expired.

~~~


That should no longer be the case. Which election precisely did you 
follow the link from? Maybe we missed updating one of them. That 
said, I still see other people claiming it.


Could it be that you just need to fully refresh the page?

I'll have a look at the links meanwhile. Maybe I spot something.


I just tried from 
https://elections.fedoraproject.org/vote/fedora%20mindshare%20election%20for%20f40


Badge link: 
https://badges.fedoraproject.org/invitations/716f01bd050fefd9a0647ae956af2b13/claim


Error message:
 410 Gone
 This resource is no longer available. No forwarding address is 
given.


 That invitation is expired.
--


The same link works for me and other people are claiming the badge. 
That leads me to believe some local cache or the like might be 
getting in the way. I don't have access to the logs. That makes my 
guesses as good as anyone's.



I have created new profile just due to this and I claimed the badge, 
but it does not work with my current profile. I am not going to delete 
caches and what not due to this.


IOW there is some bug which would be nice to fix.



Heh, trying back in my original profile, first I got again the error. 
Then I got "500 internal server error" and now the links proceeds to 
badges with "You already have i-voted:-fedora-40 badge". Next attempt 
"500 internal server error".



Vít





Vít




However, now the link is in the open, we might have to change it 
again and invalidate the link you posted. It's not meant to be out in 
the open.


Btw, it seems you've got the badge after all. I'm looking at the 
front page as I type.


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


OpenPGP_signature.asc
Description: OpenPGP digital 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 Elections - Voting is now open!

[Vít Ondruch]

Dne 21. 05. 24 v 16:27 Sandro napsal(a):

On 21-05-2024 16:22, Steven A. Falco wrote:

On 5/21/24 10:17 AM, Sandro wrote:

On 21-05-2024 15:47, Vít Ondruch wrote:

Dne 21. 05. 24 v 15:45 Vít Ondruch napsal(a):


Dne 21. 05. 24 v 15:31 Steven A. Falco napsal(a):
I'm getting the "410 Gone" message, too. Tried multiple times 
since yesterday with no luck.



Yes, this is the message.


+

~~~

This resource is no longer available. No forwarding address is given.

That invitation is expired.

~~~


That should no longer be the case. Which election precisely did you 
follow the link from? Maybe we missed updating one of them. That 
said, I still see other people claiming it.


Could it be that you just need to fully refresh the page?

I'll have a look at the links meanwhile. Maybe I spot something.


I just tried from 
https://elections.fedoraproject.org/vote/fedora%20mindshare%20election%20for%20f40


Badge link: 
https://badges.fedoraproject.org/invitations/716f01bd050fefd9a0647ae956af2b13/claim


Error message:
 410 Gone
 This resource is no longer available. No forwarding address is 
given.


 That invitation is expired.
--


The same link works for me and other people are claiming the badge. 
That leads me to believe some local cache or the like might be getting 
in the way. I don't have access to the logs. That makes my guesses as 
good as anyone's.



I have created new profile just due to this and I claimed the badge, but 
it does not work with my current profile. I am not going to delete 
caches and what not due to this.


IOW there is some bug which would be nice to fix.


Vít




However, now the link is in the open, we might have to change it again 
and invalidate the link you posted. It's not meant to be out in the open.


Btw, it seems you've got the badge after all. I'm looking at the front 
page as I type.


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


OpenPGP_signature.asc
Description: OpenPGP digital 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 Elections - Voting is now open!

[Vít Ondruch]

Dne 21. 05. 24 v 15:45 Vít Ondruch napsal(a):


Dne 21. 05. 24 v 15:31 Steven A. Falco napsal(a):
I'm getting the "410 Gone" message, too. Tried multiple times since 
yesterday with no luck.



Yes, this is the message.


+

~~~

This resource is no longer available. No forwarding address is given.

That invitation is expired.

~~~


Vít




I have voted yesterday but tried to claim the badge today, if that 
makes any difference.



Vít




Steve

On 5/21/24 05:21 AM, Aoife Moloney wrote:
I've seen someone in the Red Hat Waterford office be able to claim 
it no problem so the issue may be individually based as the link is 
definitely active and claimable. Interested to know too how its 
working for some nd not others.


On Tue, May 21, 2024 at 9:41 AM Sandro <mailto:li...@penguinpee.nl>> wrote:


    On 21-05-2024 09:47, Vít Ondruch wrote:
 > And it does not work again

    What issue / error are you experiencing?

    It seems to work for others. Looking at the badges front page, 
the badge

    has been awarded as recently as 15 minutes ago.

    -- Sandro
    --
    ___
    devel mailing list -- devel@lists.fedoraproject.org 
<mailto:devel@lists.fedoraproject.org>
    To unsubscribe send an email to 
devel-le...@lists.fedoraproject.org 
<mailto:devel-le...@lists.fedoraproject.org>
    Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
    List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines 
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
    List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> 

    Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue 
<https://pagure.io/fedora-infrastructure/new_issue>




--

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im <http://fedora.im>

IRC: amoloney



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


OpenPGP_signature.asc
Description: OpenPGP digital 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 Elections - Voting is now open!

[Vít Ondruch]

Dne 21. 05. 24 v 15:31 Steven A. Falco napsal(a):
I'm getting the "410 Gone" message, too.  Tried multiple times since 
yesterday with no luck.



Yes, this is the message.

I have voted yesterday but tried to claim the badge today, if that makes 
any difference.



Vít




Steve

On 5/21/24 05:21 AM, Aoife Moloney wrote:
I've seen someone in the Red Hat Waterford office be able to claim it 
no problem so the issue may be individually based as the link is 
definitely active and claimable. Interested to know too how its 
working for some nd not others.


On Tue, May 21, 2024 at 9:41 AM Sandro <mailto:li...@penguinpee.nl>> wrote:


    On 21-05-2024 09:47, Vít Ondruch wrote:
 > And it does not work again

    What issue / error are you experiencing?

    It seems to work for others. Looking at the badges front page, 
the badge

    has been awarded as recently as 15 minutes ago.

    -- Sandro
    --
    ___
    devel mailing list -- devel@lists.fedoraproject.org 
<mailto:devel@lists.fedoraproject.org>
    To unsubscribe send an email to 
devel-le...@lists.fedoraproject.org 
<mailto:devel-le...@lists.fedoraproject.org>
    Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/ 
<https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
    List Guidelines: 
https://fedoraproject.org/wiki/Mailing_list_guidelines 
<https://fedoraproject.org/wiki/Mailing_list_guidelines>
    List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org 
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org> 

    Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue 
<https://pagure.io/fedora-infrastructure/new_issue>




--

Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im <http://fedora.im>

IRC: amoloney



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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Node.js 22.x coming to Rawhide/F41

[Vít Ondruch]

It seems that it breaks at least two of my packages unfortunately:

https://koschei.fedoraproject.org/package/rubygem-ejs

https://koschei.fedoraproject.org/package/rubygem-execjs

The former is using the latter, so the real issue is likely in the 
latter. I don't have cycles to investigate more :(


BTW these are likely used in some other components of Ruby on Rails, so 
the potential for breakage is higher. But Koschei is experiencing some 
issue, so hard to tell.



Vít



Dne 17. 05. 24 v 14:28 Stephen Gallagher napsal(a):

As of today, I have built Node.js 22.2.0 for Fedora Rawhide. It is
currently available as a non-default package (Node.js 20 remains the
default during this short transition period).

If you maintain a package that depends on Node.js (either runtime or
build-time), please take some time in the next week or so to verify
whether it continues to work properly with Node.js 22. I plan to
switch the default in Rawhide over to 22.x as per the
recently-approved Change[1] on or shortly after May 27th.

If you encounter a significant problem with Node.js 22, please contact
the nod...@fedoraproject.org mailing list and we will try to help you.


[1] https://fedoraproject.org/wiki/Changes/Nodejs22
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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 Elections - Voting is now open!

[Vít Ondruch]

And it does not work again


Vít


Dne 20. 05. 24 v 22:03 František Šumšal napsal(a):

Can confirm that the badge link now works as expected, thank you!

On 5/20/24 20:18, Aoife Moloney wrote:

So the wiki page error has been fixed, thanks for letting me know!


The badge error, I  have created the claim link and my interface says 
it's valid for 11 more days (set to 31st May). I've also sent it to 
Kevin who's helping me massively by looking into it on the backend 
and making sure it's still valid and it seems in working order. I've 
also added to every active ballot box, the same link, so at this 
point I am going to hope it will continue to work.



For folks who didn't get a badge, can you retry please? And if no 
success still, just email me directly and I will award you one 
through that way.



Thanks all,
Aoife




Aoife Moloney
Fedora Operations Architect

On Mon, May 20, 2024, 6:48 PM Sandro > wrote:


    On 20-05-2024 19:42, Miro Hrončok wrote:
 > On 20. 05. 24 16:37, Aoife Moloney wrote:
 >> Hi Folks,
 >>
 >> After _much_ troubleshooting and some wonderful folks working 
with me
 >> to help resolve the issues that littered the elections today, 
I am
 >> pleased to say all issues have been resolved, or at least I 
live in

 >> hope that they are! :crosses fingers:
 >> ...
 >> If you have voted in Council and/or Mindshare, and did not 
have a
 >> claim link for your badge, please revisit your vote as the 
link has
 >> been updated and you should be able to access it. If you 
can't, email
 >> me directly and I will manually award this to you (I cant see 
who

 >> voted so I can't do this without knowing who to send it to).
 >
 > I'm afraid the badge claim link is expired now:
 >
 > """
 > 410 Gone
 > This resource is no longer available. No forwarding address is 
given.

 >
 > That invitation is expired.
 > """

    Yes, we are aware. What's not clear is how or why that has happened.

    Either way, the link will be updated again soon. After that we'll 
know

    better. An update will go out once the new link is active.

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

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: rich deps result in packages being uninstalled from buildroot

[Vít Ondruch]

Dne 17. 05. 24 v 7:16 Panu Matilainen napsal(a):

On 5/16/24 16:10, Vít Ondruch wrote:


Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote:
Proper solution is actually minimazing content of the minimal build 
root

Most of the packages in the buildroot are libraries, pulled in via
dependencies.

@buildsys-build group is:
Mandatory packages   : bash  # basic shell env
  : bzip2 # source extraction
  : coreutils # basic shell env
  : cpio  # source extraction
  : diffutils # source extraction
  : fedora-release-common   # rpm environment
  : findutils # basic shell env
  : gawk  # basic shell env
  : glibc-minimal-langpack  # we want this to 
avoid other langpacks

  : grep  # basic shell env
  : gzip  # source extraction
  : info
  : patch # source extraction
  : redhat-rpm-config  # rpm environment
  : rpm-build  # rpm environment
  : sed   # basic shell env
  : shadow-utils
  : tar   # source extraction
  : unzip # source extraction
  : util-linux    # basic shell env
  : which # basic shell env. (command -v 
is more portable, but meh.)

  : xz    # source extraction



And there is this proposal to reduce the amount of compression 
libraries:


https://github.com/rpm-software-management/rpm/issues/1396

Actually, since RPM now uses `rpmuncompress` to extract the archives, 
it could also make sense to e.g. extract this utility into separate 
sub-package and move the extraction utilities out from the 
@buildsys-build. That would not reduce the the buildroot size at 
first, but get the dependencies to the right place for the start.




Doesn't work.

rpmuncompress doesn't know how to uncompress ANYTHING AT ALL by 
itself. It only knows which command(s) to call to do that.



The point is that the group is not the right place to list the 
extraction utilities. The definition should be closer to RPM IMHO. Of 
course one might argue that distribution might want to have a word and 
avoid some compression algorithm, but it can't add anything what RPM 
somehow does not support.


And I didn't want to imply that rpmuncompress can extract some archive 
on its own. Although it can likely be read that way ...



Vít




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


OpenPGP_signature.asc
Description: OpenPGP digital 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: rich deps result in packages being uninstalled from buildroot

[Vít Ondruch]

Dne 16. 05. 24 v 14:28 Zbigniew Jędrzejewski-Szmek napsal(a):

On Thu, May 16, 2024 at 01:14:16PM +0200, Petr Pisar wrote:

Proper solution is actually minimazing content of the minimal build root

Most of the packages in the buildroot are libraries, pulled in via
dependencies.

@buildsys-build group is:
Mandatory packages   : bash  # basic shell env
  : bzip2 # source extraction
  : coreutils # basic shell env
  : cpio  # source extraction
  : diffutils # source extraction
  : fedora-release-common   # rpm environment
  : findutils # basic shell env
  : gawk  # basic shell env
  : glibc-minimal-langpack  # we want this to avoid other 
langpacks
  : grep  # basic shell env
  : gzip  # source extraction
  : info
  : patch # source extraction
  : redhat-rpm-config  # rpm environment
  : rpm-build  # rpm environment
  : sed   # basic shell env
  : shadow-utils
  : tar   # source extraction
  : unzip # source extraction
  : util-linux# basic shell env
  : which # basic shell env. (command -v is more 
portable, but meh.)
  : xz# source extraction



And there is this proposal to reduce the amount of compression libraries:

https://github.com/rpm-software-management/rpm/issues/1396

Actually, since RPM now uses `rpmuncompress` to extract the archives, it 
could also make sense to e.g. extract this utility into separate 
sub-package and move the extraction utilities out from the 
@buildsys-build. That would not reduce the the buildroot size at first, 
but get the dependencies to the right place for the start.



Vít



Out of this list, I see only three candidates for removal:

1. info. This is presumably present for /usr/sbin/install-info.
It's a small package (360kB) and probably not worth the hassle to
remove. On my system, 472 rpms provide info files, and if we remove
it from the default set, we'd need to patch a huge amount of
packages to add it back to make the builds work.

2. util-linux. This could be replaced by util-linux-core. This
has a bunch of deps too, so it'd save some. util-linux has 95
binaries, and while _most_ of them have little use in a constrained
build environment, probably a few are used somewhere. So this
would need some investigation.

3. shadow-utils. It was added in:

commit 79e1728c1b9e9e98d2e38b1286d90d596f233a56
Author: Jesse Keating 
Date:   Tue Jan 15 15:31:27 2008 +

 Make sure shadow-utils makes it into a buildroot, or else mock will fail

It's been a while, and I doubt we actually need it. Maybe we could
drop that?

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: LLVM Packaging Ideas for Fedora 41

[Vít Ondruch]

Dne 15. 05. 24 v 12:10 Miro Hrončok napsal(a):

On 15. 05. 24 10:08, Vít Ondruch wrote:


Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a):

On 14. 05. 24 16:02, Vít Ondruch wrote:


Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):

On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in 
Python, the current Python versioning sucks hard. How am I 
supposed to tell what is the current version just looking at e.g. 
the repository? Is it `python3.12` or is it already `python3.13`? 
Despite I have spent with Fedora more then a decade, answering 
such simple question is not trivial for me.


I guess that for the user, the easiest way is to look at the RPMs. 
Users barely look into our repositories.





~~~

$ rpm -q python
package python is not installed

~~~


Why?


Because it is called python3.

$ rpm -q python3
python3-3.12.3-2.fc39.x86_64

I thought this discussion is about python3.12 vs python3.13, not 
about python vs python3. I supposed the reason it is called python3 
and not python is well know at this point (but if it is not, let me 
know and I'll try to explain).


We are in 2024, so I suppose we could rename everything python3 to 
python now, I just worry that it would be a lot of effort for not 
much benefit.


Even if `# dnf install python` does something, it still won't 
install `python` package.


Well, it installs the python-unverisoned-command package. Which 
requires python3. So it install python. Why does it matter? What are 
you trying to demonstrate here? (Don't take me wrong, I always 
appreciate good criticism, I juts don't understand what are you 
suggesting we should do.)


Do you suggest to rename python-unversioned-command to python?
Do you suggest to rename python3 to python?
Do you suggest to rename the python3.12 component to python? (As 
names of the components started this discussion.)

Or is it something else?



Every time I bring up such discussion, I am told "the reason it is 
called python3 and not python is well know" and yes, it is know to 
some, including me. But advocating for less experienced users. I 
advocating for users which are not experts on Python ecosystem. I am 
advocating for conventions.


I am trying to demonstrate that things should be obvious. There is 
"Python" language. Not "Python 3" language. There is e.g. 
https://www.python.org/ not https://www.python3.org/ etc.


Therefore, I'd rather hear "you are right, that does not make too 
much sense (these days). It is confusing and it is about the time to 
make the things right (finally)". In your words "We are in 2024, so I 
suppose we could rename everything python3 to python now" is what I 
would appreciate.


So you say "python3" should be renamed to "python".

But this entire discussion started about component names (e.g. 
"python3.12") and your inability to tell which Python version is the 
default just by looking at the sources.


I am not disagreeing with you. I just don't see how we suddenly 
discuss a completely different thing.



The whole discussion started with LLVM and Python was used as an 
example. I am saying that Python is bad example and nobody should follow it.


The problem I see is that there is no `python` package which would be 
coming from `python` SRPM and `python` repository. On top of that, there 
is by default no `python` command while Python is installed on the 
system. That is not intuitive.


BTW the `Why?` was rhetoric question, wondering why it so unintuitive. 
After all, I know the status, history, commands etc. I also acknowledge 
the amount of invested work to get to the point where we are.



Vít






Anyway, let me tell you:


You are right, calling the package(s) "python3" does not make too much 
sense any more. It might be confusing and it might be about the time 
to make things right by renaming ~4200 packages back to "python". Feel 
free to propose a detailed plan of execution.


Note that I won't do it, because I don't think the benefits outweighs 
the necessary work. However, if there is a volunteer to drive this, I 
am happy to review the proposal and share my feedback.




OpenPGP_signature.asc
Description: OpenPGP digital 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: SPDX Statistics - Hulk edition

[Vít Ondruch]

It is still not late to introduce e.g. `%callaway_licenses` macro and 
enclose the old licenses into such macro, to make it more obvious that 
those licenses were not converted yet. This should have been done from 
the start 



Vít


Dne 13. 05. 24 v 23:41 Miroslav Suchý napsal(a):

Dne 13. 05. 24 v 5:38 odp. Fabio Valentini napsal(a):

Can we at least still recommend to use the AND / OR / WITH
capitalization for Fedora license tags, even if the lower-case ones
are technically considered valid now?


The other way round. We will not encourage using lower case and all 
our examples use upper case.


And I will stop correcting such errors - I made dozens such PRs.

BTW

GfDl-1.1-oR-lAtEr AND cC-bY-Sa-3.0

is valid SPDX expression. And was even valid with SPDX v2.x 
specification. But please dont say that to anyone :)


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


OpenPGP_signature.asc
Description: OpenPGP digital 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: GIMP 3.0 in F41?

[Vít Ondruch]

Dne 13. 05. 24 v 23:22 Nils Philippsen napsal(a):

On Mon, 2024-05-13 at 14:58 +0200, Vít Ondruch wrote:

Why would you push Gimp 3 into Fedora <= 40?

Why wouldn’t I? It’s technically feasible without really jumping
through hoops, and I don’t want to force users to upgrade the OS – or
wait for Fedora 41 to be at a level of stability acceptable to them –
before they can use the new version.



I am not against Gimp 3 in F40 and older per se. But the issue is that 
it drives you towards `gimp3` for compatibility reasons. IOW I think 
that it would be perfectly fine to have Gimp 2 (gimp package) as default 
in F40 and Gimp 3 (still gimp package) in F41+. Because while they might 
be substantially different, the change happens with major Fedora version 
and users should be prepared for such changes.


IOW situation would be much easier if `gimp` package was Gimp 2 up until 
F40 and Gimp 3 since F41. Optionally, it would also make sense to 
provide `gimp2` package in F41 for backward compatibility.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: LLVM Packaging Ideas for Fedora 41

[Vít Ondruch]

Dne 14. 05. 24 v 18:35 Miro Hrončok napsal(a):

On 14. 05. 24 16:02, Vít Ondruch wrote:


Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):

On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in 
Python, the current Python versioning sucks hard. How am I supposed 
to tell what is the current version just looking at e.g. the 
repository? Is it `python3.12` or is it already `python3.13`? 
Despite I have spent with Fedora more then a decade, answering such 
simple question is not trivial for me.


I guess that for the user, the easiest way is to look at the RPMs. 
Users barely look into our repositories.





~~~

$ rpm -q python
package python is not installed

~~~


Why?


Because it is called python3.

$ rpm -q python3
python3-3.12.3-2.fc39.x86_64

I thought this discussion is about python3.12 vs python3.13, not about 
python vs python3. I supposed the reason it is called python3 and not 
python is well know at this point (but if it is not, let me know and 
I'll try to explain).


We are in 2024, so I suppose we could rename everything python3 to 
python now, I just worry that it would be a lot of effort for not much 
benefit.


Even if `# dnf install python` does something, it still won't install 
`python` package.


Well, it installs the python-unverisoned-command package. Which 
requires python3. So it install python. Why does it matter? What are 
you trying to demonstrate here? (Don't take me wrong, I always 
appreciate good criticism, I juts don't understand what are you 
suggesting we should do.)


Do you suggest to rename python-unversioned-command to python?
Do you suggest to rename python3 to python?
Do you suggest to rename the python3.12 component to python? (As names 
of the components started this discussion.)

Or is it something else?



Every time I bring up such discussion, I am told "the reason it is 
called python3 and not python is well know" and yes, it is know to some, 
including me. But advocating for less experienced users. I advocating 
for users which are not experts on Python ecosystem. I am advocating for 
conventions.


I am trying to demonstrate that things should be obvious. There is 
"Python" language. Not "Python 3" language. There is e.g. 
https://www.python.org/ not https://www.python3.org/ etc.


Therefore, I'd rather hear "you are right, that does not make too much 
sense (these days). It is confusing and it is about the time to make the 
things right (finally)". In your words "We are in 2024, so I suppose we 
could rename everything python3 to python now" is what I would appreciate.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: LLVM Packaging Ideas for Fedora 41

[Vít Ondruch]

Dne 13. 05. 24 v 20:23 Miro Hrončok napsal(a):

On 13. 05. 24 15:38, Vít Ondruch wrote:
And TBH, for me as a Fedora used with no special interest in Python, 
the current Python versioning sucks hard. How am I supposed to tell 
what is the current version just looking at e.g. the repository? Is 
it `python3.12` or is it already `python3.13`? Despite I have spent 
with Fedora more then a decade, answering such simple question is not 
trivial for me.


I guess that for the user, the easiest way is to look at the RPMs. 
Users barely look into our repositories.





~~~

$ rpm -q python
package python is not installed

~~~


Why?


Even if `# dnf install python` does something, it still won't install 
`python` package.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

Dne 14. 05. 24 v 2:03 Stephen Gallagher napsal(a):

On Mon, May 13, 2024 at 10:09 AM Vít Ondruch  wrote:


Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):

On 5/13/24 16:09, Vít Ondruch wrote:

Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):

%patch otoh (now) is a regular (though internally implemented) macro
that is expanded with other macros and though can be used in other
macros and expressions.


Do I read correctly that we can now use `%patch` in e.g. `%check`
section? Interesting. Is this documented?

No, while %patch and %setup *could* be made available elsewhere now,
they are still only available in %prep because that's the only place
where they make sense.


Working with Ruby, which is interpreted language, there are cases where
we want to patch tests, while we want to keep them in their original
form in the package. This might sound weird, but the thing is that for
running tests, we might be limited by infrastructure. E.g. Koji does not
have internet access, builders are slow, etc. So we might want to apply
some patch to workaround such issues.

I have no hopes convincing you. But thank you for clarification.


This last statement was unnecessarily hostile. You are better than that, Vit.



Sorry. What I wanted is just to explain some context and somehow said 
that while I would like have this possibility, I am not e.g. going to 
open upstream RFE ticket.





I assume that Panu's statement above - "that's the only place where
they make sense" - was an unintentional overstatement and should have
been read as "that's the only place we could think of where it made
sense". You've now provided a reasonable argument for why %check might
make sense.

To expand on your example a bit, what I think you're saying is that in
the case of Ruby, we ship not only the binary bits but also the Ruby
tests in the RPMs. For sensible reasons, we want to deliver those
unmodified from upstream, but we also want to be able to run them in
the %check section which necessitates making some modifications due to
the limitations and restrictions present in the Koji build system. By
being able to constrain the patch application to the %check section
(which, if I remember correctly is run AFTER the creation of the
binary RPMs) means that we can package the unmodified sources without
having to resort to custom trickery in the specfile (copying all the
tests to a new location to modify them before running or some such).
Is that a fair restatement of your use-case, Vit?



Right, that is fair.

Thank you for taking time to make sure my use case is properly 
understood. Appreciate that.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

Dne 14. 05. 24 v 11:26 Tim Landscheidt napsal(a):

Vít Ondruch  wrote:


%patch otoh (now) is a regular (though internally
implemented) macro that is expanded with other macros
and though can be used in other macros and expressions.

Do I read correctly that we can now use `%patch` in
e.g. `%check` section? Interesting. Is this documented?

No, while %patch and %setup *could* be made available
elsewhere now, they are still only available in %prep
because that's the only place where they make sense.

Working with Ruby, which is interpreted language, there are
cases where we want to patch tests, while we want to keep
them in their original form in the package. This might sound
weird, but the thing is that for running tests, we might be
limited by infrastructure. E.g. Koji does not have internet
access, builders are slow, etc. So we might want to apply
some patch to workaround such issues.
I have no hopes convincing you. But thank you for clarification.

This feels like the tests should be patched (and these
patches upstreamed) to behave differently depending on some
option



I don't disagree. I am all for upstreaming. But there are more pros and 
cons.



Vít



, and the spec file should then use this option to
trigger the correct one.  I don't know enough about Ruby to
suggest The Way™ to pass this option; but usually
environment variables will do.  (Other test suites have tags
that can be used to select tests that should (not) be run
which might be another (upstreamable) solution.)

Tim



OpenPGP_signature.asc
Description: OpenPGP digital 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: Smaller buildroot for Perl packages

[Vít Ondruch]

Dne 10. 05. 24 v 14:16 Petr Pisar napsal(a):

V Fri, May 10, 2024 at 01:13:53PM +0200, Lumír Balhar napsal(a):

I might have an idea how to make building Perl packages faster and their
buildroot a little bit smaller.

perl-devel depends on systemtap-sdt-devel and that package contains a single
script written in Python and using pycparser. The single script bring
python3-pycparser and therefore the whole Python with its standard library
to the buildroot of all perl packages although (according to my testing)
none of the packages needs it.

I've selected all packages build-requiring perl-devel but don't
build-requiring python-devel directly - 520 in total. And from that number:

  7  faild to build for unrelated reasons
  3  packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
81  packages have python3-libs but not python3-devel (different reasons than
systempat-sdt-devel)

and finally, the rest - 436 packages - builds fine without the python script
in systemtap-sdt-devel and therefore without Python at all.

My idea is to split systemtap-sdt-devel into two packages: one with all the
content but without the python script (/usr/bin/dtrace) and a new one
containing only the mentioned script.

That would make buildroots for many packages smaller and their builds
faster.

I also did a test rebuild of all packages directly build-requiring
systemtap-sdt-devel and identified these packages that really need the
dtrace script: glib2, sssd, qemu, python2.7, postgresql15, postgresql16,
perl, php, mariadb10.11, and libvirt. Those would newly depend on a new
package where we move the script to.

What do you think about this idea? Is it worth writing a Fedora change for
it?


That looks like a great optimization from Perl point of view. It also seems
that only 10 components will need adjustments, so a self-contained Fedora
change should be enough.

Unanswered question is run-time dependencies. There might be packages which
run-require systemtap-sdt-devel because of dtrace executable:

# dnf -q -C repoquery --whatrequires systemtap-sdt-devel
lttng-ust-devel-0:2.13.8-1.fc41.x86_64
perl-devel-4:5.38.2-507.fc41.x86_64
systemtap-testsuite-0:5.1~pre17062192g5fd8daba-1.fc40.x86_64



What about BuildRequires? Shouldn't they be included in your query?

Vít


But probably the most important part is systemtap maintainer (CCed). Is he
fine with this change? Isn't this incompatible change too obstrusive for dtrace
users? I believe it isn't, otherwise dtrace would not be packaged in a -devel
package.

-- Petr

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

Dne 13. 05. 24 v 15:22 Panu Matilainen napsal(a):

On 5/13/24 16:09, Vít Ondruch wrote:


Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro 
that is expanded with other macros and though can be used in other 
macros and expressions.



Do I read correctly that we can now use `%patch` in e.g. `%check` 
section? Interesting. Is this documented?


No, while %patch and %setup *could* be made available elsewhere now, 
they are still only available in %prep because that's the only place 
where they make sense.



Working with Ruby, which is interpreted language, there are cases where 
we want to patch tests, while we want to keep them in their original 
form in the package. This might sound weird, but the thing is that for 
running tests, we might be limited by infrastructure. E.g. Koji does not 
have internet access, builders are slow, etc. So we might want to apply 
some patch to workaround such issues.


I have no hopes convincing you. But thank you for clarification.


Vít




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


OpenPGP_signature.asc
Description: OpenPGP digital 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: LLVM Packaging Ideas for Fedora 41

[Vít Ondruch]

Dne 13. 05. 24 v 15:28 Fabio Valentini napsal(a):

On Mon, May 13, 2024 at 3:23 PM Vít Ondruch  wrote:


Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):

* Switch to python-style compat/main packages.  In order to make the packaging 
more
consistent between the main package (e.g. llvm) and the compat package (e.g. 
llvm18),
we would retire the un-versioned dist-git for llvm, and create a new versioned 
dist-git
for each new release (e.g. llvm19, llvm20, llvm21 etc.).  We would then 
designate one
of these as the 'main version', and that version would produce binary rpms that 
look
like the current main package (i.e. llvm-libs instead of  llvm19-libs).

Ehh? I guess? I don't think this buys us that much.

* Invert the order of compat/main packages.  Instead of having the compat 
package be
the old version, and the main package be the new version, we would have the 
compat package
be newer and the main package be older.  This would allow us to introduce a new 
version of
llvm without impacting other packages that depend on the main version of LLVM.

I don't like this idea, it makes things harder to reason about and
doesn't actually solve any problems.


I concur with Neal here.

I we were living in ideal world, we would have just one `llvm` package. Since 
we are not living in ideal world, it makes sense to have some compat versions. 
But we should try to get as close as possible to ideal world. Versioning 
packages by default goes against that goal, because it encourages sticking to 
some specific version for no particular reason.

For the special case of LLVM, I disagree here. Some projects are just
not compatible with newer LLVM versions until upstream moves first,
and that can take time. So I don't think that counts as "sticking to
some specific version for no particular reason", it's "upstream
doesn't support LLVM X at all yet, they only support LLVM X-1 for
now". I have never seen a Fedora package that uses an LLVM compat
package "for no particular reason".



My point is that we can spent time maintaining llvm00 - llvm99 packages 
or we can spent time adjusting upstream projects to be compatible with 
the latest llvm. Maintaining old versions of package might IMHO cost 
more then adjusting the package to new version.



Vít




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


OpenPGP_signature.asc
Description: OpenPGP digital 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: LLVM Packaging Ideas for Fedora 41

[Vít Ondruch]

Dne 13. 05. 24 v 15:23 Vít Ondruch napsal(a):



Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):

* Switch to python-style compat/main packages.  In order to make the packaging 
more
consistent between the main package (e.g. llvm) and the compat package (e.g. 
llvm18),
we would retire the un-versioned dist-git for llvm, and create a new versioned 
dist-git
for each new release (e.g. llvm19, llvm20, llvm21 etc.).  We would then 
designate one
of these as the 'main version', and that version would produce binary rpms that 
look
like the current main package (i.e. llvm-libs instead of  llvm19-libs).


Ehh? I guess? I don't think this buys us that much.


* Invert the order of compat/main packages.  Instead of having the compat 
package be
the old version, and the main package be the new version, we would have the 
compat package
be newer and the main package be older.  This would allow us to introduce a new 
version of
llvm without impacting other packages that depend on the main version of LLVM.


I don't like this idea, it makes things harder to reason about and
doesn't actually solve any problems.



I concur with Neal here.

I we were living in ideal world, we would have just one `llvm` 
package. Since we are not living in ideal world, it makes sense to 
have some compat versions. But we should try to get as close as 
possible to ideal world. Versioning packages by default goes against 
that goal, because it encourages sticking to some specific version for 
no particular reason.





Actually, reading Miro's answer and since I spent quite some time 
thinking about this, maybe I should elaborate more.


I truly think that we should really have one default / rolling 
non-versioned version of packages and try as hard as we can to keep 
everything compatible with those versions. This is actually where I see 
the biggest benefit of distributions. And this is actually also where 
most of my upstream contributions went.


And if there is need for multiple versions, we should make them parallel 
installable with the default / rolling version. This would actually 
allow to have `python` package, which is the default version and likely 
also `python3.12` if somebody choose to stay with some specific version 
for specific reason. This would also allow to introduce `python3.13` and 
keep it for testing forward compatibility and later for backward 
compatibility purposes.


And no, I don't think about `python` package as a metapackage or so. It 
would be fully fledged package. Maybe it would be currently the same or 
very close to the `python3.12` package.


And TBH, for me as a Fedora used with no special interest in Python, the 
current Python versioning sucks hard. How am I supposed to tell what is 
the current version just looking at e.g. the repository? Is it 
`python3.12` or is it already `python3.13`? Despite I have spent with 
Fedora more then a decade, answering such simple question is not trivial 
for me.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: LLVM Packaging Ideas for Fedora 41

[Vít Ondruch]

Dne 27. 04. 24 v 6:58 Neal Gompa napsal(a):

* Switch to python-style compat/main packages.  In order to make the packaging 
more
consistent between the main package (e.g. llvm) and the compat package (e.g. 
llvm18),
we would retire the un-versioned dist-git for llvm, and create a new versioned 
dist-git
for each new release (e.g. llvm19, llvm20, llvm21 etc.).  We would then 
designate one
of these as the 'main version', and that version would produce binary rpms that 
look
like the current main package (i.e. llvm-libs instead of  llvm19-libs).


Ehh? I guess? I don't think this buys us that much.


* Invert the order of compat/main packages.  Instead of having the compat 
package be
the old version, and the main package be the new version, we would have the 
compat package
be newer and the main package be older.  This would allow us to introduce a new 
version of
llvm without impacting other packages that depend on the main version of LLVM.


I don't like this idea, it makes things harder to reason about and
doesn't actually solve any problems.



I concur with Neal here.

I we were living in ideal world, we would have just one `llvm` package. 
Since we are not living in ideal world, it makes sense to have some 
compat versions. But we should try to get as close as possible to ideal 
world. Versioning packages by default goes against that goal, because it 
encourages sticking to some specific version for no particular reason.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

Dne 10. 05. 24 v 15:20 Florian Festi napsal(a):

On 5/10/24 14:10, Vít Ondruch wrote:

I'd actually prefer the `%patch 1` syntax (which is also the first on
the list [1]). Yes, I understand that `%patch -P1` is to stay on the
safe side, but this is Fedora change, not RHEL or EPEL change.

But if you insist on `-P1`, then please skip all packages I am
associated with. I'd prefer to have them broken and if needed, I fix
them later myself.

We have an even easier solution for you: You can just run the script at
[3] with -n on your own spec files to get them changed to the %patch N
variant. If you do that right now they will not break nor will they be
touched during the mass change.



This is not easier, because it needs action "right now", while I'd like 
to take action when time permits (or when really needed, FTBFS is not 
end of the world after all). Of course I'd be more then happy if you can 
run your script with `-n` option on my packages right now.


Thank you


Vít





As I said the %patch -PN syntax is the one with the best compatibility -
  reaching back into the dark ages. I am not advocating for people to use
it. Anyone is free and encouraged to move to something more modern -
before or after the change. We are using this variant so spec files
continue to work on older distributions and the chance of breakage is
minimized. This way packagers that don't care don't have to.

Florian


Dne 06. 05. 24 v 13:56 Florian Festi napsal(a):

Hi everyone,

RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
the patch number for a year now. See the RPM documentation for more
information [1]. In current RPM versions, this syntax only emits a
deprecation warning, but support for this syntax has been removed
completely in the upcoming RPM 4.20 release. As it will be added in
Fedora soon [2] it is time to switch over to the new syntax now.

There are around 1800 packages that still use the old syntax. Later this
week/next week, we will run this script [3] over the affected packages
[4][5] to update them to the modern patch syntax. For example, the
script will change:

%patch0 -p1 → %patch -P0 -p1
%patch0005 -p2 → %patch -P0005 -p2

If anyone has any objections or would like to exclude a package, please
let me know.

As this change does not affect the resulting binary packages an
immediate rebuild is not needed. The change will "only" ensure the
packages still build with the new version of RPM.

This is the change with the highest compatibility (back to RPM 3.x).
There are more modern options (like %autosetup) that packagers are
encouraged to use but are out of scope here.

Florian

[1]
https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1
[2] https://fedoraproject.org/wiki/Changes/RPM-4.20
[3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh
[4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt
[5]
https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt
--
___
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

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


OpenPGP_signature.asc
Description: OpenPGP digital 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.fedoraproje

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

Dne 13. 05. 24 v 11:39 Florian Festi napsal(a):
%patch otoh (now) is a regular (though internally implemented) macro 
that is expanded with other macros and though can be used in other 
macros and expressions.



Do I read correctly that we can now use `%patch` in e.g. `%check` 
section? Interesting. Is this documented?



Vít




OpenPGP_signature.asc
Description: OpenPGP digital 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: GIMP 3.0 in F41?

[Vít Ondruch]

Dne 13. 05. 24 v 13:24 Nils Philippsen napsal(a):

Hi everyone,

On Mon, 2024-05-13 at 11:49 +0200, Dominik 'Rathann' Mierzejewski
wrote:

On Monday, 13 May 2024 at 01:00, Neal Gompa wrote:

On Sun, May 12, 2024 at 4:59 PM Sérgio Basto 
wrote:



https://src.fedoraproject.org/rpms/gimp3


What the heck? This should have been gimp2 for the old version, not
gimp3 for the new version...

this is to avoid package renaming churn and to be able to introduce
GIMP 3 alongside the 2.x packages already in Fedora. I use the same MO
for Ardour, which gets major version updates more often than GIMP and
whose users have a similar requirement to be able to open old projects
with matching versions of the application while starting new ones on
the latest and greatest.

If I’m not off track, renaming the existing version to “gimp2” would at
least make people install it as an update to “gimp-2.10.x” without any
real benefit to them. And it would make ”gimp” jump to version 3 which
is wildly different



Am I supposed to read this that over time, GIMP3 will get closer to 
GIMP2 and once they are identical, the switch will be painless? I don't 
think this is the plan.


Look at e.g. Python. How long it took to migrate and have we migrated to 
Python 3 when everything was ready? Hardly. There was just pain during 
all the years. Or look at DNF.


Introducing GIMP 3 package is just extending pain. Nothing more. If 
somebody wants to stick with GIMP2 for whatever reason, they can pin 
their version or if you want to be super nice, provide the gimp2 package.




  (and would probably go against package
compatibility guidelines if done in Fedora <= 40).



Why would you push Gimp 3 into Fedora <= 40?


Vít





OpenPGP_signature.asc
Description: OpenPGP digital 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: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

[Vít Ondruch]

I'd actually prefer the `%patch 1` syntax (which is also the first on 
the list [1]). Yes, I understand that `%patch -P1` is to stay on the 
safe side, but this is Fedora change, not RHEL or EPEL change.


But if you insist on `-P1`, then please skip all packages I am 
associated with. I'd prefer to have them broken and if needed, I fix 
them later myself.



Vít


Dne 06. 05. 24 v 13:56 Florian Festi napsal(a):

Hi everyone,

RPM has deprecated the %patchN syntax in favor of %patch -PN where N is
the patch number for a year now. See the RPM documentation for more
information [1]. In current RPM versions, this syntax only emits a
deprecation warning, but support for this syntax has been removed
completely in the upcoming RPM 4.20 release. As it will be added in
Fedora soon [2] it is time to switch over to the new syntax now.

There are around 1800 packages that still use the old syntax. Later this
week/next week, we will run this script [3] over the affected packages
[4][5] to update them to the modern patch syntax. For example, the
script will change:

%patch0 -p1 → %patch -P0 -p1
%patch0005 -p2 → %patch -P0005 -p2

If anyone has any objections or would like to exclude a package, please
let me know.

As this change does not affect the resulting binary packages an
immediate rebuild is not needed. The change will "only" ensure the
packages still build with the new version of RPM.

This is the change with the highest compatibility (back to RPM 3.x).
There are more modern options (like %autosetup) that packagers are
encouraged to use but are out of scope here.

Florian

[1] https://rpm-software-management.github.io/rpm/manual/spec.html#patch-1
[2] https://fedoraproject.org/wiki/Changes/RPM-4.20
[3] https://fedoraproject.org/wiki/File:User-Ffesti-new_patch_syntax.sh
[4] https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-packages.txt
[5]
https://fedoraproject.org/wiki/File:User-Ffesti-patchNN-package-owners.txt
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Vít Ondruch]

Dne 15. 04. 24 v 11:10 Miroslav Suchý napsal(a):

Dne 13. 04. 24 v 1:16 odp. Zbigniew Jędrzejewski-Szmek napsal(a):

The proposal explicitly states that we don't want Perl in all buildroots.


How many seconds we save by NOT pulling Perl? Per each build? In total 
for whole release cycle?




I know that I have saved quite significant time every build.

Also having buildroot minimal also makes sure that we have correctly 
specified explicit dependencies, therefore making the builds more 
reproducible. IOW adding Perl back into the build root would be against 
the goal of this change proposal.



Vít


How many seconds we loose (lost) by refactoring the code? And syncing 
with Debian? Or even worse finding issues that Debian will find and we 
not?


--
Miroslav Suchy, RHCA
Red Hat, Manager, Packit and CPT, #brno, #fedora-buildsys

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


OpenPGP_signature.asc
Description: OpenPGP digital 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: F41 Change Proposal - Reproducible Package Builds (System-Wide)

[Vít Ondruch]

Dne 13. 04. 24 v 21:04 Zbigniew Jędrzejewski-Szmek napsal(a):

On Sat, Apr 13, 2024 at 01:38:49PM +, Zbigniew Jędrzejewski-Szmek wrote:

On Sat, Apr 13, 2024 at 01:41:59PM +0200, Fabio Valentini wrote:

On Sat, Apr 13, 2024 at 1:18 PM Zbigniew Jędrzejewski-Szmek
 wrote:

Yes. But actually I think Rust is the optimal choice here. Writing
this in Python would be possibly slightly nicer, but we don't want
to pull the interpreter and packages into the buildroot. Python
also has the problem (challenge?) that it needs to be bootstrapped
once per year. The less packages are involved in the bootstrap, the
easier it is. And if the brp was written in Python, we'd need to
deal with that, and it would probably increase the number of builds
which are done without the cleanup. Having this as an indepedent
binary avoids some of the issues with bootstrap.

I think Rust *would* be a good choice here ...
BUT add-determinism uses pyo3 to link to CPython, so it pulls in
python3-libs anyway.
So you get the downsides of pulling in Python without the upsides of
using Rust ...

Yes, it currently pulls in python3-libs as a dependency, but not the
rest of the Python stack. Ideally, the dependency on python3-libs will
become optional, and we'll use it if found at runtime if found and
ignore otherwise. (Anything that creates pyc files will have python
installed, so it's fine if the pyc handler only works if there.)
How to best do this is something that needs to be figured out…

https://github.com/keszybz/add-determinism/pull/1 makes the dependency
on libpython optional. One option would be to compile the binary
twice, and use rich dependencies to install the heavyweight one if
python3 is installed. If somebody has a better approach, I'm all ears.



Could you please share some comparison of what is impact on buildroot? 
How many packages added, download size, install size.


Thx a lot


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Updating Taskwarrior to v3

[Vít Ondruch]

Our guidelines suggest that the "main" package should be unversioned, 
while if needed, the "compat" packages should include version:


https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple

So if you want to introduce new package, then please introduce `task2` 
and update the current `task` package to the most recent version.



Vít


Dne 15. 04. 24 v 12:04 Ankur Sinha napsal(a):


On Mon, Apr 15, 2024 09:41:05 -, Onuralp SEZER wrote:

+1 to create task3 but the CLI command is "task". It either needs to
rename both like "task2,task3" or conflict old and new ones and
prevent installing both of them.

They are not designed to be installed in parallel, so task3 will
obsolete task. However, task3 will not provide the task package, so that
task will not be updated to task3 during normal upgrades. Users will
have to explicitly install task3.


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


OpenPGP_signature.asc
Description: OpenPGP digital 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: convert everything to rpmautospec?

[Vít Ondruch]

Dne 09. 04. 24 v 19:06 Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, Apr 09, 2024 at 12:57:33PM -0400, Neal Gompa wrote:

On Tue, Apr 9, 2024 at 12:56 PM Zbigniew Jędrzejewski-Szmek
 wrote:

On Tue, Apr 09, 2024 at 09:41:01AM +0200, Vít Ondruch wrote:

Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):

And we already have a significant fraction of packages using rpmautospec,


Actually, could you quantify the "significant fraction"?

7399 / 23912 = 31%.

How much of it is non-Rust and non-Go?

3720 / 19454 = 19% when '^(rust|golang)-.*\.spec' is filtered out
(which matches most but not all rust packages).



Thx for the numbers. While it is not insignificant number, it is also 
far from majority. Based on this, I don't think it is the right time yet.


BTW last time I tried rpmautospec, I quickly reverted back. Not that I 
dislike the idea, but I have immediately hit some issues (don't remember 
the details, sorry). This reminds me that maybe I should give it another 
try and than you for opening the discussion (and reminding me :) ).



Vít



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


OpenPGP_signature.asc
Description: OpenPGP digital 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: "fedpkg local" builds fail for rust packages

[Vít Ondruch]

Dne 09. 04. 24 v 14:15 Fabio Valentini napsal(a):

On Tue, Apr 9, 2024 at 1:19 PM Vít Ondruch  wrote:

Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a):

Packaged Rust crates work *fine* for local development as long as you
are willing to cut yourself off from crates.io. Unlike *every other
language package manager*, Cargo does not support multiple concurrent
indexes. This is ultimately the bottleneck, and there's been very
little interest in resolving this upstream.

Upstream issue: https://github.com/rust-lang/cargo/issues/4883


OTOH, there does not seem to be linked any PR implementing this RFE.

All people involved with Rust packaging in Fedora seem to be very
disillusioned wrt/ getting stuff upstreamed into cargo.
As far as I know, all of us have had very frustrating experiences when
trying to work with cargo upstream.



Trust me, I know the feeling.

But after all, I almost always had bigger success providing PR then just 
suggesting some changes. And of course a lot of patience is needed as well.



Vít




Spending a lot of time working on feature development only to be told
"we're not interested" is not a good way to spend our (limited) time.

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: "fedpkg local" builds fail for rust packages

[Vít Ondruch]

Dne 08. 04. 24 v 12:32 Neal Gompa napsal(a):

On Mon, Apr 8, 2024 at 6:17 AM Richard W.M. Jones  wrote:

On Fri, Apr 05, 2024 at 03:33:35PM +0200, Fabio Valentini wrote:

On Fri, Apr 5, 2024 at 9:51 AM Michael J Gruber  wrote:

So you're saying that those packages are in the repos for everyone but
not meant to be installed by anyone (besides mock chroots), and that is
how and why they are packaged.

Yes. That is the best we can do given how cargo + Rust work.


`This package contains library source intended for building other packages which
use the "xyz" crate.`

So the description matches what I said?


Unless you `fedpkg local` build it. Or maybe only if you `fedpkg
mockbuild` it. Does a rebuild from `fedpkg srpm` even work?

Wow!

Sorry to burst your bubble, but "fedpkg local" is an ugly hack
(independent of Rust peculiarities).

fedpkg local works fine for almost all cases.


And I am not interested in adding workarounds to the Rust packaging
toolchain to support it.

"fedpkg mockbuild" and "fedpkg srpm" all work as expected ...


Is there any other set of packages which we package like that?

Probably golang ... maybe Haskell, OCaml?

OCaml is definitely _not_ packaged like this.  ocaml-* and
ocaml-*-devel packages are normal packages that can be installed by
end users if they want, although usually only if they're developing
OCaml software.


Packaged Rust crates work *fine* for local development as long as you
are willing to cut yourself off from crates.io. Unlike *every other
language package manager*, Cargo does not support multiple concurrent
indexes. This is ultimately the bottleneck, and there's been very
little interest in resolving this upstream.

Upstream issue: https://github.com/rust-lang/cargo/issues/4883



OTOH, there does not seem to be linked any PR implementing this RFE.


Vít




Without this feature, it becomes difficult to do development using
packaged crates.




OpenPGP_signature.asc
Description: OpenPGP digital 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: convert everything to rpmautospec?

[Vít Ondruch]

Dne 08. 04. 24 v 10:43 Zbigniew Jędrzejewski-Szmek napsal(a):

And we already have a significant fraction of packages using rpmautospec,



Actually, could you quantify the "significant fraction"?


Thx


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Vít Ondruch]

Dne 04. 04. 24 v 17:32 Kevin Kofler via devel napsal(a):

Neal Gompa wrote:

By default, GNOME only presents the close window button. The other
buttons are missing, and there isn't really an intuitive way to
discover the other window management actions.



I agree that there are no other buttons. But still, Gnome opens the 
windows in normalized state, not maximized what was the original claim.




In the version I tried, and judging from end user reports, for several
years, it did not even present that, leading to fun issues such as some KDE
dialogs that could not be closed at all (because they were missing a "Close"
button and relying on the window decoration exclusively).



I have never seen Gnome / Gtk app without "Close" button. I can imagine 
that there likely can be issue for some non-Gtk app. I don't know.


In any case, I prefer to use Gtk apps for Gnome and I assume this is the 
case for Gnome users. Similarly I won't be surprised if KDE users prefer 
QT apps. Mixing the DE and frameworks might not always work without 
issues. And this is not just about Gtk / Qt and Gnome / KDE. E.g. Java 
apps might look out of place on both DEs.



Vít




OpenPGP_signature.asc
Description: OpenPGP digital 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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Vít Ondruch]

Dne 04. 04. 24 v 0:44 Kevin Kofler via devel napsal(a):

Leon Fauster via devel wrote:

I already had RHL installed on a Sun IPX with Gnome, so I'm biased.

Interesting that you were not put off by the changes that have happened to
GNOME since the old RHL days. I tried GNOME 1 at one point long ago, it was
actually pretty good. (It was very configurable back then. Remember when it
shipped Enlightenment as the window manager, how many options that had?)
Then GNOME 2 came, removing much of the configurability of GNOME 1. And then
GNOME 3 came, removing AGAIN much of the remaining configurability of GNOME
2, leading to a very hardcoded experience. GNOME 2 was already too much for
me, and I switched back to KDE, back because I had already tried KDE 1.1.1
on another distro. And I have never looked back.

Well, actually, I wanted to be fair and give GNOME 3 a chance, so I tried it
out once. But it took less than 10 minutes for me to realize that it is not
for me. The user experience is just too unfamiliar (the unified application
menu and open window selector (launch menu AND task bar replacement), the
always maximized windows, the lack of a system tray, the shut down options
in the mouse menu hidden behind a keyboard dead key, etc.), and GNOME does
not make it easy for you to change it. (You can actually get a pretty
standard desktop experience nowadays if you install a lot of "unbreak this",
"unbreak that" GNOME Shell extensions, but that kinda defeats the point of
GNOME.) The default experience felt pretty much unusable to me personally.



Uh, from your description, I would really have hard time to decipher you 
are talking about Gnome 3.


"the always maximized windows" what is this about? Maybe you are missing 
some maximize/normalize buttons.


"the shut down options in the mouse menu hidden behind a keyboard dead 
key, etc.)" this is also not the case for ages, or at least not in its 
completeness.


Maybe you should give it second try.


Vít



KDE Plasma not only has more familiar defaults (actually looking and feeling
much more similar to GNOME 1 than GNOME 3 does), but also lets you easily
change those defaults that you do not like.

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Three steps we could take to make supply chain attacks a bit harder

[Vít Ondruch]

Dne 30. 03. 24 v 18:26 Artem S. Tashkinov via devel napsal(a):

Hi,

It was sheer luck that the exploit was discovered and major distros haven't yet 
included it in their stable releases. It's quite possible and plausible it 
could have reached RHEL, Debian, Ubuntu, SLES and other distros and it's almost 
reached Fedora 40.

I don't know how to talk to RedHat/IBM/FSF/Ubuntu and all the big players 
behind Open Source/Linux but I want to raise a very important issue.

There's near zero accountability for the tens of thousands of packages included in Linux 
distros, often by maintainers who have no resources, qualifications or even know any 
programming languages to spot the "bad" code and raise an alarm. Upstream 
packages are pushed into Linux distros without considerationand that's it.

That's all completely unacceptable on multiple levels. Security is a joke as a result of 
this considering the infamous "Jia Tan" who was almost the sole maintainer of 
XZ for over two years.

I propose this issue to be tackled in a centralized way by the collaboration of 
major distros.



If I was JT, I would applaud this proposal. This would give me an 
opportunity to infiltrate such powerful body and either


1) close my eyes above some of the reviewed content from the right 
parties or


2) have some nice proposal such as "do you think your code is correct 
and won't you include rather this specially crafted piece of  code?"



But since I am not JT, I prefer the current decentralized approach.


Vít




There must be a website or a central authority which includes known to be 
good/safe/verified/vetted open source packages along with e.g. 
SHA256/384/512/whatever hashes of the source tarballs. In addition, the source 
tarballs (not their compressed versions because people may use different 
compressors and compression settings) and their hashes must be digitally signed 
or have the appropriate PGP signatures from the trusted parties.

Some parties must be assigned trust to be able to push new packages to this 
repository. Each push must be verified by at least two independent parties, 
let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. The 
representatives of these parties must be people whose whereabouts are known to 
confirm who they physically are. No nicknames allowed.

This website must also have/allow a revocation mechanism for situations like 
this.

Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing they 
are safe to use.

If that's the wrong place to come up with this proposal, please forward it to 
the people who are responsible for making such decisions. I'm not willing to 
dig through the dirt to understand how the Fedora project works, who is 
responsible for what, and what are the appropriate communication channels. If 
you care, you'll simply forward my message. Thanks a lot.

Best regards,
Artem
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Three steps we could take to make supply chain attacks a bit harder

[Vít Ondruch]

Dne 30. 03. 24 v 22:14 Zbigniew Jędrzejewski-Szmek napsal(a):

On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote:

Zbigniew Jędrzejewski-Szmek wrote:

I think there's some useful points here, but this would need to be
qualified and/or made more flexible to be applied.

For example, systemd repo has fuzzer case files, which are a mix of
text, mojibake, and actual binary protocol samples. For example, dhcp
input packets, dns packets. There are also other ~binary test files,
for example corrupted journal files.

The tests are defined via meson.build, so those files are "referred to
in the build tools", and would not be allowed by the above definition.
But if we dropped those, we'd lose very valuable testing of the codebase.

On the other hand, "test files" are exactly how the payload of this backdoor
was disguised! So a policy that deletes all binary test files or even all
test files altogether would have prevented this backdoor.

Well, if we made a rule that "binary" files are not allowed



I think that we should really not talk about binary files and talk e.g. 
about pre-generated files instead. This chapter in guidelines is already 
trying to cover this:


https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#pregenerated-code

But maybe we should rewrite the "No inclusion of pre-built binaries or 
libraries" chapter above to be more generic.



Vít






, the
attacker would e.g. commit some minified bash that generates whatever output
is needed. The real problem was the complex and unreadable build system
that made it easy to embed _multiple_ obfuscated components for the attack.

To trust code, it needs to be reviewed. And if the code is reviewed,
and the build system is sane, it's usually fairly easy to say "oh,
this is a sample and the only way it's used is as input to a fuzzer
binary", or "this sample is used as input to a unit test", etc.

A policy against binary files would hinder this particular implementation
of the attack, but the attacker had full control of the repo, so they
would be able to arrange the attack around such a policy without too
much trouble.

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

[Vít Ondruch]

Dne 27. 03. 24 v 7:40 Miroslav Suchý napsal(a):

Dne 26. 03. 24 v 6:00 odp. Artur Frenszek-Iwicki napsal(a):

If we're going to introduce any kind of (semi-)automatic
conversion of existing license tags, I think it'd be good
to make "convert «and» and «or» to upper-case"
part of the process.

A.FI.

[0]https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/#d2-case-sensitivity


*nod*

BTW based of the feedback of all of you and because it is very common 
error in writing SPDX formula in SPDXv3 it will likely be allowed to 
use "and", "or".


https://github.com/spdx/spdx-spec/pull/892



I wish there was also comma operator `,` with the meaning of `AND`, that 
could be useful.


Just FTR, I have opened this RPM discussion a while ago:

https://github.com/rpm-software-management/rpm/discussions/2892

Just to realize not long ago that one hurdle is how to merge the tags 
together, because RPM itself does not know anything about SPDX or any 
other license identifiers. If needed, comma would be the most natural 
operator for list of licenses.


Not mentioning, it does not have issues with upper / lower case and 
writing ", " instead of " AND " requires just 40 % of the effort.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Vít Ondruch]

Dne 26. 03. 24 v 8:02 Zbigniew Jędrzejewski-Szmek napsal(a):

On Tue, Mar 26, 2024 at 06:39:35AM +0100, Jan Kolarik wrote:

Previously, I had issues that migration from DNF4 to DNF5 left a lot of

data in /var/cache. How is this going to be addressed? I don't think it is
fair to leave those behind and waste disk space for regular users.


That's a good point. Though since this migration isn't entirely removing
dnf4 from the system but just altering the symlink, users can still access
it. Hence, automated removal isn't feasible. However, we could consider
offering a user prompt after the transaction involving symlink replacement,
advising users to delete /var/cache/dnf if they no longer intend to use
dnf4.

What about adding the scriptlet to remove /var/cache/dnf to the
dnf4 package? (That's how I understood the original ask.)



Maybe the "isn't entirely removingdnf4 from the system" is the root of 
the issue. Is this planned? Because in that case, the cache would be 
likely removed:


https://src.fedoraproject.org/rpms/dnf/blob/c7f6b4941a317bfde54b704e925152daecb17dda/f/dnf.spec#_292


Vít




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


OpenPGP_signature.asc
Description: OpenPGP digital 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: F41 Change Proposal: Switch to DNF 5 (System-Wide)

[Vít Ondruch]

Dne 25. 03. 24 v 16:46 Aoife Moloney napsal(a):


=== Reduced footprint ===
The dnf5 package is a fully-featured package manager that doesn't
require Python dependencies.

It also reduces the number of software management tools in Fedora by
replacing both the dnf and microdnf packages.

The installation size of the dnf5 stack in an empty container is
approximately 60% smaller than the dnf installation.

Currently, dnf, microdnf, and PackageKit use their own cache, leading
to significant metadata redundancy. With dnf5 and dnf5daemon, which
share metadata, this redundancy will be eliminated.



... snip ...




= [https://github.com/rpm-software-management/dnf5/issues/169
GNOME Software support] =
The integration of dnf5 support, particularly dnf5daemon, into GNOME
Software is currently underway. Developers from both DNF5 and GNOME
Software are closely connected and regularly synchronize the progress
of their work.



... snip ...




= GNOME Software =
Rawhide users will continue to utilize the current PackageKit backend
connected to the existing libdnf interface. These libraries can
coexist with the new dnf5 package on the same system. Although the
setup is not ideal due to differences in package state metadata
formats stored at separate locations, resulting in inefficient storage
usage, this is generally imperceptible for typical GUI users.
Furthermore, the underlying RPM DB remains the sole shared source of
information about installed packages.



I don't understand this. So if GS going to use DNF, therefore the same 
cache etc, or not? Or what other metadata PackageKit downloads on top of 
DNF?




 Before upgrade 

$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf-3
├── dnf-3
└── dnf4 -> dnf-3


 After upgrade 

$ tree /usr/bin/ -P dnf*
/usr/bin/
├── dnf -> dnf5
├── dnf-3
├── dnf4 -> dnf-3
└── dnf5






Love these versions, as always





=== Different system state ===
The transactional history in dnf and dnf5 is not shared, and they now
use different formats. Transactions performed in dnf will not be
visible in dnf5, and vice versa.

While the history database is not migrated to dnf5, when running a
transaction in dnf5 for the first time, an attempt is made to convert
and load the existing system state from dnf. This should preserve
information about the reasons for installed packages and prevent them
from being treated as user-installed, requiring manual removal from
the system instead of being seen as dependencies of explicitly removed
packages.



Previously, I had issues that migration from DNF4 to DNF5 left a lot of 
data in /var/cache. How is this going to be addressed? I don't think it 
is fair to leave those behind and waste disk space for regular users.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Review swap

[Vít Ondruch]

Isn't the wasi-sdk just umbrella project? Is it really needed? We have 
llvm / clang, we have wasi-libc, what else do you need?



Vít


Dne 06. 03. 24 v 11:08 Jan Horak napsal(a):

Hi,
if anyone is willing to make a review for wasi-sdk - build require for 
the Firefox rlbox sandboxing of the used c/c++ libraries, please have 
a look and let me know about your package:


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



--
Jan Horak
Senior Software Engineer
Red Hat

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-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


OpenPGP_signature.asc
Description: OpenPGP digital 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: Update gumbo-parser to 0.12.1/libgumbo SONAME bump

[Vít Ondruch]

Dne 01. 03. 24 v 19:58 Adam Williamson napsal(a):

On Fri, 2024-03-01 at 09:34 +0100, Michael J Gruber wrote:

Am Fr., 1. März 2024 um 07:55 Uhr schrieb Ralf Corsépius :

Hi,

I intend to update gumbo-parser to 0.12.1 in rawhide.
This comes along with an soname bump libgumbo to libgumbo.so.2

This requires a rebuilt of several dependent packages, AFAICT:
claws-mail
litehtml
mupdf
perl-HTML-Gumbo
python3-PyMuPDF
qpdfview
zathura-pdf-mupdf

I'll try to rebuild these packages on side-tag f41-build-side-84865
(Please, bear with me, I haven't used side-tags, before. I couldn't find
any usable docs on how to use them)

Preliminary tests indicate, something unrelated to libgumbo.so.* has
changed with these packages (Probably mupdf), causing gpdfview to FTBFS
and dependency changes in rawhide.

Interesting. I wasn't aware of that dependency - I guess I have to
re-run detection more often. Speaking of - do we have a policy about
this? This is not about blaming, but how do we ensure that everyone is
aware of new dependencies? Frequent re-runs to detect them or
announcements the other way round?

Unless I've missed something, the general situation in Fedora is all
the onus is on the party bumping the depended-upon package. We don't
require dependent packages to announce their dependencies in any way
(except, you know, through an actual package dependency).

If you're changing a package in any way that could be fairly considered
"not backwards compatible" for another package depending on it in a
"typical" way, I'm pretty sure the onus is on you to find those
dependencies and make sure they are handled, not vice versa.

Honestly, we could really use more automation here, but it's a fairly
hard thing to do *reliably* and there just isn't anybody specifically
tasked with it so it doesn't happen. I had an interesting chat with
Martin Pitt about britney -
https://release.debian.org/doc/britney/what-is-britney.html



We have:

https://gitlab.com/fedora/packager-tools/mass-prebuild

It does not do automated official builds, but it certainly helps to 
better understand what is the impact of changes on dependent packages.



Vít



  - which
Debian and Ubuntu use in this area. If I understood the explanation
correctly, it's a sort of automated update bundler; Debian and Ubuntu
devs can just throw builds at a staging area, and britney takes care of
grouping them into logical sets based on their dependencies. So to do
an soname bump you'd build the bumped library in the staging area, wait
for it to appear in the staging area buildroot (I guess), then build
all the dependencies, and britney would figure out that this group of
packages needs to go out of the staging area and into stable together
and make that happen, so the packager doesn't have to group them
manually. If you've got a build in the staging area which britney can't
"solve", I think, you get alerts so you know what needs doing ("package
X needs rebuilding against your thing", or whatever).

Something along those lines for Fedora would be awesome! But we can't
just lift-and-shift britney - we'd have to adapt it to RPM dependencies
(if that hasn't been done already) and integrate it with Bodhi
(definitely not done already). That's a lot of work for someone. We
could conceivably code an equivalent feature into Bodhi ourselves, but
again, a lot of work for someone. And it'd probably need some thought
about a way to allow cutoffs/exceptions so you could get an soname bump
through if it has 500 dependencies and you've fixed 499 and the other
is some obscure package that hasn't been maintained for a year. All of
that is work that isn't #1 on anybody's priority list, I think :( I
would love to say I'm gonna work on it, but I've added three neat
projects to my "neat side project backlog" since *yesterday* and it's
about a thousand items long at this point, so, hmm.

It'd also be nice to have a reliable distro-wide automated check for
"does this update break the dependencies of anything else?" so we could
at least prevent all updates that break dep chains going stable. Right
now openQA catches some such cases, but *only* ones that affect
critical path packages *and* happen to involve a package that actually
gets installed during an openQA test. The CI rpmdeplint test is
supposed to cover this, I think, but historically hasn't proven
reliable enough to be made universally gating (and I think maybe only
works on Rawhide). But again...somebody has to clear the time to work
on it :|


OpenPGP_signature.asc
Description: OpenPGP digital 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 spa

Re: libxslxwriter (misspelled package) in zombie state

[Vít Ondruch]

Dne 03. 03. 24 v 10:55 Miro Hrončok napsal(a):

On 02. 03. 24 23:28, Richard W.M. Jones wrote:

On Sat, Mar 02, 2024 at 10:16:02PM +0100, Miro Hrončok wrote:

On 02. 03. 24 11:31, Richard W.M. Jones wrote:

On Fri, Mar 01, 2024 at 10:00:20AM -0800, Kevin Fenzi wrote:

On Fri, Mar 01, 2024 at 11:49:06AM +, Richard W.M. Jones wrote:


We were discussing this on IRC, so just to bring the topic up on the
mailing list ...

(1) Package libxslxwriter (note: "xslx") with only automated 
activity

and no builds:
https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide
https://koji.fedoraproject.org/koji/packageinfo?packageID=32741

(2) Package libxlsxwriter (note: "xlsx") which is normal:
https://src.fedoraproject.org/rpms/libxlsxwriter/commits/rawhide
https://koji.fedoraproject.org/koji/packageinfo?packageID=32754

It seems like the first package is in some sort of zombie state?


Yeah, the package owner (or a provenpackager) should just be able to
'fedpkg retire' it...


Well I took that as a hint and I ran the retire command. I'm not sure
if it actually worked completely.  There was an error towards the end:

$ fedpkg retire 
"https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/";

rm '.gitignore'
rm 'README.md'
rm 'libxlsxwriter.spec'
rm 'libxlsxwriter_sover.patch'
rm 'libxlsxwriter_zlib.patch'
rm 'sources'
[rawhide 922af46] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/X6ADYQA27WRLDQYAL3MHMGCHN3NQY47S/

  7 files changed, 1 insertion(+), 143 deletions(-)
  delete mode 100644 .gitignore
  delete mode 100644 README.md
  create mode 100644 dead.package
  delete mode 100644 libxlsxwriter.spec
  delete mode 100644 libxlsxwriter_sover.patch
  delete mode 100644 libxlsxwriter_zlib.patch
  delete mode 100644 sources
...
Could not execute retire: The following error occurred while 
disabling monitoring: You are not allowed to modify this project


This seems like https://pagure.io/fedpkg/issue/505

The package is retired in dist-git:

https://src.fedoraproject.org/rpms/libxslxwriter/commits/rawhide


OK .. but is it retired?


It is now. When you asked, it might have been only partially retired. 
Package retirement is an asynchronous chain of events.


1. It is retired in rawhide distgit bacuase it has the dead.package 
file ✔️


2. It is "active: false" in rawhide PDC ✔️
https://pdc.fedoraproject.org/rest_api/v1/component-branches/?name=rawhide&global_component=libxslxwriter 



3. It is blocked in f41 Koji ✔️
$ koji list-pkgs --show-blocked --tag f41 --quiet --package libxslxwriter
libxslxwriter   f41 smani  [BLOCKED]

4. It is not in the rawhide repository ✔️
This package never was, so :/


For docs, see 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#_koji





It should also be marked as "retired" / "unmaintained" in Pagure and 
there should be no owner which is not the case. And this is not the only 
package in this state. I have reported it here:



https://pagure.io/releng/issue/11994


Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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: Donate 1 minute of your time to test upgrades from F39 to F40

[Vít Ondruch]

Dne 25. 02. 24 v 18:02 Ralf Corsépius napsal(a):



Am 24.02.24 um 10:12 schrieb Samuel Sieb:

On 2/24/24 00:47, Ralf Corsépius wrote:

Am 24.02.24 um 01:36 schrieb Samuel Sieb:

On 2/23/24 15:38, Sérgio Basto wrote:

On Sat, 2024-02-24 at 00:06 +0100, Ralf Corsépius wrote:



Am 23.02.24 um 22:37 schrieb Samuel Sieb:

On 2/23/24 10:50, Ralf Corsépius wrote:


# dnf system-upgrade download --releasever=40
...
No match for group package "multican"
...

WTH?


It was a program for controlling Canon cameras that has been
retired.
Some group you have installed has that package listed in it.

Ah, this likely explains why neither "dnf repoquery" nor "dnf group
list" could find "multican".


  The comps
groups need to be cleaned out and that's just a warning.

Well, ... IMHO, most about comps and groups is in an embarrassing
unusable shape.


No match for group package "baekmuk-ttf-batang-fonts"

[snip]

No match for group package "util-linux-user"

I got these ones , is something on my rpm db ?


I am seeing these on another machine, too.


I expect you would see that on all machines.

No.  Well, sort of.  As mentioned, those are packages that have 
been removed from the distro, but are still listed in the comps 
groups. dnf checks the installed groups for packages that need to 
be updated and can't find these ones.

Really? How do I check for which groups I have installed?

At least I haven't found any way to check for them, neither with rpm 
nor with dnf.


dnf group list --installed


# dnf group list --installed
Last metadata expiration check: 4:04:39 ago on Sun 25 Feb 2024 
01:48:48 PM CET.

Installed Environment Groups:
   Xfce Desktop
Installed Groups:
   Administration Tools
   LibreOffice
   Fonts
   Hardware Support

# dnf system-upgrade --release=40 download
...
No match for group package "paktype-ajrak-fonts"



Just looking at the first one, this is defined here:


https://pagure.io/fedora-comps/blob/main/f/comps-f40.xml.in#_2189

https://pagure.io/fedora-comps/blob/main/f/comps-f41.xml.in#_2189


So if those packages were dropped, then the same person who did that 
should update also the groups.



Looking at dist-git:

https://src.fedoraproject.org/rpms/paktype-ajrak-fonts

It seems those were removed due to being orphaned. That suggest that the 
process should be improved to cover comps. Adding the responsible people 
on CC.



Vít



No match for group package "eosrei-emojione-fonts"
No match for group package "google-noto-sans-phags-pa-fonts"
No match for group package "multican"
No match for group package "nafees-pakistani-web-naskh-fonts"
No match for group package "baekmuk-ttf-batang-fonts"
No match for group package "layla-thuluth-fonts"
No match for group package "layla-digital-fonts"
No match for group package "lohit-nepali-fonts"
No match for group package "google-noto-looped-thai-fonts"
No match for group package "nafees-tehreer-naskh-fonts"
No match for group package "lohit-tamil-classical-fonts"
No match for group package "samyak-gujarati-fonts"
No match for group package "layla-arcyarc-fonts"
No match for group package "nafees-riqa-fonts"
No match for group package "gimp-heif-plugin"
No match for group package "kalapi-fonts"
No match for group package "ibus-bogo"
No match for group package "samyak-devanagari-fonts"
No match for group package "scim-sayura"
No match for group package "lohit-malayalam-fonts"
No match for group package "nafees-pakistani-naskh-fonts"
No match for group package "samyak-odia-fonts"
No match for group package "layla-basic-arabic-fonts"
No match for group package "layla-diwani-fonts"
No match for group package "samyak-tamil-fonts"
No match for group package "nafees-naskh-fonts"
No match for group package "nafees-web-naskh-fonts"
No match for group package "cdac-sakal-marathi-fonts"
No match for group package "layla-ruqaa-fonts"
No match for group package "samyak-malayalam-fonts"
No match for group package "layla-boxer-fonts"
No match for group package "baekmuk-ttf-hline-fonts"
No match for group package "fontawesome-fonts"
No match for group package "baekmuk-ttf-gulim-fonts"
No match for group package "nafees-nastaleeq-fonts"
No match for group package "layla-koufi-fonts"
No match for group package "baekmuk-ttf-dotum-fonts"
...


My actual problem seems to be not being able to get rid of the 
"installed groups".


"dnf group remove " apparently uninstalls all packages from 
this .


This is not what I want. I want to remove the comps-groups from my 
system, because of the harmful effects they obviously have.


Ralf
--
___
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, repor

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

[Vít Ondruch]

Dne 21. 02. 24 v 18:38 Jun Aruga (he / him) napsal(a):

On Wed, Feb 21, 2024 at 6:09 PM Stephen Smoogen  wrote:



On Wed, 21 Feb 2024 at 12:05, Miroslav Suchý  wrote:

Dne 21. 02. 24 v 17:38 Jun Aruga (he / him) napsal(a):

$ mock -r fedora-rawhide-x86_64 --shell



--setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3
--disableplugin=versionlock install @buildsys-build

This is suspicious. It should use DNF5 now.

What is

   rpm -qf /etc/mock/fedora-rawhide-x86_64.cfg

Since mock-core-configs-40.2-1 it should use DNF5.

That said, DNF3 should work too. But instead of hunting this bug it may be 
easier to update configs and use DNF5 that should be used anyway.


Usually when I see errors like this.. it is usually a mixed up rawhide cache 
stored somewhere.. aka something is pulling in something really old. `mock 
--clean fedora-rawhide-x86_64` usually fixes these but it may also need a local 
update first too.

Thanks for your help. I still see the same error after running the
`mock --clean fedora-rawhide-x86_64`.

```
$ mock --clean fedora-rawhide-x86_64

$ mock -r fedora-rawhide-x86_64 --shell
...
ERROR: Command failed:
  # /usr/bin/systemd-nspawn -q -M 46d4e94c6647468aa33584d8fb7d42ae -D
/var/lib/mock/fedora-rawhide-x86_64-bootstrap/root -a
--capability=cap_ipc_lock
--bind=/tmp/mock-resolv.0la37cbp:/etc/resolv.conf --console=pipe
--setenv=TERM=vt100 --setenv=SHELL=/bin/bash
--setenv=HOME=/var/lib/mock/fedora-rawhide-x86_64/root/installation-homedir
--setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin
'--setenv=PROMPT_COMMAND=printf "\033]0;\007"'
'--setenv=PS1= \s-\v\$ ' --setenv=LANG=C.UTF-8
--setenv=LC_MESSAGES=C.UTF-8 --resolv-conf=off /usr/bin/dnf-3
--installroot /var/lib/mock/fedora-rawhide-x86_64/root/ --releasever
35



Fedora 35 ^^ buildroot? Probably something to check.


Vít



  --setopt=deltarpm=False --setopt=allow_vendor_change=yes
--allowerasing --disableplugin=local --disableplugin=spacewalk
--disableplugin=versionlock install @buildsys-build
--setopt=tsflags=nocontexts
Traceback (most recent call last):
   File "/usr/bin/dnf-3", line 61, in 
 from dnf.cli import main
   File "/usr/lib/python3.12/site-packages/dnf/__init__.py", line 30, in 

 import dnf.base
   File "/usr/lib/python3.12/site-packages/dnf/base.py", line 29, in 
 import libdnf.transaction
   File "/usr/lib64/python3.12/site-packages/libdnf/__init__.py", line
14, in 
 from . import conf
   File "/usr/lib64/python3.12/site-packages/libdnf/conf.py", line 10,
in 
 from . import _conf
ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer
```



OpenPGP_signature.asc
Description: OpenPGP digital 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: Help with creating first PR for a package

[Vít Ondruch]

Dne 20. 02. 24 v 9:21 Loren M. Lang napsal(a):

On Sun, Feb 18, 2024 at 06:08:53AM -0300, Priscila Gutierres wrote:

I created this post based on my own experience:
https://dev.to/prinewgirl/a-recipe-made-to-create-your-first-pr-for-the-fedora-project-21be
Hope it helps.

Thanks, with these and an Kan-Ru's instructions, I was able to
successfully push up my changes to my fork on Pagure. However, I did
have one issue with the sources. The push initially failed with the
error:

Source file (or tarball) 'cachelib-0.12.0.tar.gz' wasn't uploaded
to the lookaside cache.

I assume that this is another restriction of not being a packager?



Yes, this is expected.

You can us `fedpkg` with `--offline` param to explicitly avoid this issue.



However, I didn't see this addressed in the provided docs. I was able to
bypass it with --no-verify, but the Fedora CI build that was triggered
when I made my Pull Request fails since it couldn't find the uploaded
sources.



Uploading sources for PR or not, that is a bit grey zone due to possible 
issue with uploading legally problematic code.





I was able to manually submit a passing CI build by pushing up the SRPM.



But having the legally problematic code in SRPM would not be any better 
I guess :)



Vít




-Loren


Em dom., 18 de fev. de 2024 às 05:32, Ondrej Mosnáček 
escreveu:


On Sun, 18 Feb 2024 at 09:23, Kan-Ru Chen  wrote:

Hi,

On Sun, Feb 18, 2024, at 10:52 AM, Loren M. Lang wrote:

I've cloned it down and worked on bringing it more up-to-date. Now that
I have something passing the test suite, I thought I'd file a PR and
start a discussion. I forked the project on Pagure.io, but found that
even with my own personal fork, I don't seem to have commit access to

it

without being in the Packagers group. Is that standard? I thought the
point of the fork was to allow non-packagers to use the PR mechanism as
an easy mechanism for sponsors to view proposals.

In any case, I decided to through it up on GitHub temporarily so I

could

at least create a Remote PR.

https://src.fedoraproject.org/rpms/python-cachelib/pull-request/6

I have recently done this. You need to use fedpkg to clone the

repository then

it will setup the hook for authentication with FAS.

For example if you have fork at `fork/penguin359/rpms/python-cachelib`

then use

this command to clone

 fedpkg clone -a forks/penguin359/rpms/python-cachelib

then in the cloned repo you can push normally.

FWIW. it is documented here:

https://docs.fedoraproject.org/en-US/ci/pull-requests/#_you_are_not_a_packager
--
___
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



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


OpenPGP_signature.asc
Description: OpenPGP digital 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: The semiannual "Transaction failed: Signature verification failed." exercise

[Vít Ondruch]

Dne 16. 02. 24 v 18:27 Kevin Fenzi napsal(a):

On Fri, Feb 16, 2024 at 09:46:05AM +0100, Vít Ondruch wrote:


Other solution could be if Rawhide lived in rawhide repos instead of f41.

I'm not sure I follow... rawhide is in a rawhide repo?

pub/fedora/linux/development/rawhide/



I stand corrected. Sorry. Not sure what I was checking.


Vít




Or did you mean to sign rawhide with a 'rawhide' key always that never
changes? Thats an option, but then there's no regular key rotation...

kevin

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: The semiannual "Transaction failed: Signature verification failed." exercise

[Vít Ondruch]

Dne 16. 02. 24 v 3:03 Kevin Fenzi napsal(a):

On Thu, Feb 15, 2024 at 07:57:37PM +, Zbigniew Jędrzejewski-Szmek wrote:

It's this time of the year again:

...

Could we please do something so that this doesn't happen?
Dunno, generate and distribute the keys earlier so that mock
and https://fedoraproject.org/fedora.gpg get updated _before_
we need it?

That won't do it. We need mock to update it's config at exactly the same
moment a successfull rawhide compose completes and mirrors to whatever
mirror you are hitting. ;(

We make keys a year ahead now. The f42 key is in fedora-release already.


I know this subject comes up approx. twice a year (or once once for F21 ;) ),
e.g. [2]. I know this can be "fixed" with some manual steps, but I posit
that this should never occur in the first place.

I guess one possible solution would be for rpm to support multiple
signatures and koji to support writing out those rpms and then we could
sign new rawhide with both keys at least for a while.



Other solution could be if Rawhide lived in rawhide repos instead of f41.


Vít




I guess I had that idea 7 years ago:
https://github.com/rpm-software-management/rpm/issues/189

Or I suppose we could move to just one key for everything, but then it
would have a larger effect if we ever had to revoke/reissue.

At the very least, perhaps mock could try and identify this problem and
note to upgrade mock-core-configs?

Dunno. I agree it's not good, but it's not easy to solve either.

kevin

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


OpenPGP_signature.asc
Description: OpenPGP digital 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: dnf-4.19.0 without filelists in Rawhide soon

[Vít Ondruch]

/usr/bin/BINARYNAME is part of the primary metadata AFAIK


Vít


Dne 14. 02. 24 v 10:49 Jan Kolarik napsal(a):

Hi Marcin,

> So no more "dnf install /usr/bin/BINARYNAME" in default setup?

In the case where a file path argument is provided to dnf, it will 
automatically attempt to download the missing filelists metadata. 
Sorry, I forgot to explicitly mention this use case.


Jan

On Wed, Feb 14, 2024 at 10:42 AM Marcin Juszkiewicz 
 wrote:


W dniu 9.02.2024 o 14:02, Jan Kolarik pisze:
> Just a heads up that a new DNF version (4.19.0) is on its way to
Rawhide
> and is expected to land within the next several hours. This update
> brings a system-wide change
> 
related
> to not downloading filelists metadata by default.

So no more "dnf install /usr/bin/BINARYNAME" in default setup?
--
___
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 todevel-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


OpenPGP_signature.asc
Description: OpenPGP digital 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

Orphaning rubygem-rest-client

[Vít Ondruch]

Hi,

I have orphaned rubygem-rest-client. It used to be dependency of Vagrant 
up until version 2.2.11. Nothing depends on it now, therefore I orphaned 
the package. There are not know issues with the package (except flaky 
test suite) and the upstream is a bit stalled.



Vít



OpenPGP_signature.asc
Description: OpenPGP digital 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