Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Tue, Sep 11, 2012 at 7:13 AM, Michał Górny wrote: > On Thu, 6 Sep 2012 01:11:45 -0700 > Brian Harring wrote: > >> A compatibility hack that stacks them is strongly advisable; >> something akin to the following: >> >> Literally, we do the following: >> inherit() { >> if eapi blah; then >> local DEPEND PDEPEND RDEPEND >> >> else >> >> fi >> >> if eapi blah; then >> local _deps=( ) _x >> for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do >> [ -n "${!_x}" ] && deps+=( "${!_x}" ) >> done >> [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}" >> unset DEPEND RDEPEND PDEPEND _x _deps >> >> else >> >> fi >> } >> >> Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set >> the DEPENDENCIES directly; those that have to support multiple eapi's >> (aka, every fricking eclass that exists right now) can just use the >> old form, shifting into the new form as things progress. > > If we decide to go with a such a hack, then we either have to support > it indefinitely, or to decide to drop the support in some further EAPI. It's a transitional hack; we support it as long as we need the transition coverage. Meaning if by EAPI7, everyone is using EAPI5 and up (or by EAPI7 it's basicaly insane to try and support 0,1,2,3,4,5,6,7), we drop the transition code in EAPI8. This is no different to how RDEPEND/DEPEND autosetting was phased out. > If we go for the latter, then it's just delaying the ugly conditional > eclasses will have to suffer at some random point in the future. Hate to say "na uh", but... na uh. The point is as long as an eclass has to support older EAPI's, they can use set DEPEND/RDEPEND and it would work fine. If the eclass needs the newer depends types (hdep, fdep, whatever) for something, it levels an EAPI check, and then sets DEPENDENCIES. Meanwhile, until it moves it's minimal EAPI to one requiring DEPENDENCIES, they can use the old syntax and have it stacked. Basically, either we can have git.eclass (for example) doing: if has $EAPI 0 1 2 3 4; then DEPEND=">=dev-util/git-1.6" else DEPENDENCIES="dep:build? ( >=dev-util/git-1.6 )" fi Or, as long as it's suppporting EAPI's 0 1 2 3 4 and the transition is still enabled for the actual EAPI it's being used in... DEPEND=">=dev-util/git-1.6" Doing this means no eclass code has to maintain EAPI5 dependencies code and =EAPI5, they convert to DEPENDENCIES syntax as they go/have spare cycles. Bluntly, this approach makes transition pretty painless for the vast majority of the tree. In the grand scheme of things, this is actually one of the simplest/cleanest migration EAPI will see I suspect. There really isn't a sane argument to be made against this beyond "screw it, just make the devs convert immediately and damn the costs" (which I don't view as sane). Either way, strongly get the feeling you're arguing purely because it had the term DEPENDENCIES in it... ~harring
Re: [gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
On 12 September 2012 08:02, Duncan <1i5t5.dun...@cox.net> wrote: > Gentoo's bash-completion breaks when make.conf is in /etc/portage. Bug > filed back in early July and there's a simple enough patch, but > app-shells/gentoo-bashcomp has only the shell-tools herd, no dedicated > maintainer, and 13 open bugs including this one, all apparently portage > (or gentoolkit) related, with the last release in 2010 (Dec) with > stabilization a month later. So it's not seeing a lot of movement. > > https://bugs.gentoo.org/show_bug.cgi?id=424777 > > So anyone who depends on tab-completion for their emerge commands, etc, > may want to either hold off on the move or apply the patch manually, until > this is fixed. Or use zsh instead. You can thank me later. ;-) -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
[gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
Zac Medico posted on Tue, 11 Sep 2012 09:29:36 -0700 as excerpted: > I would recommend to simply use /etc/make.conf alone until the legacy > tools that you use catch up. We have to change the default location in > the stages in order to expose the bugs so they can get fixed. I posted to the portage-dev list about this so you probably already know, but for others, particularly users, following this transition thread: Gentoo's bash-completion breaks when make.conf is in /etc/portage. Bug filed back in early July and there's a simple enough patch, but app-shells/gentoo-bashcomp has only the shell-tools herd, no dedicated maintainer, and 13 open bugs including this one, all apparently portage (or gentoolkit) related, with the last release in 2010 (Dec) with stabilization a month later. So it's not seeing a lot of movement. https://bugs.gentoo.org/show_bug.cgi?id=424777 So anyone who depends on tab-completion for their emerge commands, etc, may want to either hold off on the move or apply the patch manually, until this is fixed. FWIW here's the listing of all open app-shells/gentoo-bashcomp bugs: https://bugs.gentoo.org/buglist.cgi?quicksearch=app-shells%2Fgentoo-bashcomp -- 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] [Future EAPI] src_fetch() phase function to support VCS fetching
On Tue, Sep 11, 2012 at 06:36:46PM -0400, Rick "Zero_Chaos" Farina wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 09/06/2012 02:50 PM, Micha?? G??rny wrote: > > On Thu, 6 Sep 2012 09:49:13 -0700 > > Brian Harring wrote: > > > >> One additional thought- re: the scenarios where we don't fetch to an > >> intermediate location, then transfer that contents into ${WORKDIR}, > >> while a better name is needed, something along the lines of > >> RESTRICT=fetches-into-workdir comes to mind. > > Realizing this is a late response I would like to add Um, what? > src_fetch should only be putting things into /usr/portage/distfiles, > never into ${WORKDIR}, that's for src_unpack to handle. > > Am I missing something here? WORKDIR was an example; punting it directly into the pkgs distfiles is also fine. Basically, you're assuming that the content *is* cachable- cause if it isn't, then dumping in ${DISTDIR} is wasteful (both since it'll require a copy into the ebuild's workdir, and since it means increasing crap accumulating in the workdir). Further, there are cases where content *is* available, but is fundamentally outside ${DISTDIR}- in cros, they have the chrome/chromium source available in certain cases. Now, either we can store 13GB int ${DISTDIR} that's a copy of that external developer checkout, then copy that into ${WORKDIR}, or w/ a restrict marker, copy that sucker into ${WORKDIR} directly. Is it a corner case? Yep, but it's easy enough to deal w/- the only constraint there is that the src_fetch's target dir isn't ${DISTDIR}, it's ${WORKDIR}, and the PM is required to preserve ${WORKDIR} from src_fetch to the time of that pkg actually running. ~harring
Re: [gentoo-dev] [Future EAPI] src_fetch() phase function to support VCS fetching
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/06/2012 02:50 PM, Michał Górny wrote: > On Thu, 6 Sep 2012 09:49:13 -0700 > Brian Harring wrote: > >> One additional thought- re: the scenarios where we don't fetch to an >> intermediate location, then transfer that contents into ${WORKDIR}, >> while a better name is needed, something along the lines of >> RESTRICT=fetches-into-workdir comes to mind. Realizing this is a late response I would like to add Um, what? src_fetch should only be putting things into /usr/portage/distfiles, never into ${WORKDIR}, that's for src_unpack to handle. Am I missing something here? - -Zero >> >> Basically that restriction would be interpretted as "$WORKDIR must be >> setup/preserved from invocation of src_fetch to actual building". >> >> Via that restrict, both scenarios should be addressed in full. > > Does separate src_fetch() provide any benefit in that scenario? > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQT7z+AAoJEKXdFCfdEflKVPQQALGcLGAgfo8U+M6TdW5Edksf oqaXE+NSTeFe2DE0G2mgKYSdSIZgMiFp5mLFwpdfAT1gjzFAc+34+5SY8X/0uaaG OU7fafdUmOlqgD7rCvX56kSWZVPmTV3oZDghmwB1SUIQpL9PNSZoz5uKoatt4UL8 mBMiTmnsYou8f+wDCJoN8eLVoQb/Hm2inobGUCozCsqU6ASgk1eVePpAmJNNVKp6 wrKuVbj4FeDS17Q6xc2g8exXlkxhGmdS1MmugKBR9csYC9P82fh4bXqVzxG15h9O YZDU5nagJQ9fY6M7oeKg6etVe6PvwOd/FH0Z4wtQJ2NicOsu6DiBf7J+yLvadJdF M5fE1kxjtR+rm+6bfNgBl2hP5DPdUYxPnZChftPNRpiVe0P0YZGuRgy+GqfXSmMh 8Zf37hJylauBDy397yGapIJ4ergpYVb3Z1ZfU6uW7n8k0apqjqk+TYLEv2tajtTc WBdRoBAT1LxvjFIHj2Bf5uzNtqev4l19vJv1AnALgs1v1Z8/TiSPB/B/2DvvIawR Ys+mAEKzQOCezaCjVOpjq7pvi80/8PMcw6Txk9WpsAezrxdAj2X24kwsptVugCAO lG3agqmOQgH+vCf0PkplxMSGBlofh4hZ3mNbuDaFlaRfiSlzFX//rkQTtOjK4YQu 6SiRnKxiDzJEn+Q1SNUr =xgcT -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Tue, Sep 11, 2012 at 5:01 PM, William Hubbs wrote: > > I can agree that a server would probably want a static configuration, > but all work stations do not use gnome, kde, etc. > Most do not run unix, but at work I can't think of any servers that are using static configurations. They might be assigned static IPs, but they'll use DHCP just the same. I deploy my network at home in the same way - most of my standing PCs have DNS and static IP assignments, but they still use DHCP. This way I can still utilize PXE for backups/etc, and adjust things at any time fairly easily. Rich
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Tue, Sep 11, 2012 at 02:43:08PM -0400, Olivier Crête wrote: > On Tue, 2012-09-11 at 20:01 +0200, Luca Barbato wrote: > > On 9/10/12 11:05 PM, William Hubbs wrote: > > > On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: > > >> On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: > > >>> In researching this program, I have found that it and ifplugd, which is > > >>> the alternative, have been unmaintained for years. Also Debian has > > >>> declared netplugd to be obsolete in favor of ifplugd. > > >>> > > >>> Does anyone have any thoughts about whether we should keep OpenRC > > >>> support for one or both of these? > > >> > > >> The ifplugd author recommends you use NetworkManager for dynamic > > >> networking scenarios. > > > > > > NM seems bloated though unless you are using a desktop environment. It > > > wants to install 29 dependencies on my box. > > > > NM and connman are quite a bit overkill indeed. > > If you're on a server, you probably want a static configuration anyway, > not something dynamic. I can agree that a server would probably want a static configuration, but all work stations do not use gnome, kde, etc. William pgpLytOppCMKG.pgp Description: PGP signature
Re: [gentoo-dev] EJOBS variable for EAPI 5?
On Tue, Sep 11, 2012 at 1:07 PM, Zac Medico wrote: > On 09/11/2012 09:54 AM, Ian Stakenvicius wrote: >> At the ebuild level, certainly, but that's one of the reasons for >> EJOBS in the first place, so that it can be overridden consistently >> within a phase, if necessary for the ebuild (regardless of build >> system type), right? > > Right. I'm surprised that ELOADAVG wasn't proposed in tandem with EJOBS > though, since overloading is not a good idea, and can happen easily any > time that you doing lots of things in parallel. I tend to agree that load average matters more, although that doesn't factor in RAM use. I don't suggest that this is something that is easily remedied, but I have run into a situation where WHAT you're doing greatly influences how many jobs you can run - distcc. I once tried to implement distcc in a fairly large cluster, and then run make with VERY high levels of parallelization - such as -j32. That worked great - if the package used C. Then portage would try to build something that used ant and suddenly the host was trying to run 32 jvms in parallel - just killing the system. Ditto for python/etc. There was no way to tell the build system to go nuts with anything using distcc but not everything else. I think this is just a fundamental limitation of make - I don't suggest that we can fix this at the portage level. However, that is a use case where WHAT you're doing influences how many jobs you can run. Rich
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On Tue, 2012-09-11 at 20:01 +0200, Luca Barbato wrote: > On 9/10/12 11:05 PM, William Hubbs wrote: > > On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: > >> On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: > >>> In researching this program, I have found that it and ifplugd, which is > >>> the alternative, have been unmaintained for years. Also Debian has > >>> declared netplugd to be obsolete in favor of ifplugd. > >>> > >>> Does anyone have any thoughts about whether we should keep OpenRC > >>> support for one or both of these? > >> > >> The ifplugd author recommends you use NetworkManager for dynamic > >> networking scenarios. > > > > NM seems bloated though unless you are using a desktop environment. It > > wants to install 29 dependencies on my box. > > NM and connman are quite a bit overkill indeed. If you're on a server, you probably want a static configuration anyway, not something dynamic. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Tue, 28 Aug 2012 00:23:11 + (UTC) "Mike Frysinger (vapier)" wrote: > vapier 12/08/28 00:23:11 > > Modified: ChangeLog profiles.desc > Log: > add new s390x profile #345421 [...] > @@ -152,7 +153,7 @@ > x86 default/linux/x86/10.0/server > stable > # Gentoo/FreeBSD Profiles > -amd64-fbsd default/bsd/fbsd/amd64/9.0 stable > +amd64-fbsd default/bsd/fbsd/amd64/9.0 dev > sparc-fbsddefault/bsd/fbsd/sparc/8.2 exp > x86-fbsd default/bsd/fbsd/x86/8.2 dev > x86-fbsd default/bsd/fbsd/x86/9.0 dev please be more careful, it is good practice to review the cvs diff output before hitting ci when committing to the profiles or eclass directories. A.
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
On 9/10/12 11:05 PM, William Hubbs wrote: On Mon, Sep 10, 2012 at 04:26:10PM -0400, Olivier Crête wrote: On Mon, 2012-09-10 at 09:48 -0500, William Hubbs wrote: In researching this program, I have found that it and ifplugd, which is the alternative, have been unmaintained for years. Also Debian has declared netplugd to be obsolete in favor of ifplugd. Does anyone have any thoughts about whether we should keep OpenRC support for one or both of these? The ifplugd author recommends you use NetworkManager for dynamic networking scenarios. NM seems bloated though unless you are using a desktop environment. It wants to install 29 dependencies on my box. NM and connman are quite a bit overkill indeed. lu
Re: [gentoo-dev] EJOBS variable for EAPI 5?
On 09/11/2012 09:54 AM, Ian Stakenvicius wrote: > On 11/09/12 12:43 PM, Zac Medico wrote: >> On 09/11/2012 09:36 AM, viv...@gmail.com wrote: >>> Dunno where to place this request, but if we go for something >>> like EJOBS could we also make it phase specific? So compile, >>> install and test could have a different number of jobs running. >>> Possibly three different variables that override a predefined >>> EJOBS. > >> Per-phase sounds a little to fine-grained. Instead, I'd suggest to >> add an ELOADAVG variable that's analogous to make's --load-average >> option. That should be enough to compensate for any differences >> between phases. > > I personally wonder about why this would be necessary from the > perspective of the user; if the user's system at emerge time can > handle X concurrent processes per emerge-job , i don't see why it > would matter what phase these jobs would be launched from. Right, what matters is the system load, which is why I suggested ELOADAVG. > At the ebuild level, certainly, but that's one of the reasons for > EJOBS in the first place, so that it can be overridden consistently > within a phase, if necessary for the ebuild (regardless of build > system type), right? Right. I'm surprised that ELOADAVG wasn't proposed in tandem with EJOBS though, since overloading is not a good idea, and can happen easily any time that you doing lots of things in parallel. -- Thanks, Zac
Re: [gentoo-dev] EJOBS variable for EAPI 5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 11/09/12 12:43 PM, Zac Medico wrote: > On 09/11/2012 09:36 AM, viv...@gmail.com wrote: >> Dunno where to place this request, but if we go for something >> like EJOBS could we also make it phase specific? So compile, >> install and test could have a different number of jobs running. >> Possibly three different variables that override a predefined >> EJOBS. > > Per-phase sounds a little to fine-grained. Instead, I'd suggest to > add an ELOADAVG variable that's analogous to make's --load-average > option. That should be enough to compensate for any differences > between phases. I personally wonder about why this would be necessary from the perspective of the user; if the user's system at emerge time can handle X concurrent processes per emerge-job , i don't see why it would matter what phase these jobs would be launched from. At the ebuild level, certainly, but that's one of the reasons for EJOBS in the first place, so that it can be overridden consistently within a phase, if necessary for the ebuild (regardless of build system type), right? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBPbLEACgkQ2ugaI38ACPA1qAD/bvjy7aB6nk5YboJHnCpQ8C56 QolKD9BPHL9eN8Xf41oA/iTZU+tyB+BDl+woZAlVGbaa6AR2r6Qp8rwOzkUWSwV/ =FhKc -END PGP SIGNATURE-
Re: [gentoo-dev] EJOBS variable for EAPI 5?
On 09/11/2012 09:36 AM, viv...@gmail.com wrote: > Dunno where to place this request, but if we go for something like EJOBS > could we also make it phase specific? > So compile, install and test could have a different number of jobs running. > Possibly three different variables that override a predefined EJOBS. Per-phase sounds a little to fine-grained. Instead, I'd suggest to add an ELOADAVG variable that's analogous to make's --load-average option. That should be enough to compensate for any differences between phases. -- Thanks, Zac
Re: [gentoo-dev] EJOBS variable for EAPI 5?
Il 04/09/2012 19:15, Zac Medico ha scritto: On 09/04/2012 04:00 AM, Walter Dnes wrote: On Sat, Sep 01, 2012 at 05:20:02PM -0700, Brian Harring wrote This approach is fine imo, although I'd *potentially* look at adding a magic $PROC_COUNT var that is the # of cpu threads on the system; either that or defaulting jobs to it. I rather dislike requiring users to go jam a 2/4/8 in there when it's easy to compute. That said, it's minor. Either way, yes, I think EJOBS should be in EAPI5. One question about the suggested EJOBS variable; will it over-ride MAKEOPTS? Every so often on the Gentoo-user list, someone comes along with a mysterious build failure. The first suggestion is to reset MAKEOPTS to -j1. And on some occasions, that is indeed the solution to the mysterious build failure. That would be due to a missing dependency in the Makefiles, and using -j1 is just a workaround. The ebuild can be hardcoded to use emake -j1 until the Makefile gets fixed. I set -j1 and leave it that way. Yes, the builds take longer, but the resulting binary is just as fast. And the amount of time I "save" will be blown away the first time I end up screwing around a couple of hours trying to fix a mysterious build failure. That's why I want the user to have the option of over-riding EJOBS, should it ever be implemented. You could use EXTRA_EMAKE for that. You can do per-package settings via /etc/portage/package.env. Dunno where to place this request, but if we go for something like EJOBS could we also make it phase specific? So compile, install and test could have a different number of jobs running. Possibly three different variables that override a predefined EJOBS. TIA
Re: [gentoo-dev] Re: News item 1: changes to stages (make.conf and make.profile)
On 09/10/2012 08:29 PM, Gregory M. Turner wrote: > On 9/9/2012 6:34 PM, Zac Medico wrote: >> On 09/09/2012 05:59 PM, Duncan wrote: >>> To your knowlege (IOW have you tested) having /etc/make.conf either a >>> symlink to /etc/portage/make.conf or a simple one-line >>> "source /etc/portage/make.conf"? >> >> I've tested them both just now, and they work for me. Why wouldn't they? > > If both /etc/portage/make.conf and /etc/make.conf were evaluated, stuff > like > > FOO="${FOO} bar" > > could cause, i.e., duplications... not sure what all the rules are > limiting what one can and can't put in make.conf, but one could imagine > all kinds of wacky stuff. It could cause duplicates, but for variables where FOO="${FOO} bar" makes sense, duplicates probably aren't harmful. > However, IIRC, /etc/make.conf is just ignored by portage if > /etc/portage/make.conf is present, I don't know where you got that idea, but it's not true. Portage sources both files, and settings from /etc/portage/make.conf will override settings from /etc/make.conf. > so symlinking, or even better, if > possible, hardlinking those files would probably "do the right thing" > for legacy tools that don't know about the new location... unless I'm > mistaken, which is always plausible :) I would recommend to simply use /etc/make.conf alone until the legacy tools that you use catch up. We have to change the default location in the stages in order to expose the bugs so they can get fixed. -- Thanks, Zac
Re: [gentoo-dev] HDEPEND (host dependencies for cross-compilation) for EAPI 5?
On Thu, 6 Sep 2012 01:11:45 -0700 Brian Harring wrote: > A compatibility hack that stacks them is strongly advisable; > something akin to the following: > > Literally, we do the following: > inherit() { > if eapi blah; then > local DEPEND PDEPEND RDEPEND > > else > > fi > > if eapi blah; then > local _deps=( ) _x > for _x in DEPENDENCIES DEPEND RDEPEND PDEPEND; do > [ -n "${!_x}" ] && deps+=( "${!_x}" ) > done > [ ${#deps} -ne 0 ] && DEPENDENCIES="${deps[*]}" > unset DEPEND RDEPEND PDEPEND _x _deps > > else > > fi > } > > Via that, we eclasses that are pure DEPENDENCIES eapi wise, just set > the DEPENDENCIES directly; those that have to support multiple eapi's > (aka, every fricking eclass that exists right now) can just use the > old form, shifting into the new form as things progress. If we decide to go with a such a hack, then we either have to support it indefinitely, or to decide to drop the support in some further EAPI. If we go for the latter, then it's just delaying the ugly conditional eclasses will have to suffer at some random point in the future. Well, maybe two eclasses less if we wait with it for an EAPI which will provide 'killer features' which will render the eclasses unusable with older EAPIs. And way, it will be a bit confusing to remember two switch points... If we go for the former... then some developers will ask: why eclasses and not ebuilds? Why? -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: netplugd and ifplugd support in OpenRc
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/09/12 04:05 PM, David Leverton wrote: > 4) dhcpcd: not sure when it was introduced, but current dhcpcd can > detect when the link goes up and down, and request/renew its lease > when it comes up. The only wrinkle that I can see here is that, if > no ifplugd/netplug/wpa_supplicant is configured, OpenRC waits for > it to receive a lease when starting the interface, rather than > allowing it to background itself. > > So for dhcpcd, it might be enough to just make OpenRC aware that > it doesn't need to wait for a lease when starting the interface. According to bug 253925 , this would only work for certain hardware (ie, those that support the IFF_RUNNING method); ifplugd suppots three methods (IFF_RUNNING, ethtool-style, mii-style), and netplug -seems- to do it by connecting at the netlink level to the interface and just listening for traffic (as far as I can tell). So for link detection, both ifplugd and netplug would be better than attempting to just use dhcpcd, imo (not to mention the non-dhcp-based configs).. (plus, since this is all for oldnet only, i would expect dhcpcd would be a bit of an issue to integrate so that it would be able to move net.* from inactive to started state and then exclude it from being run a second time to configure the now-up iface..) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlBPOVcACgkQ2ugaI38ACPBevgD+LN73S/g6aQ8D2sR4rrIjNkSd 3eP1KgcGoEFeU+yPFIcA/RyC/fShiEaLiATnxN0ybymqspMQQcSrLj4GxeMqnPfs =jpCo -END PGP SIGNATURE-