On 2011-09-21, Nils Philippsen <nils(a)redhat.com&gt; wrote: Bodhi and F17? -- Petr

On Wed, 21 Sep 2011 13:32:59 +0200 Nils Philippsen <nils(a)redhat.com&gt; wrote: It is. Bodhi doesn't operate on rawhide at all... and a buildroot override makes no sense related to rawhide. When you build a package in rawhide it's automatically added to the buildroot the next time it's generated. kevin

On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: You're thinking of creating a /new/ build target and build tag/root. That's not what bodhi does. Buildroot overrides for the rawhide tags make no sense, as anything built automatically lands in the build root. - jlk

On Oct 4, 2011, at 10:31 PM, Adam Williamson wrote: I don't even know what that would mean. Tag is an overloaded term, even within koji itself. A "tag" is an identifier that can be applied to specific builds. It can also create a unique place to assign package ownership and package membership, e.g. "bash does not exist in tag f7-nobash" and "bash-3.2.5-2.fc17 has been tagged with f16". Tag can also represent what collection of packages is used when a build is done for a certain build target. The f17-candidate build target makes use of the f17-build tag to populate the build root. After the build is done, the f17 tag is applied to the build. Tags also have inheritance, so the f17-build tag inherits data from the f17 tag, which is why when a build is done and is tagged with f17, it will show up in the f17-build tag and be used in the build root. We also make use of "override" tags, our own terminology here. By injecting a tag between f17-build and f17, we have a way of 'overriding' what will normally appear in the build root by way of f17. Thus we can temporarily 'override' a bad build, or in the case of Fedoras that are managed by updates-testing, we can short-circuit the time it would take for a certain build to wind up in the build root. Further, we can create topic based tags that inherit from a base tag, but keep any builds from winding up in the base tag. We've done this for perl rebuilds and other sweeping changes that would be very disruptive to the day to day activities. For example, we could create a tag f17-perl that inherits data and builds from f17, create a build target f17-perl that makes use of the f17-perl tag to populate the build root, and all builds when finished would get tagged with f17-perl. They would have their own little world in which to prepare a mass rebuild, and when done "move" it all into f17 proper. I suspect this particular scenario is what some people are looking for in bodhi for rawhide, but there is a (high) cost in the form of repo regeneration. Every time something gets tagged for f17 it will cause a newRepo call for any targets that use build tags that inherit from f17. That would be f17-candidate, and now f17-perl, and any other topic tags that exist. If there was an f18 tag at the time it would also get a repo regeneration, and any f18 topic tags. newRepo tasks are one of the most expensive things our build system does, dealing with 12K~ source packages generating something like 50K rpms on each of our arches. As much speedup as we've tried to do this is still a heavy process on the koji DB and the filesystems. So much so that we have to limit them to only 3 at a time. Once you start adding a lot of topic branches that 3 can be a hindrance and can cause significant delays in our build systems ability to keep its build roots up to date. 20 minutes or so per newRepo, 3 at a time. If you have 9 tags to regenerate it can be over 1 hour between each newRepo for each particular target. tl;dr if you're looking for bodhi to allow on-demand creation of topic-tags for isolating build efforts from rawhide, that's too expensive of an item to allow a free-for-all at this time, in my opinion. - jlk

On Oct 5, 2011, at 11:07 AM, Tom Lane wrote: When I was handling releng stuff, I liked to use the amount of days it would take to realistically fix things as a hubristic. If it was going to take more than a day or two then it was probably worth it. I also would make sure there has been some prep work, like attempted rebuilds in a local mock to find errors before we spend resources in the build system. Your task of bumping libpng does seem like a reasonable use of a topic tag. Although I'm not releng for Fedora anymore, I would recommend spending some time with mock testing the rebuilds to find errors before we create a divergent line of development. The longer the topic-tag exists, the more risk you have of conflicting changes going on in rawhide vs the changes you're making in the topic-tag that will have to be reconciled. The topic-tag should be used to get the work done, not explore what work might be necessary. - jlk

On Wed, 2011-10-05 at 10:06 -0700, Jesse Keating wrote: I was thinking of something like the f16-gnome tag the desktop team uses to do big messy GNOME builds in before re-tagging them so they can be submitted as updates. I didn't know all the issues behind that. :) On demand, no. That's why I said 'if they request one'. I was assuming a manually handled, human-in-the-loop type of 'request', not a fill out the form and bonk on the button type of 'request'. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net

Dne 21.9.2011 13:45, Honza Horak napsal(a): Its strange to me. There are concerns to have Rawhide usable but at the end, if somebody wants to prevents problems using dedicated build root, it is denied by Rel-Engs, because it is probably to much work. This is disappointing. Vit

On Wed, Sep 21, 2011 at 14:01:10 +0200, Nils Philippsen <nils(a)redhat.com&gt; wrote: Chain building is allowed for rawhide to help get groups of packages built. What I have personally done is asked to co-maintain dependent packages so that I can handle soname bumps myself. While this probably isn't practical for packages with huge numbers of dependent packages, it seems reasonable for something on the order of a dozen. Note that in rawhide, all successful builds end up in the build root. The real difference is that with bodhi you can delay the updates going out to users until all the related updates are available.

On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff III <bruno(a)wolff.to&gt; wrote: The chain-build facility is very useful. But when you've got a chain of 3 packages to build, and the build of the second one fails, then you're done for the day. You can't restart the chain-build, because the first package has already been built. You can't restart the chain-build from the second package, because the already-built first package won't be available to build against until the next repo compose. Is there any way of addressing this that isn't prohibitively expensive? That is, can we either: - make chain-build atomic, so the failure of any build causes all builds in the chain to be marked as failed (allows restarting the chain-build); or - have a buildroot-override kind of functionality, where we can ask that the newly built packages be added to the Rawhide buildroot temporarily, so that the chain-build can be restarted at the failed build? Regards, -- Jerry James http://www.jamezone.org/

On 09/21/2011 04:49 PM, Kevin Fenzi wrote: Yes, but there's still a wait until it's actually available to build against, though it's usually a wait of less than an hour rather than the next day. And to manually wait until A is in the rawhide buildroot: koji wait-repo dist-rawhide --build=A-%{version}-%{release} e.g. koji wait-repo dist-rawhide --build=perl-Digest-Perl-MD5-1.8-2.fc17 Paul.

On Wed, 21 Sep 2011 14:01:10 +0200 Nils Philippsen <nils(a)redhat.com&gt; wrote: Bodhi doesn't create buildroots. It just allows you to override the process on non rawhide branches and get a package into the koji buildroot before it normally would be. There's only one buildroot for each build target... ie, rawhide, f16, f15, f14, f15-gnome, etc. Every target added that has a buildroot that must be generated means more overhead for koji. It has to populate and createrepo the buildroots a lot. Doing more means that other ones have to wait. I don't understand how they could here. kevin

On 2011-09-21, Petr Pisar <ppisar(a)redhat.com&gt; wrote: State info: Because bug in glibc-2.14.90-9.x86_64 (https://bugzilla.redhat.com/show_bug.cgi?id=740235), perl cannot be recompiled now, so you can still enjoy GDBM-featured Perl. I will send another notification once pruned Perl reaches F17 build root. -- Petr

On 2011-09-29, Petr Pisar <ppisar(a)redhat.com&gt; wrote: Something wrong with dependencies. I've untaged it. -- Petr

On 09/30/2011 11:07 AM, Petr Pisar wrote: The new gdbm-1.9.1-1 has just landed in Fedora Rawhide. Please, re-build your package(s) if depends on gdbm. Also python and perl can be re-build with gdbm support again. Note, that some changes can be needed to build against the new version, like: https://bugzilla.redhat.com/show_bug.cgi?id=742242 Feel free to contact me if something goes wrong. Honza

On Wed, 2011-09-21 at 10:59 +0000, Petr Pisar wrote: FWIW I added a "with_gdbm" boolean to the specfile for both python and python3 and set it to 0, building them into rawhide as: python-2.7.2-12.fc17 and python3-3.2.2-4.fc17 (fwiw, this was a week ago, on 2011-09-13) Let me know when the new gdbm is in the buildroot for f17, and we can set those booleans to 1 and rebuild python/python3 (or some other python maintainer/proven packager can do it). Hope this is helpful Dave