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 07-28-2011, 02:24 PM
Przemek Klosowski
 
Default RPM version goes backward in Rawhide

On 07/28/2011 04:54 AM, Michael Schwendt wrote:
> On Wed, 27 Jul 2011 18:51:12 -0700, AW (Adam) wrote:
>
>> And how would we stop that? by...encouraging people not to use it as a
>> dumping ground. What's the best way to achieve that? Try and change the
>> perception of it as a dumping ground...
>
> Communication, education, guidelines, policies. Start there?
>
> Not even Fedora's official Wiki page is 'trying very hard to kill the
> notion that "rawhide may eat babies"' (quoting Jesse).
>
> http://fedoraproject.org/wiki/Releases/Rawhide


Maybe a more nuanced logo, e.g.

"rawhide: tries hard to NOT eat babies"
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-28-2011, 02:48 PM
Adam Williamson
 
Default RPM version goes backward in Rawhide

On Thu, 2011-07-28 at 10:24 -0400, Przemek Klosowski wrote:

> Maybe a more nuanced logo, e.g.
>
> "rawhide: tries hard to NOT eat babies"

We could have one of those workplace accident signs - "Rawhide Hasn't
Eaten A Baby For (XX) Days"...
--
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 07-28-2011, 03:41 PM
James Antill
 
Default RPM version goes backward in Rawhide

On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote:
> On 7/27/11 2:03 AM, Michael Schwendt wrote:
> > In this case, the bad rpm-build broke koji builds, and since Rawhide
> > may eat babies, it can happen that Rawhide users need downgrade manually
> > while they have to wait for the fixed rpm-build.

distro-sync also helps, and is a bit more generic.

> We are trying very hard to kill the notion that "rawhide may eat
> babies". It's non-productive.

Sisyphean task ... IMO.

> There are multiple ways to throw
> baby-eating updates over the wall for testing before they get into
> rawhide. Stop treating it like a dumping ground.

But at some point you have to commit. You have to have a place all the
updates go first, currently that's rawhide. It's been rawhide for ~20
years, it seems like a better idea for it to continue to be rawhide and
just create a "tanned" repo. (or multiple ones) that eats less babies.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-28-2011, 03:58 PM
Jesse Keating
 
Default RPM version goes backward in Rawhide

On 7/28/11 8:41 AM, James Antill wrote:
> Sisyphean task ... IMO.

So was moving us off of CVS. *shrug*

>> > There are multiple ways to throw
>> > baby-eating updates over the wall for testing before they get into
>> > rawhide. Stop treating it like a dumping ground.
> But at some point you have to commit. You have to have a place all the
> updates go first, currently that's rawhide. It's been rawhide for ~20
> years, it seems like a better idea for it to continue to be rawhide and
> just create a "tanned" repo. (or multiple ones) that eats less babies.

Actually the plan log ago was to involve AutoQA as a filter between "I
built this package for rawhide" and "this build showed up in buildroots
and the public rawhide repo".

At first the autoQA tests were going to be very simplistic, like "does
it break every dep in the world", or things like that. It would also
allow developers to manually override the test results and push a
package anyway if they knew what they were doing. Then as that got
mature we could start introducing package specific functional testing as
well.

Since much of this rests on the shoulders of AutoQA, it is not
surprising that it isn't documented much in the wiki.

--
Jesse Keating
Fedora -- Freedom˛ is a feature!
identi.ca: http://identi.ca/jkeating
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-28-2011, 04:16 PM
Nalin Dahyabhai
 
Default RPM version goes backward in Rawhide

On Thu, Jul 28, 2011 at 11:41:47AM -0400, James Antill wrote:
> On Wed, 2011-07-27 at 09:19 -0700, Jesse Keating wrote:
> > On 7/27/11 2:03 AM, Michael Schwendt wrote:
> > > In this case, the bad rpm-build broke koji builds, and since Rawhide
> > > may eat babies, it can happen that Rawhide users need downgrade manually
> > > while they have to wait for the fixed rpm-build.
>
> distro-sync also helps, and is a bit more generic.
>
> > We are trying very hard to kill the notion that "rawhide may eat
> > babies". It's non-productive.
>
> Sisyphean task ... IMO.
>
> > There are multiple ways to throw
> > baby-eating updates over the wall for testing before they get into
> > rawhide. Stop treating it like a dumping ground.
>
> But at some point you have to commit. You have to have a place all the
> updates go first, currently that's rawhide. It's been rawhide for ~20
> years, it seems like a better idea for it to continue to be rawhide and
> just create a "tanned" repo. (or multiple ones) that eats less babies.

Raw Hide's only existed since 1998 [1], but anyway.

I'd lean more toward reminding package maintainers who put updates into
Raw Hide that what they put there impacts everyone else who's trying to
put updates into Raw Hide -- _one_ person breaking Raw Hide makes it
harder for _all_ package maintainers to get things done.

I'm probably understating just how frustrating that is (for me, at
least), but using harsher words would probably undermine my point.

Nalin

[1] http://www.redhat.com/about/news/prarchive/1998/press_rolling.html
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-28-2011, 05:48 PM
Dennis Gilmore
 
Default RPM version goes backward in Rawhide

On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
> On 7/26/11 1:14 PM, Michael Schwendt wrote:
> > Yes, It got untagged. See last week's thread on this list:
> > Subject: rpm builds failing with "Installed (but unpackaged) file(s)
> > found"
>
> I thought there was a hard rule about not having nvrs go backwards, and
> if a bad build was put out, it should be fixed with epoch or other such
> NVR things to make sure the upgrade path continues. (that is once a
> build makes it out in the nightly repos)

I untagged the rpm build and we do have that rule, I could have sworn that it
had only been built that day and not made it into rawhide. if i had realised
that it had made it to rawhide i would have bumped the epoch on the old build
to ensure that updating was correctly handled.

Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-28-2011, 11:29 PM
Kalev Lember
 
Default RPM version goes backward in Rawhide

On 07/28/2011 08:48 PM, Dennis Gilmore wrote:
> On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
>> I thought there was a hard rule about not having nvrs go backwards, and
>> if a bad build was put out, it should be fixed with epoch or other such
>> NVR things to make sure the upgrade path continues. (that is once a
>> build makes it out in the nightly repos)
>
> I untagged the rpm build and we do have that rule, I could have sworn that it
> had only been built that day and not made it into rawhide. if i had realised
> that it had made it to rawhide i would have bumped the epoch on the old build
> to ensure that updating was correctly handled.

Bumping epoch in rpm would have made it harder for all other packages to
depend on a particular rpm version. Instead of having e.g.
Requires: rpm >= 4.9.1, they would now also have to remember the put the
correct epoch in there.

I think it's reasonable to have a broken package pulled from rawhide for
a little while, if it's going to be properly fixed up in a few days.
Yes, we should try to avoid such things, but having a hard rule here
would be counter-productive.

Also, we have a much worse case of versions going backwards. After each
Alpha release, lots of people are going to install Branched pre-releases
and they automatically get enabled updates-testing repos. And in that
updates-testing repo, packages are often pulled out and versions go
backwards. Why is such practice allowed in Branched, but not in rawhide?


--
Kalev
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 07-29-2011, 12:32 AM
Adam Williamson
 
Default RPM version goes backward in Rawhide

On Fri, 2011-07-29 at 02:29 +0300, Kalev Lember wrote:
> On 07/28/2011 08:48 PM, Dennis Gilmore wrote:
> > On Tuesday, July 26, 2011 03:24:58 PM Jesse Keating wrote:
> >> I thought there was a hard rule about not having nvrs go backwards, and
> >> if a bad build was put out, it should be fixed with epoch or other such
> >> NVR things to make sure the upgrade path continues. (that is once a
> >> build makes it out in the nightly repos)
> >
> > I untagged the rpm build and we do have that rule, I could have sworn that it
> > had only been built that day and not made it into rawhide. if i had realised
> > that it had made it to rawhide i would have bumped the epoch on the old build
> > to ensure that updating was correctly handled.
>
> Bumping epoch in rpm would have made it harder for all other packages to
> depend on a particular rpm version. Instead of having e.g.
> Requires: rpm >= 4.9.1, they would now also have to remember the put the
> correct epoch in there.
>
> I think it's reasonable to have a broken package pulled from rawhide for
> a little while, if it's going to be properly fixed up in a few days.
> Yes, we should try to avoid such things, but having a hard rule here
> would be counter-productive.
>
> Also, we have a much worse case of versions going backwards. After each
> Alpha release, lots of people are going to install Branched pre-releases
> and they automatically get enabled updates-testing repos. And in that
> updates-testing repo, packages are often pulled out and versions go
> backwards. Why is such practice allowed in Branched, but not in rawhide?

Indeed; and remember we have yum distro-sync which fixes that problem
quite nicely, I don't see why it shouldn't also work for quick reverts
in Rawhide.
--
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 07-29-2011, 09:01 AM
Michael Schwendt
 
Default RPM version goes backward in Rawhide

On Fri, 29 Jul 2011 02:29:23 +0300, KL (Kalev) wrote:

> Bumping epoch in rpm would have made it harder for all other packages to
> depend on a particular rpm version. Instead of having e.g.
> Requires: rpm >= 4.9.1, they would now also have to remember the put the
> correct epoch in there.

Worth noting is that the rpm* packages currently are still without Epoch,
and the second release of 4.9.1 has also been untagged a few days later.
That would have resulted in a second Epoch bump then.

> I think it's reasonable to have a broken package pulled from rawhide for
> a little while, if it's going to be properly fixed up in a few days.
> Yes, we should try to avoid such things, but having a hard rule here
> would be counter-productive.

Especially if the breakage didn't cause loss of data or severe damage
on users' machines. Just rpm-build was affected, wasn't it?

> Also, we have a much worse case of versions going backwards. After each
> Alpha release, lots of people are going to install Branched pre-releases
> and they automatically get enabled updates-testing repos. And in that
> updates-testing repo, packages are often pulled out and versions go
> backwards. Why is such practice allowed in Branched, but not in rawhide?

Good question, IMO.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 08-02-2011, 11:23 AM
Panu Matilainen
 
Default RPM version goes backward in Rawhide

On 07/27/2011 09:39 PM, Michael Schwendt wrote:
> On Wed, 27 Jul 2011 09:19:08 -0700, JK (Jesse) wrote:
>
>> On 7/27/11 2:03 AM, Michael Schwendt wrote:
>>> There is a big difference between "a package going backwards in its EVR
>>> and staying there" and "a package getting untagged because it breaks koji
>>> buildroot and with the plan to go forward in EVR as soon as the bug is
>>> found and fixed".
>>
>> If it goes backwards to await a fix, that fix needs to be happening
>> within the same day or so.
>
> Panu has mentioned that he will be looking into fixing this unexpected
> breakage. If that isn't acceptable to you, feel free to provide a fix
> faster.

Rawhide now has rpm 4.9.1.1 which should fix the regressions. Apologies
for taking so long with it, I didn't expect to be this busy AFK just
like I did not expect such breakage with the 4.9.1 release.

If further breakage is spotted (I certainly hope not, but...), untag and
ping ffesti and jnovy in addition to me.

>> Not prolonged so that updates fail on users'
>> systems.
>
> Do they fail in this case?
> Do you prefer rpm-build in koji buildroot to fail even longer?
> An issue with rpm-build on Rawhide installations is minor compared with
> Fedora's offical buildsys.
>
>>> In this case, the bad rpm-build broke koji builds, and since Rawhide
>>> may eat babies, it can happen that Rawhide users need downgrade manually
>>> while they have to wait for the fixed rpm-build.
>>
>> We are trying very hard to kill the notion that "rawhide may eat
>> babies". It's non-productive. There are multiple ways to throw
>> baby-eating updates over the wall for testing before they get into
>> rawhide. Stop treating it like a dumping ground.
>
> Take off your pink glasses. Rawhide *is* a dumping ground. It breaks
> users' installations regularly because of package maintainers using it
> as exactly that, a dumping ground for potentially untested builds.

In this case, nobody's system was at risk of being eaten alive, these
issues "only" affected rpmbuild. Obviously rpm generating buggy packages
is bad enough as it affects everything and the world, but sometimes s***
just happens no matter how much testing gets done before a release.

- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:53 PM.

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