Re: [gentoo-dev] Minor change in pkg-config behavior, starting with 0.28, late heads up for maintainers
29.03.2013 10:30, Samuli Suominen пишет: This is from Fedora Devel Mailing List. I found it to be news worthy also for Gentoo maintainers. So here it is: snip Remi Collet Fedora at FamilleCollet.com Thu Mar 28 10:39:52 UTC 2013 Previous versions $ echo ==$(pkg-config --cflags-only-I openssl)== == == New version $ echo ==$(pkg-config --cflags-only-I openssl)== This space to empty string output can breaks some poorly written autoconf script. Remi. P.S.1: I hope it could helps some packager... avoid losing too much time on this... P.S.2:example of broken script http://git.php.net/?p=php-src.git;a=commitdiff;h=640e72ce91d8e591b92cd93c18d1bfe3befe3424 /snip I have discovered this behaviour change due to resolving bug #455984, where custom configure script was unaware of new pkgconfig. -- Best regards, Sergey Popov Gentoo Linux Developer Desktop-effects project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Collecting items for EAPI 6
2013/3/28 Michał Górny mgo...@gentoo.org: Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi #444366 - unique subslot for live ebuilds -- Christoph Junghans http://dev.gentoo.org/~ottxor/
Re: [gentoo-dev] Collecting items for EAPI 6
On Sat, 30 Mar 2013 12:39:14 -0600 Christoph Junghans ott...@gentoo.org wrote: 2013/3/28 Michał Górny mgo...@gentoo.org: Hello, As discussed with ulm, I'd like to start a thread for collecting initial items for EAPI 6. Preferably items which are either almost ready or are easy to implement and are non-controversial. In other words, thing which are practically ready to get on the actual list. As usual, each item should have a corresponding 'Future EAPI' bug which blocks the tracker [1]. [1]:https://bugs.gentoo.org/show_bug.cgi?id=future-eapi #444366 - unique subslot for live ebuilds Has anyone tried implementing this and using it in practice? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
130329 Samuli Suominen wrote: Attached new version again, more generic than before. I find this difficult to decipher. Who is it aimed at ? I've just updated to Udev 200 . Following the news item, I renamed /etc/udev/rules.d/70-persistent-net.rules : my script to start my I/net connection with DHCP failed. I restored the file to its old name all works as usual : it has 'NAME=eth0'. I am always aware of grateful for the unpaid efforts of Gentoo devs, but I'm not pleased with confused or confusing news items. The first thing any news item should make clear is its audience : If you are using ABC or belong to the group describable as DEF, then you need to do GHI. Clearly, I don't fall into the group at whom the Udev news item is aimed, perhaps those with 1 net card. What proportion of Gentoo users fall into that group ? HTH improve news items. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 31/03/13 04:06, Philip Webb wrote: 130329 Samuli Suominen wrote: Attached new version again, more generic than before. I find this difficult to decipher. Who is it aimed at ? I've just updated to Udev 200 . Following the news item, I renamed /etc/udev/rules.d/70-persistent-net.rules : my script to start my I/net connection with DHCP failed. I restored the file to its old name all works as usual : it has 'NAME=eth0'. Aimed to everyone and it already answers your questions. I can answer them differently here again, but if you read the news item, this all is there: If kernel assigns eth0 to first network interface (driver/module) then you can't rename to eth0, thus the rule you have is likely superflous and it doesn't matter if you delete it or not -- you are currently using random kernel names What it might do is interfere with enabling of the new networking, so you should propably symlink /etc/udev/rules.d/80-net-name-slot.rules to /dev/null and delete the 70-persistent-net.rules and the behavior of your system stays exactly as it's when you are writing this now, using random kernel names, but if it's an system with only 1 network card, it propably doesn't matter much as eth0 gets always used (almost always) Nothing is stopping you from leaving out the symlink either and migrating to the new name despite using only 1 network card either, it's still more reliable than the kernel names The logic really isn't that hard... It's documented everywhere... :-(
Re: [gentoo-dev] Re: Request of news item review: 2013-03-29-udev-predictable-network-interface-names.en.txt
On 31/03/2013 03:17, Samuli Suominen wrote: it's still more reliable than the kernel names I still call that bullshit. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
[gentoo-dev] sys-apps/texinfo vs @system
the new texinfo-5.x series has rewritten makeinfo in perl. the main `info` program is still in pure C. when it comes to packages installing .info pages, it's largely limited to the GNU projects as the format has never really caught on. many of those projects also install man pages. personally, i've never found info pages usable. for most utils, the man pages or the --help output is sufficient, and for people doing heavy development, the online html manuals are significantly more useful. when it was pure C, i could live with it as it's only 1MiB and no real deps to speak of. now it's more like 3MiB, and pulls in 3 semi-uncommon additional perl packages (not to mention perl itself). it's in @system for two reasons: it provides `info` and `makeinfo`. the former is for reading info pages (i.e. RDEPEND) while the latter is used for generating info pages (i.e. DEPEND) when the tarball didn't ship with them pregenerated (they usually do). one option would be to make the makeinfo stuff into a USE flag so all the perl junk isn't pulled in by default. only the packages that actually generate info pages can DEPEND on that. it'd be simpler if we just dropped it altogether from @system. if people want `info`, they can `emerge` it themselves. if packages want `makeinfo`, they can DEPEND on it -- few fall into this category (100 by a rough survey of random Gentoo installs). obviously my preference is for the latter. -mike signature.asc Description: This is a digitally signed message part.
