Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
On Mon, 14 May 2012 07:23:35 +0200 Hans de Graaff gra...@gentoo.org wrote: On Sun, 2012-05-13 at 16:27 -0400, Mike Gilbert wrote: To make ebuilds utilizing python-distutils-ng.eclass usable out-of-the-box, the python team would like to add the following to make.defaults in the base profile. PYTHON_TARGETS=python2_7 See also bug 415575 [1]. I think this should have been done when the eclass was first committed. When there is no default setting people will have to set something themselves and it becomes much harder for the python team to provide a smooth upgrade path by adding in new preferred targets later on. Yes, in particular the person who opened my bug has interpreted the 'any-of' message as 'set to python2_6 python2_7'... -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Stability of /sys api
After some Google-searching, I think I've figured out how to implement automounting under mdev. I'd like to put in as much sanity-checking into the script as possible. Right now I have 1 USB stick plugged in as /dev/sdb. Th hard drive is /dev/sda. The removable data is readable like so... cat /sys/block/sda/removable 0 cat /sys/block/sdb/removable 1 My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 03:53:53AM -0400, Walter Dnes wrote: After some Google-searching, I think I've figured out how to implement automounting under mdev. I'd like to put in as much sanity-checking into the script as possible. Right now I have 1 USB stick plugged in as /dev/sdb. Th hard drive is /dev/sda. The removable data is readable like so... cat /sys/block/sda/removable 0 cat /sys/block/sdb/removable 1 My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. Api is stable although last I dealt with that crap it was reliant on chipsets/controllers not sucking and misreporting (mmc in particular comes to mind, although perhaps the hardware sucks less these days). Suggest you start studying udev source in addition since your questions of that sort are likely to be answered there. Aka, most likely wind up asking udev upstream (likely gregkh assuming he hasn't killfile'd everyone from that thread). Now the unfun part; this isn't really the right place to be asking. I get you're doing this w/ a gentoo intent, but you're dancing that line mightily fine. People asking can I safely use nested context managers in python2.6 even if it's orientated towards a potential gentoo bit (say the ephemeral gentoo stats project), typically will be told dunno. Ask the people who wrote the damn thing. Point there is that the ml shouldn't be used as tech help for the guts of I don't want udev and am trying to replace it with mdev; pkgcore nor paludis internal questions don't come here (format does since this is the appropriate venue) under the same logic. Forums come to mind, or appropriate upstreams as mentioned. Barring that, use the source luke, and start reading the lkml. If you're trying to do this, you'll likely need to track discussions there. Not trying to be a dick mind you, and perhaps others view othewise, but this isn't the place for it nor do I suspect people care to see more of this particular war play out on our ml. ~harring
Re: [gentoo-dev] Re: Proposal of accepting arguments to `default` in src_install (and more?) phases in EAPI=5 (for the next council meeting?)
2012-05-14 06:58:30 Duncan napisał(a): Ulrich Mueller posted on Sat, 12 May 2012 20:39:05 +0200 as excerpted: On Sat, 12 May 2012, Michał Górny wrote: EXTRA_EMAKE isn't supposed to be mentioned there. It's an internal use variable for users who need to pass something specific to make. You are right, of course. I guess the following ebuilds should be fixed then: eclass/bsdmk.eclass eclass/python.eclass eclass/scons-utils.eclass dev-db/redis/redis-2.2.12.ebuild dev-db/redis/redis-2.4.4-r1.ebuild dev-db/redis/redis-2.4.7.ebuild dev-db/redis/redis-2.4.8.ebuild dev-db/redis/redis-2.4.10.ebuild dev-db/redis/redis-2.4.13.ebuild gnome-base/gconf/gconf-2.32.4.ebuild net-misc/mico/mico-2.3.13-r5.ebuild sci-chemistry/ccp4-apps/ccp4-apps-6.1.3-r10.ebuild sys-fs/udev/udev-171-r5.ebuild Ouch, in eclasses too! All matches in eclasses and some matches in ebuilds are false positives. -- Arfrever Frehtes Taifersar Arahesis
Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
On 5/14/2012 12:50 AM, Ben de Groot wrote: On 14 May 2012 04:27, Mike Gilbert flop...@gentoo.org wrote: To make ebuilds utilizing python-distutils-ng.eclass usable out-of-the-box, the python team would like to add the following to make.defaults in the base profile. PYTHON_TARGETS=python2_7 See also bug 415575 [1]. Any objections? I think this is a good addition. I would also like to include python3_2, but I do not think this will be possible due to dev-lang/python:3.2 not being stabilized on several arches. Perhaps this could be set in arch-specific profiles? Would that work? I don't see how python:3.2 is useful for most of our users. And I especially don't see how having two python versions installed (but only one active) is useful for most of our users. So let's make sure only one version gets pulled in, unless specifically configured by the user. So long as any installed package depends on dev-lang/python without specifying a version, the user will end up with python-3 unless they mask it. There is no easy way out of that situation at this point; I think it would basically require renaming =dev-lang/python-3 to something else. If we acknowledge that users have both python:3.2 and python:2.7 installed most of the time, I think it makes sense to set the default value of PYTHON_TARGETS to match that expectation. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
El lun, 14-05-2012 a las 11:09 -0400, Mike Gilbert escribió: On 5/14/2012 12:50 AM, Ben de Groot wrote: On 14 May 2012 04:27, Mike Gilbert flop...@gentoo.org wrote: To make ebuilds utilizing python-distutils-ng.eclass usable out-of-the-box, the python team would like to add the following to make.defaults in the base profile. PYTHON_TARGETS=python2_7 See also bug 415575 [1]. Any objections? I think this is a good addition. I would also like to include python3_2, but I do not think this will be possible due to dev-lang/python:3.2 not being stabilized on several arches. Perhaps this could be set in arch-specific profiles? Would that work? I don't see how python:3.2 is useful for most of our users. And I especially don't see how having two python versions installed (but only one active) is useful for most of our users. So let's make sure only one version gets pulled in, unless specifically configured by the user. So long as any installed package depends on dev-lang/python without specifying a version, the user will end up with python-3 unless they mask it. There is no easy way out of that situation at this point; I think it would basically require renaming =dev-lang/python-3 to something else. If we acknowledge that users have both python:3.2 and python:2.7 installed most of the time, I think it makes sense to set the default value of PYTHON_TARGETS to match that expectation. Would be too difficult to finally fix ebuilds to properly convet shebangs and so and then, be able to have a proper system even when python3 is main interpreter? Personally, I run with it as main interpreter to catch failures, and try to fix them when possible, maybe all devs should do the same to fix packages still not working at all. signature.asc Description: This is a digitally signed message part
[gentoo-dev] -Werror unwanted?
https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then?
Re: [gentoo-dev] -Werror unwanted?
hasufell schrieb: https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then? -Werror is basically saying that it is not safe to ship code which produces warnings. I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. However this causes a heavy maintenance burden and will frequently break compilation, so the majority opinion is to remove -Werror from compiler flags. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] Stability of /sys api
On Monday 14 May 2012 03:53:53 Walter Dnes wrote: My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. if userspace is relying on stuff in /sys, then it's part of the ABI -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] -Werror unwanted?
On Monday 14 May 2012 11:44:17 hasufell wrote: https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then? the common opinion is that no package in the tree should ever allow upstream to add -Werror to the build -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] -Werror unwanted?
On Mon, 2012-05-14 at 17:44 +0200, hasufell wrote: https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then? -Werror is unwanted in anything that links to glib, gtk+, or other gnome libraries. This is because gnome upstream developers have been adding compiler warnings for usage of deprecated API which, despite being deprecated, will in all likelihood remain supported for years; -Werror turns those warnings into fatal build errors, and tracking down all instances of deprecated API use twice a year (after a new version of gnome is released) increases maintenance burden for little benefit. -Alexandre.
Re: [gentoo-dev] Stability of /sys api
WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
On Mon, 2012-05-14 at 12:31 -0400, James Cloos wrote: WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. And I'm sure it works fine with udev? Those who do not understand udev are condemned to reinvent it, poorly. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Adding PYTHON_TARGETS=python2_7 to base profile
On 5/14/2012 11:17 AM, Pacho Ramos wrote: Would be too difficult to finally fix ebuilds to properly convet shebangs and so and then, be able to have a proper system even when python3 is main interpreter? Yeah, python_convert_shebangs is an easy fix for most cases. Personally, I run with it as main interpreter to catch failures, and try to fix them when possible, maybe all devs should do the same to fix packages still not working at all. Thanks for that, the help is appreciated. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] -Werror unwanted?
On 05/14/2012 06:13 PM, Alexandre Rostovtsev wrote: On Mon, 2012-05-14 at 17:44 +0200, hasufell wrote: https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then? -Werror is unwanted in anything that links to glib, gtk+, or other gnome libraries. This is because gnome upstream developers have been adding compiler warnings for usage of deprecated API which, despite being deprecated, will in all likelihood remain supported for years; -Werror turns those warnings into fatal build errors, and tracking down all instances of deprecated API use twice a year (after a new version of gnome is released) increases maintenance burden for little benefit. -Alexandre. So, I will file a documentation bug unless someone can point me in the right direction. I didn't find a reference to that issue.
Re: [gentoo-dev] Stability of /sys api
On Mon, 14 May 2012 12:56:39 -0400 Olivier Crête tes...@gentoo.org wrote: On Mon, 2012-05-14 at 12:31 -0400, James Cloos wrote: WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. And I'm sure it works fine with udev? I dunno. Internet Explorer broke and now udev won't run. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Adding PYTHON_TARGETS=python2_7 to base profile
On 5/13/2012 4:27 PM, Mike Gilbert wrote: To make ebuilds utilizing python-distutils-ng.eclass usable out-of-the-box, the python team would like to add the following to make.defaults in the base profile. PYTHON_TARGETS=python2_7 See also bug 415575 [1]. Any objections? Seeing no objections to this part, I plan to add PYTHON_TARGETS=python2_7 to the base profile in the next day or so. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 12:31:25PM -0400, James Cloos wrote WD cat /sys/block/sda/removable WD 0 Note that a 0 there does not imply that the device cannot hotplug. My USB drive reports 0. You're right. Same for me. Thanks for pointing it out. -- Walter Dnes waltd...@waltdnes.org
[gentoo-dev] RFC: new global USE flag: jit
I propose adding the following global USE flag: jit - Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened. Current local flags that could probably be unified: app-arch/libzpaq:jit - Enable just-in-time compilation for faster compression (requires SSE2) dev-libs/libpcre:jit - Enable Just-In-Time compilation of regexp bytecode to machine code, through the SLJIT compiler. This feature might conflict wtih security mitigation strategies such as NX/PaX as enabled by Gentoo Hardened. dev-python/pypy:jit - Enable the JIT compiler dev-scheme/racket:jit - Enable just-in-time compiler media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua net-libs/webkit-gtk:jit - Enable JIT javascript compiler (disabling it will cause performance penalty) www-client/epiphany:jit - Allow using net-libs/webkit-gtk that has the JIT javascript compiler enabled www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. www-client/seamonkey:methodjit - Enable JIT for JavaScript using MethodJIT for faster JS performance. Hardened users can disable this USE-flag to use MPROTECT on grsecurity kernels. www-servers/nginx:pcre-jit - Enable JIT for pcre x11-libs/qt-core:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-script:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-webkit:jit - Enable JavaScriptCore just-in-time compiler for faster JavaScript execution -Alexandre.
Re: [gentoo-dev] RFC: new global USE flag: jit
On Monday 14 May 2012 14:05:12 Alexandre Rostovtsev wrote: I propose adding the following global USE flag: jit - Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened. Current local flags that could probably be unified: app-arch/libzpaq:jit - Enable just-in-time compilation for faster compression (requires SSE2) dev-libs/libpcre:jit - Enable Just-In-Time compilation of regexp bytecode to machine code, through the SLJIT compiler. This feature might conflict wtih security mitigation strategies such as NX/PaX as enabled by Gentoo Hardened. dev-python/pypy:jit - Enable the JIT compiler dev-scheme/racket:jit - Enable just-in-time compiler media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua net-libs/webkit-gtk:jit - Enable JIT javascript compiler (disabling it will cause performance penalty) www-client/epiphany:jit - Allow using net-libs/webkit-gtk that has the JIT javascript compiler enabled www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. www-client/seamonkey:methodjit - Enable JIT for JavaScript using MethodJIT for faster JS performance. Hardened users can disable this USE-flag to use MPROTECT on grsecurity kernels. www-servers/nginx:pcre-jit - Enable JIT for pcre x11-libs/qt-core:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-script:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-webkit:jit - Enable JavaScriptCore just-in-time compiler for faster JavaScript execution -Alexandre. +1 -- Agostino Sarubboago -at- gentoo.org Gentoo/AMD64 Arch Security Liaison GPG: 0x7CD2DC5D signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] intel (icc,mkl...) packages looking for new maintainer
On Sun, May 13, 2012 at 9:14 AM, Jeroen Roovers j...@gentoo.org wrote: On Fri, 11 May 2012 16:19:33 -0700 Sébastien Fabbro bicat...@gentoo.org wrote: dev-lang/icc dev-lang/ifc they have up-to-date versions in the science overlay. Do these up-to-date ebuilds fix the Macrovision bug[1]? Do we even have a proper workaround for the sandbox violation that doesn't involve disabling the sandbox? unfortunately they do not. this bug is indeed quite annoying i have no easy solution. this is even more annoying for x86* users with USE=-fortran who might need to pull a fortran compiler to build lapack as a dependency of a package, and since it depends on virtual/fortran, dev-lang/ifc will be chosen. -- sébastien
Re: [gentoo-dev] -Werror unwanted?
On Mon, 14 May 2012 18:01:22 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: -Werror is basically saying that it is not safe to ship code which produces warnings. An upstream demanding -Werror should work means upstream would need to test rather a lot more than their own favourite distro/architecture/library versions/kernel/userland, which isn't going to happen. I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. Upstream does not need to take into account warnings produced by compilers for lesser known architectures, as explained above. As an upstream development aid to check code that has just been added or changed, -Werror is fine, but not in the wild jungle that is Gentoo. You might as well just look at the warnings themselves instead of breaking the build system by making them fatal. In other words, for upstream development it's convenient, but never for our users out there. Also, bug reports based on *FLAGS=-Werror will be closed as INVALID. (Perhaps we should document that too.) jer
Re: [gentoo-dev] -Werror unwanted?
On Mon, 14 May 2012 17:44:17 +0200 hasufell hasuf...@gentoo.org wrote: https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then? Upstream which enforces a particular warning flags on users is a dumb upstream. Necessary warning flags should be set locally by devs / distro maintainers rather than through autoconf. If they can't handle that, someone should probably be replaced. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/05/12 09:54, Olivier Crête wrote: Hi, On Thu, 2012-05-10 at 06:34 +0200, Fabio Erculiani wrote: I think expressing my own opinion about Lennart-made software is my right, after all. I would express my opinion about Fabio made software, but I've never heard of any. Not his fault, he wrote plenty of interesting stuff though. Fabio attitude still isn't that horrible regarding feedbacks, Rigo got created more or less because the previous UI got a sound it sucks. His quite short and a bit extreme reaction probably is due having lots of unhappy user complaining at him for some issue with avahi (hangs in bonjour now and then) and pulse (skype freezing randomly anyone). Firstly, it's almost impossible nowadays to avoid including avahi, systemd and pulseaudio into a desktop distro so, there is no real choice. This issue became a sensible matter for those users who for instance, wanted to have a silly mp3 player working without going through the PA nonsense, really missing the old ALSA-oh-it-was-always-working days. Maybe the reason every sensible distribution uses Avahi, Pulseaudio, etc is because they are better than other solutions out there? If there are solutions somebody will use them, if people are aware of them and doesn't get too hard. I did like the concept about pulse and even wrote support for pulse in a certain fringe software you might use. The pulse concept is quite good, some corner cases and some design issues make it annoying at time. The fact some of them are consider features or design obviously make the whole thing less nice. Do you think is a fast conspiracy to make your life suck? I believe engineers in every distribution are looking at what's available and picking what they think is the best solution, and it turns out Lennart is pretty damn good at making useful software. No, he is pretty damn good in getting interesting concepts, having people sold on them and then you need 5 years to have the audio seldom crash, bonjour seldom kill pidgin and so on. Till it is some minor annoyance that is comparable to not having the feature or the same to other feature provider (dmix isn't exactly great as well) you surely can live with it. Was alsa always working? I remember spending hours trying to figure out the right control in alsamixer and fighting with alsa's arcane configuration languages (it has 3 different ones). And how do you deal with modern technologies like Bluetooth audio without Pulseaudio exactly? I used to do that and it was working sort of fine even if it was crashing in dbus... Of course, I am not only bringing my personal opinion here, but the one of the majority of users I've been talking with. I think you only hear from users who like to complain, others are just happy that everything works for them thanks to Pulseaudio, systemd, etc. As said, if they are minor annoyances most people would just cope with them. A - Skype hangs because pulse? oh well, let's reload it no biggie B - AAaargh I missed the important confcall because #%$#@ skype hang due pulse, I hate YOU Lennart! A and B are different reactions from the same small issue. If you think that Lennart does not solve problems, maybe it's because you don't even understand what the problems were? For example, I encourage you to read about how the dynamic latency in PA allows for lower power usage or how modern audio hardware is designed to use a userspace sound server, etc. I recall when the whole thing got initially reported and it was pulse eats my batter and if you consider that the stock pulse on ubuntu oneric eats about a *least* 10% cpu on imx51 due funny resampling loops you know something needed some more attention. I guess I'm digressing. The main issue is that udev best replacement so far is mdev plus some additional helpers to let applications using libudev or the dbus interface still get compatibility. So having udev merge with systemd is quite in the shovel meet throat side. People that had and have some bad experience with pulse and avahi or directly with Lennart stubborn and abrasive personality can be *quite* concerned about this vertical and linux-only approach. If you consider that in 2 weeks the whole thing went from udev moves to systemd since is easier for us, but not be concerned udev can build stand alone to udev stand alone is unsupported you can see that isn't that simple and lots of people might start to get angry. lu - -- Luca Barbato Gentoo/linux http://dev.gentoo.org/~lu_zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xU3sACgkQ6Ex4woTpDjTNewCfU5cahmNPbgKQJt/2GkbVBh4o F1gAnjheSaIVRF55g1//9wu5dFe8ga3w =FlU7 -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new global USE flag: jit
El lun, 14-05-2012 a las 20:09 +0200, Agostino Sarubbo escribió: On Monday 14 May 2012 14:05:12 Alexandre Rostovtsev wrote: I propose adding the following global USE flag: jit - Enable just-in-time compilation for improved performance. May prevent use of some PaX memory protection features in Gentoo Hardened. Current local flags that could probably be unified: app-arch/libzpaq:jit - Enable just-in-time compilation for faster compression (requires SSE2) dev-libs/libpcre:jit - Enable Just-In-Time compilation of regexp bytecode to machine code, through the SLJIT compiler. This feature might conflict wtih security mitigation strategies such as NX/PaX as enabled by Gentoo Hardened. dev-python/pypy:jit - Enable the JIT compiler dev-scheme/racket:jit - Enable just-in-time compiler media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua net-libs/webkit-gtk:jit - Enable JIT javascript compiler (disabling it will cause performance penalty) www-client/epiphany:jit - Allow using net-libs/webkit-gtk that has the JIT javascript compiler enabled www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. www-client/seamonkey:methodjit - Enable JIT for JavaScript using MethodJIT for faster JS performance. Hardened users can disable this USE-flag to use MPROTECT on grsecurity kernels. www-servers/nginx:pcre-jit - Enable JIT for pcre x11-libs/qt-core:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-script:jit - Enables JIT for Javascript usage inside Qt x11-libs/qt-webkit:jit - Enable JavaScriptCore just-in-time compiler for faster JavaScript execution -Alexandre. +1 +1 also ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] -Werror unwanted?
El lun, 14-05-2012 a las 20:24 +0200, Jeroen Roovers escribió: On Mon, 14 May 2012 18:01:22 +0200 Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: -Werror is basically saying that it is not safe to ship code which produces warnings. An upstream demanding -Werror should work means upstream would need to test rather a lot more than their own favourite distro/architecture/library versions/kernel/userland, which isn't going to happen. I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. Upstream does not need to take into account warnings produced by compilers for lesser known architectures, as explained above. As an upstream development aid to check code that has just been added or changed, -Werror is fine, but not in the wild jungle that is Gentoo. You might as well just look at the warnings themselves instead of breaking the build system by making them fatal. In other words, for upstream development it's convenient, but never for our users out there. Also, bug reports based on *FLAGS=-Werror will be closed as INVALID. (Perhaps we should document that too.) jer I fully agree with Jeroen on this, -Werror problems should be reported directly to upstream if people want to help them on fixing warnings. signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Packages maintained by trapni need a co-maintainer
El dom, 06-05-2012 a las 18:38 +0200, Michael Weber escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/06/2012 05:35 PM, Pacho Ramos wrote: Well, in tree versions are still buggy and outdated, I would vote for either: 1. Mask them for removal (server is already hardmasked, but client not). 2. Proxy maintain them if anyone volunteers. I would proxy maintain. Feel free to send me a pm on #irc.freenode.net, user xmw. Michael Not sure how this ended finally :-/ Thanks for the news :) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] -Werror unwanted?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 05/14/2012 06:03 PM, hasufell wrote: On 05/14/2012 06:13 PM, Alexandre Rostovtsev wrote: On Mon, 2012-05-14 at 17:44 +0200, hasufell wrote: https://bugs.gentoo.org/show_bug.cgi?id=260867 However, I don't see references to ebuild policy (in devmanual or howtos) how to handle Werror. Is there a common opinion on that. And shouldn't we add that to the documentation then? -Werror is unwanted in anything that links to glib, gtk+, or other gnome libraries. This is because gnome upstream developers have been adding compiler warnings for usage of deprecated API which, despite being deprecated, will in all likelihood remain supported for years; -Werror turns those warnings into fatal build errors, and tracking down all instances of deprecated API use twice a year (after a new version of gnome is released) increases maintenance burden for little benefit. -Alexandre. So, I will file a documentation bug unless someone can point me in the right direction. I didn't find a reference to that issue. Open a bug, write a devmanual patch and I will be happy to apply it - -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBCgAGBQJPsVXFAAoJEPqDWhW0r/LCu6wQAL4PnIdPbockkXyrQY0srnWw Y+3bPlaLJgMecHFwiLzA6LNzk6Tc69JmPio0kGvGKxgL+lfsdhwq3FPqqq8X92lU Ao+gIdxr4ALGZNS4b5bJAdgQHSNo8NndezBaNFjXzKAr5fzI449/6oFQwucDFA/a c2smuoKfK690RP4dLjoB0uXvFmTyCRHpUK8mikaXxnMnQlQ0DpkzuVAWJHaR7u1e XuuMMHlaaQ/EJMt1p1VXfvkekTHQ60R0U/CuDNc5CjjAQRJpqIao7quwZAg0OMeY ty56OC5hu/AdqAngnEY3wUAt/iho6yDCUhKM0Z4lEHVgsJWDmZuMF3yidZTbXIP1 7Zg73zqHRfYUJLMqyWiXy7+32gTTlIjZGivbWK6KH0QB55pdKindWmsUcQfiblTD yhfOhTur6w89GH7uepB+jMPY5VRk55z3qQ1wVUe1b+rCRrgDeGAe+AIh6TWOxsrE EeuRSe9CWFR85sCFlACevTRNnZ40Nfms/Cr48eDzNNbS7Ldfmb231DHB90m1MWMT /nHRKjwYmspEnE4e3qwjSgTHvJufkm0A08cEWgUBBXxjaepsRgKfXSIrJBVHqL7T xJPKzN9zm8K3nEnQC9bXfcm4XwoerUDbSPLeIUzHTPURJHO5b1hQkhCPfwrhA9b8 Kt5bsmo1KEmD9sGBzREr =471E -END PGP SIGNATURE-
Re: [gentoo-dev] RFC: new global USE flag: jit
On Mon, May 14, 2012 at 8:05 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. Not sure it's a good fit for these two. In the other cases, there appears to be just a difference in compilation, but this is about selecting a different dependency. Cheers, Dirkjan
Re: [gentoo-dev] RFC: new global USE flag: jit
On Mon, May 14, 2012 at 9:05 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: Current local flags that could probably be unified: What about USE=orc? It's JIT in a sense — IIRC, it creates an executable in /tmp at run-time. -- Maxim Kammerer Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] -Werror unwanted?
Jeroen Roovers schrieb: -Werror is basically saying that it is not safe to ship code which produces warnings. An upstream demanding -Werror should work means upstream would need to test rather a lot more than their own favourite distro/architecture/library versions/kernel/userland, which isn't going to happen. No. -Werror just means that if a warning is encountered, the user should be prevented from installing the software. Then a developer looks at the issue and determines whether it is safe to ignore or needs to be addressed. I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. Upstream does not need to take into account warnings produced by compilers for lesser known architectures, as explained above. These warnings could be harmless or introduce silent breakage. The user often can't tell. As an upstream development aid to check code that has just been added or changed, -Werror is fine, but not in the wild jungle that is Gentoo. You might as well just look at the warnings themselves instead of breaking the build system by making them fatal. In other words, for upstream development it's convenient, but never for our users out there. -Werror is not convenient for anybody. When the developer has looked at the issue, then the particular warning could be made non-fatal. hasufell mentioned in another post the GTK+ deprecated warnings. Note that I don't propose the current policy to be changed. I can totally live with filtering -Werror in order to reduce maintenance work, at the small cost mentioned above. Best regards, Chí-Thanh Christopher Nguyễn
Re: [gentoo-dev] RFC: new global USE flag: jit
On Tue, May 15, 2012 at 1:52 AM, Maxim Kammerer m...@dee.su wrote: On Mon, May 14, 2012 at 9:05 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: Current local flags that could probably be unified: What about USE=orc? It's JIT in a sense — IIRC, it creates an executable in /tmp at run-time. Doesn't make sense to unnecessarily unify USE-flags like that. Consolidate just enough, but not too much. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] RFC: new global USE flag: jit
On Mon, 2012-05-14 at 21:51 +0200, Dirkjan Ochtman wrote: On Mon, May 14, 2012 at 8:05 PM, Alexandre Rostovtsev tetrom...@gentoo.org wrote: media-sound/csound:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua www-client/luakit:luajit - Use the lua just-in-time compiler dev-lang/luajit instead of dev-lang/lua, which should make luakit faster. Not sure it's a good fit for these two. In the other cases, there appears to be just a difference in compilation, but this is about selecting a different dependency. Good point. Since dev-lang/luajit is the actual name of the selected package, leaving the flag as luajit makes more sense. -Alexandre.
Re: [gentoo-dev] RFC: new global USE flag: jit
AR == Alexandre Rostovtsev tetrom...@gentoo.org writes: AR www-servers/nginx:pcre-jit - Enable JIT for pcre This one also should remain un-unified. There may be other, unrelated jit options in the future, whether affecting nginx itself or potential PDEPENDs or ???. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
My USB drive reports 0. WD You're right. Same for me. Thanks for pointing it out. The removable flag specifies whether the drive has removable media; before flash drives only things like floppy, optical, zip, etc drives had removable==1. It also would be accurate for flash card readers. If thumb drives specify it, then they lie. The flag is read from the drive's metadata. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] Stability of /sys api
OC == Olivier Crête tes...@gentoo.org writes: OC And I'm sure it works fine with udev? It automounts when plugged in, if that is what you mean. (In fact each partition does; the one in fstab(5) where it should and the one not in fstab in a mount point based on its label.) And the dev files get removed when the drive is unplugged. (unplugged here means either the usb cable or the power cable.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: -Werror unwanted?
On 14/05/12 23:42, Chí-Thanh Christopher Nguyễn wrote: I personally think that if an upstream says that no warnings must be produced by the code, and a developer should look at them before declaring any warnings safe, then that is best followed. Upstream does not need to take into account warnings produced by compilers for lesser known architectures, as explained above. These warnings could be harmless or introduce silent breakage. The user often can't tell. You can have breakage without any warnings being emitted, and you can have warnings that result in no breakage whatsoever. Furthermore, -Werror on Gentoo makes zero sense; portage will already produce a QA notice with warnings that have the potential to result in breakage. -Werror is not needed.
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 12:09:23PM -0400, Mike Frysinger wrote: On Monday 14 May 2012 03:53:53 Walter Dnes wrote: My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. if userspace is relying on stuff in /sys, then it's part of the ABI Yes, but note, you are looking at the wrong thing, what you are reading isn't really what you think it means... And to rely on sysfs, you have to be very careful, you can not rely on position, or files, always being where you saw them yesterday as device ids, topologies, and other stuff, change all the time. greg k-h
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 03:53:53AM -0400, Walter Dnes wrote: After some Google-searching, I think I've figured out how to implement automounting under mdev. I'd like to put in as much sanity-checking into the script as possible. Right now I have 1 USB stick plugged in as /dev/sdb. Th hard drive is /dev/sda. The removable data is readable like so... cat /sys/block/sda/removable 0 cat /sys/block/sdb/removable 1 My question... is this API stable or deprecated? I.e. can I count on it being around for a while? I figure this question is a developer type question rather than ordinary user type. You might want to look at Documentation/ABI/ in the kernel source tree if you are curious about sysfs files like this. As you have figured out, this really doesn't mean what you think it does. In fact, there's no way to determine what I think you are asking for, which is can this disk go away, as really, any disk can go away at any point in time, just like any disk can show up at any point in time as well. Think PCI hotplug systems, thunderbolt, pcmcia, ExpressCard, Firewire, USB, SCSI, etc. So you need to implement stuff such that you are not dependant on the bus type. If you see a new disk, act on it, it's that simple. But note, please do not be automounting disks from uevents directly. As someone else said on this thread, those that have not learned from the lessons of udev, will implement it poorly. We learned that this is not a good idea at all, and should be left to userspace helper applications that listen for dbus messages. Both GNOME and KDE work this way quite well, so I would be very wary of reimplementing the wheel. Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? Good luck, greg k-h
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 4:23 AM, Greg KH gre...@gentoo.org wrote:
We learned that this is not a good idea at all, and should be left to
userspace helper applications
that listen for dbus messages.
Could you perhaps expand a bit on those reasons? E.g., I had good
experience with the following short script for coupling udev events
with autofs:
https://github.com/mkdesu/liberte/blob/master/src/usr/local/sbin/ps-mount.
Gentoo wiki has a similar tutorial as well. Granted, it is a
single-user setup, but I can imagine it being extended to work with
ConsoleKit. One obvious problem is mounting encrypted volumes. I
thought about moving to e.g., udisks-glue (as a more standard
solution), but from what I hear there are too many bugs with udisks at
the moment.
Actually with all the hype about mdev these days, why not just use a 3
year old version of udev (or maybe 4), that is probably what mdev is at
as far as functionality goes.
I don't know at what state udev was 3 or 4 years ago, but mdev can:
1. Populate /dev (now unnecessary due to devtmpfs).
2. Handle ownership, permissions and symlinks to /dev nodes once they
appear, according to simple rules (can be probably done with inotify).
3. Act as /sbin/hotplug, typically doing something equivalent to this one-liner:
[ ${ACTION} = add -a -n ${MODALIAS} ] modprobe -qb ${MODALIAS}
I don't think mdev can do anything else. Building any serious
framework on top of mdev seems pointless to me, since it will probably
end up as a small subset of udev core reimplemented with scripts.
--
Maxim Kammerer
Liberté Linux (discussion / support: http://dee.su/liberte-contribute)
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote: Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? I'm wondering the same thing since once busybox 1.20.0 hits stable you will be able to have a separate /usr without an initramfs quite easily if that's what you want to do. When you emerge this version of busybox with the sep-usr use flag, you get a binary in / called ginit. Now just follow the instructions you got when you emerged it. William pgpsDOJ63MLdp.pgp Description: PGP signature
Re: [gentoo-dev] Stability of /sys api
On Tue, May 15, 2012 at 04:56:15AM +0300, Maxim Kammerer wrote
I don't know at what state udev was 3 or 4 years ago, but mdev can:
1. Populate /dev (now unnecessary due to devtmpfs).
2. Handle ownership, permissions and symlinks to /dev nodes once they
appear, according to simple rules (can be probably done with inotify).
3. Act as /sbin/hotplug, typically doing something equivalent to this
one-liner:
[ ${ACTION} = add -a -n ${MODALIAS} ] modprobe -qb ${MODALIAS}
That's *EXACTLY* what I want and need. To borrow an old emacs joke,
udev is a mediocre OS that lacks a lightweight device manager.
I don't think mdev can do anything else. Building any serious
framework on top of mdev seems pointless to me, since it will probably
end up as a small subset of udev core reimplemented with scripts.
I *DON'T WANT* a serious framework, I want a lightweight device
manager... period... end of story. Stick with the unix principle of one
app doing one thing well. mdev is enough for the vast majority of people.
--
Walter Dnes waltd...@waltdnes.org
Re: [gentoo-dev] Stability of /sys api
On Mon, May 14, 2012 at 06:23:36PM -0700, Greg KH wrote So you need to implement stuff such that you are not dependant on the bus type. If you see a new disk, act on it, it's that simple. But note, please do not be automounting disks from uevents directly. After some more Google-searching. it looks like the official channels way is via /etc/mdev.conf. Note that this is on a system with busybox[mdev] and no udev. /etc/mdev.conf has a rudimentary set of mdev rules abilities, and most importantly, it can also call external executables (scripts/programs/whatever). On my mdev based machines... $ cat /proc/sys/kernel/hotplug /sbin/mdev Actually with all the hype about mdev these days, why not just use a 3 year old version of udev (or maybe 4), that is probably what mdev is at as far as functionality goes. Why not just fork udev from then and go forward from that? What exactly are you not liking in udev that makes you want to get rid of it so badly? What is it doing that bothers people so much? Unfortunately, I am not a C programmer, so forking udev is only a dream. As Maxim has pointed out, mdev does what most people need. The busybox people do the maintenance. Given their target audience (embedded and lightweight systems), we can be certain that mdev won't grow into a monstrosity. Even if I could do it, why reinvent the wheel? We have a perfectly usable alternative right now in mdev. My main programming strength is bash scripts etc. Actually, a fork I'd be interested in would be to take standard Gentoo and replace as many programs as possible with their busybox-symlink equivalants. This would require at least a new profile, to a) create the appropriate symlinks, and b) not pull in the standalone versions. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
On 05/11/2012 06:39 PM, Mike Frysinger wrote:
+multijob_child_init() {
+ trap 'echo ${BASHPID} $? '${mj_control_fd} EXIT
+ trap 'exit 1' INT TERM
+}
Just wondering why $! in parent isn't used anywhere, even not for some
integrity check if the child's BASHPID actually was forked by parent.
+multijob_post_fork() {
+ : $(( ++mj_num_jobs ))
+ if [[ ${mj_num_jobs} -ge ${mj_max_jobs} ]] ; then
+ multijob_finish_one
Feels like ignoring this child's exitstatus isn't intentional here.
+ fi
+ return 0
+}
/haubi/
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
On 05/14/2012 12:33 AM, Michael Haubenwallner wrote:
+multijob_post_fork() {
+: $(( ++mj_num_jobs ))
+if [[ ${mj_num_jobs} -ge ${mj_max_jobs} ]] ; then
+multijob_finish_one
Feels like ignoring this child's exitstatus isn't intentional here.
Thanks, fixed now:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=2adc44295a5b5c77640c32cd24ebbd8d52e5237b
And here are a couple of more related fixes:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b4fba3e9fa2e285244de491f57700978158c1838
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=c534e32f78cf7c543e9203e7fe1c7b1630144ffb
--
Thanks,
Zac
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
On Monday 14 May 2012 03:33:58 Michael Haubenwallner wrote:
On 05/11/2012 06:39 PM, Mike Frysinger wrote:
+multijob_child_init() {
+ trap 'echo ${BASHPID} $? '${mj_control_fd} EXIT
+ trap 'exit 1' INT TERM
+}
Just wondering why $! in parent isn't used anywhere, even not for some
integrity check if the child's BASHPID actually was forked by parent.
i don't know of any cases where this would error out. if there are too many
processes, bash itself will retry a few times before aborting. so checking $!
wouldn't help.
keep in mind, what you're proposing is basically checking the return value of
fork(), and that can fail in very few ways. all of which, afaik, bash does
not bubble up to the script.
-mike
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
On Monday 14 May 2012 13:37:40 Mike Frysinger wrote:
On Monday 14 May 2012 04:44:12 Zac Medico wrote:
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b4fb
a3 e9fa2e285244de491f57700978158c1838
should really fix it to make the code parallel safe rather than disabling
it completely. i'll work on that.
this should make it parallel safe
-mike
--- a/bin/ebuild-helpers/prepstrip
+++ b/bin/ebuild-helpers/prepstrip
@@ -62,22 +62,13 @@
prepstrip_sources_dir=${EPREFIX}/usr/src/debug/${CATEGORY}/${PF}
type -P debugedit /dev/null debugedit_found=true || debugedit_found=false
debugedit_warned=false
-disable_parallel=false
-${FEATURES_splitdebug} disable_parallel=true
-${FEATURES_installsources} \
- ! ${RESTRICT_installsources} \
- ${debugedit_found} disable_parallel=true
-
-if ${disable_parallel} ; then
- # Disable parallel processing, in order to prevent interference with
- # temp files like debug.sources or prepstrip.split.debug
- numjobs() {
- echo 1
- }
-fi
-
multijob_init
+# Setup $T filesystem layout that we care about.
+tmpdir=${T}/prepstrip
+rm -rf ${tmpdir}
+mkdir -p ${tmpdir}/{splitdebug,sources}
+
unset ${!INODE_*}
# Usage: inode_var_name: file
@@ -112,11 +103,11 @@ save_elf_sources() {
buildid=$(debugedit -i \
-b ${WORKDIR} \
-d ${prepstrip_sources_dir} \
- -l ${T}/debug.sources \
+ -l ${tmpdir}/sources/${x##*/}.${BASHPID} \
${x})
}
-# Usage: save_elf_debug elf
+# Usage: save_elf_debug elf [splitdebug file]
save_elf_debug() {
${FEATURES_splitdebug} || return 0
@@ -125,6 +116,7 @@ save_elf_debug() {
# twice in this path) in order for gdb's debug-file-directory
# lookup to work correctly.
local x=$1
+ local splitdebug=$2
local y=${ED}usr/lib/debug/${x:${#D}}.debug
# dont save debug info twice
@@ -137,8 +129,8 @@ save_elf_debug() {
ln ${ED}usr/lib/debug/${!inode:${#D}}.debug ${y}
else
eval ${inode}=\${x}
- if [[ -e ${T}/prepstrip.split.debug ]] ; then
- mv ${T}/prepstrip.split.debug ${y}
+ if [[ -n ${splitdebug} ]] ; then
+ mv ${splitdebug} ${y}
else
local objcopy_flags=--only-keep-debug
${FEATURES_compressdebug} objcopy_flags+=
--compress-debug-sections
@@ -175,11 +167,13 @@ process_elf() {
if ${strip_this} ; then
# see if we can split strip at the same time
if [[ -n ${SPLIT_STRIP_FLAGS} ]] ; then
+ local shortname=${x##*/}.debug
+ local
splitdebug=${tmpdir}/splitdebug/${shortname}.${BASHPID}
${STRIP} ${strip_flags} \
- -f ${T}/prepstrip.split.debug \
- -F ${x##*/}.debug \
+ -f ${splitdebug} \
+ -F ${shortname} \
${x}
- save_elf_debug ${x}
+ save_elf_debug ${x} ${splitdebug}
else
save_elf_debug ${x}
${STRIP} ${strip_flags} ${x}
@@ -194,8 +188,8 @@ if ! ${RESTRICT_binchecks} ! ${RESTRICT_strip} ; then
# We need to do the non-stripped scan serially first before we turn
around
# and start stripping the files ourselves. The log parsing can be done
in
# parallel though.
- log=$T/scanelf-already-stripped.log
- scanelf -yqRBF '#k%F' -k '!.symtab' $@ | sed -e s#^${ED}## $log
+ log=${tmpdir}/scanelf-already-stripped.log
+ scanelf -yqRBF '#k%F' -k '!.symtab' $@ | sed -e s#^${ED}##
${log}
(
multijob_child_init
qa_var=QA_PRESTRIPPED_${ARCH/-/_}
@@ -286,9 +280,11 @@ do
multijob_post_fork
done
-# Let jobs finish before processing ${T}/debug.sources
+# With a bit more work, we could run the rsync processes below in
+# parallel, but not sure that'd be an overall improvement.
multijob_finish
+cat ${tmpdir}/sources/* ${tmpdir}/debug.sources 2/dev/null
if [[ -s ${T}/debug.sources ]] \
${FEATURES_installsources} \
! ${RESTRICT_installsources} \
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/14/2012 11:53 AM, Mike Frysinger wrote: On Monday 14 May 2012 13:37:40 Mike Frysinger wrote: On Monday 14 May 2012 04:44:12 Zac Medico wrote: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b4fb a3 e9fa2e285244de491f57700978158c1838 should really fix it to make the code parallel safe rather than disabling it completely. i'll work on that. this should make it parallel safe -mike Yeah, that looks good. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xVuEACgkQ/ejvha5XGaNa1ACeLTRHjwNuRRXp9wsLgKeTcKEp W7QAn2Z642Dx8r2OhDSifoqZtljFn7+E =piRb -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/14/2012 12:02 PM, Zac Medico wrote: On 05/14/2012 11:53 AM, Mike Frysinger wrote: On Monday 14 May 2012 13:37:40 Mike Frysinger wrote: On Monday 14 May 2012 04:44:12 Zac Medico wrote: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b4fb a3 e9fa2e285244de491f57700978158c1838 should really fix it to make the code parallel safe rather than disabling it completely. i'll work on that. this should make it parallel safe -mike Yeah, that looks good. Actually, the inode_var_name thing will not work unless it's all in one process. - -- Thanks, Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+xWDAACgkQ/ejvha5XGaM8OwCguDf5rKVv4cpEmOYoqwrLBgGM mr0AniCfHtJiNJRpF+mC4oHquO3nSen1 =3gSf -END PGP SIGNATURE-
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
On 05/14/2012 01:10 PM, Mike Frysinger wrote: On Monday 14 May 2012 15:08:32 Zac Medico wrote: Actually, the inode_var_name thing will not work unless it's all in one process. hmm, true, but that's the level we currently parallelize at, so it's fine. we do one subprocess per ELF and that includes the strip/splitdebug/splitsources. parallelizing more than on a per-ELF basis will require much finer grained queues which, while possible, would make the file much harder to hack on and extend. and i'm not sure we'd see that much of a gain. -mike The thing is, in the case of hardlinks, we're parallelizing multiple times on the *same* elf. Anyway, I've fixed it by using a directory full of hardlinks, in these commits: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ad944275b88a50d2a1f694826b127cceb9221e78 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ed00a9e70a3705164a5349145ff467e5c40ddfd -- Thanks, Zac
Re: [gentoo-portage-dev] [RFC/PATCH] prepstrip/ecompressdir: parallelize operations
On Monday 14 May 2012 18:42:07 Zac Medico wrote: On 05/14/2012 01:10 PM, Mike Frysinger wrote: On Monday 14 May 2012 15:08:32 Zac Medico wrote: Actually, the inode_var_name thing will not work unless it's all in one process. hmm, true, but that's the level we currently parallelize at, so it's fine. we do one subprocess per ELF and that includes the strip/splitdebug/splitsources. parallelizing more than on a per-ELF basis will require much finer grained queues which, while possible, would make the file much harder to hack on and extend. and i'm not sure we'd see that much of a gain. The thing is, in the case of hardlinks, we're parallelizing multiple times on the *same* elf. Anyway, I've fixed it by using a directory full of hardlinks, in these commits: well, realistically speaking, hardlinking has been broken before the parallelization work. https://bugs.gentoo.org/400767 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ad9442 75b88a50d2a1f694826b127cceb9221e78 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=9ed00 a9e70a3705164a5349145ff467e5c40ddfd i'll go through it and see what's what -mike signature.asc Description: This is a digitally signed message part.
