DevHeads.net

Strange rawhide behaviour

Hello,

I built "community-mysql" package in version 8.0.14 in rawhide.
It was built on top of "libicu-devel" 63.1-1.fc30

Comments

Re: Strange rawhide behaviour

By Florian Weimer at 01/30/2019 - 10:27

* Michal Schorm:

The default repository for mock and installations is a compose. It is
regularly recreated from the buildroot, but it can lag behind the
buildroot by basically an arbitrary amount of time.

You can use mock with --enablerepo=local to build in a chroot that has
the actual buildroot active.

Thanks,
Florian

Re: Strange rawhide behaviour

By Fabio Valentini at 01/30/2019 - 10:06

Not necessarily. Builds are only pushed to repositories after a successful
compose, but are available in koji only a few minutes after they were built.

That means that packages built locally or on COPR (which use the rawhide
repository) get "older" versions than the koji builds that have access to
new packages pre-compose.

Koschei does only koji scratch "test" builds, which aren't submitted to
repositories at all.

Or at some point, rawhide will

Yes. Check the fedora 30 schedule - it was planned for today but delayed to
tomorrow because of a known GCC bug.

Fabio

Re: Strange rawhide behaviour

By Michal Schorm at 01/30/2019 - 10:20

On Wed, Jan 30, 2019 at 3:06 PM Fabio Valentini < ... at gmail dot com> wrote:
All of those packages were built in Koji.
I wasn't talking about any custom builds. (since custom builds can't
be added anyhow to Koji, right?)

That means - it (the icu 63) was in the repository at the build time
of the community-mysql, but wasn't later at install time.
Wizardy? Untagged buiid?

Re: Strange rawhide behaviour

By Tomasz Torcz at 01/30/2019 - 10:50

On Wed, Jan 30, 2019 at 03:20:31PM +0100, Michal Schorm wrote:
I saw exactly this on Monday. I submitted a build of owfs package,
which immediately failed with
DEBUG util.py:490: BUILDSTDERR: - nothing provides gcc = 8.69 needed by annobin-8.69-2.fc30.x86_64

Strange thing was, annobin-8.69-2.fc30.x86_64 has been built only _2 hours_
before my build. How it got to be in buildroot – it's a mystery…

Re: Strange rawhide behaviour

By =?UTF-8?Q?Bj=c3... at 01/30/2019 - 13:18

Am Mittwoch, den 30.01.2019, 15:50 +0100 schrieb Tomasz Torcz:

The buildroot repository for Rawhide is automaticaly generated when a
new / updated package has been successfully built.

The "regular" installation repository for Rawhide is generated on a
daily base with the compose. If the compose fails for any arbitrary
reason, there will be no regenerated regular repository for Rawhide.

Björn

Re: Strange rawhide behaviour

By Tom Hughes at 01/30/2019 - 11:05

It was a buggy build of annobin made while trying to fix the
dependencies (RHBZ#1607430) and it was fixed a few hours later.

Tom

Re: Strange rawhide behaviour

By Tom Hughes at 01/30/2019 - 10:30

What do you mean by "install time" exactly?

Do you mean you have a system using rawhide from the mirrors
and you are trying to install there?

If so are you installing community-mysql itself from the
mirrors? or have you fetched than from koji to install
manually?

Tom

On 30/01/2019 14:20, Michal Schorm wrote:

Re: Strange rawhide behaviour

By Michal Schorm at 01/30/2019 - 10:37

Right.

Yes, I'm trying to test the installation from the mirrors. There will
be a delay.

Buildroot repo != compose repo.
That's where I was mistaken.

Case closed, I'll wait :)
Thanks

Re: Strange rawhide behaviour

By Adam Williamson at 01/31/2019 - 05:56

On Wed, 2019-01-30 at 15:37 +0100, Michal Schorm 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.

(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).

Re: Strange rawhide behaviour

By King InuYasha at 02/03/2019 - 18:27

On Sat, Feb 2, 2019 at 3:51 PM Adam Williamson
< ... at fedoraproject dot org> wrote:
I would, as a matter of principle, refuse side tags as an acceptable
solution unless all packagers were given the ability to open and close
side tags freely for this purpose. Any comprehensive solution that
would permit Rawhide gating must also permit people an easy way to
submit and merge a multitude of things at once. Otherwise, we're just
screwed and everything gets harder and moves slower. :(

As an aside, this is the first time in a while I've heard Rawhide
gating brought up. Is there a discussion somewhere about this?

Re: Strange rawhide behaviour

By Pierre-Yves at 02/04/2019 - 09:31

On Sun, Feb 03, 2019 at 05:27:45PM -0500, Neal Gompa wrote:
It's been in the air for a while and we had a concrete plan for it for a while
as well but it has not been prioritised enough until basically two weeks ago.
I am trying to get all the people who will be involved to review the current
proposal, once it is something that I feel confident about, I'll send an email
for more feedback to this list as well as submit it as a change proposal.
So do expect to hear more about this before the end of the month :)

If you want more info, I'm happy to provide them but I'd rather not expose this
to a broad audience until there is no agreement between the different
maintainers of the applications impacted by this change.

I hope this makes sense.

Pierre

Re: Strange rawhide behaviour

By =?UTF-8?B?TWlyb... at 01/31/2019 - 06:18

On 31. 01. 19 10:56, Adam Williamson wrote:
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
<a href="https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID" title="https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide/COMPOSE_ID">https://kojipkgs.fedoraproject.org/compose/rawhide/latest-Fedora-Rawhide...</a>
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?

Please, make that a policy! Soon can easily become months.

Re: Strange rawhide behaviour

By Stephen John Smoogen at 01/31/2019 - 06:51

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.

Re: Strange rawhide behaviour

By =?UTF-8?B?TWlyb... at 01/31/2019 - 06:59

On 31. 01. 19 11:51, Stephen John Smoogen wrote:
Thanks for this!

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.

Re: Strange rawhide behaviour

By =?UTF-8?B?TWlyb... at 01/31/2019 - 06:43

On 31. 01. 19 11:18, Miro Hrončok wrote:
Anyway:

Successfully waited 8:31 for lorax-30.13-2.fc30 to appear in the f30-build repo

If somebody has the powers to initiate a compose, please use them.

Re: Strange rawhide behaviour

By =?UTF-8?B?TWlyb... at 02/01/2019 - 06:01

On 31. 01. 19 11:43, Miro Hrončok wrote:
Another DOMMED one.

Do you have a tip where to look for the problem?

Is this file the correct start point?

<a href="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190131.n.1/logs/global/traceback.global.log" title="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190131.n.1/logs/global/traceback.global.log">https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201901...</a>

That brings me to

<a href="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190131.n.1/logs/armhfp/liveimage-Fedora-Xfce-armhfp-Rawhide-20190131.n.1.armhfp.log" title="https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20190131.n.1/logs/armhfp/liveimage-Fedora-Xfce-armhfp-Rawhide-20190131.n.1.armhfp.log">https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-201901...</a>

And that says "see root.log or appliance.log for more information" yet I'm not
sure where to see those.

Thanks,

Re: Strange rawhide behaviour

By Dan =?ISO-8859-... at 02/01/2019 - 06:17

On Fri, 1 Feb 2019 11:01:26 +0100

BTW wouldn't it make sense to expand the list of mandatory products,
that must succeed for the whole to compose to succeed, when getting
closer to the release? Like after branch point to have a single product
(x86 everything, to be extreme) for the new rawhide and then add other
variants and products during the time to have a full list for GA RCs?

Dan

Re: Strange rawhide behaviour

By Kevin Fenzi at 02/01/2019 - 11:40

On 2/1/19 2:17 AM, Dan Horák wrote:
Well, the list of mandatory things is controlled by FESCo... they are
the artifacts that MUST be produced to do a release. Once we have gating
in place we should hopefully be able to fix the non required artifacts
because we don't have to spend all our time fixing the required ones.

kevin

Re: Strange rawhide behaviour

By Dan =?ISO-8859-... at 02/01/2019 - 06:08

On Fri, 1 Feb 2019 11:01:26 +0100

you can open
Task info: <a href="https://koji.fedoraproject.org/koji/taskinfo?taskID=32400870" title="https://koji.fedoraproject.org/koji/taskinfo?taskID=32400870">https://koji.fedoraproject.org/koji/taskinfo?taskID=32400870</a>
from the log ^^, the go into the "createAppliance" sub-task and then you will see

...
Unable to create appliance : Failed to build transaction :
Problem: package abiword-1:3.0.2-13.fc29.armv7hl requires libabiword-3.0.so, but none of the providers can be installed
- package abiword-1:3.0.2-13.fc29.armv7hl requires libabiword = 1:3.0.2-13.fc29, but none of the providers can be installed
- conflicting requests
- nothing provides libwmflite-0.2.so.7 needed by libabiword-1:3.0.2-13.fc29.armv7hl
- nothing provides libwmf-0.2.so.7 needed by libabiword-1:3.0.2-13.fc29.armv7hl

so broken deps :-(

Dan

Re: Strange rawhide behaviour

By =?UTF-8?B?TWlyb... at 02/01/2019 - 06:39

On 01. 02. 19 11:08, Dan Horák wrote:
<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1671692" title="https://bugzilla.redhat.com/show_bug.cgi?id=1671692">https://bugzilla.redhat.com/show_bug.cgi?id=1671692</a>

Re: Strange rawhide behaviour

By =?UTF-8?B?TWlyb... at 02/01/2019 - 06:07

On 01. 02. 19 11:01, Miro Hrončok wrote:
Oh, on the Koji link from that log:

Unable to create appliance : Failed to build transaction :
Problem: package abiword-1:3.0.2-13.fc29.armv7hl requires libabiword-3.0.so,
but none of the providers can be installed
- package abiword-1:3.0.2-13.fc29.armv7hl requires libabiword =
1:3.0.2-13.fc29, but none of the providers can be installed
- conflicting requests
- nothing provides libwmflite-0.2.so.7 needed by
libabiword-1:3.0.2-13.fc29.armv7hl
- nothing provides libwmf-0.2.so.7 needed by libabiword-1:3.0.2-13.fc29.armv7hl

Re: Strange rawhide behaviour

By Adam Williamson at 02/01/2019 - 06:32

On Fri, 2019-02-01 at 11:07 +0100, Miro Hrončok wrote:
It is usually easier to just look here:

<a href="https://pagure.io/dusty/failed-composes/issues" title="https://pagure.io/dusty/failed-composes/issues">https://pagure.io/dusty/failed-composes/issues</a>

the tickets there are filed automatically by a script dusty wrote; they
provide useful information on each failure, including usually a direct
link to the relevant task. We also often do the debugging there too.

Re: Strange rawhide behaviour

By Tom Hughes at 01/30/2019 - 10:41

Yes I think it's been about a week since the last rawhide compose
so the mirrors are well out of date.

With the mass rebuild about to start it's probably not going to
get better any time soon either...

Tom

On 30/01/2019 14:37, Michal Schorm wrote: