On 03/08/2018 11:10 PM, Milan Crha wrote:
On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote:
> * CI/automated tests run on it, and if all is ok goes out in the next
> rawhide compose.
> * If not ok, you could wave the results or build more things/edit the
> update until it passes.
so it looks like you are going to remove chain-build from fedpkg,
yeah, but you would have even better workflow with a side tag.
right? It's kind of pain it doesn't work for stable, but if
you want to
get rid of it for rawhide too, or add some unnecessary obstacles for
its usage, then it's a downgrade like the kerberos usage (it's a pain
to write my password all the time when I want to do something in
packaging, with compare of once-per-year replace of the certificate,
but that's another story, which only adds to the feeling of making
process more and more painful instead of simpler (I heard some time ago
something like this "security by obscurity", with which I fully
Note that if you use KCM (now default) and it works (It has some bugs),
you only need to enter your password once a week. Also note that it's
much more industry standard, and its much harder to have someone just
take your cert and do things as you.
I chain-build like this "A : B : C D", which means in stable
that I build A, then fill override, then I build B, then fill an
override, the I build C and D and then I fill the update. I hope the
difference in stable and chain-build usage is obvious.
Sure, with this proposal you would:
* request a side tag
* build a, wait for it to be added to the repo, build b, etc.
You would not need to file overrides, just build them in the right order
with wait-repo between them.
Anyway, could you enlighten what you call "if all is ok"?
If all the tests we determine should gate packages pass.
I'd like to see a 'no new broken deps' test/check... but we could change
the tests over time.
What do I do if it's not ok?
Fix your package(s) and resubmit for new tests, or if you feel the test
is wrong file a bug on it and waive the results.
I do maintain a package which is in critpath. I'm not a proven
packager, thus I cannot touch anyone's package (I hesitate to do it
anyway, even there are cases where are not many other options). If my
critpath package changes API and soname versions, then other packages,
for which I do not have commit rights, will be broken by that update,
but the update as such will build and look just fine. What do I do now?
You request a side tag, build your new package in that, then tell all
the dependent package maintainers to use that side tag to rebuild all
their packages. Once everyone is done, you (or someone else) submits it
for testing as a unit.
Will I hunt for respective maintainers and co-maintainers kindly
them to do something about it? The paper work around this (finding who
it is, their email addresses, writing them a mail) would be a pain on
its own, but more painful would be the delay in the delivery. It will
not be rawhide anymore, from my point of view.
yes. You can use dnf repoquery to tell what uses your package and needs
rebuilding. All those people should be watching your package or at least
easy to communicate to.
sure, it might not be rawhide, it will be much more sane.
I'd rather prefer to have detected issues in updates early
understandable that doing API/ABI checks after each package update is
not doable at least due to resource requirements - thus you'd not
detect it with the gating too, right?), or at least like once a day.
Not sure what you mean here... yes, we could do a check right before a
compose, but then you have a lag after you build your package until it
gets kicked out before the compose. Much better to check it as soon as
we can so you can know and act on it.
I did a soname version bump in one of my packages recently and
announced it, with a list of "possibly affected packages". I know my
work flow is wrong in this regard, but I kind of rely on the
notifications of broken dependencies to rebuild what is really needed
to be rebuilt, because the packages sometimes requires something bigger
in the build time, which is not actually used in the run time (just my
feeling, no prove available). I didn't receive any single notification
of broken dependencies this time. While it's possible someone was just
quicker than me, I believe it's highly unlikely. I also believe I
didn't filter out any such "broken dependencies" mail notifications
from my notification settings, they used to come in the past.
As mentioned downstream the broken deps checking script was turned off
because it doesn't understand rich deps. Also, we have had very few f28
or rawhide composes this last week.
That's also another disadvantage of the gating. I recall seeing broken
dependencies messages for package I've no commit rights for for weeks.
Yep. Or longer.
Either the maintainer (or co-maintainer) didn't receive those
similar like me, or they just didn't care. How would I force them to
rebuild/correct (I am definitely willing to help to correct the
packages when an API change requires it) their packages, when they
already ignore/filter out broken dependencies notifications? Should I
hunt for a proven packager to move things forward, thus other packages
can rely on the provided change? Proven packagers have their own work
to do to, they cannot be disrupted from their work every other day by
hundreds of packages to help with the packages their update broke.
You could ask for commit on those packages you need commit on.
If those maintainers don't approve it, ask for unresponsive maintainer
process and you will get commit rights. If they still don't show up, you
could look at retiring those packages so they drop from the collection
and don't bother you anymore.
By the way, why was the compose of rawhide broken for several days?
Corresponding people/packagers not being available? It looks to me that
you just want to move the issue to a slightly upper level, but then
you'll have working rawhide compose, which will not use the
recent/bleeding code. It is, from my point of view, the main credit of
Rawhide, to be on the bleeding edge.
It's been a long trail of things that needed to get worked out.
it has nothing to do with availability. A number of people have been
spending lots of time fixing things. I personally spent most of my week
Some of the issues:
* new systemd landed in both rawhide and f28 right before freeze. It
added a fsync call after writing/creating the /etc/machine-id file.
However, in a installer chroot /proc isn't mounted so fsync fails to
write the file, so systemd thinks /etc isn't writable and bind mounts
/run/machine-id over /etc/machine-id, which results in lorax failing in
a cp -alx command it uses to copy the install tree it just created. That
was a fun one.. took up my wed tracking that down.
* Modular composes have had a number of issues in pungi. First, adding a
Modular compose made things take 36 hours or so because it was gathering
modules and trying to sort them into non modular repos. Then that was
fixed, but then module signing was messed up before there are no modules
made for f29/rawhide at all (There's a module build service bug about
that), so we needed to disable them there. Then pungi gathered
incorrectly rpms and noarch rpms were not placed in the right repos.
There are composes running now with fixes for all that (we hope).
* Bodhi enablement was also this week... lots of issues around modules
updating that were not figured since f27's fully modular approach, lots
of signing issues around how to tell what module is part of what stream,
Probibly more things I am blanking out on now. ;)
It would be very sad to turn Rawhide from 'package update' to 'people
Well, more communication is better. If people aren't responding we
should know that and fix it, not just toss packages over a wall and
Just my opinion.
Thanks for the feedback!
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org