Hello folks,
I'll update json-c to v0.13 for Rawhide. This will bump libjson-c so-
name from 2 to 3 and will remove some deprecated stuff from its API.
I'll bump and rebuild all affected packages in the same run and add
patches for the new API, if needed. As soon as the first set of builds
is done, I'll give a short update of the status.
There might be some general fallout for builds of many packages in
Rawhide for a few minutes; see `Possible complications` for the
reason.
I don't see any big complications during the rebuild, but `libu2f-
server` needs some further checks and fixes, for some tests failing
with json-c v0.13, which I will do in a few days as soon as all other
new builds have hit the mirrors.
Cheers,
Björn
=== Possible complications ===
Since we have a circular dependency in rebuilding cryptsetup (and many
other packages having direct or indirect (systemd !!!) BuildRequires on
that package, I'll do the rebuild chains in two passes:
json-c (with a copy of libjson-c.so.2*) : cryptsetup
and after the rebuilt cryptsetup has landed the f28-build repo:
json-c (final build, no libjson-c.so.2* included) :
=== Affected packages (my own packages excluded) ===
abrt
bluez
bti
cryptsetup
device-mapper-multipath
fastd
filezilla
freeradius
fwts
gdal
gdcm
gfal2
girara
gluster-block
lcgdm-dav
libreport
libstorj
libu2f-host
libu2f-server
libverto-jsonrpc
libvmi
mypaint
ndctl
newsbeuter
openhpi
opensips
postgis
riemann-c-client
strongswan
sway
syslog-ng
systemtap
tlog
zmap

=== Possible complications ===
Since we have a circular dependency in rebuilding cryptsetup (and many
other packages having direct or indirect (systemd !!!) BuildRequires on
that package, I'll do the rebuild chains in two passes:
json-c (with a copy of libjson-c.so.2*) : cryptsetup
and after the rebuilt cryptsetup has landed the f28-build repo:
json-c (final build, no libjson-c.so.2* included) :

Pretty please could you at least cc maintainers of package *before* you do such
complicated rebuilds?
AFAIK the cryptsetup package was not mentioned in your previous head-up json-c mails
(maybe because
it was not there yet as it is quite recent change).
We could do this together with rebuild for final 2.0.0 that is going to happen just now
....
There was a reason that we were very careful when introducing these new dependencies
and now it seems that proven-packagers switched to mode "it builds ok, so it must
work ok".
I am really not impressed by this approach, specifically for critical path package
like cryptsetup. At least our upstream testsuite should be run in rawhide before doing
this!
(I am going to run it now anyway.)
Thanks,
Milan

Wow! What an example of proven packager rights abuse. It didn't build
because the maintainer had an explicit requirement specified? Nah, let's
drop it.
Seriously, stop this nonsense already! We all know it's Rawhide and
occasional breakage is tolerated, but since it seems to be a new kind of
standard (according to various topics on fedora-devel recently) maybe
the proven packager concept is not so flawless after all.

I disagree here with you. The fix is simple and straightforward. But would be
better if sed would include link to upstream Pull Request. But this is general
rule for all maintainers, not just this case.

Seriously, stop this nonsense already! We all know it's Rawhide
and
occasional breakage is tolerated, but since it seems to be a new kind of
standard (according to various topics on fedora-devel recently) maybe
the proven packager concept is not so flawless after all.

All those topics are irrelevant to this. 1st was about "someone found bug in
package, pp fixed it" and 2nd was about preventing package from being broken.
Please, don't mix topics.
- --
- -Igor Gnatenko

On 12/12/2017 06:41 PM, Jan Pokorný wrote:
> On 11/12/17 01:05 +0100, Björn 'besser82' Esser wrote:
>> I'll update json-c to v0.13 for Rawhide. This will bump libjson-c so-
>> name from 2 to 3 and will remove some deprecated stuff from its API.
>
> https://src.fedoraproject.org/rpms/sway/c/bc85e0dfab91ae77c09250dbf54b8b7...
Wow! What an example of proven packager rights abuse. It didn't
build because the maintainer had an explicit requirement specified?
Nah, let's drop it.
Seriously, stop this nonsense already! We all know it's Rawhide and
occasional breakage is tolerated

If I understand it correctly, this is actually what happened here
in the first place -- json-c got released broken in version 0.13
under the circumstances exercised by sway, as Björn investigated
and subsequently fixed (thanks) -- see the referred bug.
Case solved, IMHO.

On 13/12/17 12:05 +0100, Ondrej Kozina wrote:
> On 12/12/2017 06:41 PM, Jan Pokorný wrote:
> > On 11/12/17 01:05 +0100, Björn 'besser82' Esser wrote:
> > > I'll update json-c to v0.13 for Rawhide. This will bump
> > > libjson-c so-
> > > name from 2 to 3 and will remove some deprecated stuff from its
> > > API.
> >
> > https://src.fedoraproject.org/rpms/sway/c/bc85e0dfab91ae77c09250d
> > bf54b8b7e48d43229
>
> Wow! What an example of proven packager rights abuse. It didn't
> build because the maintainer had an explicit requirement specified?
> Nah, let's drop it.
>
> Seriously, stop this nonsense already! We all know it's Rawhide and
> occasional breakage is tolerated
If I understand it correctly, this is actually what happened here
in the first place -- json-c got released broken in version 0.13
under the circumstances exercised by sway, as Björn investigated
and subsequently fixed (thanks) -- see the referred bug.
Case solved, IMHO.
> but since it seems to be a new kind of standard (according to
> various topics on fedora-devel recently) maybe the proven packager
> concept is not so flawless after all.
Either way, more (or any at all) automated tests on both
functionality
provider and consumer sides would definitely help.