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 > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 11-11-2011, 06:58 AM
Tomáš Chvátal
 
Default Stop altering of current release ebuilds and propagate the changes slowly

Hi guys,

In last 3 days i recompiled chromium 3x

1x rebuild for cups useflag
1x update
1x rebuild for cups useflag

If you screw the ebuild up then always think if the change is worth
the stupid long recompile time.
Like it is not enough there is version bump every few days...
Just alter only live ebuild and branch of it with each release and do
not alter the releases unless really critical bug is there. People are
patient and they can wait for bugfixes.

Imagine that I would adopt your approach with libreoffice. I suppose
people would chain me to some wall and use as target practice as
result fo my actions

Cheers

Tom
 
Old 11-11-2011, 07:22 AM
Alec Warner
 
Default Stop altering of current release ebuilds and propagate the changes slowly

2011/11/10 Tomáš Chvátal <scarabeus@gentoo.org>:
> Hi guys,
>
> In last 3 days i recompiled chromium 3x
>
> 1x rebuild for cups useflag
> 1x update
> 1x rebuild for cups useflag
>
> If you screw the ebuild up then always think if the change is worth
> the stupid long recompile time.

I tentatively agree in terms of USe flag mixups...however...

> Like it is not enough there is version bump every few days...
> Just alter only live ebuild and branch of it with each release and do
> not alter the releases unless really critical bug is there. People are
> patient and they can wait for bugfixes.

I actually like that chromium releases at a high rate of speed. Does
that mean it sucks for Gentoo? Sure.
However if I want to stay on a particular rev (so I don't recompile
all the time) I can pmask it (and so can you.)

>
> Imagine that I would adopt your approach with libreoffice. I suppose
> people would chain me to some wall and use as target practice as
> result fo my actions

Well one; I care a lot less about having an up to date libre office
since it is not typically a target for attacks (unlike my browser
which has a large attack surface.)
That being said; if upstream did an actual release every week I
wouldn't be offended if those releases made it into the tree; again it
is up to me as a user to decide if i am recompiling or not.

-A

>
> Cheers
>
> Tom
>
>
 
Old 11-11-2011, 07:45 AM
Michał Górny
 
Default Stop altering of current release ebuilds and propagate the changes slowly

On Fri, 11 Nov 2011 00:22:34 -0800
Alec Warner <antarus@gentoo.org> wrote:

> > Like it is not enough there is version bump every few days...
> > Just alter only live ebuild and branch of it with each release and
> > do not alter the releases unless really critical bug is there.
> > People are patient and they can wait for bugfixes.
>
> I actually like that chromium releases at a high rate of speed. Does
> that mean it sucks for Gentoo? Sure.
> However if I want to stay on a particular rev (so I don't recompile
> all the time) I can pmask it (and so can you.)

Maybe you could consider some of the releases major and other minor,
and just keep a mask for those minor. Much like we did with Opera some
time ago.

--
Best regards,
Michał Górny
 
Old 11-11-2011, 08:21 AM
Tomáš Chvátal
 
Default Stop altering of current release ebuilds and propagate the changes slowly

2011/11/11 Alec Warner <antarus@gentoo.org>:
>
>> Like it is not enough there is version bump every few days...
>> Just alter only live ebuild and branch of it with each release and do
>> not alter the releases unless really critical bug is there. People are
>> patient and they can wait for bugfixes.
>
> I actually like that chromium releases at a high rate of speed. Does
> that mean it sucks for Gentoo? Sure.
> However if I want to stay on a particular rev (so I don't recompile
> all the time) I can pmask it (and so can you.)

I am not bitching about that updates, I am pissed that even if I
update the ebuild is altered afterwards so I again have to recompile
it for no obvious benefits. Even those bugfixes can wait for next damn
release that will happen in few days...
>
>>
>> Imagine that I would adopt your approach with libreoffice. I suppose
>> people would chain me to some wall and use as target practice as
>> result fo my actions
>
> Well one; I care a lot less about having an up to date libre office
> since it is not typically a target for attacks (unlike my browser
> which has a large attack surface.)
> That being said; if upstream did an actual release every week I
> wouldn't be offended if those releases made it into the tree; again it
> is up to me as a user to decide if i am recompiling or not.
>
You would be suprised how much people try to exploit your documents
and how interesting that gets

Tom
 
Old 11-11-2011, 08:32 AM
Brian Harring
 
Default Stop altering of current release ebuilds and propagate the changes slowly

On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
> Hi guys,
>
> In last 3 days i recompiled chromium 3x
>
> 1x rebuild for cups useflag
> 1x update
> 1x rebuild for cups useflag

<snip>

Chromium moves fast and you're obviously running unstable keywording.
Meaning you're *intentionally* getting every beta channel release.

Nicely phrased, your complaint is that having ran unstable keywords,
it's moving too fast for your taste. Stable keywords seem like an
obvious solution to it.

One thing that is less obvious is that there are essentially two
flavors of unstable chromium- dev and beta. Currently beta is 17.*,
dev is 16.*. If you don't want bleeding edge, but want faster than
stable, pmask 17.*.

That said... you're complaining that having ran unstable, you're
having to rebuild too much. Stable exists for a reason.

Either way, I suggest folks flip through the changelog- not seeing
anything egregious in bumping, refactoring appears to go out during
upstream version bumps.

For the cups rebuild referenced above is a build compilation failure
that was rolled out in existing versions (or in version bumps). It
may be an annoyance to Tommy that emerge -N picked it up, but for
folks hitting the build failure, they obviously view it a bit
differently (as evidenced by a fair amount of bitching on the bug in
question).

If you really, really want to keep running bleeding edge, rebuilding
for every change that occurs on it but selectively slowing down
certain builds... well, patch portage and mangle the existing vcs
rebuild code to be usable for other packages, adding a feature along
the lines of "I want to run bleeding edge X, but rebuild it only
weekly".

Barring that, the solutions for your user configuration problem are
above.

~harring
 
Old 11-11-2011, 08:48 AM
Tomáš Chvátal
 
Default Stop altering of current release ebuilds and propagate the changes slowly

2011/11/11 Brian Harring <ferringb@gmail.com>:
> On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
>> Hi guys,
>>
>> In last 3 days i recompiled chromium 3x
>>
>> 1x rebuild for cups useflag
>> 1x update
>> 1x rebuild for cups useflag
>
> <snip>
>
> Chromium moves fast and you're obviously running unstable keywording.
> Meaning you're *intentionally* getting every beta channel release.
I am getting dev releases...
>
> Nicely phrased, your complaint is that having ran unstable keywords,
> it's moving too fast for your taste. *Stable keywords seem like an
> obvious solution to it.

It already happened multiple times in the past and i am not bitching
about the updates but to updates to ebuild without bump...
>
> One thing that is less obvious is that there are essentially two
> flavors of unstable chromium- dev and beta. *Currently beta is 17.*,
> dev is 16.*. *If you don't want bleeding edge, but want faster than
> stable, pmask 17.*.
As i said i am on 16 which is in testing, beta series is masked.
>
> That said... you're complaining that having ran unstable, you're
> having to rebuild too much. *Stable exists for a reason.
>
> Either way, I suggest folks flip through the changelog- not seeing
> anything egregious in bumping, refactoring appears to go out during
> upstream version bumps.
>
> For the cups rebuild referenced above is a build compilation failure
> that was rolled out in existing versions (or in version bumps). *It
> may be an annoyance to Tommy that emerge -N picked it up, but for
> folks hitting the build failure, they obviously view it a bit
> differently (as evidenced by a fair amount of bitching on the bug in
> question).
>
> If you really, really want to keep running bleeding edge, rebuilding
> for every change that occurs on it but selectively slowing down
> certain builds... well, patch portage and mangle the existing vcs
> rebuild code to be usable for other packages, adding a feature along
> the lines of "I want to run bleeding edge X, but rebuild it only
> weekly".
>
> Barring that, the solutions for your user configuration problem are
> above.
>
The build issue was with -cups so useflag was removed and hard
dependency enabled, fine with me.
But why the fuck the bump was issued next day still hard-depending on
it and in day after that this commit arrived in:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-16.0.912.32.ebuild?r1=1.1&r2=1.2

You are telling me this is build time failure fix, you are telling me
that people that already had pulled in that cups could not sleep
thanks to it and survive for another week to get the flag back with
bump?
 
Old 11-11-2011, 09:39 AM
Brian Harring
 
Default Stop altering of current release ebuilds and propagate the changes slowly

On Fri, Nov 11, 2011 at 10:48:15AM +0100, Tom???? Chv??tal wrote:
> 2011/11/11 Brian Harring <ferringb@gmail.com>:
> The build issue was with -cups so useflag was removed and hard
> dependency enabled, fine with me.
> But why the fuck the bump was issued next day still hard-depending on
> it and in day after that this commit arrived in:
>
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-16.0.912.32.ebuild?r1=1.1&r2=1.2
>
> You are telling me this is build time failure fix, you are telling me
> that people that already had pulled in that cups could not sleep
> thanks to it and survive for another week to get the flag back with
> bump?

I'm telling you to stop fucking bitching about running unstable
software that probably is the fastest moving upstream in the tree in
terms of versions, nor the simplest fucking thing to maintain, let
alone keep everyone happy. Libreoffice I have no doubt is a pain in
the ass to maintain, but I'd take it over chromium any day of the
week.

Realize you're ranting on the ML because /you choose to run unstable/
and don't like that it's changing to deal w/ bugs (let alone the fast
release cycle of dev channel which you're on).

Specifically, you're ranting, and I strongly suspect you didn't bother
talking to the people directly beyond firing off bitching to the ML.

Nice and friendly, that.

As I said, looking through the logs it looks like this isn't
arbitrary random fucking around w/ ebuilds as you're implying above.
Is the cups situation a fuckup? Perhaps, but in digging through the
logs it ain't seeming like it's the norm. It's more seeming like
you're just venting about changes that went out fixing chromium
building for others, and you had to rebuild.

Productive courses of action, enumerated:
1) change your user configuration. You chose to run unstable after
all.
2) talk w/ the devs directly w/ suggestions of how to slow the
releases (doesn't frankly seem all that viable, but hey, it's your
time to burn). Keep in mind your original suggestion was to leave
shit broke in unstable (but hey, at least you don't have to
recompile).
3) add an optional feature to portage enabling you to control the
frequency of rebuilds for an unstable pkg. This way you get your
bleeding edge, just control the level of pain.

Non-produtive courses of action, enumerated:
1) bitching on an ML cc'ing the maintainers rather than going to the
maintainers directly.
2) continuing to argue with me.

~brian
 
Old 11-11-2011, 11:35 AM
Rich Freeman
 
Default Stop altering of current release ebuilds and propagate the changes slowly

On Fri, Nov 11, 2011 at 4:32 AM, Brian Harring <ferringb@gmail.com> wrote:
> On Fri, Nov 11, 2011 at 08:58:14AM +0100, Tom???? Chv??tal wrote:
> One thing that is less obvious is that there are essentially two
> flavors of unstable chromium- dev and beta. *Currently beta is 17.*,
> dev is 16.*. *If you don't want bleeding edge, but want faster than
> stable, pmask 17.*.

I agree that the solution to this particular problem is to run stable.
However, it is worth noting that chromium deviates from the normal
gentoo testing workflow quite a bit.

For a typical package new builds are introduced as a higher version,
stay in the tree for a month, and then get marked stable. Often not
every version makes it to stable, so there is little churn in the
stable version.

For chromium new builds are introduced as a higher version for the
unstable branches, but never make it to stable. Instead, typically
stable gets updated as a result of security/bugfixes with new versions
being introduced into the tree and quickly being stabilized. Since
the new versions are lower than the existing unstable versions nobody
but the developers ever actually test them. So, the stable branch of
chromium doesn't benefit from extended testing by the ~arch community.
The only way it could get tested is if a particular build was
released from dev to beta without any changes, and then from beta to
stable without any changes - which never happens.

Now, this is mitigated to an extent by the fact that Google is
following a relatively strict upstream QA process. A similar
situation exists with the kernel where new stable LTS versions get
introduced and yet never hit the ~arch users who are using versions
beyond them.

I'm not sure the current situation is "broken" per se and needs
fixing. But, the interaction of upstream QA and Gentoo QA is
something that we might want to think about. Since most upstream
projects have nowhere near the level of QA as either chromium or the
kernel this isn't going to be a widespread issue.

Rich
 
Old 11-11-2011, 01:44 PM
Jeroen Roovers
 
Default Stop altering of current release ebuilds and propagate the changes slowly

On Fri, 11 Nov 2011 09:45:29 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Maybe you could consider some of the releases major and other minor,
> and just keep a mask for those minor. Much like we did with Opera some
> time ago.

I have no idea what you mean. It didn't look like that when I was
doing it



jer
 
Old 11-11-2011, 01:58 PM
Michał Górny
 
Default Stop altering of current release ebuilds and propagate the changes slowly

On Fri, 11 Nov 2011 15:44:07 +0100
Jeroen Roovers <jer@gentoo.org> wrote:

> On Fri, 11 Nov 2011 09:45:29 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > Maybe you could consider some of the releases major and other minor,
> > and just keep a mask for those minor. Much like we did with Opera
> > some time ago.
>
> I have no idea what you mean. It didn't look like that when I was
> doing it

I simply mean that weekly builds were masked.

--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 03:11 AM.

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