from:"Vít Ondruch"

Re: Macros stored in a separate file

2024-06-10 Thread 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

2024-06-10 Thread 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

2024-06-10 Thread 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)

2024-06-10 Thread 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

Re: Ruby in Rawhide is broken

2024-06-07 Thread Vít Ondruch


This is resolved now.


Vít


Dne 07. 06. 24 v 12:35 Vít Ondruch napsal(a):
The ruby-3.3.1-8.fc41 was untagged a while ago and now I have pushed 
fix into Ruby 3.3.2 PR:


https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/42b0e43e5a8ef84cfc2a7dcc09b0b39ad924f378 



In short, due to changes in RPM 4.20, the `%{_builddir}` macro expands 
differently on different places of RPM. I have reported this upstream:


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


Vít


Dne 06. 06. 24 v 20:11 Vít Ondruch napsal(a):

This is the problem:

~~~

... snip ...

Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No 
such file or directory.  Stop.


... snip ...

~~~


Vít


Dne 06. 06. 24 v 19:36 Vít Ondruch napsal(a):
I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and 
we don't have generated `rubygem()` provides in e.g. 
ruby-default-gems. I suspect that this might be related to RPM 4.20, 
because I am not aware of any other changes.


I have asked to untag that build 
https://pagure.io/releng/issue/12150 and investigate tomorrow.


Sorry for inconvenience


Vít



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

Re: Ruby in Rawhide is broken

2024-06-07 Thread Vít Ondruch

The ruby-3.3.1-8.fc41 was untagged a while ago and now I have pushed fix 
into Ruby 3.3.2 PR:


https://src.fedoraproject.org/fork/vondruch/rpms/ruby/c/42b0e43e5a8ef84cfc2a7dcc09b0b39ad924f378

In short, due to changes in RPM 4.20, the `%{_builddir}` macro expands 
differently on different places of RPM. I have reported this upstream:


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


Vít


Dne 06. 06. 24 v 20:11 Vít Ondruch napsal(a):

This is the problem:

~~~

... snip ...

Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such 
file or directory.  Stop.


... snip ...

~~~


Vít


Dne 06. 06. 24 v 19:36 Vít Ondruch napsal(a):
I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and 
we don't have generated `rubygem()` provides in e.g. 
ruby-default-gems. I suspect that this might be related to RPM 4.20, 
because I am not aware of any other changes.


I have asked to untag that build https://pagure.io/releng/issue/12150 
and investigate tomorrow.


Sorry for inconvenience


Vít



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

Re: [Rpm-maint] [rpm-software-management/rpm] `%{_builddir}` has different values in different contexts (Issue #3151)

2024-06-07 Thread Vít Ondruch

> Hmm, except that %{builddir} gets only defined now after parsing the preamble 
> and specs commonly put most of their macros there, so it's not perhaps ideal 
> just now.

Just FTR, because `%{builddir}` is defined later, it also might serve as a 
workaround. Just tried that.

But I'll likely go with `%define` / `%{_builddir}`, because it has better 
backward compatibility if I am not mistaken.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3151#issuecomment-2154550735
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Enabling RPM based sysuser handling

2024-06-07 Thread 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-maint] [rpm-software-management/rpm] `%{_builddir}` has different values in different contexts (Issue #3151)

2024-06-07 Thread Vít Ondruch

> The real issue here is using %global.

Experimenting with `%define` was my next step. Thank you for confirming.

> Hmm. Maybe, maybe we could actually work around this by undefining 
> %{_builddir} for the early spec parse.

If the `%{_builddir}` macro was not defined at that stage, it would be likely 
easier to identify.

I am also unsure if I am supposed to use `%{builddir}` instead of the 
`%{_builddir}`

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3151#issuecomment-2154370991
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] `%{_builddir}` has different values in different contexts (Issue #3151)

2024-06-07 Thread Vít Ondruch

**Describe the bug**

In ruby.spec, we are using `%{_builddir}` on several places. E.g. 
[here](https://src.fedoraproject.org/rpms/ruby/blob/677893973e5e3cac2a1eb8a691aad6f5feccf69c/f/ruby.spec#_977-978):

~~~
# Check RubyGems version.
[ "`make -C %{_vpath_builddir} -s runruby 
TESTRUN_SCRIPT='%{_builddir}/%{buildsubdir}/bin/gem -v' | tail -1`" == 
'%{rubygems_version}' ]
~~~

which expands to

~~~
++ make -C redhat-linux-build -s runruby 
'TESTRUN_SCRIPT=/builddir/build/BUILD/ruby-3.3.1-build/ruby-3.3.1/bin/gem -v'
++ tail -1
+ '[' 3.5.9 == 3.5.9 ']'
~~~

But also on other places, such as [local generator 
setup](https://src.fedoraproject.org/rpms/ruby/blob/677893973e5e3cac2a1eb8a691aad6f5feccf69c/f/ruby.spec#_242-245):

~~~
%global __local_generator_requires make -C 
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby 
TESTRUN_SCRIPT="--enable-gems %{SOURCE9}"
%global __local_generator_provides make -C 
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby 
TESTRUN_SCRIPT="--enable-gems %{SOURCE10}"
%global __local_generator_conflicts make -C 
%{_builddir}/%{buildsubdir}/%{_vpath_builddir} -s runruby 
TESTRUN_SCRIPT="--enable-gems %{SOURCE11}"
%global __local_generator_path ^%{gem_dir}/specifications/.*\.gemspec$
~~~

However, this expands differently and results in errors:

~~~
Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such file or 
directory.  Stop.
~~~

The full logs can be found 
[here](https://koji.fedoraproject.org/koji/buildinfo?buildID=2461729)

**Expected behavior**
The `%{_builddir}` is consistent.

**Environment**
rpm-4.19.91-8.fc41.x86_64


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3151
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Ruby in Rawhide is broken

2024-06-06 Thread Vít Ondruch


This is the problem:

~~~

... snip ...

Processing files: ruby-default-gems-3.3.1-8.fc41.noarch
make: *** /builddir/build/BUILD/ruby-3.3.1/redhat-linux-build: No such 
file or directory.  Stop.


... snip ...

~~~


Vít


Dne 06. 06. 24 v 19:36 Vít Ondruch napsal(a):
I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and 
we don't have generated `rubygem()` provides in e.g. 
ruby-default-gems. I suspect that this might be related to RPM 4.20, 
because I am not aware of any other changes.


I have asked to untag that build https://pagure.io/releng/issue/12150 
and investigate tomorrow.


Sorry for inconvenience


Vít



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

Ruby in Rawhide is broken

2024-06-06 Thread Vít Ondruch

I have just noticed, that Ruby in Rawhide got broken with 
ruby-3.3.1-8.fc41. It seems that generators do not work properly and we 
don't have generated `rubygem()` provides in e.g. ruby-default-gems. I 
suspect that this might be related to RPM 4.20, because I am not aware 
of any other changes.


I have asked to untag that build https://pagure.io/releng/issue/12150 
and investigate tomorrow.


Sorry for inconvenience


Vít



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

Re: [Rpm-maint] [rpm-software-management/rpm] Is there a schortcut for `%ifarch`? (Discussion #3141)

2024-06-04 Thread Vít Ondruch

That is neat. Thx 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3141#discussioncomment-9662988
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Is there a schortcut for `%ifarch`? (Discussion #3141)

2024-06-04 Thread Vít Ondruch

Currently, I have this block:

~~~
%ifarch x86_64 i686
%define arch_fortification_checks fortified="11" fortify-able="28"
%elifarch aarch64
%define arch_fortification_checks fortified="10" fortify-able="26"
%elifarch ppc64le
%define arch_fortification_checks fortified="7"  fortify-able="24"
%elifarch s390x
%define arch_fortification_checks fortified="10" fortify-able="24"
%endif
~~~

Is there a trick to make this ^^ shorter and more readable? E.g. something like 
this:

~~~
%define arch_fortification_checks fortified="11" fortify-able="28" %ifarch 
x86_64 i686
%define arch_fortification_checks fortified="10" fortify-able="26" %ifarch 
aarch64
%define arch_fortification_checks fortified="7"  fortify-able="24" %ifarch 
ppc64le
%define arch_fortification_checks fortified="10" fortify-able="24" %ifarch s390x
~~~

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3141
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: RPM_* env variables vs macros

2024-06-04 Thread 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

RPM_* env variables vs macros

2024-06-04 Thread 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

Re: Heads-up: rpm 4.20 alpha in rawhide + rough waters

2024-05-31 Thread Vít Ondruch

Dne 31. 05. 24 v 4:59 Mamoru TASAKA napsal(a):

Hello, ruby-sig f

Panu Matilainen wrote on 2024/05/29 21:31:

Folks, rpm 4.20 alpha landed in rawhide today, and with the sheer
amount of change that went into the bowels of the build code, this
process is being rougher than usual. Apologies for the disruption and
the late heads-up.

Please file bugs with low bar to entry if you suspect an rpmbuild
regression. It's better to have false positives than silent bugs or
people working around the wrong things etc.

So far we're aware of:

- GenericError: srpm mismatch on subpackage debuginfo (so not any
debuginfo, only subpackage debuginfo), is an rpm regression and we're
working on a fix (see the other thread for more details)

- java/mvn package fail on test-related paths
https://bugzilla.redhat.com/show_bug.cgi?id=2283795, this is not a
regresion but an intended change in the rpm build paths layout where
all builds now have a their own specific build-directory whether they
use %setup or not.

The build directory layout change is something the vast majority of
packages will never notice, but packages manipulating paths relative
to "raw" %{_builddir} *may* need to be adjusted.

So again, if in doubt at all, ask or just file a bug.

So now I tried rebuilding all rubygem-foo packages, and one additional
package

is now FTBFS.

* rubygem-abrt

```
Failures:

1) ABRT #handle_exception logs error into syslog when can't
communicate with ABRT daemon because no-one is listeing on the other side
Failure/Error: expect(syslog).to receive(:err).with("%s", /can't
communicate with ABRT daemon, is it running\? Connection refused -(
connect$2$ for)? "?#{socket_path}"?/)

# received :err with unexpected arguments
expected: ("%s", /can't communicate with ABRT daemon, is it
running\? Connection refused -( connect$2$ for)?
"?\/bui...ygem-abrt-0.4.0-build\/abrt-0.4.0\/usr\/share\/gems\/gems\/abrt-0.4.0\/spec\/abrt_handler_spec.rb"?/)
got: ("%s", "can't communicate with ABRT daemon, is it
running? too long unix socket path (114bytes given but 108bytes max)")

Diff:
@@ -1,3 +1,3 @@
["%s",
- /can't communicate with ABRT daemon, is it running\?
Connection refused -( connect$2$ for)?
"?\/builddir\/build\/BUILD\/rubygem-abrt-0.4.0-build\/abrt-0.4.0\/usr\/share\/gems\/gems\/abrt-0.4.0\/spec\/abrt_handler_spec.rb"?/]
+ "can't communicate with ABRT daemon, is it running? too long
unix socket path (114bytes given but 108bytes max)"]
# ./spec/abrt_handler_spec.rb:140:in `block (5 levels) in (required)>'

```

So looks line %_builddir got longer than before, and the total path
length for socket now exceeds the limitation:

https://man7.org/linux/man-pages/man7/unix.7.html

I had to check the current century in my calendar 臘‍♂️ Thx for
spotting this. I'll try to take a look, although not my highest priority
ATM.

Vít

Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue

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

Re: [Rpm-maint] [rpm-software-management/rpm] Existing package not found (Issue #3132)

2024-05-28 Thread Vít Ondruch

`Available` != installed

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3132#issuecomment-2135515482
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Fedora Elections - Voting is now open!

2024-05-22 Thread 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!

2024-05-22 Thread 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!

2024-05-21 Thread 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!

2024-05-21 Thread 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

2024-05-21 Thread 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!

2024-05-21 Thread 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

2024-05-17 Thread 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

2024-05-16 Thread 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

2024-05-15 Thread 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

2024-05-15 Thread 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?

2024-05-15 Thread 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

2024-05-15 Thread 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

2024-05-14 Thread 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

2024-05-14 Thread 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

2024-05-14 Thread 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: [Rpm-maint] [rpm-software-management/rpm] Dynamic generator generates "invalid" srpm (Issue #3096)

2024-05-14 Thread Vít Ondruch

I have used "valid" in a sense that I would not be allowed to create SRPM 
without e.g. summary. So apparently, this does not use the same code paths 
which is concerning.

Also, when I saw the test case in 
https://github.com/rpm-software-management/rpm/commit/5d288554719095d1c67fd87cad65224743152d06,
 I though that would allow to have different preamble between SRPM / RPM, which 
would be nice (see #3046). But if that is not the case, I would rather if the 
possibility to generate the main package preamble was dropped, because 
otherwise it provides confusing results. And TBH, the test case with defining 
some macro is very artificial.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3096#issuecomment-2109476389
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Dynamic generator generates "invalid" srpm (Issue #3096)

2024-05-13 Thread Vít Ondruch

~~~
$ curl -OL 
https://github.com/rpm-software-management/rpm/raw/master/tests/data/SPECS/dynamic.spec
  % Total% Received % Xferd  Average Speed   TimeTime Time  Current
 Dload  Upload   Total   SpentLeft  Speed
  0 00 00 0  0  0 --:--:-- --:--:-- --:--:-- 0
100  1695  100  16950 0   3367  0 --:--:-- --:--:-- --:--:--  3367

# rpmbuild -D "_sourcedir ." -D "_srcrpmdir ." -D "FULLDYNAMIC 1" -bs 
dynamic.spec dynamic.spec
setting SOURCE_DATE_EPOCH=1666569600
Wrote: ./dynamic-1.0-1.src.rpm
Wrote: ./dynamic-1.0-1.src.rpm

$ rpm -q --info dynamic-1.0-1.src.rpm 
Name: dynamic
Version : 1.0
Release : 1
Architecture: noarch
Install Date: (not installed)
Group   : (none)
Size: 1695

Signature   : (none)
Source RPM  : (none)
Build Date  : Mon May 13 18:20:44 2024
Build Host  : fedora
Summary : (none)
Description :
Simple rpm demonstration.
~~~

I don't think it would be possible to generate RPM without e.g. `Summary`. It 
also differs to SRPM generated with `-ba`, which contains the summary just fine:

~~~
$ rpm -q --info dynamic-1.0-1.src.rpm 
Name: dynamic
Version : 1.0
Release : 1
Architecture: noarch
Install Date: (not installed)
Group   : Utilities
Size: 1695
License : GPL
Signature   : (none)
Source RPM  : (none)
Build Date  : Mon May 13 18:22:44 2024
Build Host  : fedora
URL : http://rpm.org
Summary : dynamic hello -- hello, world rpm
Description :
Simple rpm demonstration.

~~~



-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3096
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Smaller buildroot for Perl packages

2024-05-13 Thread 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

2024-05-13 Thread 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

2024-05-13 Thread 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

2024-05-13 Thread 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

2024-05-13 Thread 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

2024-05-13 Thread 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.fedoraproject.org/archives/list/devel@lis

Re: Mass Package Change: Turn deprecated %patchN syntax into %patch -PN

2024-05-13 Thread 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?

2024-05-13 Thread 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

2024-05-10 Thread 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

Ruby updates

2024-04-25 Thread Vít Ondruch


Hi everybody,

I have created updates for Ruby in all Fedoras. The Ruby 3.3.1 has 
already landed and here are Bodhi links for the older releases:


https://bodhi.fedoraproject.org/updates/FEDORA-2024-14db7b21a2

https://bodhi.fedoraproject.org/updates/FEDORA-2024-31cac8b8ec

https://bodhi.fedoraproject.org/updates/FEDORA-2024-48bdd3abbf

I am sending heads up here, because yesterday there were complains about 
regressions. There might be issue with 3.3.1 with Bootsnap [1] and some 
complains about Fiddle broken build with 3.1.5 [2]. But the latter lack 
details and the build of Fiddle as shipped with Ruby went just fine.


Please give it and try and provide feedback either via Bohdi or here.


Vít



[1] https://bugs.ruby-lang.org/issues/20450

[2] https://bugs.ruby-lang.org/issues/20451



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

Re: Plan to update rubygem-json to 2.7.3

2024-04-19 Thread Vít Ondruch

Thanks for the heads up. I assume you are going to land this just for 
Rawhide, right? And we should also watch Ruby. So far, there is 2.7.2 in 
master and 2.7.1 in Ruby 3.3.



Checking Rails, there seems to be some patches around such as:

https://github.com/rails/rails/pull/51510


For Rspec-rails, these might be the changes:

https://github.com/rspec/rspec-rails/pull/2754

https://github.com/rspec/rspec-rails/pull/2755


Checking Haml / Pundit, they seems to be using OpenStruct just in their 
test suites.



Vít


Dne 19. 04. 24 v 10:31 Mamoru TASAKA napsal(a):

Hello, ruby-sig folks:

I am going to update rubygem-json to 2.7.3 *some day* (when I have 
enough time).


What is preventing me from doing it now is that due to json change 
that now
json makes OpenStruct support (dependency) optional, it causes the 
following

packages FTBFS:

rubygem-actionmailer
rubygem-actionpack
rubygem-actionview
rubygem-haml
rubygem-pundit
rubygem-rspec-rails

c.f.
https://github.com/flori/json/pull/565
https://github.com/flori/json/issues/579

json upstream now requests the each packge to add `require "ostruct"`, so
I am going to apply this change to the above packages (when I have 
enough time).


Regards,
Mamoru
--
___
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


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

[Rpm-maint] [rpm-software-management/rpm] Is there a way to detect `SRPM` / `RPM` build? (Discussion #3046)

2024-04-17 Thread Vít Ondruch

Looking at the dynamic spec, specifically at 
5d288554719095d1c67fd87cad65224743152d06, it is silly that the `FULLDYNAMIC` is 
external information. If it was possible to distinguish the `SRPM` / `RPM` 
build, it would be more interesting. E.g. if there was `_srpm_build` macro 
defined during the SRPM build, this could be immediately interesting:

~~~diff
$ git diff
diff --git a/dynamic.spec b/dynamic.spec
index d46a5c4..f86de2e 100644
--- a/dynamic.spec
+++ b/dynamic.spec
@@ -2,12 +2,12 @@ Name: dynamic
 Version: 1.0
 Release: 1
 BuildArch: noarch
-%{?!FULLDYNAMIC:
+%{?_srpm_build:
 Group: Utilities
 License: GPL
 Distribution: RPM test suite.
 URL: http://rpm.org
-Summary: dynamic hello -- hello, world rpm
+Summary: source dynamic hello -- hello, world rpm
 }
 
 %description
@@ -23,13 +23,11 @@ echo "Q: Why?\nA: Because we can!" > FAQ
 mkdir -p $RPM_BUILD_ROOT/usr/local/bin
 echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello
 
-%{?FULLDYNAMIC:
 echo "Group: Utilities" >> %{specpartsdir}/mainpkg.specpart
 echo "License: GPL" >> %{specpartsdir}/mainpkg.specpart
 echo "Distribution: RPM test suite." >> %{specpartsdir}/mainpkg.specpart
 echo "URL: http://rpm.org; >> %{specpartsdir}/mainpkg.specpart
-echo "Summary: dynamic hello -- hello, world rpm" >> 
%{specpartsdir}/mainpkg.specpart
-}
+echo "Summary: binary dynamic hello -- hello, world rpm" >> 
%{specpartsdir}/mainpkg.specpart
 
 echo "%package docs" >> %{specpartsdir}/docs.specpart
 %{?!FAIL:echo "Summary: Documentation for dynamic spec" >> 
%{specpartsdir}/docs.specpart}
~~~

So is there a way to detect the SRPM build?

BTW does this feature enable to build SRPM without the `Summary` / `License` 
information? Is that intentional?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/3046
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Dynamic spec for main package does not work (Issue #3038)

2024-04-17 Thread Vít Ondruch

Ah, right, there is rpm-4.20.0-alpha tag. I was somehow under impression that 
this should have been already in Rawhide. Sorry for the noise.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3038#issuecomment-2061313183
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Dynamic spec for main package does not work (Issue #3038)

2024-04-15 Thread Vít Ondruch

**Describe the bug**

Trying to reproduce the test case from 5d288554719095d1c67fd87cad65224743152d06 
it fails for me:

**To Reproduce**
Steps to reproduce the behavior:
1. 
~~~
$ cat SPECS/dynamic.spec 
Name: dynamic
Version: 1.0
Release: 1
BuildArch: noarch
%{?!FULLDYNAMIC:
Group: Utilities
License: GPL
Distribution: RPM test suite.
URL: http://rpm.org
Summary: dynamic hello -- hello, world rpm
}

%description
Simple rpm demonstration.

%prep
%setup -q -T -c

%build
echo "Q: Why?\nA: Because we can!" > FAQ

%install
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
echo " " > $RPM_BUILD_ROOT/usr/local/bin/hello

%{?FULLDYNAMIC:
echo "Group: Utilities" >> %{specpartsdir}/mainpkg.specpart
echo "License: GPL" >> %{specpartsdir}/mainpkg.specpart
echo "Distribution: RPM test suite." >> %{specpartsdir}/mainpkg.specpart
echo "URL: http://rpm.org; >> %{specpartsdir}/mainpkg.specpart
echo "Summary: dynamic hello -- hello, world rpm" >> 
%{specpartsdir}/mainpkg.specpart
}

echo "%package docs" >> %{specpartsdir}/docs.specpart
%{?!FAIL:echo "Summary: Documentation for dynamic spec" >> 
%{specpartsdir}/docs.specpart}
echo "BuildArch: noarch" >> %{specpartsdir}/docs.specpart
echo "%description docs" >> %{specpartsdir}/docs.specpart
echo "Test for dynamically generated spec files" >> 
%{specpartsdir}/docs.specpart
echo "%files docs" >> $RPM_SPECPARTS_DIR/docs.specpart
echo "%doc  FAQ" >> $RPM_SPECPARTS_DIR/docs.specpart

%files
%defattr(-,root,root)
%attr(0751,root,root)   /usr/local/bin/hello

%changelog
* Mon Oct 24 2022 Florian Festi 
- create.
~~~

2.
~~~
$ rpmbuild -D "FULLDYNAMIC 1" -ba SPECS/dynamic.spec 
error: Summary field must be present in package: (main package)
error: License field must be present in package: (main package)
~~~

**Expected behavior**
The test above passes and can build binary RPMs

**Environment**
 - OS / Distribution: Fedora Rawhide
 - Version: rpm-4.19.1.1-1.fc40.x86_64

**Additional context**
This makes me wonder if the test case is correct and if it does not test output 
of other command by accident.

In any case, the test does not try to test the header, it keeps testing the 
-docs. That does not seem to be right.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3038
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Meta programming in .spec using Lua, is it heresy? (Discussion #2969)

2024-04-15 Thread Vít Ondruch

This would actually address #1225

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2969#discussioncomment-9119090
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: F41 Change Proposal - Reproducible Package Builds (System-Wide)

2024-04-15 Thread 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)

2024-04-15 Thread 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

2024-04-15 Thread 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?

2024-04-10 Thread 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

2024-04-09 Thread 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

2024-04-09 Thread 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?

2024-04-09 Thread 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)

2024-04-05 Thread 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)

2024-04-04 Thread 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

2024-04-02 Thread 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

2024-04-02 Thread 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

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for bare `%package` (Discussion #2959)

2024-04-01 Thread Vít Ondruch

I don't know anything about Debian, but yes, having binary package of different 
name is one of the motivations. But to me, this is  optional depending if this 
scenario was supported.

Nonetheless, I think that being able to define subpackages before preamble is 
beneficial on itself and it would help to remove hacks such as:

https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/b7d1bfae1fb673c4d8a21a8866ba4e37b2cd6eaf/f/common.lua#_217-235

(and it does not mean that I necessarily defend purpose and implementation of 
those macros)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8975559
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Allow comments after conditionals (PR #2996)

2024-03-27 Thread Vít Ondruch

Ah, ok, so this works, but not for the `%endif`. I cannot say I grasped it from 
the documentation update :/

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022749958
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Allow comments after conditionals (PR #2996)

2024-03-27 Thread Vít Ondruch

> > `%dnl` already works for this purpose, doesn't it?
> 
> It doesn't, because this check happens before macro expansion.

This fails:

~~~
$ cat license-subpackages.spec
Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1%{?dist}
License: BSD-3-Clause AND MIT

%description
Using Lua and "metaprograming", it is possible to do magic with .spec files
such as collecting licenses from subpackages.


%if 0 # comment
%package foo
Summary: foo subpackage
License: BSD-3-Clause

%description foo
This foo subpackage

%files foo
%endif


%changelog
* Wed Mar 13 2024 Vít Ondruch 
- Initial version

$ fedpkg --release f41 srpm
Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
error: parse error in expression:  0 # comment
error:   ^
error: /home/vondruch/license-subpackages/license-subpackages.spec:12: bad %if 
condition:  0 # comment
error: query of specfile 
/home/vondruch/license-subpackages/license-subpackages.spec failed, can't parse

Could not execute srpm: Could not get n-v-r-e from 
/home/vondruch/license-subpackages/license-subpackages.spec

$ rpm -q rpm
rpm-4.19.1.1-1.fc40.x86_64
~~~

While this passes:

~~~
$ diff -u license-subpackages.spec{.orig,}
--- license-subpackages.spec.orig   2024-03-27 14:05:58.511376998 +0100
+++ license-subpackages.spec2024-03-27 14:06:05.735409184 +0100
@@ -9,7 +9,7 @@
 such as collecting licenses from subpackages.
 
 
-%if 0 # comment
+%if 0 %dnl # comment
 %package foo
 Summary: foo subpackage
 License: BSD-3-Clause
~~~

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022727660
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Allow comments after conditionals (PR #2996)

2024-03-27 Thread Vít Ondruch

`%dnl` already works for this purpose, doesn't it?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2996#issuecomment-2022331640
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Cumulative `License` field (Discussion #2892)

2024-03-27 Thread Vít Ondruch

Just realized that one problem is that RPM knows nothing about the actual 
content of the `License` tag, therefore it would not be easy to "just merge 
them" into single field, if needed.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2892#discussioncomment-8925584
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [SPDX] Mass license change: Intro and change of "Bitstream Vera" to "Bitstream-Vera"

2024-03-27 Thread 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)

2024-03-26 Thread 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

Re: F41 Change Proposal: Switch to DNF 5 (System-Wide)

2024-03-25 Thread 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: [Rpm-maint] [rpm-software-management/rpm] `define(name, body)` documentation does not align with implementation (Issue #2962)

2024-03-20 Thread Vít Ondruch

For the context, I have stumbled upon this issue playing with #2969 and my 
initial idea was to assign the whole macro body including the new lines to some 
macro with some specifically crafted name. But I was not able to achieve that 
no matter what and resorted to use variables (which is probably good enough 
variant).

It is my feeling that for whatever reason defining macro in Lua is limited 
comparing to plain .spec file, not being able to insert new line there. But 
maybe I have just not figured out the right amount of backslashes or what not.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-2010097636
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Add support for bare `%package` (Discussion #2959)

2024-03-19 Thread Vít Ondruch

I wish you could elaborate more. From your answer, I am not able to deduce

1. If you like / not like the idea if you were free from current implementation
2. What it would take to change the implementation
3. If there are any hopes or not

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2959#discussioncomment-8841037
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] rpmbuild should error out on conflicting %exclude directive (Issue #2952)

2024-03-18 Thread Vít Ondruch

I have not really wanted to suggest this should be prohibited / reported as an 
error.

But since duplicates are already detected and reported, reporting this would be 
in line with that and possibly prevented possible surprises, so that is 
acceptable.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2004027197
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] %exclude is too strong (Issue #2952)

2024-03-18 Thread Vít Ondruch

> the only reasonable course of action is erroring out.

Shall I open separate ticket?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952#issuecomment-2003741467
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Meta programming in .spec using Lua, is it heresy? (Discussion #2969)

2024-03-13 Thread Vít Ondruch

I am playing with ideas such as #2959 or #2892 and here is a proposal how to 
achieve that (and much more). This could be the .spec file:

~~~rpm-spec
%define subpackage() %{lua:
subpackage = arg[1]

subpackage_name = subpackage:match("\\n%%package%s*([^\\n]*)")

if subpackages == nil then
  subpackages = {}
end

subpackages[subpackage_name] = subpackage

if licenses == nil then
  licenses = {}
end

licenses[subpackage_name] = subpackage:match("\\nLicense:%s*([^\\n]*)")
}

%define subpackages() %{lua:
for k in pairs(subpackages) do
  print(rpm.expand(subpackages[k]))
end
}

%define licenses() %{lua:
local license = arg[1]

for k in pairs(licenses) do
  l = licenses[k]

  if l then
license = license .. " AND " .. l
  end
end

print(license)
}

%{subpackage:
%package foo
Summary: foo subpackage
License: BSD

%description foo
This random subpackage

%files foo
}


Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1%{?dist}
License: %{licenses:MIT}

%description
Using Lua and "metaprograming", it is possible to do magic with .spec files
such as collecting licenses from subpackages.

%{subpackages}

%changelog
* Wed Mar 13 2024 Vít Ondruch 
- Initial version
~~~

The SRPM would look like this:

~~~
$ rpm -qp --qf "%{SPEC}" license-subpackages-1-1.fc41.src.rpm









Summary: Demonstration package for mining licenses from subpackages
Name: license-subpackages
Version: 1
Release: 1.fc41
License: MIT AND BSD

%description
Using Lua and "metaprograming", it is possible to do magic with .spec files
such as collecting licenses from subpackages.


%package foo
Summary: foo subpackage
License: BSD

%description foo
This random subpackage

%files foo


%changelog
* Wed Mar 13 2024 Vít Ondruch 
- Initial version
~~~

I can imagine quite a lot more done with something similar. This trick could be 
used to enable/disable subpackages at will. If there were requires/provides, 
they could be adjusted for systems such as SCL. Is there some functionality or 
tag which RPM does not support (yet?), no problem to implement it in such macro.

Is this going too far?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2969
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Lua equivalent to `%{echo:...}` and similar (Discussion #2968)

2024-03-13 Thread Vít Ondruch

Yes, I don't argue with that. But output from Lua to terminal is useful and 
would IMHO deserve some separate note.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2968#discussioncomment-8772227
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Lua equivalent to `%{echo:...}` and similar (Issue #2967)

2024-03-13 Thread Vít Ondruch

TBH figuring out `rpm.expand("%{echo: some output}")` is also not that straight 
forward. I was able to find such example at least.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2967#issuecomment-1994195978
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Lua equivalent to `%{echo:...}` and similar (Issue #2967)

2024-03-13 Thread Vít Ondruch

Oh. Interesting, the for the tip  Nevertheless, I was not able to figure that 
out myself, therefore it would deserve to be documented if that is the right 
approach.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2967#issuecomment-1994192617
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Lua equivalent to `%{echo:...}` and similar (Issue #2967)

2024-03-13 Thread Vít Ondruch

Currently the way to get some information from Lua macro is quite clumsy. One 
needs to do something like:

~~~
%define foo() %{lua:
  rpm.expand("%{echo: some output}")
}
~~~

Would it be possible to make it easier, e.g. something like this would be more 
convenient:
~~~
%define foo() %{lua:
  rpm.echo("some output")
}
~~~

Or maybe just:

~~~
%define foo() %{lua:
  echo("some output")
}
~~~

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2967
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] `define(name, body)` documentation is incorrect (Issue #2962)

2024-03-12 Thread Vít Ondruch

IOW this is what the heading says:
~~~
$ rpm -E "%{lua:rpm.define('foo', '1')}" -E "%foo"
error: Macro %foo has empty body
error: lua script failed: [string ""]:1: error defining macro
~~~

but this is how it actually works:

~~~
$ rpm -E "%{lua:rpm.define('foo 1')}" -E "%foo"

1
~~~

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2962#issuecomment-1991262402
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] `define(name, body)` documentation is incorrect (Issue #2962)

2024-03-12 Thread Vít Ondruch

This line is incorrect IMHO:

https://github.com/rpm-software-management/rpm/blob/689f1d8d3ef4fcba4b4d05160cb5063b8ac11310/docs/manual/lua.md?plain=1#L120

It should actually be something like `define(name_body)`. This example actually 
seems to be correct:

https://github.com/rpm-software-management/rpm/blob/689f1d8d3ef4fcba4b4d05160cb5063b8ac11310/docs/manual/lua.md?plain=1#L128

But in any case, it would make more sense if the header was correct. Why it 
does not work like this?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2962
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Add support for bare `%package` (Discussion #2959)

2024-03-11 Thread Vít Ondruch

Could there be added support for bare `%package`, without any argument or 
option? Several reasons I can think of.

1) Having plain `%description` / `%files` without its `%package` counterpart is 
asymmetric
2) Having bare `%package` somewhere in the .spec file could allow to use the 
original preamble (if present) just in SRPM context.
3) Having bare `%package` would allow to place the main package declaration 
freely in .spec file.

The third point is actually my original motivation related to #2892. I believe 
that if I replaced the `License:` tags by some macro, I could likely accumulate 
the licenses and use them in the `%package` which would be listed as last. This 
in turn would likely allowed me to conditionalize the sub-package existence.

IOW the most naive (and incomplete) example could look like this:

~~~rpm-spec
%package libs
Summary: foo-libs

%description libs
foo-libs description

%package
Summary: foo
Name: foo
Version: 1
Release: 1%{?dist}
License: MIT

%description
foo description

%files

%files libs

%changelog
~~~


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2959
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Indentation support for tags (Issue #2927)

2024-03-11 Thread Vít Ondruch

Just FTR, I keep asking because example like this:

https://src.fedoraproject.org/rpms/nodejs20/blob/3391b85e233fb582fff9471c23788df5ad582d21/f/nodejs20.spec#_156-162

What could be nested here if the PR was accepted?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988728668
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Indentation support for tags (Issue #2927)

2024-03-11 Thread Vít Ondruch

> The situation wrt other sections is a bit more complicated. RPM itself does 
> not really support indentation in most. Instead for most sections (scripts 
> and scriptlets) it just does macro expansion and `#if` magic and then hands 
> the result to some interpreter - or sticks it into a tag to be handed to an 
> interpreter later. So basically each section has it's own syntax. E.g. 
> `%sources` and `%patches` will happily add any indentation to the front of 
> the file name. So we are talking about the Preamble here only.

Yes, section content is section content. But I think that this is not possible: 
` %description` (note the space before `%`):

~~~
error: line 101: Unknown tag:  %description
~~~

and I might be wrong, but I don't see this supported by the PR. Or at least I 
can't see this covered by test case.

Also I am not sure how the ` %package foo` would work. RPM does not report any 
error ATM and I suspect that such line is assumed to be part of earlier 
`%description` in my case, because adding `%description foo` afterwards, I 
receive error:

~~~
error: line 106: %description foo: package newpackage-foo does not exist
~~~

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988711676
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Indentation support for tags (Issue #2927)

2024-03-11 Thread Vít Ondruch

If the nesting for preamble was allowed, would be nestable also other sections, 
such as `%describtion`, `%pre`, etc?

BTW this change would break at minimum Vim syntax highlighter.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988628252
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Indentation support for tags (Issue #2927)

2024-03-11 Thread Vít Ondruch

> Not sure why your personal taste would have any weight in this discussion

Maybe because you value community feedback?

> Neither does this change require proper nesting from anyone

Actually RPM requires proper nesting now (no nesting) and it is mostly fine. 
Allowing nesting will open the discussion about proper nesting, if it should be 
e.g. 2 spaces or single tab etc. It will motivate people to adjust nesting by 
conditions, making diffs bigger.

No choice is sometimes better.

> nor is white space disallowed in these macro expressions (as one can easily 
> check with `rpm -E`).

Not everything can be tested by `rpm -E` probably:

~~~
$ rpmbuild -D "_sourceddir ." -D "_srpmdir ." -bs newpackage.spec
setting SOURCE_DATE_EPOCH=1705363200
Wrote: /home/vondruch/rpmbuild/SRPMS/newpackage-1-1.fc41.src.rpm
~~~

vs:

~~~
$ rpmbuild -D "_sourceddir ." -D "_srpmdir ." -bs newpackage.spec.space
error: line 150: Unknown tag:  BuildRequires: foo
~~~

and this is the difference:

~~~
$ diff -u newpackage.spec{,.space}
--- newpackage.spec 2024-03-11 14:59:41.476458832 +0100
+++ newpackage.spec.space   2024-03-11 14:59:37.510442485 +0100
@@ -147,7 +147,7 @@
 Version: 1
 Release: 1%{?dist}
 License: MIT
-%{!?foo:BuildRequires: foo}
+%{!?foo: BuildRequires: foo}
 
 %description
 
~~~



-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988523363
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Indentation support for tags (Issue #2927)

2024-03-11 Thread Vít Ondruch

I am against this request. The .spec file is not exactly easy to parse and this 
won't improve the situation. Also, it is kind of relieving that I don't have to 
bother with "proper" nesting inside conditionals.

BTW what is the impact on the shorthand such as:

~~~
{?suse_version:Requires: xdotool}
{!?suse_version:Requires: libxdo}
~~~

I think the space is currently not allowed in this construct

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2927#issuecomment-1988213113
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] %exclude is too strong (Issue #2952)

2024-03-08 Thread Vít Ondruch

Given this .spec file:

~~~rpm-spec
Summary: summary
Name: newpackage
Version: 1
Release: 1%{?dist}
License: MIT

%description

%install
mkdir -p %{buildroot}%{_tmppath}
echo "foo" > %{buildroot}%{_tmppath}/f

%files
%exclude %{_tmppath}/f
%{_tmppath}/f

%changelog
* Tue Jan 16 2024 Vít Ondruch 
- newpackage
~~~

where the file is excluded first and included later, I'd expect that the file 
will be included in the package, but that is not the case:

~~~
$ rpm -qpl 
/var/lib/mock/fedora-rawhide-x86_64/result/newpackage-1-1.fc40.x86_64.rpm 
(contains no files)
~~~

Please note that I have faced the issue when I was trying to remove some 
subpackages, but keep the files section as similar to the original state as 
possible.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2952
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Review swap

2024-03-06 Thread 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: [Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)

2024-03-06 Thread Vít Ondruch

We agree that at some point, it is good idea to forcefully remove some package 
from a system. We know how to remove the package from the system, when it is 
removed from repository using e.g. 
[fedora-obsolete-packages](https://src.fedoraproject.org/rpms/fedora-obsolete-packages).
 The method could certainly be improved, but it works. But the [assertion 
was](https://src.fedoraproject.org/rpms/fedora-obsolete-packages/pull-request/86#comment-186335):

_"So since Fedora wants to preserve installed packages on system upgrade, even 
if they are not available in the new release, straight obsoleting is not the 
correct action. And if a package needs to be obsoleted is not necessarily known 
at orphaning or retirement time."_

I see two options to help with this situation.

1) Improve metadata in RPM, because we can predict that if package not being 
maintained anymore, depending e.g. on `libruby.so.3.2()(64bit)` should be 
removed as soon and such provide is not available.
2) Improve process to collect appropriate metadata in fedora-obsolete-packages. 
Currently the process is "Lets ask users on ML for upgrade problems". We could 
possibly do better.

In any case, the purpose of this discussion is to focus on (1), i.e. is there 
something what RPM could do to help remove broken packages at the right moment? 
Because it is simply not surprise that e.g. `libruby.so.3.2()(64bit)` won't be 
available one day.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8690792
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)

2024-03-05 Thread Vít Ondruch

Well, maybe. But that would be certainly task for DNF.

Although I still believe that some people prefer to keep the removed packages 
around as long as possible. Maybe even longer, but then they could possible 
exclude those from transaction.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682165
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)

2024-03-05 Thread Vít Ondruch

What the fedora-obsolete-packages can do is to remove such package immediately. 
But that is not strictly needed. It is needed only when the ABI is broken.

I would like to have something like:

`Obsoletes: rubygem-byebug unless libruby.so.3.2()(64bit)`

or:

`Obsoletes: rubygem-byebug if its-dependencies-can't-be-satisfied-anymore`

Something like "soft obsolete", which would keep the package around as long as 
it is not objectively broken, no matter what is in repository (because 
repository is not the thing for RPM).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8682031
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)

2024-03-05 Thread Vít Ondruch

Yes, the package is precondition. But the question is if the `Obsolete` can be 
more nuanced.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938#discussioncomment-8681216
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Update gumbo-parser to 0.12.1/libgumbo SONAME bump

2024-03-04 Thread 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

Re: libxslxwriter (misspelled package) in zombie state

2024-03-04 Thread 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_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

[Rpm-maint] [rpm-software-management/rpm] How to obsolete package once their dependencies are not satisfied? (Discussion #2938)

2024-02-28 Thread Vít Ondruch

Lets have some package installed on a system, which is already removed from the 
repository. This package might work just fine as long as their dependencies are 
satisfied. But after the dependencies change, the package needs to be removed. 
Is there a way to obsolete package under such condition?

The specific example could be this:

~~~
Problem 3: package rubygem-byebug-11.1.3-5.fc39.x86_64 from @System requires 
libruby.so.3.2()(64bit), but none of the providers can be installed
  - ruby-libs-3.2.2-181.fc39.x86_64 from @System  does not belong to a 
distupgrade repository
  - problem with installed package rubygem-byebug-11.1.3-5.fc39.x86_64
~~~

As long as the `libruby.so.3.2()(64bit)` is available, the 
rubygem-byebug-11.1.3-5.fc39.x86_64 package works fine. But is there a way to 
remove it from a system once the `libruby.so.3.2()(64bit)` is not available 
anymore?

[This](https://src.fedoraproject.org/rpms/fedora-obsolete-packages/pull-request/86#)
 ticket is the background for my question. 


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2938
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: Donate 1 minute of your time to test upgrades from F39 to F40

2024-02-26 Thread 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,

Re: mock: ImportError: /lib64/libdnf.so.2: undefined symbol: g_once_init_enter_pointer

2024-02-22 Thread 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: [Rpm-maint] [rpm-software-management/rpm] Introduction of "rpms.lock.yaml" file (Discussion #2908)

2024-02-22 Thread Vít Ondruch

RPM knows that from command line parameter. Obviously `rpm -I 
vim-enhanced-10.0.038-1.fc38.x86_64.rpm` will look for the package in current 
directory. IOW the information where to get the package to install is always 
external to RPM.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8559235
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

[Rpm-maint] [rpm-software-management/rpm] Please backport support for spec local file attributes and generators into stable RPM (Issue #2918)

2024-02-20 Thread Vít Ondruch

I wonder if you would be open to backport the support for [spec local file 
attributes and 
generators](https://github.com/rpm-software-management/rpm/pull/2911) into 
stable RPM. This would allow us to drop the rpm-local-generator-support package 
from Fedora and migrate the current downstream users to the `_local_file_attrs` 
instead.

I have already asked [backport in 
Fedora](https://bugzilla.redhat.com/show_bug.cgi?id=2264885), but I was 
redirected here. And to be fully transparent, I am asking the backport here and 
now, because it would actually allow us to drop the rpm-local-generator-support 
package from Fedora and hopefully also from RHEL10.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2918
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

Re: [Rpm-maint] [rpm-software-management/rpm] Introduction of "rpms.lock.yaml" file (Discussion #2908)

2024-02-20 Thread Vít Ondruch

Fedora also used Mirror Manager, therefore the explicit URLs (in the original 
example) are going against that.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2908#discussioncomment-8528588
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint

1 2 3 4 5 6 7 8 9 10 >

1 - 100 of 3343 matches

Mail list logo