Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
2011/11/10 Tomáš Chvátal scarab...@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
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
On Fri, 11 Nov 2011 00:22:34 -0800 Alec Warner anta...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
2011/11/11 Alec Warner anta...@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
Re: [gentoo-dev] 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 signature.asc Description: Digital signature
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
2011/11/11 Brian Harring ferri...@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.1r2=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
On Fri, Nov 11, 2011 at 10:48:15AM +0100, Tom Chv??tal wrote: 2011/11/11 Brian Harring ferri...@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.1r2=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] Packages up for grabs
* 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
Re: [gentoo-dev] Packages up for grabs
* 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] Packages up for grabs
2011/11/11 Tomáš Chvátal scarab...@gentoo.org: 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
-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] Stop altering of current release ebuilds and propagate the changes slowly
On Fri, 11 Nov 2011 09:45:29 +0100 Michał Górny mgo...@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
Re: [gentoo-dev] Stop altering of current release ebuilds and propagate the changes slowly
On Fri, 11 Nov 2011 15:44:07 +0100 Jeroen Roovers j...@gentoo.org wrote: On Fri, 11 Nov 2011 09:45:29 +0100 Michał Górny mgo...@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 signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
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] Packages up for grabs
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] have portage be quiet by default
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] Stop altering of current release ebuilds and propagate the changes slowly
On Fri, 11 Nov 2011 15:58:10 +0100 Michał Górny mgo...@gentoo.org 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] Packages up for grabs
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 herd to base-system, but i haven't committed it yet. if you want to do that, and add yourself under maintainer, then feel free. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] have portage be quiet by default
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] Re: have portage be quiet by default
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] Stop altering of current release ebuilds and propagate the changes slowly
On Fri, Nov 11, 2011 at 3:02 PM, Brian Harring ferri...@gmail.com 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 snip 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
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.
[gentoo-dev] Re: Stop altering of current release ebuilds and propagate the changes slowly
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] Stop altering of current release ebuilds and propagate the changes slowly
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 https://bugs.gentoo.org/388497 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] Lastrite: pythoncard and boa-constructor (part of wxGTK 2.6 removal)
# Samuli Suominen ssuomi...@gentoo.org (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
[gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
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
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
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
Re: [gentoo-dev] rfc: openrc: use iproute2 for all network handling in linux
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
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 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
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
[gentoo-dev] Re: GCC 4.6 unmasking
On Sun, 30 Oct 2011 15:22:17 -0600 Ryan Hill dirtye...@gentoo.org 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=346809hide_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
On Fri, 11 Nov 2011 15:53:44 -0600 William Hubbs willi...@gentoo.org 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
