DevHeads.net

Upgrade soname version of qrencode in Rawhide

Dear Fedora Devops,

qrencode (critpath) package has been updated in rawhide branch.

Major change:

If you need to report any issue:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1510097" title="https://bugzilla.redhat.com/show_bug.cgi?id=1510097">https://bugzilla.redhat.com/show_bug.cgi?id=1510097</a>

Koji build:
<a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494">https://koji.fedoraproject.org/koji/taskinfo?taskID=24100494</a>

Many packages requires libqrencode (systemd, etc...) so take care
about compatibility breakage.

best regards,

Comments

Re: [critpath] Upgrade soname version of qrencode in Rawhi

By Igor Gnatenko at 01/09/2018 - 16:12

Hash: SHA256

On Tue, 2018-01-09 at 20:37 +0100, Casper wrote:
Does it mean that maintainers of those packages should take care of them or
will you?

Sending email when you **broke** all builds in rawhide is pretty bad...

Re: [critpath] Upgrade soname version of qrencode in Rawhi

By =?ISO-8859-1?Q?... at 01/09/2018 - 16:41

On Tue, 2018-01-09 at 21:12 +0100, Igor Gnatenko wrote:
nothing provides libqrencode.so.3()(64bit) needed by systemd-236-
1.fc28.aarch64

seems to me pretty serious

Re: [critpath] Upgrade soname version of qrencode in Rawhi

By Casper at 01/09/2018 - 18:06

first, thanks for your remarks.

the build has been untagged (thanks for releng reactivity), so it
won't be a melodramatic movie about rawhide which is broken... oh
wait! look the mass-rebuild showing the point of its nose...

seriously.

I will miss the next mass-rebuild because of your shitty mind

no kidding, it's a critpath, and one day it will be updated in
development branch (which is called "Rawhide").

you want a rendez-vous or what ?

Sérgio Basto a écrit :

Re: [critpath] Upgrade soname version of qrencode in Rawhi

By Matthew Miller at 01/09/2018 - 20:42

On Tue, Jan 09, 2018 at 11:06:11PM +0100, Casper wrote:
Hey. Please remember the Fedora friends foundation — and our code of
conduct. Directing this kind of comment at another contributor is not
okay.

Re: [critpath] Upgrade soname version of qrencode in Rawhi

By Kevin Kofler at 01/09/2018 - 20:09

Casper wrote:
The mass rebuild cannot happen with your incompatible package because many
packages indirectly depend on systemd.

At the very least, systemd needs to be rebuilt against the new qrencode. And
systemd itself drags in systemd as a build dependency, then it cannot be
built at all without either something providing libqrencode.so.3 or building
a systemd without qrencode support BEFORE the bumped qrencode.

Also, missing the mass rebuild is not a reason to panic, anything depending
on libqrencode.so.3 will have to be rebuilt anyway.

Kevin Kofler

Re: [critpath] Upgrade soname version of qrencode in Rawhi

By Adam Williamson at 01/09/2018 - 19:51

On Tue, 2018-01-09 at 23:06 +0100, Casper wrote:
There's a process you're meant to follow:

<a href="https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master" title="https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master">https://fedoraproject.org/wiki/Updates_Policy#Rawhide_.2F_devel_.2F_master</a>

"For updates to rawhide packages, Maintainers SHOULD:

...

* A WEEK IN ADVANCE, notify maintainers who depend on their package
to rebuild when there are abi/api changes that require rebuilds in
other packages or offer to do these rebuilds for them.
* Use a separate buildsystem tag when dealing with mass builds of many
packages, so they can land at the same time. File a ticket with
<a href="https://fedorahosted.org/rel-eng/newticket" title="https://fedorahosted.org/rel-eng/newticket">https://fedorahosted.org/rel-eng/newticket</a> for this."

I don't know if enough things depend on qrencode for it to be worth
setting up a buildsystem tag to do the rebuilds, but the first of those
two points *certainly* applies to your case. Rather than notifying at
the time you did the rebuild, you should have sent out a mail a week in
advance. Ideally it would be best to co-ordinate with the maintainers
of dependent packages so that builds of the library and the
dependencies land in the same compose and there is no breakage -
certainly for something as critical as systemd, without which nothing
works at all.

Rawhide is a development release, but that doesn't mean that it's OK to
just break it whenever you like. We are trying to keep Rawhide at
consistent Alpha quality (that's what the previous cycle's "No More
Alphas" Change was about). That certainly involves making sure the init
system always works.