Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Richard W.M. Jones]

On Mon, Feb 20, 2023 at 10:56:30AM -0800, Gordon Messmer wrote:
> On 2023-02-20 10:01, Richard W.M. Jones wrote:
> >Does it have to be something which looks so much like it might be a
> >version number?  For example it could be helpful for debugging if the
> >generated requires was something like:
> >
> >   Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1
> 
> 
> You mean the literal string "soname", right?

Yes.

> I don't know a reason
> that wouldn't work off the top of my head, but I also can't think of
> a reason that it would add information that wasn't inferred in the
> current iteration.  One reason we might want to stick with something
> that looks like a version is that we might need to extend the system
> to allow an epoch in the future (though I really hope that isn't
> necessary.)

I mean if I'm looking at an error message, it might help to know that
I should look at the SONAME instead of trying to work out where the
weird version number had come from.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: fedpkg: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Kenneth Goldman kirjoitti 14.2.2023 klo 21.19:

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
GNU_Hello/

Working through the basic tutorial there:

fedpkg --release f37 mockbuild

fails with

Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
[repeats forever]

How does fedpkg know what to build?  Does it default to whatever .spec file
exists?
Is there another argument to fedpkg. Are there some other steps between
Rpmdev-newspec and fedpkg?

What am I missing?


Sorry for not responding earlier, I currently maintain that tutorial and 
have extensively rewritten it from an earlier tutorial.


The tutorial should be self contained, you should be able to complete it 
by just doing everything listed there.

No other arguments to fedpkg are needed.
I am not certain what is the deduction logic it uses, however.

If the problem you encountered is still reproducible, please open a new 
issue at [1].

If you add some more details regarding the steps you took
(like the sequence of cli commands you issued from a fresh start),
we can take a look what is happening and how to fix it.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/issues
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Vít Ondruch kirjoitti 15.2.2023 klo 12.21:


Dne 14. 02. 23 v 20:19 Kenneth Goldman napsal(a):

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
GNU_Hello/



I wish this was update to suggest to create git repository right from 
start.


BTW I think that fedpkg could help with this task and therefore opened 
this RFE:


https://pagure.io/fedpkg/issue/500


I have attempted to modify the tutorial to use a Git repository, see [1].
As you see from the comments, there is some resistance to this idea.
I actually I have to agree: Building packages should be possible without 
necessarily mixing in Git.
So I think the better path is to improve the tutorial and tools so that 
everything works nicely without Git.
A lot has already done, as you will see from the changelog for upcoming 
rpkg 1.66 and fedpkg [2,3].


[1]: https://pagure.io/fedora-docs/package-maintainer-docs/pull-request/88
[2]: https://pagure.io/rpkg/pull-request/656
[3]: https://pagure.io/fedpkg/pull-request/501
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

GHC 9.2 is now in F38 and Rawhide

[Jens-Ulrik Petersen]

I am pleased to announce the arrival of ghc version 9 (9.2.6) and Haskell
packages based on Stackage LTS 20 versions in Rawhide and F38
.

This landed in f38 and f39 today for
https://fedoraproject.org/wiki/Changes/Haskell_GHC_9.2_and_Stackage_20.

With ghc 9.2 there are some significant performance improvements
particularly for aarch64 (with its new Native Code Generator compilation
times are now on par with Intel arch's) and also s390x gains a llvm
backend, which also improves build times a lot. (ppc64le is now the slowest
ghc arch in current Fedora). Also Haskell packages' modules are now built
in parallel in Koji for further build speed ups.

There are still a small handful of packages which didn't build yet, which I
will be sorting in the next days (the only significant ones are the gi-gtk
and dhall stacks).

If you see any problems please let me know or open a bug.

Jens
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Fabio Valentini]

On Tue, Feb 21, 2023 at 9:40 AM Richard W.M. Jones  wrote:
>
> On Mon, Feb 20, 2023 at 10:56:30AM -0800, Gordon Messmer wrote:
> > On 2023-02-20 10:01, Richard W.M. Jones wrote:
> > >Does it have to be something which looks so much like it might be a
> > >version number?  For example it could be helpful for debugging if the
> > >generated requires was something like:
> > >
> > >   Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1
> >
> >
> > You mean the literal string "soname", right?
>
> Yes.
>
> > I don't know a reason
> > that wouldn't work off the top of my head, but I also can't think of
> > a reason that it would add information that wasn't inferred in the
> > current iteration.  One reason we might want to stick with something
> > that looks like a version is that we might need to extend the system
> > to allow an epoch in the future (though I really hope that isn't
> > necessary.)
>
> I mean if I'm looking at an error message, it might help to know that
> I should look at the SONAME instead of trying to work out where the
> weird version number had come from.

This reminds me, there *is* precedent for stuffing "arbitrary"
versions into RPM Requires / Provides.
Many language ecosystems use virtual Provides / Requires like
"py3dist(foo) = 1.2.3", "crate(foo) = 0.0.11", or even
"golang(github.com/foo/bar/v2) = 2.0.1", where the version is the
*upstream* version (normalized to only contain characters that are
valid in RPM versions), but that doesn't necessarily match version of
the RPM.
The virtual provides that are generated for shared libraries have
always been a bit odd in this regard - maybe we could do something
like "Provides: soname(libnghttp2.so.14()(64bit)) = 14.24.1"?

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Florian Weimer]

* Florian Weimer:

> But I really don't get why read-only access to the RPM database during
> the build is so problematic.  I don't see how it can be worse than what
> we do with package notes.

It occurred to me that it's probably to avoid a requirement for
bootstrap chroot.  Without bootstrapping, the RPM database is maintained
by the host RPM, and the RPM in the buildroot won't necessarily be able
to interpret it.

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

Re: Creating a F37 remix/spin LiveCD without a desktop environment

[Sandro]

On 20-02-2023 22:09, Globe Trotter via devel wrote:

I would be happy to unretire it if that is possible.


It is:

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

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

Re: Note section size too big (was: Re: FTBFS bug filed, build already deleted)

[Lukas Zaoral]

On Mon, Feb 20, 2023 at 10:19 PM Julian Sikorski  wrote:
>
> Am 20.02.23 um 19:14 schrieb Orion Poplawski:
> > On 2/20/23 10:46, Fabio Valentini wrote:
> >> On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski 
> >> wrote:
> >>>
> >>> Hello,
> >>>
> >>> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> >>> build [2] has already been deleted. This is not ideal from maintainer
> >>> perspective as it effectively is a bug with no info provided
whatsoever.
> >>> Not to mention being quite wasteful from the resources perspective as
> >>> mame builds take quite a while.
> >>> While not much can be done now, can we make sure that the mass rebuild
> >>> builds do not get garbage collected, or at least the build logs are
> >>> saved somewhere? Thanks.
> >>
> >> As far as I know, at least some form of truncated build.log used to
> >> get attached when FTBFS bugs were filed after a mass rebuild ... maybe
> >> this time this wasn't possible, because bugs were reported *weeks*
> >> after the mass rebuild?
> >>
> >> And I agree, having no logs at all for something that takes a long
> >> time to build is annoying :(
> >
> > Well, if your package is tracked by koschei (which I highly recommend),
> > you likely could get a current build log from there.
> >
> Good idea, this allowed me to get further.
> I have hit another issue:
>
> error: Recognition of file
> "/builddir/build/BUILDROOT/mame-0.251-3.fc39.x86_64/usr/bin/mame"
> failed: mode 100755 , dynamically linked, interpreter
> /lib64/ld-linux-x86-64.so.2,
> BuildID[sha1]=4cb9f6821033586b869d516b865fa1d8e7b8b5f9, for GNU/Linux
> 3.2.0 Note section size too big (137005660 > 134217728) (Invalid argument)
>
> I am already building with -g1. What can be done about the error above?
> Thanks!
>
> Best regards,
> Julian

Hi Julian,
This issue is tracked in https://bugzilla.redhat.com/show_bug.cgi?id=2167964
.

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

F39 proposal: MinGW toolchain update (System-Wide Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/F39MingwEnvToolchainUpdate

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 ==
Update the MinGW toolchain to the latest upstream stable releases.

== Owner ==
* Name: [[User:smani|Sandro Mani]]
* Email: manisan...@gmail.com


== Detailed Description ==

The following packages will be updated

* mingw-gcc to version 13.x
* mingw-binutils to version 2.40

== Benefit to Fedora ==

Ship the latest available GNU toolchain for MinGW.

== Scope ==
* Proposal owners:
The above mentioned packages will be updated. Build failures following
the mass rebuild will be inspected.

* Other developers:
Help with build failures may be requested.

* Release engineering: Impact check [https://pagure.io/releng/issue/11299]
* Release engineering: Mass rebuild requested
* Policies and guidelines: No policies need to be changed

== Upgrade/compatibility impact ==
No impact

== How To Test ==
Update the system once the updated packages land, look out for new
build failures etc.

== User Experience ==
The features of the newest GNU Toolchain will be available to MinGW users.

== Dependencies ==
None

== Contingency Plan ==
* Contingency mechanism: Revert to older versions of environment /
toolchain, mass rebuild mingw packages again
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No

== Release Notes ==
Fedora 39 comes with the mingw-gcc-13 and mingw-binutils-2.40.


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Schedule for Tuesday's (Today's) FESCo Meeting (2023-02-21)

[Fabio Valentini]

Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2023-02-21 17:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2888 Nonresponsive maintainer: ModemManager lkundrak
https://pagure.io/fesco/issue/2888
APPROVED (+2, 0, -0)

#2936 Nonresponsive maintainer: Andrey Matyukov amatyuko
https://pagure.io/fesco/issue/2936
APPROVED (+2, 0, -0)

#2937 Non-responsive maintainer check for Juston Li jhli
https://pagure.io/fesco/issue/2937
APPROVED (+2, 0, -0)

#2950 FTBFS exception request for golang-helm-3
https://pagure.io/fesco/issue/2950
APPROVED (+6, 0, -0)

#2954 Change: Mass Retire Golang Leaves
https://pagure.io/fesco/issue/2954
APPROVED (+3, 0, -0)

= Followups =

N/A

= New business =

#2951 Proposal: policy for resubmitting rejected proposals
https://pagure.io/fesco/issue/2951

#2955 F38 incomplete Changes: testable deadline
https://pagure.io/fesco/issue/2955

#2956 Does FESCo want to implement the policy for retiring packages
with security bugs?
https://pagure.io/fesco/issue/2956

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or bring it
up at the end of the meeting, during the open floor topic. Note
that added topics may be deferred until the following meeting.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Creating a F37 remix/spin LiveCD without a desktop environment

[Globe Trotter via devel]

Thanks for this. But this is separate. I was wondering how do I create a LiveCD 
without a login display manager?




On Tuesday, February 21, 2023 at 07:59:27 AM CST, Sandro  
wrote: 





On 20-02-2023 22:09, Globe Trotter via devel wrote:
> I would be happy to unretire it if that is possible.

It is:

https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 10:01, Richard W.M. Jones wrote:

Does it have to be something which looks so much like it might be a
version number?  For example it could be helpful for debugging if the
generated requires was something like:

   Requires: libnghttp2.so.14()(64bit) >= soname.14.24.1
or:
   Requires: libnghttp2.so.14()(64bit)(soname) >= 14.24.1



I don't have a *reason* to dislike the first option, but my gut reaction 
is that it's messy to encode both a feature and a version into a single 
field.  Let's withhold judgement on that one for a moment to consider 
the other.


Unless I'm missing something, the second option wouldn't be compatible 
with any existing packages unless it were an addition instead of a 
change.  If it were an addition, we have the option of making the system 
more compatible with existing packages than the current proposal by 
using a rich dependency.  Assuming the generator is allowed to emit rich 
deps (which I have not verified), the generator could emit:


  Provides: libnghttp2.so.14()(64bit)(soname) >= 14.24.1

and:

  Requires: (libnghttp2.so.14()(64bit)(soname) >= 14.24.1 if 
libnghttp2.so.14()(64bit)(soname))


And in that arrangement, the deployment can be completed faster because 
packages only require a versioned library "provide" if the providing 
package has the versioned library feature, which also improves 
compatibility with third party repos that don't adopt the feature 
(assuming that users want those packages to provide something that a 
Fedora package requires, which seems very uncommon).


But that compatibility upside is a reliability down side. Imagine a 
system that has libfoo 1.2.3 which "Provides: 
libfoo.so.1()(64bit)(soname) = 1.2.3" + "Provides: 
libfoo.so.1()(64bit)", and the maintainer updates to a git version with 
libfoo.so.1.3.0git.  That will only "Provides: libfoo.so.1()(64bit)".  
If they also rebuild an associated program, it might require new 
interfaces from libfoo, but only "Requires: libfoo.so.1()(64bit)", (and 
any versioned requirements stop working) so installing the application 
wouldn't trigger an update of the library, which is the intent of this 
feature.


That might be worth further thought... at the moment I dislike the way 
it degrades.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-20 11:48, Gordon Messmer wrote:


Looking at this result, I think I see one bug and one RFE.
Should I report those in bugzilla, and if so, against what component? 



I want to add: If someone points me toward the right repo, I can work on 
both of those.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-21 08:57, Gordon Messmer wrote:
If it were an addition, we have the option of making the system more 
compatible with existing packages than the current proposal by using a 
rich dependency.



...I forgot to mention: I also wonder what adding a new dependency would 
do to the memory and CPU profile on systems during transaction 
resolution.  I'd expect that we're doubling the volume of most 
dependencies in the system.

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

Summary/Minutes from today's FESCo Meeting (2023-02-21)

[Fabio Valentini]

===
#fedora-meeting: FESCo (2023-02-21)
===

Meeting started by decathorpe at 17:00:46 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting/2023-02-21/fesco.2023-02-21-17.00.log.html

Meeting summary
---
* Init Process  (decathorpe, 17:01:13)
  * LINK:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DGN45BVWSCHYPVHMKA5ZOOWAXCEB4ZPQ/
Schedule  (decathorpe, 17:04:26)

* #2955 F38 incomplete Changes: testable deadline  (decathorpe,
  17:11:01)
  * LINK:

https://src.fedoraproject.org/rpms/fedora-flathub-remote/c/b6985fa956bd0b4912c37f3d6f1ed91af7de80d6?branch=rawhide
(mhroncok, 17:11:11)
  * LINK: https://bodhi.fedoraproject.org/updates/FEDORA-2023-a326b4331e
seems ON_QA to me  (mhroncok, 17:11:48)
  * LINK: https://src.fedoraproject.org/rpms/pam/commits/rawhide shows
no relevant commits since f36  (mhroncok, 17:14:09)
  * LINK:

https://src.fedoraproject.org/fork/besser82/rpms/cmake/c/c6527535927b10b00bbfb69bc36039945ff00aaf
(mhroncok, 17:19:27)
  * AGREED: AGREED: The Change "Drop NIS(+) support from PAM" has not
been implemented for F38 and will be returned to "incomplete" state
(+7, 0, -0)  (decathorpe, 17:23:33)
  * AGREED: AGREED: The Change "Retire the NIS(+) user-space utility
programs" has not been implemented for F38 and will be returned to
"incomplete" state (+7, 0, -0)  (decathorpe, 17:26:26)
  * AGREED: AGREED: The Change "Legacy Xorg driver removal" has not been
implemented for F38 and will be deferred to F39 (+7, 0, -0)
(decathorpe, 17:29:52)
  * The Change "Modernize Live Media" has been updated to ON_QA status
(decathorpe, 17:31:19)
  * LINK: https://pagure.io/pungi-fedora/pull-request/1145   (nirik,
17:33:46)
  * AGREED: AGREED: The Change "Ostree Native Container (Phase 2,
stable)" has not been implemented for F38 and will be deferred to
F39 (+7, 0, -0)  (decathorpe, 17:38:03)
  * LINK:

https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable#Detailed_Description
has a list  (decathorpe, 17:39:55)
  * AGREED: AGREED: In addition to being deferred to F39, FESCo requests
that the Change "Ostree Native Container (Phase 2, stable)" will
have a contingency deadline of F39 Beta Freeze and the Scope of the
proposal will be filled (+7, 0, -0)  (decathorpe, 17:49:17)
  * https://koji.fedoraproject.org/koji/rpminfo?rpmID=33668753
(zbyszek, 17:53:57)
  * AGREED: AGREED: The Change "Unified kernel support phase 1" does not
seem to have been implemented fully yet, let's wait (+6, 1, -0)
(decathorpe, 18:02:59)
  * The Change "RPMautospec by default" only changes the recommended
defaults in documentation. There is nothing to do regarding the F38
beta freeze.  (decathorpe, 18:06:24)
  * The Change "Unflitered flathub" has been implemented and should be
testable.  (decathorpe, 18:08:10)
  * LINK: https://src.fedoraproject.org/rpms/glibc32/commits/rawhide
(zbyszek, 18:09:51)
  * AGREED: AGREED: The Change "glibc32 Build Adjustments" has not been
implemented for F39, and has already been deferred since Fedora 29.
It is marked as "incomplete". Change owners can submit an updated
proposal at any time. (+7, 0, -0)  (decathorpe, 18:16:05)
  * https://bodhi.fedoraproject.org/updates/FEDORA-2023-7a3a4921e3
(zbyszek, 18:16:33)
  * The Change "Haskell GHC 9.2 and Stackage 20" has been implemented
and is set to ON_QA.  (decathorpe, 18:16:55)
  * LINK: https://github.com/fedora-silverblue/issue-tracker/issues/404
(mhroncok, 18:18:25)
  * AGREED: AGREED: The Change "Enable bootupd for Fedora Silverblue &
Kinoite" does not look done yet, but we can't tell. Change owners
are asked for comment, and this will be discussed again next week.
(+6, 0, -0)  (decathorpe, 18:23:40)

* Next Week's Chair  (decathorpe, 18:26:00)
  * ACTION: sgallagh will chair FESCo meeting on Feb 28  (decathorpe,
18:27:43)

* Open Floor  (decathorpe, 18:27:54)

Meeting ended at 18:30:26 UTC.

Action Items

* sgallagh will chair FESCo meeting on Feb 28

Action Items, by person
---
* sgallagh
  * sgallagh will chair FESCo meeting on Feb 28
* **UNASSIGNED**
  * (none)

People Present (lines said)
---
* decathorpe (119)
* mhroncok (83)
* Eighth_Doctor (55)
* zbyszek (43)
* nirik (32)
* sgallagh (24)
* music[m] (18)
* zodbot (16)
* bcotton (6)
* tstellar (3)
* JensPetersen[m] (1)
* dtometzki (1)
* dcantrell (0)
* music (0)
* mhayden (0)
* Conan_Kudo (0)
* Pharaoh_Atem (0)
* Son_Goku (0)
* King_InuYasha (0)
* Sir_Gallantmon (0)

Generated by `MeetBot`_ 0.4
.. _`MeetBot`: https://fedoraproject.org/wiki/Zodbot#Meeting_Functions
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
F

Fedora rawhide compose report: 20230221.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20230220.n.0
NEW: Fedora-Rawhide-20230221.n.0

= SUMMARY =
Added images:0
Dropped images:  3
Added packages:  30
Dropped packages:1
Upgraded packages:   173
Downgraded packages: 0

Size of added packages:  38.37 MiB
Size of dropped packages:3.97 MiB
Size of upgraded packages:   2.96 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =

= DROPPED IMAGES =
Image: KDE live aarch64
Path: Spins/aarch64/iso/Fedora-KDE-Live-aarch64-Rawhide-20230220.n.0.iso
Image: Design_suite live x86_64
Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20230220.n.0.iso
Image: Kinoite dvd-ostree ppc64le
Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230220.n.0.iso

= ADDED PACKAGES =
Package: arptools-1.0.2-21.20230218git2cf523f.fc39
Summary: Collection of libnet and libpcap based ARP utilities
RPMs:arptools
Size:112.68 KiB

Package: bowtie-1.3.1-1.fc39
Summary: An ultrafast, memory-efficient short read aligner
RPMs:bowtie
Size:31.06 MiB

Package: braille-printer-app-2.0b0^386eea385f-2.fc39
Summary: Braille printer application
RPMs:braille-printer-app
Size:219.49 KiB

Package: cups-browsed-2.0b3-1.fc39
Summary: Daemon for local auto-installation of remote printers
RPMs:cups-browsed
Size:560.26 KiB

Package: perl-Clone-0.45-7.module_f39+16222+b723cb4b
Summary: Recursively copy perl data types
RPMs:perl-Clone
Size:268.12 KiB

Package: perl-Data-Dump-1.25-3.module_f39+16222+b723cb4b
Summary: Pretty printing of data structures
RPMs:perl-Data-Dump
Size:100.96 KiB

Package: perl-Date-Manip-6.90-1.module_f39+16197+a2c51ff1
Summary: Date manipulation routines
RPMs:perl-Date-Manip
Size:1022.34 KiB

Package: perl-Digest-HMAC-1.04-4.module_f39+16222+b723cb4b
Summary: Keyed-Hashing for Message Authentication
RPMs:perl-Digest-HMAC perl-Digest-HMAC-tests
Size:107.42 KiB

Package: perl-Encode-Locale-1.05-24.module_f39+16214+7900cd31
Summary: Determine the locale encoding
RPMs:perl-Encode-Locale
Size:56.71 KiB

Package: perl-File-Listing-6.15-1.module_f39+16222+b723cb4b
Summary: Parse directory listing
RPMs:perl-File-Listing perl-File-Listing-tests
Size:176.54 KiB

Package: perl-File-Slurper-0.014-1.module_f39+16214+7900cd31
Summary: Simple, sane and efficient module to slurp a file
RPMs:perl-File-Slurper
Size:21.38 KiB

Package: perl-HTML-Parser-3.81-1.module_f39+16222+b723cb4b
Summary: Perl module for parsing HTML
RPMs:perl-HTML-Parser
Size:1.41 MiB

Package: perl-HTML-Tagset-3.20-49.module_f39+16222+b723cb4b
Summary: HTML::Tagset - data tables useful in parsing HTML
RPMs:perl-HTML-Tagset
Size:55.98 KiB

Package: perl-HTTP-Cookies-6.10-5.module_f39+16222+b723cb4b
Summary: HTTP cookie jars
RPMs:perl-HTTP-Cookies
Size:113.17 KiB

Package: perl-HTTP-Date-6.05-10.module_f39+16214+7900cd31
Summary: Date conversion routines
RPMs:perl-HTTP-Date
Size:71.82 KiB

Package: perl-HTTP-Message-6.36-2.module_f39+16222+b723cb4b
Summary: HTTP style message
RPMs:perl-HTTP-Message
Size:292.27 KiB

Package: perl-HTTP-Negotiate-6.01-31.module_f39+16222+e3c19752
Summary: Choose a variant to serve
RPMs:perl-HTTP-Negotiate
Size:59.44 KiB

Package: perl-IO-Compress-Brotli-0.004001-6.module_f39+16214+7900cd31
Summary: Perl bindings for Brotli compression
RPMs:perl-IO-Compress-Brotli
Size:108.93 KiB

Package: perl-IO-HTML-1.004-5.module_f39+16222+b723cb4b
Summary: Open an HTML file with automatic character set detection
RPMs:perl-IO-HTML
Size:83.94 KiB

Package: perl-LWP-MediaTypes-6.04-10.module_f39+16222+b723cb4b
Summary: Guess media type for a file or a URL
RPMs:perl-LWP-MediaTypes
Size:99.55 KiB

Package: perl-LWP-Protocol-https-6.10-5.module_f39+16222+b723cb4b
Summary: Provide HTTPS support for LWP::UserAgent
RPMs:perl-LWP-Protocol-https
Size:64.53 KiB

Package: perl-Mozilla-CA-20211001-2.module_f39+16222+b723cb4b
Summary: Mozilla's CA certificate bundle in PEM format
RPMs:perl-Mozilla-CA
Size:37.42 KiB

Package: perl-NTLM-1.09-31.module_f39+16222+e3c19752
Summary: NTLM Perl module
RPMs:perl-NTLM
Size:66.29 KiB

Package: perl-Net-HTTP-6.22-1.module_f39+16222+b723cb4b
Summary: Low-level HTTP connection (client)
RPMs:perl-Net-HTTP
Size:120.45 KiB

Package: perl-PerlIO-utf8_strict-0.009-4.module_f39+16214+7900cd31
Summary: Fast and correct UTF-8 I/O
RPMs:perl-PerlIO-utf8_strict
Size:105.81 KiB

Package: perl-TimeDate-1:2.33-7.module_f39+16222+e3c19752
Summary: A Perl module for time and date manipulation
RPMs:perl-TimeDate
Size:153.50 KiB

Package: perl-Try-Tiny-0.31-2.module_f39+16222+e3c19752
Summary: Minimal try/catch with proper localization of $@
RPMs:perl-Try-Tiny
Size:113.29 KiB

Package: perl-WWW-RobotRules-6.02-31.module_f39+16222+b723cb4b
Su

Re: Note section size too big (was: Re: FTBFS bug filed, build already deleted)

[Julian Sikorski]

Am 21.02.23 um 15:42 schrieb Lukas Zaoral:
On Mon, Feb 20, 2023 at 10:19 PM Julian Sikorski > wrote:

 >
 > Am 20.02.23 um 19:14 schrieb Orion Poplawski:
 > > On 2/20/23 10:46, Fabio Valentini wrote:
 > >> On Mon, Feb 20, 2023 at 6:43 PM Julian Sikorski 
mailto:beleg...@gmail.com>>

 > >> wrote:
 > >>>
 > >>> Hello,
 > >>>
 > >>> FTBFS bug was filed against mame [1]. Unfortunately, the 
corresponding

 > >>> build [2] has already been deleted. This is not ideal from maintainer
 > >>> perspective as it effectively is a bug with no info provided 
whatsoever.

 > >>> Not to mention being quite wasteful from the resources perspective as
 > >>> mame builds take quite a while.
 > >>> While not much can be done now, can we make sure that the mass 
rebuild

 > >>> builds do not get garbage collected, or at least the build logs are
 > >>> saved somewhere? Thanks.
 > >>
 > >> As far as I know, at least some form of truncated build.log used to
 > >> get attached when FTBFS bugs were filed after a mass rebuild ... maybe
 > >> this time this wasn't possible, because bugs were reported *weeks*
 > >> after the mass rebuild?
 > >>
 > >> And I agree, having no logs at all for something that takes a long
 > >> time to build is annoying :(
 > >
 > > Well, if your package is tracked by koschei (which I highly recommend),
 > > you likely could get a current build log from there.
 > >
 > Good idea, this allowed me to get further.
 > I have hit another issue:
 >
 > error: Recognition of file
 > "/builddir/build/BUILDROOT/mame-0.251-3.fc39.x86_64/usr/bin/mame"
 > failed: mode 100755 , dynamically linked, interpreter
 > /lib64/ld-linux-x86-64.so.2,
 > BuildID[sha1]=4cb9f6821033586b869d516b865fa1d8e7b8b5f9, for GNU/Linux
 > 3.2.0 Note section size too big (137005660 > 134217728) (Invalid 
argument)

 >
 > I am already building with -g1. What can be done about the error above?
 > Thanks!
 >
 > Best regards,
 > Julian

Hi Julian,
This issue is tracked in 
https://bugzilla.redhat.com/show_bug.cgi?id=2167964 
.


Regards,
Lukas


Thank you!

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

Proposal: drop delta rpms (for real this time)

[Matthew Miller]

I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
priority. Last time we talked about this we didn't really get anywhere...

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E

... and that ticket hasn't moved, because fixing it isn't trivial.


What we're doing now — as has been the case for several years, already noted
in the previous discussion — has very little end-user value. Also as noted
in that thread (as in the ticket)... that's unfortunate, because it did
bring some real benefits (and could possibly do even more.)

But, I think it's time to move on. We have ostree and various
container-delta approaches. We should focus on those — and give DeltaRPMs a
sad, fond farewell.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Proposal: drop delta rpms (for real this time)

[Fabio Valentini]

On Tue, Feb 21, 2023 at 9:48 PM Matthew Miller  wrote:
>
> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> priority. Last time we talked about this we didn't really get anywhere...
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
>
> ... and that ticket hasn't moved, because fixing it isn't trivial.
>
>
> What we're doing now — as has been the case for several years, already noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)
>
> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.

It's been a long, long, time since any dnf transaction I ran printed
positive news about deltarpms ... most of the time there either aren't
any, or using them actually increased data download.

So, I agree. It's time to pull the plug.

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

Re: Proposal: drop delta rpms (for real this time)

[Kevin P. Fleming]

On 2/21/23 15:53, Fabio Valentini wrote:

It's been a long, long, time since any dnf transaction I ran printed
positive news about deltarpms ... most of the time there either aren't
any, or using them actually increased data download.
A recent transaction went so poorly that it prompted me to disable 
deltarpms completely on my system.


--
Kevin P. Fleming
He/Him/His
Principal Program Manager, RHEL
Red Hat US/Eastern Time Zone
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Proposal: drop delta rpms (for real this time)

[Leslie Satenstein via devel]

Got it. 


Leslie Satenstein
 

On Tuesday, February 21, 2023 at 03:48:23 p.m. EST, Matthew Miller 
 wrote:  
 
 I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
priority. Last time we talked about this we didn't really get anywhere...

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E

... and that ticket hasn't moved, because fixing it isn't trivial.


What we're doing now — as has been the case for several years, already noted
in the previous discussion — has very little end-user value. Also as noted
in that thread (as in the ticket)... that's unfortunate, because it did
bring some real benefits (and could possibly do even more.)

But, I think it's time to move on. We have ostree and various
container-delta approaches. We should focus on those — and give DeltaRPMs a
sad, fond farewell.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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

F38 Change complete (100% complete) deadline today

[Ben Cotton]

As of today, F38 Changes should be 100% complete. Change owners can
indicate this by setting the Bugzilla tracker to the ON_QA state. F38
enters beta freeze today. Any updates that need to land in the beta
release will require an approved freeze exception or beta blocker.

The current beta target is the early target date of 14 March.

More schedule details are available at
https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html

-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: drop delta rpms (for real this time)

[Stephen Smoogen]

On Tue, 21 Feb 2023 at 15:48, Matthew Miller 
wrote:

> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> priority. Last time we talked about this we didn't really get anywhere...
>
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
>
> ... and that ticket hasn't moved, because fixing it isn't trivial.
>
>
So do we kill it for:

F39/F40 and beyond?
F38 and beyond?
X-date and all releases?


>
> What we're doing now — as has been the case for several years, already
> noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)
>
> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.
>
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Proposal: drop delta rpms (for real this time)

[Kevin Fenzi]

On Tue, Feb 21, 2023 at 03:48:06PM -0500, Matthew Miller wrote:
> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
> priority. Last time we talked about this we didn't really get anywhere...
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
> 
> ... and that ticket hasn't moved, because fixing it isn't trivial.

Yeah. ;( 

I fear the only way to fix it is to get pungi to merge entire repos, and
I don't think thats anything that pungi wants to be on the hook for
doing. 

> What we're doing now — as has been the case for several years, already noted
> in the previous discussion — has very little end-user value. Also as noted
> in that thread (as in the ticket)... that's unfortunate, because it did
> bring some real benefits (and could possibly do even more.)
> 
> But, I think it's time to move on. We have ostree and various
> container-delta approaches. We should focus on those — and give DeltaRPMs a
> sad, fond farewell.

yeah, I agree. 

kevin


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

Re: Proposal: drop delta rpms (for real this time)

[Matthew Miller]

On Tue, Feb 21, 2023 at 04:44:31PM -0500, Stephen Smoogen wrote:
> So do we kill it for:
> 
> F39/F40 and beyond?
> F38 and beyond?
> X-date and all releases?

My normal response would be... well, I missed the F38 change deadline by a
wide margin, so F39+.

But, I think we could stop producing deltarpms for current releases without
really affecting those releases (there would just not be more created, which
as previously explored, would not really have a strong effect). So... I
wouldn't leave the other options out of the question. 

What do infra / releng folks think?

How easy is it to shut things off?

If shut off, can it be turned back on again (in case of Regrets)?

Once shut off, is decomissioning infrastructure around it a Project, or just
more shutting off?

What risks are there?

And... how much would be saved in:

 * compute resources
 * storage
 * delays
 * ongoing maintenance work 
 * other?




-- 
Matthew Miller

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

Claim ownership of python-pydispatcher

[Eduardo Javier Echeverria Alvarado]

Following the process of 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/,
 I'd like to claim the ownership of the python-pydispatcher package; it's a 
dependency of one of my packages to install It, so I'd like to maintain it
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposal: drop delta rpms (for real this time)

[Demi Marie Obenour]

On 2/21/23 16:44, Stephen Smoogen wrote:
> On Tue, 21 Feb 2023 at 15:48, Matthew Miller 
> wrote:
> 
>> I was asked to weigh in on https://pagure.io/releng/issue/7215 as a
>> priority. Last time we talked about this we didn't really get anywhere...
>>
>>
>> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/JYKVELSBJQMEK6KEFXG354ZDZDDX4C5G/#RLEUYSWOUVUS53YAP7WQQNN7HNEBIC4E
>>
>> ... and that ticket hasn't moved, because fixing it isn't trivial.
>>
>>
> So do we kill it for:
> 
> F39/F40 and beyond?
> F38 and beyond?
> X-date and all releases?

F38+?  Also maybe disable deltarpms in dnf.conf, to reduce attack surface.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Failed to get repository name from Git url or pushurl

[Otto Liljalaakso]

Otto Liljalaakso kirjoitti 21.2.2023 klo 11.45:

Kenneth Goldman kirjoitti 14.2.2023 klo 21.19:

https://docs.fedoraproject.org/en-US/package-maintainers/Packaging_Tutorial_
GNU_Hello/

Working through the basic tutorial there:

fedpkg --release f37 mockbuild

fails with

Failed to get repository name from Git url or pushurl
Failed to get ns from Git url or pushurl
[repeats forever]

How does fedpkg know what to build?  Does it default to whatever .spec 
file

exists?
Is there another argument to fedpkg. Are there some other steps between
Rpmdev-newspec and fedpkg?

What am I missing?


Sorry for not responding earlier, I currently maintain that tutorial and 
have extensively rewritten it from an earlier tutorial.


The tutorial should be self contained, you should be able to complete it 
by just doing everything listed there.

No other arguments to fedpkg are needed.
I am not certain what is the deduction logic it uses, however.

If the problem you encountered is still reproducible, please open a new 
issue at [1].

If you add some more details regarding the steps you took
(like the sequence of cli commands you issued from a fresh start),
we can take a look what is happening and how to fix it.

[1]: https://pagure.io/fedora-docs/package-maintainer-docs/issues


Ok, I found the other parts of the thread now.
Something strange is going on here - it seems that when Arthur replies,
threading breaks and I see separate subthreads in Thunderbird.
Also lists.fedoraproject.org seems to be similarly confused.

Anyhow, while UTF-8 is valid in specfile %description and creating a 
specfile that is not UTF-8 is an error,

the tutorial is not intended to touch on such topics.
So I replaced the Unicode quotes with 7-bit ASCII ones [1].

To fix the endless loop of warnings you ran into,
I submitted a patch for rpkg (the library that powers fedpkg) [2].

The warnings themselves are quite pointless.
They are shown every time fedpkg is ran outside of Git repository,
even if everything works just fine.
I have meant to do something about them for some time already,
this case finally motivated me to submit a patch [3].

[1]: 
https://pagure.io/fedora-docs/package-maintainer-docs/c/7fa522266bc90f15ee124376f409b897ddfca142?branch=main

[2]: https://pagure.io/rpkg/pull-request/658
[3]: https://pagure.io/rpkg/pull-request/660
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Proposal: drop delta rpms (for real this time)

[Demi Marie Obenour]

On 2/21/23 17:13, Matthew Miller wrote:
> On Tue, Feb 21, 2023 at 04:44:31PM -0500, Stephen Smoogen wrote:
>> So do we kill it for:
>>
>> F39/F40 and beyond?
>> F38 and beyond?
>> X-date and all releases?
> 
> My normal response would be... well, I missed the F38 change deadline by a
> wide margin, so F39+.
> 
> But, I think we could stop producing deltarpms for current releases without
> really affecting those releases (there would just not be more created, which
> as previously explored, would not really have a strong effect). So... I
> wouldn't leave the other options out of the question.

Can we also disable deltarpms in the F38 repo files?  It’s a 1-line change,
trivially revertable, and it measurably reduces the attack surface of DNF.
If no deltarpms are being generated, there is no point in DNF looking for
them.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Creating a F37 remix/spin LiveCD without a desktop environment

[Globe Trotter via devel]

Looking at the i3 desktop kickstart file, I tried using lightdm (just to see 
how I fare):


%post
systemctl enable lightdm

# xfce configuration

# create /etc/sysconfig/desktop (needed for installation)

cat > /etc/sysconfig/desktop < wrote:





I put the following here, in case anyone wants to take a look. The LiveCD 
formed does not boot.


fpaste fedora-shunya-common.ks
Uploading (3.7KiB)...
https://paste.centos.org/view/529252f8


$ fpaste fedora-live-shunya-37.ks
Uploading (3.2KiB)...
https://paste.centos.org/view/b73160cd

I also put the old one that used to work at least with F34 here:


$ fpaste fedora-live-shunya-old.ks
Uploading (3.3KiB)...
https://paste.centos.org/view/34c9dfe3

This has the same effect as the new one. At least, that is what it looks like.

Many thanks!




On Sunday, February 19, 2023 at 11:18:38 PM CST, Globe Trotter via devel 
 wrote:





On Sunday, February 19, 2023 at 09:25:50 PM CST, Neal Gompa 
 wrote:





On Sun, Feb 19, 2023 at 9:33 PM Globe Trotter via devel
 wrote:
>
> Hello,
>
> Since about Fedora 20 or so, I have been rolling my own Fedora spin without a 
> desktop environment, and with openbox and slim (simple login manager). All 
> worked well, because I did not need to roll these that often, with dnf 
> upgrade on existing installations, except up until now when I need a new 
> LiveCD for a new machine coming online. I last successfully made a LiveCD 
> with Fedora 34.
>
> Recently, I went back to making a live cd for Fedora 37, and realized that 
> there is a new way of handling these: specifically, I have to install 
> env-group to resolve RH Bug:1891500.
>
> With an environment, it turns out one has to do something like
>
>
> @^lxde-desktop-environment
>
> but I do not want an environment.
>
>
> Can I get a LiveCD environment without all this, and with slim?
>

> Yes, you can just avoid using environment groups altogether. The bug you 
> reference should not apply in your case.

--
Thanks! Not? but it does not work. A LiveCD is  created if I do not add that 
line to my ks, but. I get something that hangs when the LiveCD boots. Did not 
happen before.



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


Looking at the i3 desktop kickstart file, I tried using lightdm:








On Monday, February 20, 2023 at 09:10:57 AM CST, Globe Trotter via devel 
 wrote: 





I put the following here, in case anyone wants to take a look. The LiveCD 
formed does not boot.


fpaste fedora-shunya-common.ks
Uploading (3.7KiB)...
https://paste.centos.org/view/529252f8


$ fpaste fedora-live-shunya-37.ks
Uploading (3.2KiB)...
https://paste.centos.org/view/b73160cd

I also put the old one that used to work at least with F34 here:


$ fpaste fedora-live-shunya-old.ks
Uploading (3.3KiB)...
https://paste.centos.org/view/34c9dfe3

This has the same effect as the new one. At least, that is what it looks like. 

Many thanks!




On Sunday, February 19, 2023 at 11:18:38 PM CST, Globe Trotter via devel 
 wrote: 





On Sunday, February 19, 2023 at 09:25:50 PM CST, Neal Gompa 
 wrote: 





On Sun, Feb 19, 2023 at 9:33 PM Globe Trotter via devel
 wrote:
>
> Hello,
>
> Since about Fedora 20 or so, I have been rolling my own Fedora spin without a 
> desktop environment, and with openbox and slim (simple login manager). All 
> worked well, because I did not need to roll these that often, with dnf 
> upgrade on existing installations, except up until now when I need a new 
> LiveCD for a new machine coming online. I last successfully made a LiveCD 
> with Fedora 34.
>
> Recently, I went back to making a live cd for Fedora 37, and realized that 
> there is a new way of handling these: specifically, I have to install 
> env-group to resolve RH Bug:1891500.
>
> With an environment, it turns out one has to do something like
>
>
> @^lxde-desktop-environment
>
> but I do not want an environment.
>
>
> Can I get a LiveCD environment without all this, and with slim?
>

> Yes, you can just avoid using environment groups altogether. The bug you 
> referenc

Re: Creating a F37 remix/spin LiveCD without a desktop environment

[Sérgio Basto]

On Tue, 2023-02-21 at 16:34 +, Globe Trotter via devel wrote:
> 
> 
> Thanks for this. But this is separate. I was wondering how do I
> create a LiveCD without a login display manager?

you got nodm package and maybe could help you this article 
https://fedoramagazine.org/build-a-kiosk-with-fedora-silverblue/ 

> 
> 
> 
> On Tuesday, February 21, 2023 at 07:59:27 AM CST, Sandro
>  wrote: 
> 
> 
> 
> 
> 
> On 20-02-2023 22:09, Globe Trotter via devel wrote:
> > I would be happy to unretire it if that is possible.
> 
> It is:
> 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
> 
> -- 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

-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
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: Creating a F37 remix/spin LiveCD without a desktop environment

[Globe Trotter via devel]

Thank you. I was not aware of nodm, so this is interesting. However, I 
understand that nodm will automatically start an X session at system boot. I 
really do not want that, except in the LiveCD.

As I mentioned in a post, I do not understand why lightdm (in my example) was 
not starting.


Looking at the i3 desktop kickstart file, I tried using lightdm (just to see 
how I fare):

 
 %post
 systemctl enable lightdm

 # create /etc/sysconfig/desktop (needed for installation)

 cat > /etc/sysconfig/desktop < wrote: 





On Tue, 2023-02-21 at 16:34 +, Globe Trotter via devel wrote:
> 
> 
> Thanks for this. But this is separate. I was wondering how do I
> create a LiveCD without a login display manager?

you got nodm package and maybe could help you this article 
https://fedoramagazine.org/build-a-kiosk-with-fedora-silverblue/ 

> 
> 
> 
> On Tuesday, February 21, 2023 at 07:59:27 AM CST, Sandro
>  wrote: 
> 
> 
> 
> 
> 
> On 20-02-2023 22:09, Globe Trotter via devel wrote:
> > I would be happy to unretire it if that is possible.
> 
> It is:
> 
> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/#claiming
> 
> -- 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

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Kevin Kofler via devel]

Gordon Messmer wrote:
> As there is some discussion of whether the ELF dependency generator
> should use the full version string presented by the library file name's
> suffix, or should assume a SemVer-style major.minor and truncate the
> requirement to the first two dot-separated numbers, questions about
> rpminspect come to mind:

It is generally unsafe to assume the version number to be in any specific 
format. While libtool is very strict on the format of soversions, other 
build systems that produce versioned libraries are not so strict. E.g., 
CMake allows setting both the soname version and the full version to 
basically arbitrary strings. So while you can have a standard libtool-style 
versioning:
libfoo.so → libfoo.so.1 → libfoo.so.1.2.3
you can also have things such as:
libfoo.so → libfoo.so.1 → libfoo.so.1.2
libfoo.so → libfoo.so.1 → libfoo.so.1.2.3.4
libfoo.so → libfoo.so.1 → libfoo.so.1.bla
but even things such as:
libfoo.so → libfoo.so.1 → libfoo.so.4.5.6
libfoo.so → libfoo.so.4 → libfoo.so.1.2.3
libfoo.so → libfoo.so.bar → libfoo.so.baz
libfoo.so → libfoo.so.1.2.3 → libfoo.so.42
(In all these, the second one is the soname, the third one is the full name. 
The last example could possibly make sense if 1.2.3 is some kind of ABI 
version and 42 is some kind of autoincremented SCM revision number. But even 
if you think it does not make sense, the build system does not prevent it.)

The full version (or even the soversion, for that matter) is also not 
guaranteed to be monotonic in any way. E.g., you could have:
libfoo.so → libfoo.so.1 → libfoo.so.1.deadbeef
or even just:
libfoo.so → libfoo.so.1 → libfoo.so.deadbeef
where "deadbeef" is a non-monotonic SCM hash (e.g., a git hash).

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

Re: FTBFS bug filed, build already deleted

[Kevin Kofler via devel]

Julian Sikorski wrote:
> FTBFS bug was filed against mame [1]. Unfortunately, the corresponding
> build [2] has already been deleted. This is not ideal from maintainer
> perspective as it effectively is a bug with no info provided whatsoever.
> Not to mention being quite wasteful from the resources perspective as
> mame builds take quite a while.
> While not much can be done now, can we make sure that the mass rebuild
> builds do not get garbage collected, or at least the build logs are
> saved somewhere? Thanks.

This is a constantly recurring problem. I have run into this very 
frequently. The retention period for failed build logs is way too short. It 
needs to be at least 13 months (the approximate time we get to fix an FTBFS 
bug before the package is retired).

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

Re: Proposal: drop delta rpms (for real this time)

[Kevin Kofler via devel]

Kevin Fenzi wrote:
> I fear the only way to fix it is to get pungi to merge entire repos, and
> I don't think thats anything that pungi wants to be on the hook for
> doing.

But there are more things than just DeltaRPMs it could be useful for. E.g., 
I remember that in ancient times (pre Core-Extras Merge), some Fedora 
repository (IIRC, the old Fedora Extras) used to ship not only the latest 
build for each package, but the TWO latest builds, so that if the latest 
build was broken, you could easily downgrade to the previous one. That 
should really be done in all the rolling repositories (updates, updates-
testing, Rawhide).

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

Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Gordon Messmer]

On 2023-02-21 20:19, Kevin Kofler via devel wrote:

It is generally unsafe to assume the version number to be in any specific
format.



I'm not sure if that means that you are opposed to the proposal, or to 
the idea of truncating the version numbers, or something else entirely.  :)




you can also have things such as:
libfoo.so → libfoo.so.1 → libfoo.so.1.2
libfoo.so → libfoo.so.1 → libfoo.so.1.2.3.4



Seems good so far, that should be compatible with the proposal.



libfoo.so → libfoo.so.1 → libfoo.so.1.bla



The current implementation will only generate a versioned dependency if 
the suffix is numbers separated by dots, so this library would be 
compatible in that it would be ignored (since we don't know the 
semantics of non-numeric versions.)




but even things such as:
libfoo.so → libfoo.so.1 → libfoo.so.4.5.6
libfoo.so → libfoo.so.4 → libfoo.so.1.2.3



That's surprising, but as long as the version in the full name increases 
monotonically, those should work as well.




libfoo.so → libfoo.so.1.2.3 → libfoo.so.42



Hm... the current implementation wouldn't generate anything in this case 
because the full name's version doesn't have a dot separating numbers, 
and my naive expectation was that such a case probably meant that only a 
"major" version was present and that it'd match the soname, in which 
case versioning the dependency wouldn't add any information that wasn't 
already there.    Perhaps the right thing to do instead would be to 
produce a versioned dependency if the suffixes do not match.




The full version (or even the soversion, for that matter) is also not
guaranteed to be monotonic in any way. E.g., you could have:
libfoo.so → libfoo.so.1 → libfoo.so.1.deadbeef
or even just:
libfoo.so → libfoo.so.1 → libfoo.so.deadbeef
where "deadbeef" is a non-monotonic SCM hash (e.g., a git hash).



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