[gentoo-dev] Re: openrc: oldnet vs newnet
William Hubbs posted on Mon, 20 Sep 2010 22:03:54 -0500 as excerpted: > [ Duncan wrote...] >> However, if we keep newnet around as a masked USE flag until it's no >> longer worth continuing, it'll give people already using it time to >> switch back, and/or to build up their own site scripts as workarounds, >> as newnet gradually gets more and more stale and broken. > > It won't be "masked", it just won't be the default setup, and you will > have to do some work that will not be documented to turn it on. I had seen some suggestions of masking it, and while it hadn't been fully discussed, that made sense to me as a USE flag to mask by default, to make it clear that its use was discouraged. And with no documentation and with someone else pointing out that in practice, arch-testers are likely to test only one or the other, and with oldnet the default it'll be oldnet, realistically, support for it in any of the network packages beyond openrc itself, is going to be somewhat iffy. As such, IMO discouraging usage, upto and including masking the newnet USE flag, does make some sense, while allowing those who are already using it some time to gracefully find other solutions, or create their own, starting with copying the existing newnet scripts if desired. But that can certainly be debated, and arguably, each arch team and optional network package could make that decision on their own, deciding to support and test both ways, if desired. I just think it's more work to support /properly/ than it's worth, in which case, masking the USE flag seems a reasonable way to communicate its unsupported status. >> Finally, I'm not sure it absolutely needs it, but for clarity-sake and >> to avoid second-guessing and debate continuing long past the point of >> usefulness, I believe a council vote on the issue is appropriate. > If we keep oldnet as the default, there is nothing for the council to > vote on as far as I can see, because stable users are covered in the > migration guide at http://www.gentoo.org/doc/en/openrc-migration.xml. > If they follow that path, there is nothing special they need to do > outside of that, so there isn't any affect. Good point. I had forgotten to take the current status of oldnet-only support into account, and was thinking that was the best way to settle the question when the inevitable complaints came. It still might be useful if someone involved wants some CYA, but as you point out, since newnet was never really supported, specifically /not/ supporting it isn't really a change of status, so no council vote actually needed. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: openrc: oldnet vs newnet
On Monday, September 20, 2010 23:03:54 William Hubbs wrote: > On Tue, Sep 21, 2010 at 01:22:59AM +, Duncan wrote: > > Finally, I'm not sure it absolutely needs it, but for clarity-sake and to > > avoid second-guessing and debate continuing long past the point of > > usefulness, I believe a council vote on the issue is appropriate. I > > don't know where we are in the meeting cycle, but it seems to me that > > barring some special-case exception, a vote in 10 days or so should be > > plenty of time for folks to make their opinions known, so the first > > meeting after that looks to be appropriate for a vote, to me. > > If we keep oldnet as the default, there is nothing for the council to > vote on as far as I can see, because stable users are covered in the > migration guide at http://www.gentoo.org/doc/en/openrc-migration.xml. > If they follow that path, there is nothing special they need to do > outside of that, so there isn't any affect. yeah, that isnt necessary. i didnt think people were actually using newnet and so we could punt it, but apparently i'm wrong in that regard. which means we either reach feature parity/simplicity between the two and merge them, or leave it alone if, by design, that is not feasible. oldnet may be complicated in some regards, but the fact that it easily works on so many diverse systems/setups means it cannot simply be culled. on s390 for example, network setup requires loading modules and grubbing around in /sys/ before the interface even exists. there is no package/script to do this for you and every other distro ive seen out there that supports s390 has a huge number of hacks in their init system to support things. whereas the Gentoo way is extraordinarily clean. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: openrc: oldnet vs newnet
On Tue, Sep 21, 2010 at 01:22:59AM +, Duncan wrote: > Keeping oldnet the default and only documented method, does seem to be the > most pragmatic/practical solution. > > Given nightmorph's indication that he's not interested in redoing the docs > twice, or documenting both methods, that does mean we're keeping oldnet > for the foreseeable future, probably as long as we keep openrc, and > there's no clear/foreseeable plan to migrate from it, so... . > > The implication is even if we don't immediately drop newnet support for > those that are already using it, it'll be undocumented, untested for > network package bumps, and therefore unsupported. In practice, anything > in /that/ status eventually dies, so by implication, a decision to make > oldnet the default and only documented version ultimately means newnet > will become less and less practical to run as it requires more and more > specific installation support and workarounds to keep it up and running. > However, if we keep newnet around as a masked USE flag until it's no > longer worth continuing, it'll give people already using it time to switch > back, and/or to build up their own site scripts as workarounds, as newnet > gradually gets more and more stale and broken. It won't be "masked", it just won't be the default setup, and you will have to do some work that will not be documented to turn it on. > Finally, I'm not sure it absolutely needs it, but for clarity-sake and to > avoid second-guessing and debate continuing long past the point of > usefulness, I believe a council vote on the issue is appropriate. I don't > know where we are in the meeting cycle, but it seems to me that barring > some special-case exception, a vote in 10 days or so should be plenty of > time for folks to make their opinions known, so the first meeting after > that looks to be appropriate for a vote, to me. If we keep oldnet as the default, there is nothing for the council to vote on as far as I can see, because stable users are covered in the migration guide at http://www.gentoo.org/doc/en/openrc-migration.xml. If they follow that path, there is nothing special they need to do outside of that, so there isn't any affect. William pgpi0yxanWOnw.pgp Description: PGP signature
[gentoo-dev] Re: openrc: oldnet vs newnet
William Hubbs posted on Mon, 20 Sep 2010 13:07:44 -0500 as excerpted: > On Mon, Sep 20, 2010 at 10:52:23AM -0700, Joshua Saddler wrote: >> On Mon, 20 Sep 2010 11:16:08 -0500 >> William Hubbs wrote: >> >> > All, >> > >> > I want to start a new thread since the discussion on openrc is >> > centering on whether we should use oldnet, newnet, or keep both. >> >> Use "oldnet." Why? >> >> 1. We already have a migration guide setup for it: >> >> http://www.gentoo.org/doc/en/openrc-migration.xml >> >> Keeping "oldnet" will greatly reduce the time needed to change all our >> other docs, since I can use it as a reference, without needing write a >> completely new migration guide for "oldnet" and *then* still have to >> change all our other docs. >> >> 2. Users are already accustomed to doing things via "oldnet," since >> they've been using OpenRC and following this guide for two years now, >> since 2008. > > I'm fine with it being the default for stable for now. > > However, I do think that once we stabilize it, we can learn something > from parts of newnet, and possibly use what it was trying to do. [I noticed that only the two bugs were still open a couple days ago, with one being documentation, with effectively an "after *" dependency, and wondered when these threads might appear. =:^) The below is my opinion, yes, but it's also intended as a bit of a high-level summary of what I've seen on the two threads so far. It seems to me this is most likely where things are headed, so if people disagree, perhaps they better post.] Keeping oldnet the default and only documented method, does seem to be the most pragmatic/practical solution. Given nightmorph's indication that he's not interested in redoing the docs twice, or documenting both methods, that does mean we're keeping oldnet for the foreseeable future, probably as long as we keep openrc, and there's no clear/foreseeable plan to migrate from it, so... . The implication is even if we don't immediately drop newnet support for those that are already using it, it'll be undocumented, untested for network package bumps, and therefore unsupported. In practice, anything in /that/ status eventually dies, so by implication, a decision to make oldnet the default and only documented version ultimately means newnet will become less and less practical to run as it requires more and more specific installation support and workarounds to keep it up and running. However, if we keep newnet around as a masked USE flag until it's no longer worth continuing, it'll give people already using it time to switch back, and/or to build up their own site scripts as workarounds, as newnet gradually gets more and more stale and broken. It's worth noting here that newnet is a part of openrc, which has only been in ~arch. There's nothing wrong with running ~arch, I run it myself, but one thing those running it do need to be prepared for, is change, change that in some cases means rolling back to older setups. As such, I don't believe the status of anyone already switched to newnet is of particular concern -- it's a risk they took, that they at least should have known was a risk. I don't believe we /need/ to leave newnet as a USE flag on their account, masked or unmasked, but given the functionality is there already, it doesn't hurt to leave it there, masked, for those that use it, to give them time to either switch back or build their own network scripts, as they wish. Meanwhile, as you (williamh) rightfully mention, just because we decide to settle on oldnet only for documentation and support, doesn't mean there's nothing in newnet worth learning from and possibly pulling into oldnet. Nothing in the above says oldnet won't continue to grow and change. In fact, that alone would ultimately destine it for the same fate as we're discussing for newnet. So yes, let's certainly borrow from newnet where it makes sense, and continue to adapt and change oldnet to modern tools and ways of doing things. Nothing wrong with that! Finally, I'm not sure it absolutely needs it, but for clarity-sake and to avoid second-guessing and debate continuing long past the point of usefulness, I believe a council vote on the issue is appropriate. I don't know where we are in the meeting cycle, but it seems to me that barring some special-case exception, a vote in 10 days or so should be plenty of time for folks to make their opinions known, so the first meeting after that looks to be appropriate for a vote, to me. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] openrc stabilization update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/20/2010 02:32 PM, Mike Frysinger wrote: > On Monday, September 20, 2010 13:49:08 Joshua Saddler wrote: >> Wrong. It will. The GDP--that's effectively just me--will already have to >> rewrite every single one of hundreds of pages of documentation to allow >> for the new syntax and way of doing things present in the "oldnet" >> behavior of OpenRC. That's ~weeks to ~months of work, even if there's >> someone besides me doing it. I'll have to do all that effort and time >> commitment yet again if we have to rewrite everything once "newnet" >> becomes the default after everyone uses "oldnet" for a while. > > man, fix your line length. what a nub you are. > >> Please. Just stick to *one* config. I strongly suggest that it be "oldnet," >> given all the problems with "newnet" raised in this thread. But more >> importantly, because *the groundork has already been done* when I wrote >> the OpenRC Migration Guide. I can piggyback all my efforts off that guide, >> which will greatly shorten the amount of time needed for the rest of the >> documentation. Otherwise a completely new "migration" guide will have to >> be written, AND all the docs will need to be adjusted to THAT one. > > we're going with oldnet by default in stable and that'll be what the GDP has > to worry about. newnet will still be there, but people will have to manually > opt out of oldnet and opt in to newnet. i dont think we need to worry about > documenting it in the handbook for now ... the bundled files with openrc are > sufficient. > -mike +1 I'm not even worried about documenting newnet. I just don't want it thrown out of openrc. Leaving it in the background is fine. - -- Anthony G. Basile, Ph.D. Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyX8GMACgkQl5yvQNBFVTUFZgCdGbk0Irx9VJUJqnGDcGjlSOcr 6sIAn2zaKI7gNa1q9qfyYzZgwX11a8/T =r/Iw -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: per package eclass GLEP
On 09/20/2010 07:30 PM, Alec Warner wrote: > Under the new system I can put the code: > > 1) In a global eclass, any ebuild can likely use it > 2) In a per-package eclass, only one package can use it > 3) In a pkg eblit, only one package can use it Per package eclasses are pretty much eblits with some PM support thrown in. > Wouldn't taking code from a global eclass and moving it to a > per-package eclass limit code re-use? No, code reuse will stay the same. What I like about the idea is moving more of the code closer to the ebuild files, tightening it's scope. No more wondering (as an ebuild author) if and how I could use php5_2-sapi.eclass - it just wouldn't be there. I'll answer more points tomorrow, but thanks for your ideas! signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] openrc stabilization update
Eray Aslan wrote: On 20.09.2010 16:37, Richard Freeman wrote: One argument I've heard against newnet is that you can't bring individual interfaces up and down. openrc[newnet] used to have problems with ppp interfaces. I do not know if it is still the case but there are some open bugs on bugzilla.g.o regarding ppp and openrc. This is a serious show stopper for newnet. So, either 1. both oldnet and newnet or 2. oldnet only would be the prudent alternatives (again, assuming problems with newnet and ppp exist). If this is the same ppp I use when on dial-up, this would make me reconsider using Gentoo. If my DSL goes out, I must have ppp and it work. We are in the sticks and the one time it has gone out since getting DSL, it was out several days. I still have wvdial installed and all the needed ppp drivers in my kernel. I don't use it often but when I need it, I need it. For this user, I would have to have a way to keep ppp available if this is the same ppp I use for dial-up. Dale :-) :-)
Re: [gentoo-dev] openrc: oldnet vs newnet
On Mon, Sep 20, 2010 at 08:18:32PM +0200, Antoni Grzymala wrote: > Does that support configurations where I set static addresses > (including ipv6) and routes (also including ipv6) based on the SSID as > is allowed by the oldnet scheme of things? I (and probably lots other > ???power users???) rely on those features extensively and I thank whoever > came up with the idea of actually configuring that in a pretty simple > way (compared to other distros and OS'es where it is more complicated > or plain impossible sometimes). Things like this are why I wanted to bring up this discussion. I personally haven't had a reason to set things up based on a ssid, so I've never tried to do that. wpa_supplicant doesn't assign addresses or routes to interfaces; it just handles the wireless portion of the setup. In my setup, dhcpcd handles assigning the route and address to the interface. For a setup involving static routes and addresses on wireless, you would still need to use a network script to configure the routes or addresses, just like you do for static addresses on a wired interface, you just wouldn't want it to run wpa_supplicant since wpa_supplicant would already be running. I guess these are the questions I'm asking in this thread: dhcpcd and wpa_supplicant, in particular, are able to manage any network interfaces they find on a system independently of what we are doing in the network scripts. The oldnet scheme runs one instance of these for each network interface instead of running one instance and allowing that instance to manage all of the interfaces. What is the reason we do that? Is it possible to rework things so that the oldnet scheme uses system wide instances of services instead of running multiple copies of them on multiple interfaces where possible? William pgp4BqO2U4dBd.pgp Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
Tobias Klausmann dixit (2010-09-20, 20:34): > On Mon, 20 Sep 2010, Benedikt Böhm wrote: > > On Mon, Sep 20, 2010, Tobias Klausmann wrote: > > > who runs servers: DHCP is uncommon there, WLAN is very unusual, > > > as a result, they would not only have to switch the way they > > > configure their nets (people don't like that kind of stuff if the > > > machine is 400 miles away); they would also have to find a way to > > > build their setups in the new "language". Servers tend to have > > > more complicated setups network-wise than workstations (think > > > firewalls, VPN endpoint, traffic observation, ...). > > > > the same is true for everyone who already runs newnet (like me). in > > fact, i do not even use the newnet conf.d stuff, but rather take > > advantage of support for /etc/ifup.eth* in /etc/init.d/network. that > > way i can configure the networking with iproute2 or any other tool > > that i already know the syntax of. no need to learn ridiculously > > convoluted array syntax foo for /etc/init.d/net.eth*. > > > > so please just keep the network init script as a use flag or extra > > package or something, so that one is not forced to use the old net > > stuff (again). > > > > P.S.: newnet does not in any way force you to use DHCP or WLAN or > > anything like that, so please stop spreading misinformation. > > Still, newnet is geared towards such setups and it is reflected > in the way it handles things. /This/ I meant by "language". And > yes, going from complicated arrays to iproute2 syntax *is* a > change that may blow up in your face, if you don't use those > tools every day. As far as I can see, oldnet (at least if you do modules="iproute2" which most sane users probably do) is *also* basically iproute2 syntax, only wrapped in some arrays: routes_Okno=( "default via 192.168.0.254" "default via 2001:foo:bar::1" ) I could add other typical iproute2 clauses to that config, like src , or metric . Same with the IP address clause. Flexible, already documented. +1 for keeping oldnet. -- [a]
Re: [gentoo-dev] openrc stabilization update
Hi!
On Mon, 20 Sep 2010, Benedikt Böhm wrote:
> On Mon, Sep 20, 2010, Tobias Klausmann wrote:
> > who runs servers: DHCP is uncommon there, WLAN is very unusual,
> > as a result, they would not only have to switch the way they
> > configure their nets (people don't like that kind of stuff if the
> > machine is 400 miles away); they would also have to find a way to
> > build their setups in the new "language". Servers tend to have
> > more complicated setups network-wise than workstations (think
> > firewalls, VPN endpoint, traffic observation, ...).
>
> the same is true for everyone who already runs newnet (like me). in
> fact, i do not even use the newnet conf.d stuff, but rather take
> advantage of support for /etc/ifup.eth* in /etc/init.d/network. that
> way i can configure the networking with iproute2 or any other tool
> that i already know the syntax of. no need to learn ridiculously
> convoluted array syntax foo for /etc/init.d/net.eth*.
>
> so please just keep the network init script as a use flag or extra
> package or something, so that one is not forced to use the old net
> stuff (again).
>
> P.S.: newnet does not in any way force you to use DHCP or WLAN or
> anything like that, so please stop spreading misinformation.
Still, newnet is geared towards such setups and it is reflected
in the way it handles things. /This/ I meant by "language". And
yes, going from complicated arrays to iproute2 syntax *is* a
change that may blow up in your face, if you don't use those
tools every day.
I'm not saying change is bad, but needless change with little
functional benefit is - especially in this case where you can
have the benefits of newnet (simply using the system tools in
scripts) without switching from oldnet to newnet, as Luca has
pointed out.
Regards,
Tobias
--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmp.c
Re: [gentoo-dev] openrc stabilization update
On Monday, September 20, 2010 13:49:08 Joshua Saddler wrote: > Wrong. It will. The GDP--that's effectively just me--will already have to > rewrite every single one of hundreds of pages of documentation to allow > for the new syntax and way of doing things present in the "oldnet" > behavior of OpenRC. That's ~weeks to ~months of work, even if there's > someone besides me doing it. I'll have to do all that effort and time > commitment yet again if we have to rewrite everything once "newnet" > becomes the default after everyone uses "oldnet" for a while. man, fix your line length. what a nub you are. > Please. Just stick to *one* config. I strongly suggest that it be "oldnet," > given all the problems with "newnet" raised in this thread. But more > importantly, because *the groundork has already been done* when I wrote > the OpenRC Migration Guide. I can piggyback all my efforts off that guide, > which will greatly shorten the amount of time needed for the rest of the > documentation. Otherwise a completely new "migration" guide will have to > be written, AND all the docs will need to be adjusted to THAT one. we're going with oldnet by default in stable and that'll be what the GDP has to worry about. newnet will still be there, but people will have to manually opt out of oldnet and opt in to newnet. i dont think we need to worry about documenting it in the handbook for now ... the bundled files with openrc are sufficient. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc: oldnet vs newnet
William Hubbs dixit (2010-09-20, 11:16): > I want to start a new thread since the discussion on openrc is > centering on whether we should use oldnet, newnet, or keep both. > > The drawback I see for newnet is that it does not allow the user to > control each interface separately, so if you want to cycle one > interface for some reason, this is not doable in that setup. I > agree this is a serious drawback. Oldnet addresses this by having a > separate script for each interface. > > The thing I do not like about oldnet is the way it handles wifi and > dynamic interfaces by running dhcpcd and wpa_supplicant on each > interface instead of running a global instance of them so that they > can control the interfaces themselves. > > On my laptop, I have net.lo in the boot runlevel, and I start > wpa_supplicant and dhcpcd in the default runlevel. In that setup, > there is no need for any net.wlan* interface scriptss, because > dhcpcd and wpa_supplicant manage everything. Does that support configurations where I set static addresses (including ipv6) and routes (also including ipv6) based on the SSID as is allowed by the oldnet scheme of things? I (and probably lots other “power users”) rely on those features extensively and I thank whoever came up with the idea of actually configuring that in a pretty simple way (compared to other distros and OS'es where it is more complicated or plain impossible sometimes). Best, -- [a] pgpXv3A85gPdT.pgp Description: PGP signature
Re: [gentoo-dev] openrc: oldnet vs newnet
On Mon, Sep 20, 2010 at 10:52:23AM -0700, Joshua Saddler wrote: > On Mon, 20 Sep 2010 11:16:08 -0500 > William Hubbs wrote: > > > All, > > > > I want to start a new thread since the discussion on openrc is centering > > on whether we should use oldnet, newnet, or keep both. > > Use "oldnet." Why? > > 1. We already have a migration guide setup for it: > > http://www.gentoo.org/doc/en/openrc-migration.xml > > Keeping "oldnet" will greatly reduce the time needed to change all our other > docs, since I can use it as a reference, without needing write a completely > new migration guide for "oldnet" and *then* still have to change all our > other docs. > > 2. Users are already accustomed to doing things via "oldnet," since they've > been using OpenRC and following this guide for two years now, since 2008. I'm fine with it being the default for stable for now. However, I do think that once we stabilize it, we can learn something from parts of newnet, and possibly use what it was trying to do. William pgpxXQXzBaG1O.pgp Description: PGP signature
Re: [gentoo-dev] openrc: oldnet vs newnet
On Mon, 20 Sep 2010 11:16:08 -0500 William Hubbs wrote: > All, > > I want to start a new thread since the discussion on openrc is centering > on whether we should use oldnet, newnet, or keep both. Use "oldnet." Why? 1. We already have a migration guide setup for it: http://www.gentoo.org/doc/en/openrc-migration.xml Keeping "oldnet" will greatly reduce the time needed to change all our other docs, since I can use it as a reference, without needing write a completely new migration guide for "oldnet" and *then* still have to change all our other docs. 2. Users are already accustomed to doing things via "oldnet," since they've been using OpenRC and following this guide for two years now, since 2008. signature.asc Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 20 Sep 2010 06:46:21 -0400 "Anthony G. Basile" wrote: > Why can't we keep both? There are strong advantages/disadvantages > either way and there are users invested in both new/oldnet. I know > this is more work on doc writers, but I don't think that will equal > the pain users will experience being forced one way or another. Wrong. It will. The GDP--that's effectively just me--will already have to rewrite every single one of hundreds of pages of documentation to allow for the new syntax and way of doing things present in the "oldnet" behavior of OpenRC. That's ~weeks to ~months of work, even if there's someone besides me doing it. I'll have to do all that effort and time commitment yet again if we have to rewrite everything once "newnet" becomes the default after everyone uses "oldnet" for a while. Worse yet, if BOTH are enabled, and we have to document both simultaneously. Then we'd have to fill up our docs with stupid conditionals: "IF you're using oldnet, use THIS complicated config, but IF you're using newnet, then follow THIS complicated set of steps." Documenting both config styles, whether simultaneously or sequentially, is massively complex, unnecessary, and a complete waste of time. I'd probably quit if I had to redo everything more than once, and then there would be absolutely no one to work on any docs. That's not a threat by the way, just a statement of likely outcome. I simply wouldn't have enough spare time to adjust the suddenly "broken" mass of documentation for the new config style. Please. Just stick to *one* config. I strongly suggest that it be "oldnet," given all the problems with "newnet" raised in this thread. But more importantly, because *the groundork has already been done* when I wrote the OpenRC Migration Guide. I can piggyback all my efforts off that guide, which will greatly shorten the amount of time needed for the rest of the documentation. Otherwise a completely new "migration" guide will have to be written, AND all the docs will need to be adjusted to THAT one. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyXnpYACgkQxPWMzpKk6kNdZwCgrVN6D12QzaHw5lXZl+h610PL /ccAni2xDC+CWwkTw9GKBCvjT/IDqcj9 =RxdN -END PGP SIGNATURE-
Re: [gentoo-dev] openrc: oldnet vs newnet
On Monday, September 20, 2010 13:21:25 Michał Górny wrote: > On Mon, 20 Sep 2010 11:16:08 -0500 William Hubbs wrote: > > The drawback I see for newnet is that it does not allow the user to > > control each interface separately, so if you want to cycle one > > interface for some reason, this is not doable in that setup. I agree > > this is a serious drawback. Oldnet addresses this by having a > > separate script for each interface. > > That's not entirely true. If you use DHCP indeed, 'cycling' a single > interface is as simple as: > > $ ifconfig eth0 down > [...] > $ ifconfig eth0 up relying on DHCP isnt an acceptable solution which means there is no safe way to "reset" a single interface. from a maintainer/general pov, William's statement is "true enough". -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] openrc stabilization update
On Sunday, September 19, 2010 20:27:50 William Hubbs wrote: > I suppose one question I need to ask is the oldnet vs newnet question. > The git repository defaults to building and installing the newnet > option, and we make oldnet the default in the ebuild. > > People migrating from stable will know the oldnet option, and this is > the only way to configure the network scripts that is actually covered > in our documentation. this is going to be the default for stable (in other words, nothing is changing). hashing out the future of the two is a separate topic. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] RFC: per package eclass GLEP
On Mon, Sep 20, 2010 at 5:19 AM, "Paweł Hajdan, Jr." wrote: > On 9/19/10 9:14 PM, Matti Bickel wrote: >> So, yeah, what do you think? Is it worth it? > > I second this GLEP. It seems like it will cleanly replace our hacked > eblits implementations from packages like php, glibc, and possibly more. > > Also, it will allow more code sharing between ebuilds, which is good. How does it provide more code sharing than the existing system? Previously I could put code I wanted shared: 1) In a global eclass, which means any ebuild in the tree can likely use it 2) In a pkg eblit Under the new system I can put the code: 1) In a global eclass, any ebuild can likely use it 2) In a per-package eclass, only one package can use it 3) In a pkg eblit, only one package can use it Wouldn't taking code from a global eclass and moving it to a per-package eclass limit code re-use? -A > > Paweł > >
Re: [gentoo-dev] openrc: oldnet vs newnet
On Mon, 20 Sep 2010 11:16:08 -0500 William Hubbs wrote: > The drawback I see for newnet is that it does not allow the user to > control each interface separately, so if you want to cycle one > interface for some reason, this is not doable in that setup. I agree > this is a serious drawback. Oldnet addresses this by having a > separate script for each interface. That's not entirely true. If you use DHCP indeed, 'cycling' a single interface is as simple as: $ ifconfig eth0 down [...] $ ifconfig eth0 up And there's no real requirement for more action here -- dhcpcd running in the background is going to automatically request IP address for that interface. > On my laptop, I have net.lo in the boot runlevel, > and I start wpa_supplicant and dhcpcd in the default runlevel. In > that setup, there is no need for any net.wlan* interface scriptss, > because dhcpcd and wpa_supplicant manage everything. And in that particular configuration oldnet is overly complex. You could simple use network to set up lo0. > Can pppd be set up to run standalone like wpa_supplicant can and > manage the ppp portion of the interface? Do the dhcp clients > recognize ppp interfaces? Afaik, there is no way for me to test this > since I haven't had a ppp interface for years, and I do not know of a > way to simulate one. Not really. pppd is assigned to a single connection, and manages a single interface. Unless you're going to use some kind of wrapper. > If all of this can work, why not come up with a new version of oldnet > that uses this type of setup? The largest disadvantage in oldnet that I see is its' complexity. It just wraps over everything, making the actual configuration more complex than writing the actual commands. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] openrc: oldnet vs newnet
All, I want to start a new thread since the discussion on openrc is centering on whether we should use oldnet, newnet, or keep both. The drawback I see for newnet is that it does not allow the user to control each interface separately, so if you want to cycle one interface for some reason, this is not doable in that setup. I agree this is a serious drawback. Oldnet addresses this by having a separate script for each interface. The thing I do not like about oldnet is the way it handles wifi and dynamic interfaces by running dhcpcd and wpa_supplicant on each interface instead of running a global instance of them so that they can control the interfaces themselves. On my laptop, I have net.lo in the boot runlevel, and I start wpa_supplicant and dhcpcd in the default runlevel. In that setup, there is no need for any net.wlan* interface scriptss, because dhcpcd and wpa_supplicant manage everything. Can pppd be set up to run standalone like wpa_supplicant can and manage the ppp portion of the interface? Do the dhcp clients recognize ppp interfaces? Afaik, there is no way for me to test this since I haven't had a ppp interface for years, and I do not know of a way to simulate one. what about pppoe? Can it work the same way I am running wpa_supplicant? If all of this can work, why not come up with a new version of oldnet that uses this type of setup? William pgpzLPNxFXK1o.pgp Description: PGP signature
Re: [gentoo-dev] openrc stabilization update
On 20.09.2010 16:37, Richard Freeman wrote: > One argument I've heard against newnet is that you can't bring > individual interfaces up and down. openrc[newnet] used to have problems with ppp interfaces. I do not know if it is still the case but there are some open bugs on bugzilla.g.o regarding ppp and openrc. This is a serious show stopper for newnet. So, either 1. both oldnet and newnet or 2. oldnet only would be the prudent alternatives (again, assuming problems with newnet and ppp exist). -- Eray
Re: [gentoo-dev] openrc stabilization update
On 09/20/2010 07:06 AM, Michał Górny wrote: > I guess quite a good solution for now might be enabling newnet through > an USE flag, being masked in the profile by default. That would satisfy > the oldnet compatibility requirement for users, while the small group > preferring newnet could still benefit from it. > This pretty-much guarantees that arch testers/etc will end up testing it one way or the other, and not both. That could lead to QA issues when packages work fine for some users and not for others. Granted, this is mainly a concern for lower-level network-config related apps. I'd hate to be the maintainer of an ebuild that needs to take into account multiple network configuration options. I still haven't heard a good reason as to why we need two. I'm running oldnet (baselayout-1), and changing to newnet would be a pain, but I don't expect the distro to take this into account for my sake when making decisions like this. I'm sure people running newnet feel similarly. The only argument I've heard for newnet is that it is more DHCP-friendly or something like that (not that DHCP is required). However, I've never found getting DHCP to work particularly difficult - it practically comes like that by default (just emerge dhcpcd and add the interface to your init.d). I imagine wireless might be more complex. One argument I've heard against newnet is that you can't bring individual interfaces up and down. That sounds like a potential drawback. Granted, most of the sorts of things that I'd like to conditionally bring up (vpn, ipv6 tunnel, etc) probably won't use the network scripts anyway. Rich
Re: [gentoo-dev] FOSDEM 2011
hi. after already posting in -core someone pointed me to this thread ;) 1) I am going to be at FOSDEM (Flights booked still looking into some cheap B&B for a night or sth for me and a friend who's coming too) 2) I might still have a high quality print of the Gentoo logo from Linuxday(.at) in 2003 where I was (pretty much by myself unfortunately) doing a talk and a small booth 3) back then I handed out more than 30odd cds for sure .. but I guess nowadays a lot more people have fast internet connections 4) If there's gonna be a booth i can help out a bit but I'll want to look around a bit more as well since it's gonna be my first FOSDEM and we're only gonna be there some time saturday morning and fly back sunday evening. Regards original message- From: "Markus Duft" markus.d...@salomon.at To: gentoo-dev@lists.gentoo.org CC: r...@gentoo.org, sp...@gentoo.org, hol...@gentoo.org Date: Mon, 30 Aug 2010 09:31:48 +0200 - > On 08/27/2010 04:26 PM, Jorge Manuel B. S. Vicetto wrote: >> On 26-08-2010 12:07, Alex Legler wrote: >>> On Thu, 26 Aug 2010 11:01:27 +0200, Markus Duft >>> markus.d...@salomon.at wrote: >> booth registration is not yet open, i will have an eye on this too... (is there any interest in it anyway? who could come up with flyers, cds, etc.?) >> >> Any attempt to get a booth should be preceded by a serious discussion >> about what will be handed at the booth and who will be responsible to >> ensure the merchandise and promotion tools (banner?) are present. We >> should not forget that the experience in some of the former events >> wasn't "stellar". > > yeah, right :) > > i once worked in an advertising agency, where i can possibly get rather > good prices to print banners, flyers, etc. i just need them in digital > form. however transportation by plane is not so easy, if it's a lot. > > would it be an option to send them to somebody whos going by > train/car/whatever? (grobian?) > >> >>> The Gentoo e.V. has printed flyers a year ago. There should be plenty >>> left, especially in English. Talk to rbu, sping or hollow. Also, >>> there's other stuff like T-Shirts, see >>> https://www.gentoo-ev.org/wiki/Events for a few pictures. > > rbu, sping, hollow: any comments? :) will any of you be there? is there > some stuff left over we can use? > >> >>> As for CDs, we've used the 10.1 LiveDVDs, simply burned to DVD-R, but >>> with a nice printed label. You can expect to hand out at least 35 per >>> day (we gave them to people for free after a short chat). >> >> It would be great if we could get a LiveDVD release around January. It >> isn't simple and last year we weren't able to get it done by FOSDEM - we >> being mostly likewhoa. Having more people help testing and fixing >> packages would help. >> About CDs per day, I'm pretty sure we handed more than 35 on FOSDEM2009 >> and they weren't "pretty". > > if we get some funds for cds and ink from the foundaiton, i can both > burn and prettify (i.e. print directly on them). i guess 100 would be a > good number for the start? > > i will request funds as soon as we've come up with a list of things we > need. (so waiting for rbu/sping/hollow to respond in the first place now). > > markus > >> > >
Re: [gentoo-dev] RFC: per package eclass GLEP
On 9/19/10 9:14 PM, Matti Bickel wrote: > So, yeah, what do you think? Is it worth it? I second this GLEP. It seems like it will cleanly replace our hacked eblits implementations from packages like php, glibc, and possibly more. Also, it will allow more code sharing between ebuilds, which is good. Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] openrc stabilization update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 20 Sep 2010 06:46:21 -0400 "Anthony G. Basile" wrote: > Why can't we keep both? There are strong advantages/disadvantages > either way and there are users invested in both new/oldnet. I know > this is more work on doc writers, but I don't think that will equal > the pain users will experience being forced one way or another. I guess quite a good solution for now might be enabling newnet through an USE flag, being masked in the profile by default. That would satisfy the oldnet compatibility requirement for users, while the small group preferring newnet could still benefit from it. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) iEYEARECAAYFAkyXQCIACgkQnGSe5QXeB7tR2gCfeix45C4N1MFvHf864ReeavLn xz8AoOUiUpwYb+Dan1LpmwhCHKdTO/nN =fcQc -END PGP SIGNATURE-
Re: [gentoo-dev] openrc stabilization update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/19/2010 09:22 PM, William Hubbs wrote: > On Mon, Sep 20, 2010 at 06:05:46AM +0530, Nirbheek Chauhan wrote: >> On Mon, Sep 20, 2010 at 5:57 AM, William Hubbs wrote: >>> I suppose one question I need to ask is the oldnet vs newnet question. >>> The git repository defaults to building and installing the newnet >>> option, and we make oldnet the default in the ebuild. >>> >>> People migrating from stable will know the oldnet option, and this is >>> the only way to configure the network scripts that is actually covered >>> in our documentation. >>> >>> Do we want to switch the upstream repository to make oldnet the default? >>> >>> What about newnet. ??Should we keep it at all? ??If we do, should we put >>> it behind a use flag which would be off by default? >>> >> >> Is there any advantage to using newnet over oldnet? If there aren't >> any advantages, we should not attempt to support it (even as an >> optional feature). Old-net by default, no use-flag for newnet; people >> can use EXTRA_ECONF if they *really* want to use it. > > If I go this route, I'll probably just get rid of newnet in the next > release entirely. > > newnet is a single script, "network", which sets up all of the static > routes and static interfaces. > > It is small and simple, but the disadvantage of it is that you can't > stop/start a single interface. > > William > Why can't we keep both? There are strong advantages/disadvantages either way and there are users invested in both new/oldnet. I know this is more work on doc writers, but I don't think that will equal the pain users will experience being forced one way or another. - -- Anthony G. Basile, Ph.D. Gentoo Developer -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyXO30ACgkQl5yvQNBFVTVhuQCbBG2owroUS8ZFko2oEE1ZIYgQ rZ0An19HgxWA9Ltat3owfIB5cvqjdRGE =YqFX -END PGP SIGNATURE-
Re: [gentoo-dev] openrc stabilization update
On 09/20/2010 11:10 AM, Benedikt Böhm wrote: > the same is true for everyone who already runs newnet (like me). in > fact, i do not even use the newnet conf.d stuff, but rather take > advantage of support for /etc/ifup.eth* in /etc/init.d/network. that > way i can configure the networking with iproute2 or any other tool > that i already know the syntax of. no need to learn ridiculously > convoluted array syntax foo for /etc/init.d/net.eth*. if you are using /etc/ifup.eth* what would prevent having oldnet run those as the newnet do? lu -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero
Re: [gentoo-dev] openrc stabilization update
On Mon, Sep 20, 2010 at 10:29 AM, Tobias Klausmann wrote: > Hi! > > On Mon, 20 Sep 2010, Michał Górny wrote: >> William Hubbs wrote: >> > What about newnet. Should we keep it at all? If we do, should we put >> > it behind a use flag which would be off by default? >> >> I insist on keeping it as I use it myself. The new approach seems more >> desktop-targeted to me. The network script sets the domain name >> and bonding, dhcpcd script starts dhcpcd (which can control more than >> a single interface) and wpa_supplicant script is responsible for wifi. > > I'm with nightmorph: we should have exactly one way to configure > networking (i.e. exactly one syntax). > > That said, switching to newnet would be a huge mess for everybody > who runs servers: DHCP is uncommon there, WLAN is very unusual, > as a result, they would not only have to switch the way they > configure their nets (people don't like that kind of stuff if the > machine is 400 miles away); they would also have to find a way to > build their setups in the new "language". Servers tend to have > more complicated setups network-wise than workstations (think > firewalls, VPN endpoint, traffic observation, ...). the same is true for everyone who already runs newnet (like me). in fact, i do not even use the newnet conf.d stuff, but rather take advantage of support for /etc/ifup.eth* in /etc/init.d/network. that way i can configure the networking with iproute2 or any other tool that i already know the syntax of. no need to learn ridiculously convoluted array syntax foo for /etc/init.d/net.eth*. so please just keep the network init script as a use flag or extra package or something, so that one is not forced to use the old net stuff (again). P.S.: newnet does not in any way force you to use DHCP or WLAN or anything like that, so please stop spreading misinformation. -Bene
Re: [gentoo-dev] openrc stabilization update
Hi!
On Mon, 20 Sep 2010, Michał Górny wrote:
> William Hubbs wrote:
> > What about newnet. Should we keep it at all? If we do, should we put
> > it behind a use flag which would be off by default?
>
> I insist on keeping it as I use it myself. The new approach seems more
> desktop-targeted to me. The network script sets the domain name
> and bonding, dhcpcd script starts dhcpcd (which can control more than
> a single interface) and wpa_supplicant script is responsible for wifi.
I'm with nightmorph: we should have exactly one way to configure
networking (i.e. exactly one syntax).
That said, switching to newnet would be a huge mess for everybody
who runs servers: DHCP is uncommon there, WLAN is very unusual,
as a result, they would not only have to switch the way they
configure their nets (people don't like that kind of stuff if the
machine is 400 miles away); they would also have to find a way to
build their setups in the new "language". Servers tend to have
more complicated setups network-wise than workstations (think
firewalls, VPN endpoint, traffic observation, ...).
So we would make things more complicated for a large user base
for the benefit of desktop users who can't get DHCP/Wifi to work
with oldnet. I doubt the latter is a larger group than the
former.
Regards,
Tobias
--
panic("%s: CORRUPTED BTREE OR SOMETHING", __FUNCTION__);
linux-2.6.6/fs/xfs/xfs_bmap.c
Re: [gentoo-dev] openrc stabilization update
On Sun, 19 Sep 2010 19:27:50 -0500 William Hubbs wrote: > I suppose one question I need to ask is the oldnet vs newnet question. > The git repository defaults to building and installing the newnet > option, and we make oldnet the default in the ebuild. > > People migrating from stable will know the oldnet option, and this is > the only way to configure the network scripts that is actually covered > in our documentation. Pick one way of configuration. One and only one. I'm not going to completely rewrite hundreds of pages of documentation more than once, so whichever you choose (ideally the way that I've already covered in the OpenRC migration guide), just choose one. None of this "old way now and then something completely different in the future once it's stabilized" within the same package. One for simplicity, one for somewhat-happy tech writers, one for the win. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
В Пнд, 20/09/2010 в 09:16 +0200, Michał Górny пишет: > On Mon, 20 Sep 2010 09:44:38 +0400 > Peter Volkov wrote: > > > Another problem that there is no way to alter ChangeLog. Since > > ChangeLogs are intended for users it's good idea to be able fix > > typos / add credits there and thus it's impossible to generate them > > from git commit messages. > > How about using git notes [1] to alter ChangeLogs? These could be added > to any commit without altering the commit itself (i.e. the hash remains > the same). > > [1] http://www.kernel.org/pub/software/scm/git/docs/git-notes.html It's ok if it works: http://archives.gentoo.org/gentoo-dev/msg_2e115d6286018891e62bbacd2e8f8c7c.xml But that said, text files are easier... -- Peter.
Re: [gentoo-dev] openrc stabilization update
On Sun, 19 Sep 2010 19:27:50 -0500 William Hubbs wrote: > What about newnet. Should we keep it at all? If we do, should we put > it behind a use flag which would be off by default? I insist on keeping it as I use it myself. The new approach seems more desktop-targeted to me. The network script sets the domain name and bonding, dhcpcd script starts dhcpcd (which can control more than a single interface) and wpa_supplicant script is responsible for wifi. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Repoman to autogenerate ChangeLog entries
On Mon, 20 Sep 2010 09:44:38 +0400 Peter Volkov wrote: > Another problem that there is no way to alter ChangeLog. Since > ChangeLogs are intended for users it's good idea to be able fix > typos / add credits there and thus it's impossible to generate them > from git commit messages. How about using git notes [1] to alter ChangeLogs? These could be added to any commit without altering the commit itself (i.e. the hash remains the same). [1] http://www.kernel.org/pub/software/scm/git/docs/git-notes.html -- Best regards, Michał Górny signature.asc Description: PGP signature
