FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 09-29-2011, 09:47 AM
Petr Pisar
 
Default GDBM upgrade in F17

On 2011-09-29, Petr Pisar <ppisar@redhat.com> wrote:
> On 2011-09-21, Petr Pisar <ppisar@redhat.com> wrote:
>> On 2011-09-21, Petr Pisar <ppisar@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
 
Old 09-29-2011, 10:22 AM
Nils Philippsen
 
Default GDBM upgrade in F17

On Wed, 2011-09-21 at 08:49 -0600, Kevin Fenzi wrote:
> On Wed, 21 Sep 2011 13:32:59 +0200
> Nils Philippsen <nils@redhat.com> wrote:
>
> > On Wed, 2011-09-21 at 11:29 +0000, Petr Pisar wrote:
> > > On 2011-09-21, Nils Philippsen <nils@redhat.com> wrote:
> > > > On Wed, 2011-09-21 at 10:59 +0000, 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.
>
> 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.

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.

Nils
--
Nils Philippsen "Those who would give up Essential Liberty to purchase
Red Hat a little Temporary Safety, deserve neither Liberty
nils@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
 
Old 09-29-2011, 01:39 PM
Jesse Keating
 
Default 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
 
Old 09-30-2011, 09:07 AM
Petr Pisar
 
Default GDBM upgrade in F17

On 2011-09-21, Petr Pisar <ppisar@redhat.com> wrote:
> On 2011-09-21, Petr Pisar <ppisar@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
 
Old 09-30-2011, 01:31 PM
Honza Horak
 
Default 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
 
Old 10-03-2011, 10:38 AM
Petr Pisar
 
Default GDBM upgrade in F17

On 2011-09-30, Honza Horak <hhorak@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
 
Old 10-05-2011, 05:31 AM
Adam Williamson
 
Default 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
 
Old 10-05-2011, 05:06 PM
Jesse Keating
 
Default 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
 
Old 10-05-2011, 06:07 PM
Tom Lane
 
Default GDBM upgrade in F17

Jesse Keating <jkeating@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
 
Old 10-05-2011, 06:20 PM
Jesse Keating
 
Default GDBM upgrade in F17

On Oct 5, 2011, at 11:07 AM, Tom Lane wrote:
> Jesse Keating <jkeating@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
 

Thread Tools




All times are GMT. The time now is 04:48 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org