Re: [gentoo-dev] Stability of /sys api
On Tue, 2012-05-15 at 01:05 -0400, Walter Dnes wrote: > 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. For the people who don't want to easily use USB sticks or digital cameras or gsm dongles or really any modern hardware, I'm sure mdev is fine. A static /dev is even fine for you probably. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
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
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
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 4:23 AM, Greg KH 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 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 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
[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
> "OC" == Olivier Crête 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 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 OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] RFC: new global USE flag: jit
> "AR" == Alexandre Rostovtsev 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 OpenPGP: 1024D/ED7DAEA6
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 > 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
On Tue, May 15, 2012 at 1:52 AM, Maxim Kammerer wrote: > > On Mon, May 14, 2012 at 9:05 PM, Alexandre Rostovtsev > 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] -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 Mon, May 14, 2012 at 9:05 PM, Alexandre Rostovtsev 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] RFC: new global USE flag: jit
On Mon, May 14, 2012 at 8:05 PM, Alexandre Rostovtsev 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] -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] 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?
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 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] 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] 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] -Werror unwanted?
On Mon, 14 May 2012 17:44:17 +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? 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] -Werror unwanted?
On Mon, 14 May 2012 18:01:22 +0200 Chí-Thanh Christopher Nguyễn 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] intel (icc,mkl...) packages looking for new maintainer
On Sun, May 13, 2012 at 9:14 AM, Jeroen Roovers wrote: > On Fri, 11 May 2012 16:19:33 -0700 > Sébastien Fabbro 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] 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.
[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] 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
[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, 14 May 2012 12:56:39 -0400 Olivier Crête 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
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] 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] 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] 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 OpenPGP: 1024D/ED7DAEA6
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] -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] 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?
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
[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] 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 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
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 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] 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] 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
[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
