Re: GDBM upgrade in F17
On 2011-10-05, Tom Lane t...@redhat.com wrote: My particular reason for asking is that I'm looking at a soname bump for libpng, and if repoquery is telling me the truth, there are about 1200 packages that will need to be rebuilt. Few days ago I've been asked by Marcela how should I cope with this problem (just another library). I proposed this solution: Package current shared library (and only the library, no development files or dodocumentation or bundled tools) as new package. I call the new package `shaddow package' not to confuse with already existing `compat' packages (that should deliver full-featured environment as header files). This shaddow package will RPM-provide current SONAME, thus after injecting this package into repositories, you can fluently upgrade library in the original package and then rebuild all reverse dependencies (i.e. applications like gimp) without any stress. The shaddow package will get pulled into build root automatically by the SONAME provide. Once all depending packages are rebuilt, the shaddow package becames unnecessary, but you can keep it living in repositories because it can be reused on next SONAME upgrade just by moving then-current library into the shaddow package. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Oct 4, 2011, at 10:31 PM, Adam Williamson wrote: On Thu, 2011-09-29 at 09:39 -0400, Jesse Keating wrote: On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. 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. So really want they want is a *tag*, not a buildroot override, right? They can have a tag for Rawhide if they request one, I presume? 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
Jesse Keating jkeat...@j2solutions.net writes: 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. Fair enough. Is there a policy or guideline on how big a change is big enough to request a topic-tag for, rather than breaking rawhide until the rebuild completes? My particular reason for asking is that I'm looking at a soname bump for libpng, and if repoquery is telling me the truth, there are about 1200 packages that will need to be rebuilt. regards, tom lane -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Oct 5, 2011, at 11:07 AM, Tom Lane wrote: Jesse Keating jkeat...@j2solutions.net writes: 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. Fair enough. Is there a policy or guideline on how big a change is big enough to request a topic-tag for, rather than breaking rawhide until the rebuild completes? My particular reason for asking is that I'm looking at a soname bump for libpng, and if repoquery is telling me the truth, there are about 1200 packages that will need to be rebuilt. regards, tom lane 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-10-05 at 10:06 -0700, Jesse Keating wrote: On Oct 4, 2011, at 10:31 PM, Adam Williamson wrote: On Thu, 2011-09-29 at 09:39 -0400, Jesse Keating wrote: On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. 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. So really want they want is a *tag*, not a buildroot override, right? They can have a tag for Rawhide if they request one, I presume? I don't even know what that would mean. 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. :) 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. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Thu, 2011-09-29 at 09:39 -0400, Jesse Keating wrote: On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. 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. So really want they want is a *tag*, not a buildroot override, right? They can have a tag for Rawhide if they request one, I presume? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-09-30, Honza Horak hho...@redhat.com wrote: On 09/30/2011 11:07 AM, Petr Pisar wrote: Perl has been rebuilt _without_ GDBM in F17 as perl-5.14.1-191.fc17 and it's available in build root now. -- Petr The new gdbm-1.9.1-1 has just landed in Fedora Rawhide. Please, re-build your package(s) if depends on gdbm. perl with GDBM rebuilt as perl-5.14.1-192.fc17. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. I will send another notification once pruned Perl reaches F17 build root. Perl has been rebuilt _without_ GDBM in F17 as perl-5.14.1-191.fc17 and it's available in build root now. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 09/30/2011 11:07 AM, Petr Pisar wrote: Perl has been rebuilt _without_ GDBM in F17 as perl-5.14.1-191.fc17 and it's available in build root now. -- Petr 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. 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. Perl has been rebuilt _without_ GDBM in F17 as perl-5.14.1-190.fc17 and it's available in build root now. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-09-29, Petr Pisar ppi...@redhat.com wrote: On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. 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. Perl has been rebuilt _without_ GDBM in F17 as perl-5.14.1-190.fc17 and it's available in build root now. Something wrong with dependencies. I've untaged it. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote: Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface to manage something in koji then. It'd still be handy if we could use that for Rawhide so we don't break all dependent things for people who want to test something else than what we're breaking at the moment. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On 09/21/2011 04:49 PM, Kevin Fenzi wrote:
On Wed, 21 Sep 2011 09:23:52 -0600
Jerry Jamesloganje...@gmail.com wrote:
On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff IIIbr...@wolff.to
wrote:
Chain building is allowed for rawhide to help get groups of packages
built.
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.
Incorrect.
The first package is already in the build root.
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.
All chain build does is the waiting for you.
build A; wait until A is in the buildroot; build B
If B fails, then you can fix it and resume from B and it will work
fine.
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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Thu, 22 Sep 2011 09:32:11 +0100
Paul Howarth p...@city-fan.org wrote:
...snip...
The first package is already in the build root.
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.
This is what chain build does for you. :) It waits until it's in the
buildroot before building B. ;)
All chain build does is the waiting for you.
build A; wait until A is in the buildroot; build B
If B fails, then you can fix it and resume from B and it will work
fine.
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
Sure. Chain build does this part for you though...
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
GDBM upgrade in F17
Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 11:29 +, Petr Pisar wrote: On 2011-09-21, Nils Philippsen n...@redhat.com wrote: On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Bodhi and F17? Why not, you're not trying to submit an update, are you ;-)? As of buildroot overrides, bodhi isn't used solely for updates anymore (even though the URL ends in /updates/). The buildroot override document[1] doesn't mention that this would be limited to branches. Nils [1]: http://fedoraproject.org/wiki/Bodhi/BuildRootOverrides -- Nils Philippsen Those who would give up Essential Liberty to purchase Red Hat a little Temporary Safety, deserve neither Liberty n...@redhat.com nor Safety. -- Benjamin Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 09/21/2011 01:14 PM, Nils Philippsen wrote: On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils I understand that buildroot override in bodhi works for f16 and lower only, am I wrong? I wanted to create a new target to make it safe, but after a discussion with rel-engs it appears to be too big hammer for such a few of packages. A temporary perl built without gdbm seems to be fine enough for this purpose. Honza -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
Dne 21.9.2011 13:45, Honza Horak napsal(a): On 09/21/2011 01:14 PM, Nils Philippsen wrote: On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. Have you tried building gdbm, creating the buildroot in bodhi, then untagging gdbm from f17 instead? Nils I understand that buildroot override in bodhi works for f16 and lower only, am I wrong? I wanted to create a new target to make it safe, but after a discussion with rel-engs it appears to be too big hammer for such a few of packages. A temporary perl built without gdbm seems to be fine enough for this purpose. Honza 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, Sep 21, 2011 at 14:01:10 +0200, Nils Philippsen n...@redhat.com wrote: It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as 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. It shouldn't really involve rel-eng at all, Bodhi buildroot overrides should just do this as it does with branched releases. 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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On 2011-09-21, Bruno Wolff III br...@wolff.to wrote: On Wed, Sep 21, 2011 at 14:01:10 +0200, Nils Philippsen n...@redhat.com wrote: It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as Chain building is allowed for rawhide to help get groups of packages built. Chain building helps but does not solve this problem. In gdbm---perl scenario both packages are in set of default build environment, so once you upgrade gdbm, you cannot install perl resulting in mock failure in root preparation stage. -- Petr -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On 2011-09-21, Petr Pisar ppi...@redhat.com wrote: That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, 21 Sep 2011 14:01:10 +0200 Nils Philippsen n...@redhat.com wrote: On Wed, 2011-09-21 at 13:53 +0200, Vít Ondruch wrote: Dne 21.9.2011 13:45, Honza Horak napsal(a): I understand that buildroot override in bodhi works for f16 and lower only, am I wrong? I wanted to create a new target to make it safe, but after a discussion with rel-engs it appears to be too big hammer for such a few of packages. A temporary perl built without gdbm seems to be fine enough for this purpose. Honza It seems that you're right, I got this when I tried to submit a buildroot override for the current Rawhide dcraw package: Error: Could not determine release for dcraw-9.10-1.fc17 with tags ['f17'] It's unclear to me why this would need to be the case. Creating a build root for what we perceive as Rawhide should be just the same as 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. 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. 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. It shouldn't really involve rel-eng at all, Bodhi buildroot overrides should just do this as it does with branched releases. I don't understand how they could here. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff III br...@wolff.to wrote: Chain building is allowed for rawhide to help get groups of packages built. 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/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
On Wed, 21 Sep 2011 09:23:52 -0600 Jerry James loganje...@gmail.com wrote: On Wed, Sep 21, 2011 at 6:50 AM, Bruno Wolff III br...@wolff.to wrote: Chain building is allowed for rawhide to help get groups of packages built. 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. Incorrect. The first package is already in the build root. All chain build does is the waiting for you. build A; wait until A is in the buildroot; build B If B fails, then you can fix it and resume from B and it will work fine. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: GDBM upgrade in F17
On Wed, 2011-09-21 at 10:59 +, Petr Pisar wrote: Jan Horak (hhorak) is going to upgrade GDBM to version with new SONAME in F17. Because rel-engs refused to provide dedicated build root, the upgrade will be performed in F17 directly. That means Perl, Pyhon and other default-build-root packages will disable support for GDBM temporarily. So if your package needs GDBM support in those languages, please wait until new GDMB and other packages (Perl, Python and similar) get recompiled again against this new GDBM. 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Buildroot overrides in Rawhide, was: GDBM upgrade in F17
Dne 21.9.2011 16:52, Kevin Fenzi 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. 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. Yes, Koji might have more work, but in opposite case, Rawhide is going to be broken and it might be broken for indefinite period of time if something goes wrong. So should be Rawhide usable even though it would mean that Koji has more work and somebody might wait longer for his task or should Rawhide be broken? I would opt for slower Koji, but apparently the broken Rawhide is preferred. Vit -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
