Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Nico Kadel-Garcia 
That addresses my concern. I'd assumed that it would occur as part of
an RPM update, rather than as a triggered out of band event. It makes
rebooting mandatory and slightly risky, especially if /usr overflows
halfway through, the process, but that becomes far, far less likely
with systemd doing it at boot time running at the same time other RPM
updates. I do hope the scripting will exit gracefully if /usr
overflows or is unwriteable for other reasons, such as being part of
the "immutable" Linux concept.

Nico Kadel-Garcia

On Sat, Jan 8, 2022 at 8:30 PM Chris Murphy  wrote:
>
> On Sat, Jan 8, 2022 at 6:07 PM Nico Kadel-Garcia  wrote:
> >
> > On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy  wrote:
> > >
> > > On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  
> > > wrote:
> > > >
> > > > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> > > > >
> > > > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  
> > > > > > wrote:
> > > > > > >
> > > > > >
> > > > > > (snip)
> > > > > >
> > > > > > >
> > > > > > > == Detailed Description ==
> > > > > > > === Current location ===
> > > > > > > /var/lib/rpm
> > > > > > >
> > > > > > > === New location ===
> > > > > > > /usr/lib/sysimage/rpm
> > > > > > >
> > > > > > > /var/lib/rpm will be a symlink pointing to
> > > > > > > /usr/lib/sysimage/rpm
> > > > > >
> > > > > > I did not find a mention of this in the thread or in the Change
> > > > > > proposal, so I'll ask:
> > > > > > How do you plan to handle the directory -> symlink replacement on 
> > > > > > upgrade?
> > > > > >
> > > > > > As far as I can tell, those always required special treatment via
> > > > > > %pretrans scriptlets or something, and even the method currently
> > > > > > recommended by the Packaging Guidelines seems to be broken due to 
> > > > > > the
> > > > > > way dnf / RPM verifies validity of transactions.
> > > > > >
> > > > > > Additionally, that "special" handling will probably need to stay in
> > > > > > the RPM package's .spec file for years, given that upgrades from
> > > > > > Fedora 34 to 36 will need to be supported.
> > > > > >
> > > > >
> > > > > This is documented in the Change:
> > > > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> > > > >
> > > > > The part that's probably missing there is that the upgraded package
> > > > > will release ownership of /var/lib/rpm and own the
> > > > > /usr/lib/sysimage/rpm directory.
> > > > >
> > > > > The configuration will change in the upgrade, and then an rpmdb
> > > > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > > > > done by loading the rpmdb in memory, renaming the directory,
> > > > > recreating it, and re-initializing the database files from memory.
> > > > >
> > > > > This avoids the pitfalls you've described with the pretrans stuff.
> > > >
> > > > Oh, great. Looks like I'm ~tired~ and missed that this is in the
> > > > Change proposal after all ...
> > > > Thanks for confirming that you found a way to handle upgrades.
> > >
> > > I did a manual proof of concept with the pseudo-sequence in the change
> > > proposal on a Fedora Rawhide VM. And it did work, and continues to do
> > > both GNOME Software and dnf updates OK. This is a sample size of 1, so
> > > there's more work to do to make sure it can be done safely, using the
> > > rpm sqlite upgrade as a guide. But I can write up the steps I used, so
> > > that anyone can test before we have it wired up.
> > >
> > > We have considered not applying the change to upgrades. Strictly
> > > speaking the release criterion say we only support upgrades from
> > > *clean installs* of the current two releases. But in practice quite a
> > > lot of users depend on reliable upgrades for *many* releases, and they
> > > get mad when things break even when it's been 10+ releases since they
> > > did a clean install. And also, Workstation edition PRD  "upgrade
> > > process should give a result that is the same as an original install".
> > > That is a tall order, but so long as it's safe, it's probably better
> > > to apply this change to upgrades. If we run into issues or establish
> > > the risk is too high, it's not such a big deal to apply the change to
> > > only new clean installs.
> >
> > I'm personally concerned that the RPM transactions may not be handled
> > atomically if the /var/lib/rpm/ is migrated in the midst of an RPM
> > update. I'm not personally sure if RPM and Berkeley DB will handle
> > that correctly if there's any issues with the migration, particularly
> > if /usr/ overflows in the process of other bulky updates such as
> > libreoffice. Part of my work involves looking for where multiple
> > things can go wrong at once.
>
> Sqlite applies here, not bdb.
>
> But also note from that change, the rpmdb conversion to sqlite was not
> done during the system upgrade, but by a systemd unit.
> https://fedoraproject.org/wiki/Changes/S

Re: Unannounced soname bump of libre2

2022-01-08 Thread Kevin Fenzi 
On Sat, Jan 08, 2022 at 11:56:04PM +0900, Mamoru TASAKA wrote:
> Miro Hrončok wrote on 2022/01/08 20:05:
> > On 08. 01. 22 11:39, Miro Hrončok wrote:
> > > The re2 package was updated today in Rawhide and bumped soname from 
> > > libre2.so.0a to libre2.so.9.
> > > 
> > > https://src.fedoraproject.org/rpms/re2/c/dafa514
> > > 
> > > Seven packages are broken:
> > > 
> > > dnsdist: https://bugzilla.redhat.com/show_bug.cgi?id=2038544
> > fails to build, not sure if re2 related
> 
> There is at least a fault on new re2, filed:
> https://bugzilla.redhat.com/show_bug.cgi?id=2038572
> 
> > > frr: https://bugzilla.redhat.com/show_bug.cgi?id=2038545
> > depends on grpc
> > 
> > > grpc: https://bugzilla.redhat.com/show_bug.cgi?id=2038546
> > fails to build due to another unrelated fails to install bug
> > 
> > > qt5-qtwebengine: https://bugzilla.redhat.com/show_bug.cgi?id=2038551
> > fails to build, re2 related

Just FYI, the qt5-qtwebengine breakage is breaking rawhide composes
starting today. ;( 

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Chris Murphy 
On Sat, Jan 8, 2022 at 6:07 PM Nico Kadel-Garcia  wrote:
>
> On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy  wrote:
> >
> > On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  wrote:
> > >
> > > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> > > >
> > > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  
> > > > wrote:
> > > > >
> > > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> > > > > >
> > > > >
> > > > > (snip)
> > > > >
> > > > > >
> > > > > > == Detailed Description ==
> > > > > > === Current location ===
> > > > > > /var/lib/rpm
> > > > > >
> > > > > > === New location ===
> > > > > > /usr/lib/sysimage/rpm
> > > > > >
> > > > > > /var/lib/rpm will be a symlink pointing to
> > > > > > /usr/lib/sysimage/rpm
> > > > >
> > > > > I did not find a mention of this in the thread or in the Change
> > > > > proposal, so I'll ask:
> > > > > How do you plan to handle the directory -> symlink replacement on 
> > > > > upgrade?
> > > > >
> > > > > As far as I can tell, those always required special treatment via
> > > > > %pretrans scriptlets or something, and even the method currently
> > > > > recommended by the Packaging Guidelines seems to be broken due to the
> > > > > way dnf / RPM verifies validity of transactions.
> > > > >
> > > > > Additionally, that "special" handling will probably need to stay in
> > > > > the RPM package's .spec file for years, given that upgrades from
> > > > > Fedora 34 to 36 will need to be supported.
> > > > >
> > > >
> > > > This is documented in the Change:
> > > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> > > >
> > > > The part that's probably missing there is that the upgraded package
> > > > will release ownership of /var/lib/rpm and own the
> > > > /usr/lib/sysimage/rpm directory.
> > > >
> > > > The configuration will change in the upgrade, and then an rpmdb
> > > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > > > done by loading the rpmdb in memory, renaming the directory,
> > > > recreating it, and re-initializing the database files from memory.
> > > >
> > > > This avoids the pitfalls you've described with the pretrans stuff.
> > >
> > > Oh, great. Looks like I'm ~tired~ and missed that this is in the
> > > Change proposal after all ...
> > > Thanks for confirming that you found a way to handle upgrades.
> >
> > I did a manual proof of concept with the pseudo-sequence in the change
> > proposal on a Fedora Rawhide VM. And it did work, and continues to do
> > both GNOME Software and dnf updates OK. This is a sample size of 1, so
> > there's more work to do to make sure it can be done safely, using the
> > rpm sqlite upgrade as a guide. But I can write up the steps I used, so
> > that anyone can test before we have it wired up.
> >
> > We have considered not applying the change to upgrades. Strictly
> > speaking the release criterion say we only support upgrades from
> > *clean installs* of the current two releases. But in practice quite a
> > lot of users depend on reliable upgrades for *many* releases, and they
> > get mad when things break even when it's been 10+ releases since they
> > did a clean install. And also, Workstation edition PRD  "upgrade
> > process should give a result that is the same as an original install".
> > That is a tall order, but so long as it's safe, it's probably better
> > to apply this change to upgrades. If we run into issues or establish
> > the risk is too high, it's not such a big deal to apply the change to
> > only new clean installs.
>
> I'm personally concerned that the RPM transactions may not be handled
> atomically if the /var/lib/rpm/ is migrated in the midst of an RPM
> update. I'm not personally sure if RPM and Berkeley DB will handle
> that correctly if there's any issues with the migration, particularly
> if /usr/ overflows in the process of other bulky updates such as
> libreoffice. Part of my work involves looking for where multiple
> things can go wrong at once.

Sqlite applies here, not bdb.

But also note from that change, the rpmdb conversion to sqlite was not
done during the system upgrade, but by a systemd unit.
https://fedoraproject.org/wiki/Changes/Sqlite_Rpmdb

Same for this change proposal.


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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Neal Gompa 
On Sat, Jan 8, 2022 at 8:07 PM Nico Kadel-Garcia  wrote:
>
> On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy  wrote:
> >
> > On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  wrote:
> > >
> > > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> > > >
> > > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  
> > > > wrote:
> > > > >
> > > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> > > > > >
> > > > >
> > > > > (snip)
> > > > >
> > > > > >
> > > > > > == Detailed Description ==
> > > > > > === Current location ===
> > > > > > /var/lib/rpm
> > > > > >
> > > > > > === New location ===
> > > > > > /usr/lib/sysimage/rpm
> > > > > >
> > > > > > /var/lib/rpm will be a symlink pointing to
> > > > > > /usr/lib/sysimage/rpm
> > > > >
> > > > > I did not find a mention of this in the thread or in the Change
> > > > > proposal, so I'll ask:
> > > > > How do you plan to handle the directory -> symlink replacement on 
> > > > > upgrade?
> > > > >
> > > > > As far as I can tell, those always required special treatment via
> > > > > %pretrans scriptlets or something, and even the method currently
> > > > > recommended by the Packaging Guidelines seems to be broken due to the
> > > > > way dnf / RPM verifies validity of transactions.
> > > > >
> > > > > Additionally, that "special" handling will probably need to stay in
> > > > > the RPM package's .spec file for years, given that upgrades from
> > > > > Fedora 34 to 36 will need to be supported.
> > > > >
> > > >
> > > > This is documented in the Change:
> > > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> > > >
> > > > The part that's probably missing there is that the upgraded package
> > > > will release ownership of /var/lib/rpm and own the
> > > > /usr/lib/sysimage/rpm directory.
> > > >
> > > > The configuration will change in the upgrade, and then an rpmdb
> > > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > > > done by loading the rpmdb in memory, renaming the directory,
> > > > recreating it, and re-initializing the database files from memory.
> > > >
> > > > This avoids the pitfalls you've described with the pretrans stuff.
> > >
> > > Oh, great. Looks like I'm ~tired~ and missed that this is in the
> > > Change proposal after all ...
> > > Thanks for confirming that you found a way to handle upgrades.
> >
> > I did a manual proof of concept with the pseudo-sequence in the change
> > proposal on a Fedora Rawhide VM. And it did work, and continues to do
> > both GNOME Software and dnf updates OK. This is a sample size of 1, so
> > there's more work to do to make sure it can be done safely, using the
> > rpm sqlite upgrade as a guide. But I can write up the steps I used, so
> > that anyone can test before we have it wired up.
> >
> > We have considered not applying the change to upgrades. Strictly
> > speaking the release criterion say we only support upgrades from
> > *clean installs* of the current two releases. But in practice quite a
> > lot of users depend on reliable upgrades for *many* releases, and they
> > get mad when things break even when it's been 10+ releases since they
> > did a clean install. And also, Workstation edition PRD  "upgrade
> > process should give a result that is the same as an original install".
> > That is a tall order, but so long as it's safe, it's probably better
> > to apply this change to upgrades. If we run into issues or establish
> > the risk is too high, it's not such a big deal to apply the change to
> > only new clean installs.
>
> I'm personally concerned that the RPM transactions may not be handled
> atomically if the /var/lib/rpm/ is migrated in the midst of an RPM
> update. I'm not personally sure if RPM and Berkeley DB will handle
> that correctly if there's any issues with the migration, particularly
> if /usr/ overflows in the process of other bulky updates such as
> libreoffice. Part of my work involves looking for where multiple
> things can go wrong at once.

We're not doing the migration during the transaction itself.



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Nico Kadel-Garcia 
On Sat, Jan 8, 2022 at 7:53 PM Chris Murphy  wrote:
>
> On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  wrote:
> >
> > On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> > >
> > > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  
> > > wrote:
> > > >
> > > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> > > > >
> > > >
> > > > (snip)
> > > >
> > > > >
> > > > > == Detailed Description ==
> > > > > === Current location ===
> > > > > /var/lib/rpm
> > > > >
> > > > > === New location ===
> > > > > /usr/lib/sysimage/rpm
> > > > >
> > > > > /var/lib/rpm will be a symlink pointing to
> > > > > /usr/lib/sysimage/rpm
> > > >
> > > > I did not find a mention of this in the thread or in the Change
> > > > proposal, so I'll ask:
> > > > How do you plan to handle the directory -> symlink replacement on 
> > > > upgrade?
> > > >
> > > > As far as I can tell, those always required special treatment via
> > > > %pretrans scriptlets or something, and even the method currently
> > > > recommended by the Packaging Guidelines seems to be broken due to the
> > > > way dnf / RPM verifies validity of transactions.
> > > >
> > > > Additionally, that "special" handling will probably need to stay in
> > > > the RPM package's .spec file for years, given that upgrades from
> > > > Fedora 34 to 36 will need to be supported.
> > > >
> > >
> > > This is documented in the Change:
> > > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> > >
> > > The part that's probably missing there is that the upgraded package
> > > will release ownership of /var/lib/rpm and own the
> > > /usr/lib/sysimage/rpm directory.
> > >
> > > The configuration will change in the upgrade, and then an rpmdb
> > > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > > done by loading the rpmdb in memory, renaming the directory,
> > > recreating it, and re-initializing the database files from memory.
> > >
> > > This avoids the pitfalls you've described with the pretrans stuff.
> >
> > Oh, great. Looks like I'm ~tired~ and missed that this is in the
> > Change proposal after all ...
> > Thanks for confirming that you found a way to handle upgrades.
>
> I did a manual proof of concept with the pseudo-sequence in the change
> proposal on a Fedora Rawhide VM. And it did work, and continues to do
> both GNOME Software and dnf updates OK. This is a sample size of 1, so
> there's more work to do to make sure it can be done safely, using the
> rpm sqlite upgrade as a guide. But I can write up the steps I used, so
> that anyone can test before we have it wired up.
>
> We have considered not applying the change to upgrades. Strictly
> speaking the release criterion say we only support upgrades from
> *clean installs* of the current two releases. But in practice quite a
> lot of users depend on reliable upgrades for *many* releases, and they
> get mad when things break even when it's been 10+ releases since they
> did a clean install. And also, Workstation edition PRD  "upgrade
> process should give a result that is the same as an original install".
> That is a tall order, but so long as it's safe, it's probably better
> to apply this change to upgrades. If we run into issues or establish
> the risk is too high, it's not such a big deal to apply the change to
> only new clean installs.

I'm personally concerned that the RPM transactions may not be handled
atomically if the /var/lib/rpm/ is migrated in the midst of an RPM
update. I'm not personally sure if RPM and Berkeley DB will handle
that correctly if there's any issues with the migration, particularly
if /usr/ overflows in the process of other bulky updates such as
libreoffice. Part of my work involves looking for where multiple
things can go wrong at once.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Chris Murphy 
On Sat, Jan 8, 2022 at 7:53 AM Fabio Valentini  wrote:
>
> On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
> >
> > On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  wrote:
> > >
> > > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> > > >
> > >
> > > (snip)
> > >
> > > >
> > > > == Detailed Description ==
> > > > === Current location ===
> > > > /var/lib/rpm
> > > >
> > > > === New location ===
> > > > /usr/lib/sysimage/rpm
> > > >
> > > > /var/lib/rpm will be a symlink pointing to
> > > > /usr/lib/sysimage/rpm
> > >
> > > I did not find a mention of this in the thread or in the Change
> > > proposal, so I'll ask:
> > > How do you plan to handle the directory -> symlink replacement on upgrade?
> > >
> > > As far as I can tell, those always required special treatment via
> > > %pretrans scriptlets or something, and even the method currently
> > > recommended by the Packaging Guidelines seems to be broken due to the
> > > way dnf / RPM verifies validity of transactions.
> > >
> > > Additionally, that "special" handling will probably need to stay in
> > > the RPM package's .spec file for years, given that upgrades from
> > > Fedora 34 to 36 will need to be supported.
> > >
> >
> > This is documented in the Change:
> > https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
> >
> > The part that's probably missing there is that the upgraded package
> > will release ownership of /var/lib/rpm and own the
> > /usr/lib/sysimage/rpm directory.
> >
> > The configuration will change in the upgrade, and then an rpmdb
> > rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> > done by loading the rpmdb in memory, renaming the directory,
> > recreating it, and re-initializing the database files from memory.
> >
> > This avoids the pitfalls you've described with the pretrans stuff.
>
> Oh, great. Looks like I'm ~tired~ and missed that this is in the
> Change proposal after all ...
> Thanks for confirming that you found a way to handle upgrades.

I did a manual proof of concept with the pseudo-sequence in the change
proposal on a Fedora Rawhide VM. And it did work, and continues to do
both GNOME Software and dnf updates OK. This is a sample size of 1, so
there's more work to do to make sure it can be done safely, using the
rpm sqlite upgrade as a guide. But I can write up the steps I used, so
that anyone can test before we have it wired up.

We have considered not applying the change to upgrades. Strictly
speaking the release criterion say we only support upgrades from
*clean installs* of the current two releases. But in practice quite a
lot of users depend on reliable upgrades for *many* releases, and they
get mad when things break even when it's been 10+ releases since they
did a clean install. And also, Workstation edition PRD  "upgrade
process should give a result that is the same as an original install".
That is a tall order, but so long as it's safe, it's probably better
to apply this change to upgrades. If we run into issues or establish
the risk is too high, it's not such a big deal to apply the change to
only new clean installs.


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

Re: Need help with some rpmlint errors

2022-01-08 Thread Jerry James 
On Sat, Jan 8, 2022 at 6:37 AM Mattia Verga via devel
 wrote:
> `E: shared-library-without-dependency-information
> /usr/lib64/libapogee.so.3.2`
> I'm not sure if this is a rpmlint false positive. All I can found
> searching is an issue in rpmlint which says that the library could be
> statically linked [3], but running ldd on the file shows it is shared.
> (as far I understand, I'm not a software developer)

I see this happen with libraries that do not depend on any symbols in
libc.  Check pretty much any ocaml-* package, for example, and rpmlint
will report this.  If your library functions as expected, then ignore
this message.

> `E: missing-PT_GNU_STACK-section /usr/lib64/libapogee.so.3.2`
> I can't find anything searching for this online. Maybe another false
> positive?

This means that the toolchain thinks your library needs an executable
stack.  That usually happens because the project includes assembly
language files, and those files do not contain the magic to tell the
toolchain that the stack does not need to be executable.  Try adding
-Wa,--noexecstack to the build flags or -Wl,-z,noexecstack to the
linker flags.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Self Introduction: Malcolm Inglis (mcinglis)

2022-01-08 Thread Otto Urpelainen 

Kevin Fenzi kirjoitti 8.1.2022 klo 1.23:

On Fri, Jan 07, 2022 at 11:43:15PM +0200, Otto Urpelainen wrote:


I can give a couple of reasons why just using the packager-sponsors tracker
always would be better. This is from the point of view of somebody who had
to find a sponsor. I am not a sponsor myself, so I do not really know this
looks from that side.

1. The process is currently so complicated that newcomers are frequently
confused and dissuaded by it. Having just a single way would make it
simpler. Of these two options, the single way would have to be the tracker,
because the FE-NEEDSPONSOR method only works for new package submissions.

2. In the tracker, you can write your "letter of application" in the
description, and add all the proof you have. So you can first evaluate
yourself, gather more proof if you think it will be needed, and only submit
an application when you feel you are ready. For FE-NEEDSPONSOR, it is not so
clear. The same thing can be done in the review request comments, of course.
But then the review request and the sponsorship request get mixed up, but
actually they are two different things.

3. It may be just my impression, but the system of adding the FE-NEEDSPONSOR
link feels a bit like "don't call us, we'll call you". Saying that you can
file an issue and it will be looked at feels more friendly and inviting.


Sure, I agree with all of that. However, If everyone who wanted to be
added to packager was told to file a issue, I am not at all sure we
can promise 'it would be looked at'. All the packager-sponsors tickets
go to everyone in the packager sponsors group, but I've only ever seen a
small fraction of them respond to any tickets. ;( I am not sure if thats
because they don't want to deal with sponsoring co-maintainers (the
current 'reason' to file a ticket there) or something else, but I worry
that it would just result in a big backlog of tickets there. :(


Ok, I start to see this better now. I was under the impression that both 
FE-NEEDSPONSOR and the tracker were on equal footing and generally 
speakin, receive similar attention from the sponsors. But, if the reason 
for having the tracker is (or: originally was) just the co-maintainer 
requests, where the primary maintainer actually mentors the new 
packager, then it makes sense that just a couple of sponsors keep an eye 
on that tracker and accept the request on behalf of the primary maintainers.



Additionally, I fear it would also leed to 'HI, make me a packager' type
tickets (with no other info). We could of course close those or ask for
more info, but then someone has to manage that.


One easy thing that can be done now is to add an issue template to the 
tracker repo.



Apart from co-maintenance, the tracker is also important for the case where
somebody wants to become a pacakger to rescue an orphaned package.


Well, in the past we have asked such folks to file a review request and
get the orphaned package re-reviewed.


Interesting. Previously, there was no documented process for handling 
this case at all, so I wrote section "Adopting orphaned packages" [1] to 
How to Get Sponsored page. As you can see, that section currently points 
to the tracker. Do you think we should change that to ask for a 
re-review? The current wording is not just my invention, though. There 
was discussion on devel first, and the change went through a docs pull 
request.


In case a review is required, I would like to understand, why? My 
understanding was this: Orphaned packages are assumed to be is 
acceptable condition, because existing maintainers can adopt them 
without a review. The new packager are assumed to be equal to existing 
maintainers, because somebody has agreed to sponsor them and is 
available for mentoring as needed. Some caution is certainly needed, 
since some orphaned packages can be minefields, it just did not occur to 
me that package review would be the appropriate safeguard here.


[1]: 
https://docs.fedoraproject.org/en-US/package-maintainers/How_to_Get_Sponsored_into_the_Packager_Group/#adopting_orphaned_packages

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

Re: [Discussion] Future of the CLI APP packaging

2022-01-08 Thread Jiri Konecny 



Dne 08. 01. 22 v 15:28 Fabio Valentini napsal(a):

On Sat, Jan 8, 2022 at 3:08 PM Jiri Konecny  wrote:
(snip)


I really can't blame the people. Not everyone has the week of time to
package all the dependencies
one by one. But COPR is a nice shortcut to that so I can have what the
upstream is producing
without spending so much time and just re-using binaries produced
upstream. The same works for
pinging people to update their packages.

On the other hand ... if you don't have the time to properly maintain
a package, maybe you shouldn't push it to the official Fedora
repositories at all?
This only results in the worst outcome: Frustration for the packager
(don't have time to properly update) *and* users (package in Fedora is
out of date).
Pushing things in a
not-entirely-packaging-guidelines-compliant-but-maintainable-with-limited-time
form to COPR would be a way better solution here from the start.
I understand your point but this kind of packaging is starting to be so 
demanding
that I fear that only a few people will be able to have packages in the 
Fedora in

the future. And those will be pretty overloaded.

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

Re: Heads up: libffi 3.4 rebuild in rawhide today

2022-01-08 Thread Miro Hrončok 

On 08. 01. 22 10:37, Miro Hrončok wrote:
I intent to rebuild the following packages with libffi 3.4 in Rawhide side tag 
f36-build-side-49314 today.


The update: https://bodhi.fedoraproject.org/updates/FEDORA-2022-c440651258

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads up: libffi 3.4 rebuild in rawhide today

2022-01-08 Thread Miro Hrončok 

On 08. 01. 22 18:09, Carlos O'Donell wrote:

https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/cjs/
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/gjs/
both "killed by signal 11 SIGSEGV"

Right, this is because there is an ordering dependency between 
gobject-introspection and
cjs/gjs. You need the introspection library rebuilt first with libffi 3.4+ and 
then build
the javascript packages, that way they both have the same library and can pass 
objects
back and forth for introspection.


Indeed. Second build works nicely. I was sure I've tried that, but apparently 
not.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Heads up: libffi 3.4 rebuild in rawhide today

2022-01-08 Thread Carlos O'Donell 
On 1/8/22 04:37, Miro Hrončok wrote:
> Hello packagers,
> 
> I intent to rebuild the following packages with libffi 3.4 in Rawhide side 
> tag f36-build-side-49314 today.

Thank you for helping with the rebuilds!
 
> The previous version remains available as libffi13.1, so failures to build 
> will not result in uninstallable packages.
> 
> You can inspect some known failures:
> 
> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/cjs/
> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/gjs/
> both "killed by signal 11 SIGSEGV"

Right, this is because there is an ordering dependency between 
gobject-introspection and
cjs/gjs. You need the introspection library rebuilt first with libffi 3.4+ and 
then build
the javascript packages, that way they both have the same library and can pass 
objects
back and forth for introspection.
 
> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/hadolint/
> Not all RPM dependencies satisfied

Agreed.

DEBUG util.py:444:  No matching package to install: 'ghc-colourista-prof'
DEBUG util.py:444:  No matching package to install: 'ghc-ilist-prof'
DEBUG util.py:444:  No matching package to install: 'ghc-spdx-prof'
DEBUG util.py:444:  No matching package to install: 'ghc-timerep-prof'
DEBUG util.py:444:  Not all dependencies satisfied
DEBUG util.py:444:  Error: Some packages could not be found.

Rawhide did build successfully on 2021-11-30, but that was while ago and the 
deps have issues now.

> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/jffi/
> make: *** No rule to make target '-L/usr/lib64/../lib64', needed by 
> '/builddir/build/BUILD/jffi-jffi-1.3.4/build/jni/jffi/Array.o'.  Stop.

I don't know why this one fails. Passed in c9s with earlier jffi and libffi 3.4.

Rawhide did build successfully on 2021-08-22, but that was a while ago.

> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/ruby/
> Segmentation fault
> FAIL 1/1489 tests failed

This failed in the same place in two different builds in the test_ractor.rb 
(Ruby Ractor)
test case, and it crashes in 'ractor_select()' within 'rb_vm_exec()'.

This is odd that it should fail with the libffi update since this the failure 
is in the
Ruby Ractor test, which I wouldn't expect to use any of the FFI APIs. It has 
failed
twice though in the same place.

I didn't see this in c9s. The last built ruby in c9s was built by me and it is 
3.0.2-155,
where test_ractor.rb passes just fine built with libffi 3.4.

The ruby-mri binary has no deep DT_NEEDED dependencies which should need libffi 
or other
libraries to be built in a particular order, but with dlopen you can get odd 
ordering
issues that are only resolved after the SONAME bump is complete and rebuilds 
completed
across dependent libraries.

Rawhide did build successfully on 2021-12-10.

> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/thunderbird/
> collect2: error: ld returned 1 exit status

The logs don't contain any more information. This is a static linker failure 
when building
libxul.so.

Rawhide did build successfully on 2021-12-15.
 
> https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/xs/
> Run-time dependency ffi found: NO (tried pkgconfig and cmake)

Run-time dependency ffi found: NO (tried pkgconfig and cmake)
Library ffi found: YES
^^
Run-time dependency gc found: NO (tried pkgconfig and cmake)
Library gc found: YES
Library gccpp found: YES
Run-time dependency readline found: YES 8.1
Program touch found: YES (/usr/bin/touch)
Program ../generators/buildinfo.sh found: NO
meson.build:24:2: ERROR: Program '../generators/buildinfo.sh' not found or not 
executable
  
^^^
A full log can be found at 
/builddir/build/BUILD/XS-789540c5f208b8e8f07fc81c3bec3d0ee47c6dea/build/meson-logs/meson-log.txt

xs has been FTBS since July 2021:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1805437

> 
> TIP: If your package is present in c9s, consider looking how it was fixed 
> there.
> 
> 
> The rest of the packages I'll rebuild (passed on x86_64 in copr):
> 
> Agda
> alex
> bench
> brainfuck
> bustle
> cab
> cabal-install
> cabal-rpm
> cpphs
> darcs
> dfuzzer
> dhall
> dhall-json
> dl-fedora
> ecl
> fbrnch
> firefox
> gambas3
> gforth
> ghc
> ghc-aeson-pretty
> ghc-cabal-helper
> ghc-clientsession
> ghc-criterion
> ghc-DAV
> ghc-doctest
> ghc-hakyll
> ghc-HaXml
> ghc-hgettext
> ghc-highlighting-kate
> ghc-hjsmin
> ghc-hspec-discover
> ghc-cheapskate
> ghcid
> ghc-libffi
> ghc-pretty-show
> ghc-servant-server
> ghc-vty
> ghc-wai-app-static
> ghc-wai-websockets
> ghc8.10
> ghc9.0
> ghc9.2
> git-annex
> gitit
> git-repair
> glib2
> gnustep-base
> gobject-introspection
> gtk2hs-buildtools
> guile
> guile22
> guile30
> happy
> haskell-platform
> hedgewars
> hledger
> hledger-ui
> hledger-web
> hlint
> hscolour
> idris
> jna
> libomp

Re: Unannounced soname bump of libre2

2022-01-08 Thread Mamoru TASAKA 

Miro Hrončok wrote on 2022/01/08 20:05:

On 08. 01. 22 11:39, Miro Hrončok wrote:

The re2 package was updated today in Rawhide and bumped soname from 
libre2.so.0a to libre2.so.9.

https://src.fedoraproject.org/rpms/re2/c/dafa514

Seven packages are broken:

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

fails to build, not sure if re2 related


There is at least a fault on new re2, filed:
https://bugzilla.redhat.com/show_bug.cgi?id=2038572


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

depends on grpc


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

fails to build due to another unrelated fails to install bug


qt5-qtwebengine: https://bugzilla.redhat.com/show_bug.cgi?id=2038551

fails to build, re2 related

The rest (bloaty, perl-re-engine-RE2, python-fb-re2) seems to build fine, at 
least on some architectures.

%57 failure rate :(


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

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Fabio Valentini 
On Sat, Jan 8, 2022 at 3:39 PM Neal Gompa  wrote:
>
> On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  wrote:
> >
> > On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> > >
> >
> > (snip)
> >
> > >
> > > == Detailed Description ==
> > > === Current location ===
> > > /var/lib/rpm
> > >
> > > === New location ===
> > > /usr/lib/sysimage/rpm
> > >
> > > /var/lib/rpm will be a symlink pointing to
> > > /usr/lib/sysimage/rpm
> >
> > I did not find a mention of this in the thread or in the Change
> > proposal, so I'll ask:
> > How do you plan to handle the directory -> symlink replacement on upgrade?
> >
> > As far as I can tell, those always required special treatment via
> > %pretrans scriptlets or something, and even the method currently
> > recommended by the Packaging Guidelines seems to be broken due to the
> > way dnf / RPM verifies validity of transactions.
> >
> > Additionally, that "special" handling will probably need to stay in
> > the RPM package's .spec file for years, given that upgrades from
> > Fedora 34 to 36 will need to be supported.
> >
>
> This is documented in the Change:
> https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact
>
> The part that's probably missing there is that the upgraded package
> will release ownership of /var/lib/rpm and own the
> /usr/lib/sysimage/rpm directory.
>
> The configuration will change in the upgrade, and then an rpmdb
> rebuild on reboot will finalize the transition, as rpmdb rebuilds are
> done by loading the rpmdb in memory, renaming the directory,
> recreating it, and re-initializing the database files from memory.
>
> This avoids the pitfalls you've described with the pretrans stuff.

Oh, great. Looks like I'm ~tired~ and missed that this is in the
Change proposal after all ...
Thanks for confirming that you found a way to handle upgrades.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Neal Gompa 
On Sat, Jan 8, 2022 at 8:58 AM Fabio Valentini  wrote:
>
> On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
> >
>
> (snip)
>
> >
> > == Detailed Description ==
> > === Current location ===
> > /var/lib/rpm
> >
> > === New location ===
> > /usr/lib/sysimage/rpm
> >
> > /var/lib/rpm will be a symlink pointing to
> > /usr/lib/sysimage/rpm
>
> I did not find a mention of this in the thread or in the Change
> proposal, so I'll ask:
> How do you plan to handle the directory -> symlink replacement on upgrade?
>
> As far as I can tell, those always required special treatment via
> %pretrans scriptlets or something, and even the method currently
> recommended by the Packaging Guidelines seems to be broken due to the
> way dnf / RPM verifies validity of transactions.
>
> Additionally, that "special" handling will probably need to stay in
> the RPM package's .spec file for years, given that upgrades from
> Fedora 34 to 36 will need to be supported.
>

This is documented in the Change:
https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr#Upgrade.2Fcompatibility_impact

The part that's probably missing there is that the upgraded package
will release ownership of /var/lib/rpm and own the
/usr/lib/sysimage/rpm directory.

The configuration will change in the upgrade, and then an rpmdb
rebuild on reboot will finalize the transition, as rpmdb rebuilds are
done by loading the rpmdb in memory, renaming the directory,
recreating it, and re-initializing the database files from memory.

This avoids the pitfalls you've described with the pretrans stuff.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Discussion] Future of the CLI APP packaging

2022-01-08 Thread Fabio Valentini 
On Sat, Jan 8, 2022 at 3:08 PM Jiri Konecny  wrote:
>

(snip)

>
> I really can't blame the people. Not everyone has the week of time to
> package all the dependencies
> one by one. But COPR is a nice shortcut to that so I can have what the
> upstream is producing
> without spending so much time and just re-using binaries produced
> upstream. The same works for
> pinging people to update their packages.

On the other hand ... if you don't have the time to properly maintain
a package, maybe you shouldn't push it to the official Fedora
repositories at all?
This only results in the worst outcome: Frustration for the packager
(don't have time to properly update) *and* users (package in Fedora is
out of date).
Pushing things in a
not-entirely-packaging-guidelines-compliant-but-maintainable-with-limited-time
form to COPR would be a way better solution here from the start.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [Discussion] Future of the CLI APP packaging

2022-01-08 Thread Jiri Konecny 



Dne 08. 01. 22 v 1:08 Fabio Valentini napsal(a):

On Fri, Jan 7, 2022 at 9:48 PM Jiri Konecny  wrote:

Hi everyone,

I would like to do here a bit of brainstorming and ask if there is an
existing solution to this problem. To explain my problem,
recently I found more and more apps likes terminals, prompt and command
line tooling, which are great to use but not
packaged or are outdated in our repositories. The reason for this is
simple. These apps are written in languages like Rust or
Go which works the way that there are plenty of smaller libraries and
these are really a hell to package or maintain in
Fedora. On the other hand it's pretty simple to build it from the source
(most of the time) but hard to split it into packages.

Hello!

(I'd argue that most popular Rust libraries really are not small at
all. Some are, but some are large. Most are medium-sized, as Rust does
not have the same incentives as, for example, NodeJS, to publish
single-function-modules.)

I did not programmed much in Rust so I can't tell. :)



Great example of this is Startship command line prompt, we have outdated
version but when you look to dependencies[1]
you have to completely understand.

There is a slight problem with picking starship as an example here.
Because it is almost certainly the Rust application with the largest
number of (direct) dependencies.

The starship project also frequently adds new dependencies with new
versions, and aggressively uses new major versions of dependencies,
both of which make updating it very painful (which is also why the
package maintainer seemingly gave up on the Fedora package and now
only updates it in COPR).

Another example is chezmoi:
https://github.com/twpayne/chezmoi/blob/master/go.mod#L5

Not packaged in Fedora at all. However, a great tool for solving your 
dotfiles.
Upstream recommended way how to install this -> curl install script to 
bash... :(

However, they also have RPM files (without repository).



I don't want to start here a discussion if that is insecure or a good
idea. That is something which has to be solved by
people creating the ecosystem around these languages. What I would like
to discuss here is how Fedora could improve
the situation.

Where you see a technological problem, I see a deeper problem with the
way we do package maintenance.

Many packagers came to the Rust ecosystem because they wanted to add
"that one cool new application" to Fedora. But they usually don't have
the time to care about their dependencies too, other than maybe doing
the initial packaging and then throwing them over the rust-sig wall.

On the other hand, there's people like me, who try to keep the
lower-level libraries up-to-date, monitor security advisories, etc.,
but obviously I can't care about updating shiny application X or
the-new-hotness Y as well - because I just don't have the time. And I
don't think making sure somebody else can update their package is my
responsibility.

That disconnect between "application maintainers" and "library
maintainers" is often frustrating. Application maintainers grumble
about having to file new package review tickets, and that their
dependencies are out of date. Library maintainers often update
libraries to new major versions only "as needed", because those major
changes often involve creating compat packages or pushing coordinated
updates of all dependents of a library.

But often the "I can't update my shiny application X to the new
version! The libraries are out of date, you lazy library maintainers!"
(I'm exaggarating, but you get the point) is the result of missing
"major" updates that just weren't needed (or possible!) before shiny
application X needed the new version.

Additionally, some application maintainers are now no longer actively
maintaining their Fedora packages, but instead push updates only to
COPR, where they don't need to follow Packaging Guidelines. starship
is an example here [1]. While the COPR is up-to-date (with using
bundled dependencies), the Fedora package could be described as
unmaintained.
I really can't blame the people. Not everyone has the week of time to 
package all the dependencies
one by one. But COPR is a nice shortcut to that so I can have what the 
upstream is producing
without spending so much time and just re-using binaries produced 
upstream. The same works for

pinging people to update their packages.


[1]: https://copr.fedorainfracloud.org/coprs/atim/starship/


I would say, that for GUI apps we already done that. We have Flatpak
which is doing great job to get these apps there
and motivate people to do that because it's then consumable on plenty of
places. However, this is not really usable if you
need app which is core part of the system (like prompt) or emacs/vim
which needs a lot of dependencies from the system
based on user configuration.

My question is, what we can do to avoid situations as in Windows? I mean
that first thing what Win users are doing is to
look on internet and start to download

Re: F36 Change: Relocate RPM database to /usr (System-Wide Change proposal)

2022-01-08 Thread Fabio Valentini 
On Wed, Dec 29, 2021 at 4:03 PM Ben Cotton  wrote:
>

(snip)

>
> == Detailed Description ==
> === Current location ===
> /var/lib/rpm
>
> === New location ===
> /usr/lib/sysimage/rpm
>
> /var/lib/rpm will be a symlink pointing to
> /usr/lib/sysimage/rpm

I did not find a mention of this in the thread or in the Change
proposal, so I'll ask:
How do you plan to handle the directory -> symlink replacement on upgrade?

As far as I can tell, those always required special treatment via
%pretrans scriptlets or something, and even the method currently
recommended by the Packaging Guidelines seems to be broken due to the
way dnf / RPM verifies validity of transactions.

Additionally, that "special" handling will probably need to stay in
the RPM package's .spec file for years, given that upgrades from
Fedora 34 to 36 will need to be supported.

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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Need help with some rpmlint errors

2022-01-08 Thread Mattia Verga via devel 
In Fedora we provide several different packages for libraries and
drivers from INDI [1] we can ship (due to patent issues).

As this requires a lot of work, I'm starting to create a single package
for all libraries. I've started to do a scratch build on COPR [2] with
only the libapogee library, but while working on this I discovered that
running rpmlint both on new package and the one currently in Fedora
repositories (libapogee) points out several errors:

`E: shared-library-without-dependency-information
/usr/lib64/libapogee.so.3.2`
I'm not sure if this is a rpmlint false positive. All I can found
searching is an issue in rpmlint which says that the library could be
statically linked [3], but running ldd on the file shows it is shared.
(as far I understand, I'm not a software developer)

`E: missing-PT_GNU_STACK-section /usr/lib64/libapogee.so.3.2`
I can't find anything searching for this online. Maybe another false
positive?

Is there anyone that can shed some light on what's happening?Thanks
Mattia

[1] https://github.com/indilib/indi-3rdparty
[2] https://copr.fedorainfracloud.org/coprs/mattia/Astronomy/build/3134210/
[3] https://github.com/rpm-software-management/rpmlint/issues/361
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unretire python-trml2pdf

2022-01-08 Thread Vitaly Zaitsev via devel 

On 08/01/2022 13:09, Евгений Пивнев wrote:

What to do?


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

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Unretire python-trml2pdf

2022-01-08 Thread Евгений Пивнев 
Package is 'Review-request'ed and approved: 
https://bugzilla.redhat.com/show_bug.cgi?id=1922783 

But pagure reject all requests:

```bash
bash-5.1$ LC_ALL=C git push
Enumerating objects: 8, done.
Counting objects: 100% (8/8), done.
Delta compression using up to 2 threads
Compressing objects: 100% (6/6), done.
Writing objects: 100% (7/7), 1.26 KiB | 1.26 MiB/s, done.
Total 7 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Branch refs/heads/main is unsupported
remote: Denied push for ref 'refs/heads/main' for user 'tieugene'
remote: Branch refs/heads/rawhide is unsupported
remote: Denied push for ref 'refs/heads/rawhide' for user 'tieugene'
remote: All changes have been rejected
To ssh://pkgs.fedoraproject.org/rpms/python-trml2pdf
 ! [remote rejected] main -> main (pre-receive hook declined)
 ! [remote rejected] rawhide -> rawhide (pre-receive hook declined)
error: failed to push some refs to 
'ssh://pkgs.fedoraproject.org/rpms/python-trml2pdf'
```

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

Re: unretire luit and vttest

2022-01-08 Thread Vitaly Zaitsev via devel 

On 07/01/2022 13:58, Thomas Dickey wrote:

I did that - see


I will review these packages and sponsor you to Fedora.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Sundials 6.0.0

2022-01-08 Thread Antonio T. sagitter 

What about bout++ ?

On 12/19/21 20:17, Antonio T. sagitter wrote:

Hi all.

Sundials-6.0.0 is available, it's a major release that includes many 
changes (https://github.com/LLNL/sundials/blob/master/CHANGELOG.md)


I compiled the new packages in Copr, rebuilt bout++ and octave which 
need attention before we can push them in Rawhide:

https://copr.fedorainfracloud.org/coprs/sagitter/ForTesting/builds/



--
---
Antonio Trande
Fedora Project
mailto: sagit...@fedoraproject.org
GPG key: 0xCC1CFEF30920C8AE
GPG key server: https://keyserver1.pgp.com/


OpenPGP_0xCC1CFEF30920C8AE.asc
Description: OpenPGP public key


OpenPGP_signature
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Unannounced soname bump of libre2

2022-01-08 Thread Miro Hrončok 

On 08. 01. 22 11:39, Miro Hrončok wrote:
The re2 package was updated today in Rawhide and bumped soname from 
libre2.so.0a to libre2.so.9.


https://src.fedoraproject.org/rpms/re2/c/dafa514

Seven packages are broken:

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


fails to build, not sure if re2 related


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


depends on grpc


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


fails to build due to another unrelated fails to install bug


qt5-qtwebengine: https://bugzilla.redhat.com/show_bug.cgi?id=2038551


fails to build, re2 related

The rest (bloaty, perl-re-engine-RE2, python-fb-re2) seems to build fine, at 
least on some architectures.


%57 failure rate :(

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Unannounced soname bump of libre2

2022-01-08 Thread Miro Hrončok 
The re2 package was updated today in Rawhide and bumped soname from 
libre2.so.0a to libre2.so.9.


https://src.fedoraproject.org/rpms/re2/c/dafa514

Seven packages are broken:

bloaty: https://bugzilla.redhat.com/show_bug.cgi?id=2038543
dnsdist: https://bugzilla.redhat.com/show_bug.cgi?id=2038544
frr: https://bugzilla.redhat.com/show_bug.cgi?id=2038545
grpc: https://bugzilla.redhat.com/show_bug.cgi?id=2038546
perl-re-engine-RE2: https://bugzilla.redhat.com/show_bug.cgi?id=2038549
python-fb-re2: https://bugzilla.redhat.com/show_bug.cgi?id=2038550
qt5-qtwebengine: https://bugzilla.redhat.com/show_bug.cgi?id=2038551

I'll submit rebuilds and hope for the best.

Denis, please coordinate soname bumps in the future before doing them, thanks.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [cfe-dev] Release 13.0.1-rc1 has been tagged

2022-01-08 Thread Tom Stellard 

On 1/1/22 12:54, Sean McBride wrote:

On 30 Nov 2021, at 1:07, Tom Stellard via cfe-dev wrote:


Testers can begin testing and uploading binaries.


It's been over a month since 13.0.1-rc1, and, as has been the case for many 
previous releases, there are no macOS binaries.  And chance we'll see some?



This has been uploaded now.

-Tom


Thanks,

Sean


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

Re: Heads up: libffi 3.4 rebuild in rawhide today

2022-01-08 Thread Miro Hrončok 

On 08. 01. 22 10:37, Miro Hrončok wrote:

Hello packagers,

I intent to rebuild the following packages with libffi 3.4 in Rawhide side tag 
f36-build-side-49314 today.


The previous version remains available as libffi13.1, so failures to build will 
not result in uninstallable packages.


You can inspect some known failures: ...


The rest of the packages I'll rebuild (passed on x86_64 in copr):

...

As always, please don't rebuild the package in regular rawhide until the side 
tag is merged.


For the record, I intent to build the following packages only after the side 
tag is merged because they build for a long time:


firefox
racket
llvm
llvm10
llvm11
llvm12
llvm7.0
llvm9.0
pypy
pypy3.7
pypy3.8

Thanks to the compat package, it should not break anything.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Heads up: libffi 3.4 rebuild in rawhide today

2022-01-08 Thread Miro Hrončok 

Hello packagers,

I intent to rebuild the following packages with libffi 3.4 in Rawhide side tag 
f36-build-side-49314 today.


The previous version remains available as libffi13.1, so failures to build will 
not result in uninstallable packages.


You can inspect some known failures:

https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/cjs/
https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/gjs/
both "killed by signal 11 SIGSEGV"

https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/hadolint/
Not all RPM dependencies satisfied

https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/jffi/
make: *** No rule to make target '-L/usr/lib64/../lib64', needed by 
'/builddir/build/BUILD/jffi-jffi-1.3.4/build/jni/jffi/Array.o'.  Stop.


https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/ruby/
Segmentation fault
FAIL 1/1489 tests failed

https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/thunderbird/
collect2: error: ld returned 1 exit status

https://copr.fedorainfracloud.org/coprs/churchyard/libffi-3.4/package/xs/
Run-time dependency ffi found: NO (tried pkgconfig and cmake)


TIP: If your package is present in c9s, consider looking how it was fixed there.


The rest of the packages I'll rebuild (passed on x86_64 in copr):

Agda
alex
bench
brainfuck
bustle
cab
cabal-install
cabal-rpm
cpphs
darcs
dfuzzer
dhall
dhall-json
dl-fedora
ecl
fbrnch
firefox
gambas3
gforth
ghc
ghc-aeson-pretty
ghc-cabal-helper
ghc-clientsession
ghc-criterion
ghc-DAV
ghc-doctest
ghc-hakyll
ghc-HaXml
ghc-hgettext
ghc-highlighting-kate
ghc-hjsmin
ghc-hspec-discover
ghc-cheapskate
ghcid
ghc-libffi
ghc-pretty-show
ghc-servant-server
ghc-vty
ghc-wai-app-static
ghc-wai-websockets
ghc8.10
ghc9.0
ghc9.2
git-annex
gitit
git-repair
glib2
gnustep-base
gobject-introspection
gtk2hs-buildtools
guile
guile22
guile30
happy
haskell-platform
hedgewars
hledger
hledger-ui
hledger-web
hlint
hscolour
idris
jna
libomp
librep
llvm
llvm10
llvm11
llvm12
llvm7.0
llvm9.0
lsfrom
lua-lgi
micropython
moarvm
ocaml-ctypes
ormolu
pagure-cli
pandoc
patat
perl-FFI-Platypus
perl-Glib-Object-Introspection
php
pkgtreediff
pygobject2
pygobject3
pypy
pypy3.7
pypy3.8
python-cffi
python2.7
python3.10
python3.11
python3.6
python3.7
python3.8
python3.9
p11-kit
racket
rhbzquery
rpmbuild-order
rubygem-ffi
seamonkey
shake
ShellCheck
squeak-vm
tart
unlambda
wayland
xmobar
xmonad
yosys

As always, please don't rebuild the package in regular rawhide until the side 
tag is merged.


--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Cloud-34-20220108.0 compose check report

2022-01-08 Thread Fedora compose checker 
No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20220107.0):

ID: 1098875 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1098875
ID: 1098886 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1098886

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [ELN] Why is rubygem-liquid included in eln?

2022-01-08 Thread Otto Urpelainen 

Troy Dawson kirjoitti 7.1.2022 klo 16.46:

On Fri, Jan 7, 2022 at 12:20 AM Otto Urpelainen  wrote:


I am the maintainer of rubygem-liquid package in Fedora. Every now and
then is receive notification that this package has been built and
updated for eln, for example [1,2].

I have been trying to understand why this package is included in eln. As
far as I can understand, it should be somehow visible in Content
Resolver [3]. I have not found a "search by package name" feature there,
so I have also grepped the content-resolver-input repository [4]. I
cannot find anything there, either.

Could somebody explain how this package ends up being included in eln?

The reason why I care is that I have deferred the Liquid 5 update in
Fedora on the basis that its only consumer, Jekyll, is still on 4. These
eln builds make me suspect that rubygem-liquid is used for something
else there. I would like to check with the correct people that my
decision to stay on 4 is ok for them, too.

Otto

[1]: http://koji.fedoraproject.org/koji/buildinfo?buildID=1873495
[2]: https://bodhi.fedoraproject.org/updates/FEDORA-2022-11b99445de
[3]: https://tiny.distro.builders/
[4]: https://github.com/minimization/content-resolver-input



It is a build dependency of  rubygem-sinatra and rubygem-tilt [5]
Currently, the only way to find that was to go into the buildroot section
of ELN
Views -> eln -> x86_64 -> buildroot

This problem of the build dependencies being sort of hidden is being worked
on.
We are hoping to have the next major release of Content Resolver out in a
month or two.  It will make it much easier to see why a package is in the
list.


Thank you Troy, that explains the situation. I also shows that my 
original query for Fedora reverse dependencies was the build-requires.


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

Fedora-Cloud-35-20220108.0 compose check report

2022-01-08 Thread Fedora compose checker 
No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20220107.0):

ID: 1098859 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1098859
ID: 1098870 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1098870

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure