On 31. 01. 19 11:51, Stephen John Smoogen wrote:
On Thu, 31 Jan 2019 at 05:21, Miro Hrončok <mhroncok@xxxxxxxxxx
<mailto:mhroncok@xxxxxxxxxx>> wrote:
On 31. 01. 19 10:56, Adam Williamson wrote:
> Just as a note, what's in the 'rawhide' repo right now differs quite a
> lot from what's in the buildroot as we haven't had a successful compose
> since 2019-01-21. This is for various reasons - most recently
> libreoffice needed rebuilding for the poppler soname bump and did not
> build successfully for nearly a week, and now lorax has a dependency
> issue.
Oh I was so happy that I managed to build libreoffice this night after it
timeouted on arm yesterday, and now it's lorax :(
I'm hypnotizing
https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID
for days. When I blink I see "Fedora-Rawhide-20190121.n.1" written on a wall :D
Remind me why is this designed in a way that one single thing can block the
entire repo from even being created? I never really understood that part. I
mean
of course we can't build images, but why not repos?
Because everything was designed when we had a much smaller set of packages and
several things have come up over and over again.
1. Anything that breaks apart the distro from being 1 thing brings up the Extras
vs Core boogeymen and massive flame wars that some packages have become 'core
(can block a compose)' and others 'extras (can't block a compose)'. Nobody in
release engineering/IT has any emotional energy to get involved in that anymore.
2. Some method could be done but it takes a lot of concentrated effort by the
people keeping the current system working. We are not allowed to slow down
releases and are being asked to speed them up. Slowing anything down causes
people to complain mightily (even if they earlier complained things were
broken).. so we have been going along as best we can.
3. There have been several quick 'oh that would fix everything!' fixes that
people have tried and each one has fallen down to either a) the size of the repo
b) sure that works but anyone can inject or alter a build with their own rootkit
type problems (or similar security problems). That then takes time to figure out
how not to do that.. and we fall into 1 & 2.
We can try to get out of this but people are going to have to deal with some
breakage, slowing, etc.. or come up with an alternative solution and implement it.
Thanks for this!
> (it occurs to me to wonder whether it should be a matter of policy that
> soname rebuilds that involve libreoffice must be done in a side tag,
> but Rawhide package gating may render that concern obsolete soon).
Please, make that a policy! Soon can easily become months.
Do you want it to be a written policy or a coded policy? A written policy no one
actually follows can happen shortly. A policy which actually looks to see if you
are doing something and doesn't would be another thing.
I suppose start with a written policy. Make sure that we inform all the
maintainers of whatever libs libreoffice requires directly. It BRs ~100 devel
packages, so we can watch them closely and constantly remind the maintainers if
they break this policy.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
