Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[Joshua Saddler]

On Fri, 11 Nov 2011 15:53:44 -0600
William Hubbs  wrote:

> Hi all,
> 
> http://bugs.gentoo.org/show_bug.cgi?id=389437
> 
> has prompted a discussion of whether or not we should use ifconfig
> in openrc to configure networking on linux systems.
> 
> I'm not asking that we consider removing net-tools from systems,
> because there are tools there that we still need. In my view
> though, two of these tools (ifconfig and route), have been
> surpassed in functionality by iproute2's ip tool. So, what I am
> considering doing is dropping the ifconfig module from openrc and
> using iproute2 for all network configuration on linux systems.
> 
> The other side of the discussion seems to be that openrc needs to
> work on minimal installations, so we need to continue supporting
> using ifconfig.
> 
> I realize there would be a trade-off if I stop supporting linux's
> ifconfig and route in openrc, but how much of a trade-off? Would the
> benefits of iproute2 outweigh the down side of not supporting
> ifconfig and route on linux?
> 
> What does everyone think?
> 
> William
> 

i'm in favor of whatever doesn't force me and our users to install
Yet Another Tool besides what's in the system set, and whatever
doesn't result in a LOT of work for the GDP to update all of our
documentation. there are dozens of places in all the docs that refer
to ifconfig and the other utilities installed with
sys-apps/net-tools.

i'd really prefer it if i didn't have to learn a whole new set of
tools & syntax, and then had to rewrite all of our docs for them.
ifconfig and net-tools work as-is; i've yet to see a compelling case
for installing & learning iproute.

if net-tools isn't being dropped from the system set, don't force our
users to install redundant utilities.


signature.asc
Description: PGP signature

[gentoo-dev] Re: GCC 4.6 unmasking

[Ryan Hill]

On Sun, 30 Oct 2011 15:22:17 -0600
Ryan Hill  wrote:

> 4.6.2 is now in the tree.  It will be unmasked next weekend.

Yeah I'm a tease.  Looks like we have enough issues that I want to do
another patchset.  We also have showstopper bugs in grub:0 and libmpeg2 that
need looking at.  As always, if your favorite package is on
https://bugs.gentoo.org/showdependencytree.cgi?id=346809&hide_resolved=1
then it's time to get your ass in gear.


-- 
fonts, gcc-porting,  it makes no sense how it makes no sense
toolchain, wxwidgets   but i'll take it free anytime
@ gentoo.orgEFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662


signature.asc
Description: PGP signature

Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[William Hubbs]

On Fri, Nov 11, 2011 at 04:10:50PM -0600, Matt Thode wrote:
> I think that we should be using the new tools by now, it's been in 
> development for the last ten years.  There would have to be some sort of 
> migration path for people to use though.

If you have iproute2 installed, and you do not have a line like the
following in your /etc/conf.d/net file:

modules="!ifconfig"

or

modules_ifname="!ifconfig"

you are already using iproute2 to configure your routes and static
addresses, so the only thing that would need to change, and this doesn't
have to happen now, is that you would have to change over to using cidr
addresses,, for example:

config_ethx="x.x.x.x/24"

instead of

config_ifname="x.x.x.x netmask 255.255.255.0"

But, because of the way the network scripts are written, this is a
separate issue from dropping support for ifconfig, so it could be
handled with a migration path later.

William



pgpJSJlndVp4u.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[Chí-Thanh Christopher Nguyễn]

Matt Thode schrieb:
> I think that we should be using the new tools by now, it's been in 
> development for the last ten years.  There would have to be some sort of 
> migration path for people to use though.

Those people can continue using the tools they like, what openrc calls
is not visible to the user.
Removing/replacing references to the old tools from Gentoo documentation
would be something worth considering though.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[William Hubbs]

On Fri, Nov 11, 2011 at 11:01:43PM +0100, Chí-Thanh Christopher Nguyễn wrote:
> William Hubbs schrieb:
> > I realize there would be a trade-off if I stop supporting linux's
> > ifconfig and route in openrc, but how much of a trade-off? Would the
> > benefits of iproute2 outweigh the down side of not supporting ifconfig
> > and route on linux?
> > 
> > What does everyone think?
> 
> +1
> Do you need iproute2 at all? I think you could fall back to busybox if
> iproute2 is not installed.
 
 I haven't looked at busybox that much yet, but I know that ip is part
 of it, so that may be a possibility.

> While you are at it, please also switch from wireless-tools to iw :)
> https://bugs.gentoo.org/show_bug.cgi?id=261655

Yeah I know about that bug. :-) I want to get 0.9.5 out the door and
make that a stable candidate, then after that, I will look into both of
these.

William


pgpT73XHSlwTH.pgp
Description: PGP signature

Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[Matt Thode]

On Nov 11, 2011, at 4:01 PM, Chí-Thanh Christopher Nguyễn wrote:

> William Hubbs schrieb:
>> I realize there would be a trade-off if I stop supporting linux's
>> ifconfig and route in openrc, but how much of a trade-off? Would the
>> benefits of iproute2 outweigh the down side of not supporting ifconfig
>> and route on linux?
>> 
>> What does everyone think?
> 
> +1
> Do you need iproute2 at all? I think you could fall back to busybox if
> iproute2 is not installed.
> 
> While you are at it, please also switch from wireless-tools to iw :)
> https://bugs.gentoo.org/show_bug.cgi?id=261655
> 
> 
> Best regards,
> Chí-Thanh Christopher Nguyễn
> 

I think that we should be using the new tools by now, it's been in development 
for the last ten years.  There would have to be some sort of migration path for 
people to use though.

-- Matthew Thode

PGP.sig
Description: This is a digitally signed message part

Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[Chí-Thanh Christopher Nguyễn]

William Hubbs schrieb:
> I realize there would be a trade-off if I stop supporting linux's
> ifconfig and route in openrc, but how much of a trade-off? Would the
> benefits of iproute2 outweigh the down side of not supporting ifconfig
> and route on linux?
> 
> What does everyone think?

+1
Do you need iproute2 at all? I think you could fall back to busybox if
iproute2 is not installed.

While you are at it, please also switch from wireless-tools to iw :)
https://bugs.gentoo.org/show_bug.cgi?id=261655


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux

[William Hubbs]

Hi all,

http://bugs.gentoo.org/show_bug.cgi?id=389437

has prompted a discussion of whether or not we should use ifconfig in
openrc to configure networking on linux systems.

I'm not asking that we consider removing net-tools from systems, because
there are tools there that we still need. In my view though, two of
these tools (ifconfig and route), have been surpassed in functionality
by iproute2's ip tool. So, what I am considering doing is dropping the
ifconfig module from openrc and using iproute2 for all network
configuration on linux systems.

The other side of the discussion seems to be that openrc needs to work
on minimal installations, so we need to continue supporting using ifconfig.

I realize there would be a trade-off if I stop supporting linux's
ifconfig and route in openrc, but how much of a trade-off? Would the
benefits of iproute2 outweigh the down side of not supporting ifconfig
and route on linux?

What does everyone think?

William



pgpobWNG7UdX6.pgp
Description: PGP signature

[gentoo-dev] Lastrite: pythoncard and boa-constructor (part of wxGTK 2.6 removal)

[Samuli Suominen]

# Samuli Suominen  (11 Nov 2011)
# Masked for removal in 30 days since wxpython-2.6 is going away wrt bug
330683
dev-python/pythoncard
dev-util/boa-constructor

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Paweł Hajdan, Jr.]

First thanks for the feedback about chromium, and sorry for the
annoyances. I'm not sure how we can "fix" that though.

I've batched my replies to several people in this e-mail.

On 11/11/11 8:58 AM, Tomáš Chvátal wrote:
> In last 3 days i recompiled chromium 3x

So the timeline is:

26 Oct  is filed.
01 Nov cups USE is dropped from 16.x while still hard masked
03 Nov 16.x is unmasked (dev -> beta release)
10 Nov cups USE restored for 16.x while in ~arch

I'm not sure which update you've applied (there are many in that time
range), but the data suggests you're running hard masked package
(otherwise you shouldn't see those cups USE flag changes).

> If you screw the ebuild up then always think if the change is worth
> the stupid long recompile time.

Sorry about the recompile time, but then you're not required to actually
apply the update every time it's available. Also, if you sync and update
every day, that in itself increases number of updates, just most
packages are smaller than chromium.

Note that changes that don't require revbumps are done without revbumps.
USE flag changes are only picked up with -N emerge option. All other
changes require a revbump, which is usually compensated by hard mask on
the dev channel releases.

I avoid needlessly revbumping beta and especially stable. If you have a
case where this happened and I just didn't realize what I was doing,
please let me know.

> Like it is not enough there is version bump every few days...

That's how upstream does it. Stable channel releases are roughly every
2-3 weeks from each other (the release cycle is 6 weeks, but there are
usually 1-2 security updates in between).

> 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.

The problem here is that at least for me it's hard to work with live
ebuild (upstream moves very fast at ~200 commits per day
chromium+webkit), so I mostly work on dev channel releases which are
roughly weekly. They're hard masked though.

And then if we want stable and ~arch to be unaffected, the fix should be
pushed as fast as possible, so we can test it before that branch is
promoted to a more stable channel, which happens within weeks, much
faster than with many other projects.

On 11/11/11 9:45 AM, Michał Górny wrote:
> Maybe you could consider some of the releases major and other minor,
> and just keep a mask for those minor.

Yup, stable is stable, beta is ~arch, and dev is hard masked.

On 11/11/11 3:58 PM, Michał Górny wrote:
> I simply mean that weekly builds were masked.

Note that in case of chromium those are actually releases, that go
through upstream QA etc.



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: Stop altering of current release ebuilds and propagate the changes slowly

[Mike Gilbert]

On 11/11/2011 2:58 AM, 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
> 
> 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

I often rebuild chromium several times a day, so I probably don't notice
the effect that small changes would have on a more typical user. I'm
sorry that the frequent updates are inconvenient for you.

I think Pawel and I do a good job of not screwing with the stable channel.

We try to limit most of the changes to the dev channel releases (hard
masked). The cups use flag change happened just before upstream pushed
16.x to the beta channel (~arch), so that put us in an odd spot when
adding the cups use flag back.



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: have portage be quiet by default

[Mike Frysinger]

On Friday 11 November 2011 10:50:47 Zac Medico wrote:
> On 11/10/2011 10:59 PM, Duncan wrote:
> > But please do at least einfo the change, and what to do to get back to
> > non-quiet by default if desired.  Someone mentioned a news item.  I'm not
> > sure it warrants that, but certainly an einfo, and if a news item will
> > prevent needless bugs and is thought to be worth the required
> > bureaucracy, I've no problem with it.
> 
> Yeah, I think a new item is a bit too much. I'll mention it in the
> ebuild ChangeLog, the RELEASE-NOTES, and I'll also trigger an elog
> message when upgrading from earlier versions.

a note to dev-announce might be a good compromise.  i think a news item too 
heavy as well ...
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Nirbheek Chauhan]

On Fri, Nov 11, 2011 at 3:02 PM, Brian Harring  wrote:
> 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
>
> 
>
> Chromium moves fast and you're obviously running unstable keywording.
> Meaning you're *intentionally* getting every beta channel release.
>

Actually, even in the mozilla team, we try to reduce the no. of
revbumps and USE-flag changes ebuilds get by batching them up. Even
though Firefox (and earlier xulrunner) doesn't have the crazy release
cycle of Chromium (yet), it simply helps to reduce irritation for
users. We try the same with webkit-gtk/evolution/e-d-s under GNOME
(although, they don't require many updates anyway).

Small things like these that cost little help in keeping users happy.
It's a very easy development process change. I remember a blog post by
the chromium team about this too, so they are aware of user
complaints. scarabeus isn't the only one. :)

Also, about attack vectors on beta builds of chromium, they're too
fast-moving a target with a very low target population. Excessively
unlikely that someone will release malware to attack a vulnerability
in version 17.x.y.z. We don't need to go ape-shit over security of
alpha/beta builds. Serious bugs, of course, should be fixed.

OTOH, if you're seriously concerned about personalized attacks, you
should be running adblock and noscript anyway.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] Re: have portage be quiet by default

[Zac Medico]

On 11/10/2011 10:59 PM, Duncan wrote:
> Zac Medico posted on Thu, 10 Nov 2011 18:11:38 -0800 as excerpted:
> 
>> I think --quiet-build would be a reasonable default, but --quiet
>> suppresses various warning messages that I think need to be enabled by
>> default for newbies.
> 
> What's the difference in output format between --quiet, and the output 
> one gets with parallel portage jobs (not just MAKEOPTS but emerge-jobs, 
> too) turned on (my default these days)?
> 
> If it's the same as with parallel emerge-jobs, yeah, quiet emerges by 
> default makes sense to me.

It's identical.

> But please do at least einfo the change, and what to do to get back to 
> non-quiet by default if desired.  Someone mentioned a news item.  I'm not 
> sure it warrants that, but certainly an einfo, and if a news item will 
> prevent needless bugs and is thought to be worth the required 
> bureaucracy, I've no problem with it.

Yeah, I think a new item is a bit too much. I'll mention it in the
ebuild ChangeLog, the RELEASE-NOTES, and I'll also trigger an elog
message when upgrading from earlier versions.
-- 
Thanks,
Zac

Re: [gentoo-dev] have portage be quiet by default

[Zac Medico]

On 11/11/2011 07:11 AM, Mike Frysinger wrote:
> On Thursday 10 November 2011 22:23:57 Zac Medico wrote:
>> On 11/10/2011 07:17 PM, Zac Medico wrote:
>>> On 11/10/2011 06:59 PM, Mike Frysinger wrote:
 On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
>> On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
>>> if you want quiet portage output, use something like --quiet when
>>> running emerge.  the verbosity of the build output isn't really an
>>> issue imo.
>>
>> perhaps a more controversial question: should we make --quiet the
>> default
>
> I think --quiet-build would be a reasonable default, but --quiet
> suppresses various warning messages that I think need to be enabled by
> default for newbies.

 WFM

 would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults
 be too hideous for people to swallow ?
>>>
>>> Less than sys-apps/portage-2.1.9.43 will choke on that, it's an
>>> unrecognized option. So, we'd better just enable it by default for the
>>> next portage release.
>>
>> Actually, it's been around since portage-2.1.7.5 (bug #291200). Still,
>> it's probably better not to set it in the profile.
> 
> good point.  we don't want to punish old portage users.  let's enable it by 
> default in portage itself then.  just add `elog` output to the portage ebuild 
> to inform users of the change ?  or do we want a news item ?
> 
> what's the flag to negate the default ?  --no-quiet-build ? ;)
> -mike

It's --quiet-build=n. I've gone ahead and enabled it for release in
portage-2.1.10.34:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0cc174b6fc28feb26ea151d76f794e0ff2c2fa39

-- 
Thanks,
Zac

Re: [gentoo-dev] Packages up for grabs

[Mike Frysinger]

On Friday 11 November 2011 10:05:56 Nathan Phillip Brink wrote:
> On Fri, Nov 11, 2011 at 09:38:24AM -0500, Ian Stakenvicius wrote:
> > On 11/11/11 06:38 AM, Tomáš Chvátal wrote:
> > > sys-devel/autoconf-archive - binki
> 
> I'll take autoconf-archive, unless if someone else wants it.

i was going to set  to base-system, but i haven't committed it yet.  if 
you want to do that, and add yourself under , then feel free.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Jeroen Roovers]

On Fri, 11 Nov 2011 15:58:10 +0100
Michał Górny  wrote:
> I simply mean that weekly builds were masked.

I still do it like that with snapshots and in fact with
the entire www-client/opera-next series.


 jer

Re: [gentoo-dev] have portage be quiet by default

[Mike Frysinger]

On Thursday 10 November 2011 22:23:57 Zac Medico wrote:
> On 11/10/2011 07:17 PM, Zac Medico wrote:
> > On 11/10/2011 06:59 PM, Mike Frysinger wrote:
> >> On Thursday 10 November 2011 21:11:38 Zac Medico wrote:
> >>> On 11/10/2011 05:56 PM, Mike Frysinger wrote:
>  On Thursday 10 November 2011 20:39:11 Mike Frysinger wrote:
> > if you want quiet portage output, use something like --quiet when
> > running emerge.  the verbosity of the build output isn't really an
> > issue imo.
>  
>  perhaps a more controversial question: should we make --quiet the
>  default
> >>> 
> >>> I think --quiet-build would be a reasonable default, but --quiet
> >>> suppresses various warning messages that I think need to be enabled by
> >>> default for newbies.
> >> 
> >> WFM
> >> 
> >> would putting this as EMERGE_DEFAULT_OPTS in profiles/base/make.defaults
> >> be too hideous for people to swallow ?
> > 
> > Less than sys-apps/portage-2.1.9.43 will choke on that, it's an
> > unrecognized option. So, we'd better just enable it by default for the
> > next portage release.
> 
> Actually, it's been around since portage-2.1.7.5 (bug #291200). Still,
> it's probably better not to set it in the profile.

good point.  we don't want to punish old portage users.  let's enable it by 
default in portage itself then.  just add `elog` output to the portage ebuild 
to inform users of the change ?  or do we want a news item ?

what's the flag to negate the default ?  --no-quiet-build ? ;)
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Packages up for grabs

[Mike Frysinger]

On Friday 11 November 2011 06:38:00 Tomáš Chvátal wrote:
> sys-devel/autoconf-archive

i'd been updating this for years ... didn't realize someone else had taken it 
over ;).  i'll move it to base-system herd.
-mike


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Packages up for grabs

[Nathan Phillip Brink]

On Fri, Nov 11, 2011 at 09:38:24AM -0500, Ian Stakenvicius wrote:
> OK, to clarify i'm just re-listing which packages ppl have spoken up for:
> 
> 
> On 11/11/11 06:38 AM, Tomáš Chvátal wrote:
> > 
> > app-misc/dsgui
> > app-misc/klavaro
> > dev-cpp/yaml-cpp - neurogeek
> > dev-libs/softhsm - mschiff
> > dev-ruby/dnsruby - mschiff
> > net-dns/opendnssec - mschiff
> > net-libs/dslib
> > net-libs/libisds
> > net-misc/shigofumi
> > sys-devel/autoconf-archive - binki

I'll take autoconf-archive, unless if someone else wants it.

-- 
binki

Look out for missing or extraneous apostrophes!


pgpkm8X0yZYdb.pgp
Description: PGP signature

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Michał Górny]

On Fri, 11 Nov 2011 15:44:07 +0100
Jeroen Roovers  wrote:

> On Fri, 11 Nov 2011 09:45:29 +0100
> Michał Górny  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Jeroen Roovers]

On Fri, 11 Nov 2011 09:45:29 +0100
Michał Górny  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

Re: [gentoo-dev] Packages up for grabs

[Ian Stakenvicius]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

OK, to clarify i'm just re-listing which packages ppl have spoken up for:


On 11/11/11 06:38 AM, Tomáš Chvátal wrote:
> 
> app-misc/dsgui
> app-misc/klavaro
> dev-cpp/yaml-cpp - neurogeek
> dev-libs/softhsm - mschiff
> dev-ruby/dnsruby - mschiff
> net-dns/opendnssec - mschiff
> net-libs/dslib
> net-libs/libisds
> net-misc/shigofumi
> sys-devel/autoconf-archive


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)

iF4EAREIAAYFAk69M2AACgkQAJxUfCtlWe1FogD/dnqup9UAq8JFkCbonJtY27wk
FzsnbmP6uYdpbO40gccA/1SWJQ7o8PWBbL2gENbHOwQaVWyC67YbwGWFjyijtrpc
=VXw8
-END PGP SIGNATURE-

Re: [gentoo-dev] Packages up for grabs

[Jesus Rivero (Neurogeek)]

2011/11/11 Tomáš Chvátal :
> Hello guys,
>
> As my only Gentoo installation is libreoffice test virtual I am not
> able to really care about these.
>
> So these packages are up for grabs if anyone finds them interesting:
>
> app-misc/dsgui
> app-misc/klavaro
> dev-cpp/yaml-cpp
> dev-libs/softhsm
> dev-ruby/dnsruby
> net-dns/opendnssec
> net-libs/dslib
> net-libs/libisds
> net-misc/shigofumi
> sys-devel/autoconf-archive
>
> Have fun
>
> Tom

I'll take dev-cpp/yaml-cpp.

Best regards,
>
>



-- 
Jesus Rivero (Neurogeek)
Gentoo Developer

Re: [gentoo-dev] Packages up for grabs

[Marc Schiffbauer]

* Tomáš Chvátal schrieb am 11.11.11 um 12:38 Uhr:
> Hello guys,
> 
> As my only Gentoo installation is libreoffice test virtual I am not
> able to really care about these.
> 
> So these packages are up for grabs if anyone finds them interesting:
> 

and those two as well as opendnssec depends on them

> dev-libs/softhsm
> dev-ruby/dnsruby

-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Rich Freeman]

On Fri, Nov 11, 2011 at 4:32 AM, Brian Harring  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

Re: [gentoo-dev] Packages up for grabs

[Marc Schiffbauer]

* Tomáš Chvátal schrieb am 11.11.11 um 12:38 Uhr:
> Hello guys,
> 
> As my only Gentoo installation is libreoffice test virtual I am not
> able to really care about these.
> 
> So these packages are up for grabs if anyone finds them interesting:

I will take this one:

> net-dns/opendnssec


-Marc
-- 
8AAC 5F46 83B4 DB70 8317  3723 296C 6CCA 35A6 4134


signature.asc
Description: Digital signature

[gentoo-dev] Packages up for grabs

[Tomáš Chvátal]

Hello guys,

As my only Gentoo installation is libreoffice test virtual I am not
able to really care about these.

So these packages are up for grabs if anyone finds them interesting:

app-misc/dsgui
app-misc/klavaro
dev-cpp/yaml-cpp
dev-libs/softhsm
dev-ruby/dnsruby
net-dns/opendnssec
net-libs/dslib
net-libs/libisds
net-misc/shigofumi
sys-devel/autoconf-archive

Have fun

Tom

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Brian Harring]

On Fri, Nov 11, 2011 at 10:48:15AM +0100, Tom Chv??tal wrote:
> 2011/11/11 Brian Harring :
> 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

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Tomáš Chvátal]

2011/11/11 Brian Harring :
> 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
>
> 
>
> 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?

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Brian Harring]

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



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


signature.asc
Description: Digital signature

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Tomáš Chvátal]

2011/11/11 Alec Warner :
>
>> 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

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Michał Górny]

On Fri, 11 Nov 2011 00:22:34 -0800
Alec Warner  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


signature.asc
Description: PGP signature

Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly

[Alec Warner]

2011/11/10 Tomáš Chvátal :
> 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
>
>