Re: [gentoo-dev] Re: Should portage tree CVS impose a commit moratorium during snapshot creation?
On 9 January 2013 20:23, Diego Elio Pettenò wrote: > On 09/01/2013 13:20, Duncan wrote: >> Are the git migration blockers at such a point that we can get an ETA >> yet? > > PLEASE ALL STOP DETOURING EVERY DAMN TOPIC OUT THERE WITH THE GIT > MIGRATION, THANK YOU VERY MUCH. > > And yes I know it's not polite to scream. At this point I DON'T CARE. > > -- > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > Please stop behaving like a troll. If you don't want to discuss the git migration, then simply ignore that part of the conversation. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Re: call for testers: udev predictable network interface names
On 2013-01-10, Daniel Campbell wrote: > On 01/09/2013 04:13 PM, William Hubbs wrote: >> All, >> >> as you probably know by now, udev-197 has hit the tree. >> >> This new version implements a new feature called predictable >> network interface names [1], which I have currently turned off for >> live systems, because it will require migration on the part of the >> user. >> >> When you upgrade to this new version of udev, you will find a file >> /etc/udev/rules.d/80-net-name-slot.rules on your system. It >> currently has comments explaining what is happening. >> >> As long as this file is in place, this feature is not activated. >> That is why there is not a news item. If you do nothing, nothing >> changes. >> >> What I would like to do is find some people who are willing to >> migrate and report any issues they find. >> >> I would like this to be the default for everyone at some point, so >> I want to document the migration process and find out if there are >> any bugs in tools because they expect the eth* names. >> >> Thoughts? >> >> William >> >> [1] >> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames >> >> > So long as users retain the choice of keeping eth* or wlan*, no > complaints from me. I (and others) came to Gentoo to get away from > systemd, and this smells of a systemd-ism. Will eudev be pursuing this > as well? This sounds like an udev feature, completely unrelated to systemd. It's a bit hard for me to understand why do you even relate this to systemd, when udev has done this kind of device name management for *ages*. I mean, I think udev has been bundled with *persistent* rules for some months now... Playing with NIC device names is not something exclusive to udev, it has always been fun with wireless drivers who roam between eth*, wlan*, ath*... -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-dev] call for testers: udev predictable network interface names
On Wed, Jan 09, 2013 at 11:33:42PM -0500, Rich Freeman wrote: > On Wed, Jan 9, 2013 at 11:21 PM, Daniel Campbell wrote: > > So long as users retain the choice of keeping eth* or wlan*, no > > complaints from me. I (and others) came to Gentoo to get away from > > systemd, and this smells of a systemd-ism. Will eudev be pursuing this > > as well? > > Keep in mind that this is a udev announcement, not a eudev > announcement. Udev is generally going to follow upstream, so if > avoiding systemd is your main goal in life you probably will want to > stick with eudev, which might or might not adopt this feature. For the record, I have no plans of forcing systemd on anyone. I still maintain OpenRC and plan to continue doing so. As described on the wiki, it is very simple to turn this feature off either by adding your own persistent rules in /etc/udev/rules.d or by overriding the 80-net-slot-name.rules file by putting a file in /etc/udev/rules.d with that name. So, how is this a "systemd-ism"? a lot of software has defaults that you can reconfigure. William pgpNpURpjZgz8.pgp Description: PGP signature
Re: [gentoo-dev] call for testers: udev predictable network interface names
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/01/13 11:21 PM, Daniel Campbell wrote: >> [1] >> http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames > >> > > So long as users retain the choice of keeping eth* or wlan*, no > complaints from me. I (and others) came to Gentoo to get away from > systemd, and this smells of a systemd-ism. Will eudev be pursuing > this as well? > The eudev team hasn't discussed it yet, but it's on the agenda for our next meeting. I believe that we will be implementing the functionality (probably by default) in the eudev software package, but we will not be enabling this by default in the eudev ebuilds (at least, not any time soon). Also of note, though, is that the eudev package (and ebuild) will still have available (although not by default) the old legacy persistent-net functionality. I am planning to update the rules generator for this to use the same attributes as the new method though, which should be theoretically more reliable than the old attributes. - --- Finally, something that wasn't mentioned yet -- if a user has / still uses a 75-persistent-net.rules from old udev's, or any custom iface-naming rules, then the new 80-net-name-slot.rules will also not take effect on any of the interfaces that were named in these other rules. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDuydMACgkQ2ugaI38ACPDaLwD+JCn43am7AkSkz4/7d/IisXAp U9wm1hD2hqjAe2RjAQUBAKGwBTRAcDDx5od26ip99svgnWu6TQw2DKSICWq8BGQd =T9fH -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Should portage tree CVS impose a commit moratorium during snapshot creation?
On 9 January 2013 23:16, Duncan <1i5t5.dun...@cox.net> wrote: > Diego Elio Pettenò posted on Wed, 09 Jan 2013 13:23:13 +0100 as excerpted: > >> On 09/01/2013 13:20, Duncan wrote: >>> Are the git migration blockers at such a point that we can get an ETA >>> yet? >> >> PLEASE ALL STOP DETOURING EVERY DAMN TOPIC OUT THERE WITH THE GIT >> MIGRATION, THANK YOU VERY MUCH. >> >> And yes I know it's not polite to scream. At this point I DON'T CARE. > > A single reply, possibly even a single sentence, is what I asked for, > specifically stating I didn't intend it to become a subthread. Instead, > I got... a content-free troll, in ALL CAPS, even.. =:( > > And here I am adding to it. I was successfully trolled too and know it > but still can't help it. =:^( But I should have known there's nothing > more likely to bring out a troll than a post saying I don't want a > subthread... > > Sorry everyone. 100% honest, I /just/ wanted a single one one sentence > answer and had no intention of... this! ARGH! No need to be sorry. Diego was way out of line. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On Wednesday 09 January 2013 06:39:37 justin wrote: > On 09/01/13 12:29, justin wrote: > > On 09/01/13 10:26, Diego Elio Pettenò wrote: > >> On 09/01/2013 09:40, justin wrote: > >>> Also the internals of the build are affected (probably through the > >>> difference in configure). This leads to disrespected LDFLAGS and broken > >>> tclConfig.sh. So this simple change has deep consequences. > >> > >> This looks like the _version_ of autoconf used is different. Is the > >> output from the same exact system? > > > > Okay, did some more debugging and it seems to be not the new singly > > inheriting eclass. > > > > Repeating the sequential emerge on different FS I get a completely mixed > > result. Sometimes both compile are good, sometimes only one and sometime > > none. > > Could this be a problem with eautoreconf or is this autotools specifc > > problem? > > I assume it is a portage problem, because the log says autoconf is run > but configure.in didn't change. this sounds like bug 417355. the autom4te.cache dir gets busted (somehow). when autotools runs, it looks at the cache dir, sees that things are up to date, and then doesn't regen any files. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] About *ECLASS_ONCE_* stuff at top of some eclasses but not others
On 11/01/13 05:10, Mike Frysinger wrote: > On Wednesday 09 January 2013 06:39:37 justin wrote: >> On 09/01/13 12:29, justin wrote: >>> On 09/01/13 10:26, Diego Elio Pettenò wrote: On 09/01/2013 09:40, justin wrote: > Also the internals of the build are affected (probably through the > difference in configure). This leads to disrespected LDFLAGS and broken > tclConfig.sh. So this simple change has deep consequences. This looks like the _version_ of autoconf used is different. Is the output from the same exact system? >>> >>> Okay, did some more debugging and it seems to be not the new singly >>> inheriting eclass. >>> >>> Repeating the sequential emerge on different FS I get a completely mixed >>> result. Sometimes both compile are good, sometimes only one and sometime >>> none. >>> Could this be a problem with eautoreconf or is this autotools specifc >>> problem? >> >> I assume it is a portage problem, because the log says autoconf is run >> but configure.in didn't change. > > this sounds like bug 417355. the autom4te.cache dir gets busted (somehow). > when autotools runs, it looks at the cache dir, sees that things are up to > date, and then doesn't regen any files. > -mike > Yeah, it was because of the double patching of configure and configure.in. Cleaning the patch made it work. Interestingly in the beginning I really could reproduce a correlation between the inherit order and this breakage. Bad that was false. Thanks justin signature.asc Description: OpenPGP digital signature
