I'll update json-c to v0.13.1 for fc28 and Rawhide. This will bump
libjson-c so-name from 3 to 4 without any changes to the API. The bump
was done, because some distributions already bumped the so-name to 3
with json-c v0.12 on their own.
I'll bump and rebuild all affected packages in one run. There are no
adjustments nor patches needed.
There might be some general fallout for builds of many packages in
Rawhide for a few minutes; see `Circular dependencies` for the
I don't see any big complications during the rebuild as v0.13.1 just
brings the set of patches I already carried downstream in the present
As soon as the builds are done, I'll give a short update of the status.
=== Circular dependencies ===
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.3* included) : cryptsetup
and after the rebuilt cryptsetup has landed the build-repos:
json-c (final build, no copy of libjson-c.so.3*) : $other_packages
=== Affected packages (my own packages excluded) ===
# Fedora Quality Assurance Meeting
# Date: 2018-04-02
# Time: 15:00 UTC
# Location: #fedora-meeting on irc.freenode.net
We didn't meet for the last few weeks due to Beta work, so let's get
together and check in on where we're at.
If anyone has any other items for the agenda, please reply to this
email and suggest them! Thanks.
== Proposed Agenda Topics ==
1. Previous meeting follow-up
2. Fedora 28 status
3. Test Day status
4. Criteria proposals
5. Open floor
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
test-announce mailing list -- test-announce(a)lists.fedoraproject.org
To unsubscribe send an email to test-announce-leave(a)lists.fedoraproject.org
On 03/28/2018 02:21 PM, Michael Thomas wrote:
> On 3/28/18 1:17 PM, Artur Iwicki wrote:
>> I took a look at "SIG/Games/Packaging" page  on the Fedora wiki, and it seems to be quite old - the revision history says the last edit was made in May 2008, which places it at close to 10 years old.
>> Could we possibly revise the packaging guidelines to make sure they don't contradict the general guidelines - and if they do, have a clear "yes, this contradicts the main guidelines, do it either way" message?
> I'd be happy to make any changes needed if folks point them out.
I am +1 to making modern revisions to this SIG's guidelines, but I am
unable to offer much technical insight for these changes.
In May 2008, Windows XP / Vista were in wide use, Steam was not yet in
the eye of the mainstream gaming world, and Fedora was approaching five
years old. A lot of things in technology, gaming, and Fedora have
changed since May 2008. :-)
The best way to move forward, as I see it, is to draft proposed /
revised changes. If you have a draft with proposed changes, it is easier
to collect feedback on those changes. I am not much of a packager, so I
cannot contribute much technical insight. However, I am happy to help
gather feedback and formally adopt any new guidelines, once a draft is
Justin W. Flory
Greetings fellow Fedorans!
I would like to kick off a general discussion about how we might gate
packages in Rawhide. I think it would be nice to get something in place
for the Fedora 29 timeframe.
As one of the Bodhi contributors, I am inclined to suggest that we could
use Bodhi on Rawhide, similar to how we use it for our stable/branched
releases, with more relaxed rules (perhaps 1 day in testing or something
It may be possible to automate the process a bit to make it less heavy
for developers, though there is some complication for multi-package
updates (more on that in a bit). For simple package updates, we may be
able to detect new commits on dist-git, and react to those by
automatically starting a Koji build, and automatically filing a Bodhi
update when that build is complete. I think that would be pretty nice,
and pingou created a PoC to do this about a year ago.
Multi-package updates won't be so easy though. It's not uncommon for us
to need to update packages together, and the above workflow would be
problematic since it would result in updates with single packages in
them rather than updates with multiple packages. Of course, buildroot
overrides would be a problem too, since multi-package updates often
depend on each other at build time too.
We could create some way for packagers to indicate that a commit (or
possibly even a whole repo) is not intended to be "autobuilt/updated".
If the packager indicates this then their builds would go into a
rawhide-pending (similar to what we do for f27 today). Once they have
all their builds (and buildroot overrides) the way they want them, they
can create the update.
Another idea that was tossed around in some chats I had with people
about this involved a system for packagers to use to create Koji side
tags. Bodhi manages BuildRoot Overrides today (with expirations), so
perhaps Bodhi could be expanded to also manage Koji side tags (also with
expirations). I can't remember all the details about this approach or
why it was suggested over the former approach, but I wanted to list it
to invite others to chew on it and see if it could work.
If you have other suggestions on how we might gate packages in Rawhide
that are wildly different than the above, please feel free to share!