Re: [gentoo-dev] RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
On Mon, May 16, 2011 at 5:15 PM, Samuli Suominen ssuomi...@gentoo.org wrote: Let's start with generalized example so everyone gets the idea... Reference: man 8 pklocalauthority /etc/polkit-1/localauthority/10-vendor.d/example-udisks.pkla [Local users] Identity=unix-group:plugdev Action=org.freedesktop.udisks.* ResultAny=yes ResultInactive=yes ResultActive=yes The above file would grant permission with or without active local ConsoleKit session to users in plugdev group to everything udisks handles. Notice that getting active ConsoleKit session you are now required to use PAM, or Display Manager like GDM with internal ConsoleKit support. Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y support enabled in kernel to get valid sessionid string and not all minor archs support this kernel option. Does the handbook mention this? We could have similar .pkla files also for other stuff like bluetooth, networkmanager, shutdown/reboot, suspend and hibernate (upower), and the list continues. The benefits are somewhat clear, things would work out of box for remote users beloging to right group, PAM-less users, as well as minor arches. The downside of this is that most users would propably end up using this as workaround for inactive ConsoleKit sessions that should really be local, but the user is just failing to configure his system in proper state to gain it (launching the X wrong way, wrong kernel opts, ...) As long as this is documented somewhere, I don't think users should have to screw with anything too much to get this stuff working. God knows I don't want to. And if we want this, should we stick to generalized plugdev group? Or perhaps group wheel for shutdown/reboot. Group storage for udisks. Group power for upower (hibernate, suspend). Group bluetooth for bluez. Group network for networkmanager? (Just throwing ideas...) So... any comments before I just pick what I think is best and commit the .pkla files (or not). I'm really 50-50 on this... Would like to get this decided before p.masking HAL.
[gentoo-dev] Council May Summary: Changes to ChangeLog handling
http://www.gentoo.org/proj/en/council/meeting-logs/20110510-summary.txt Please note that you must now update ChangeLog with each commit. For more information please see the meeting log and the preceding mailing list thread: http://www.gentoo.org/proj/en/council/meeting-logs/20110510.txt http://archives.gentoo.org/gentoo-dev/msg_eaefa325b31360324d0fe53d0b9071e6.xml On behalf of the council, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: RFC: Do we still want group based permissions for storage and power devices in light of ConsoleKit and Policykit?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 17-05-2011 00:20, Samuli Suominen wrote: On 05/17/2011 03:15 AM, Samuli Suominen wrote: Let's start with generalized example so everyone gets the idea... Reference: man 8 pklocalauthority /etc/polkit-1/localauthority/10-vendor.d/example-udisks.pkla [Local users] Identity=unix-group:plugdev Action=org.freedesktop.udisks.* ResultAny=yes ResultInactive=yes ResultActive=yes The above file would grant permission with or without active local ConsoleKit session to users in plugdev group to everything udisks handles. Notice that getting active ConsoleKit session you are now required to use PAM, or Display Manager like GDM with internal ConsoleKit support. Note that the PAM method requires you to have CONFIG_AUDITSYSCALL=y support enabled in kernel to get valid sessionid string and not all minor archs support this kernel option. We could have similar .pkla files also for other stuff like bluetooth, networkmanager, shutdown/reboot, suspend and hibernate (upower), and the list continues. The benefits are somewhat clear, things would work out of box for remote users beloging to right group, PAM-less users, as well as minor arches. The downside of this is that most users would propably end up using this as workaround for inactive ConsoleKit sessions that should really be local, but the user is just failing to configure his system in proper state to gain it (launching the X wrong way, wrong kernel opts, ...) And if we want this, should we stick to generalized plugdev group? Or perhaps group wheel for shutdown/reboot. Group storage for udisks. Group power for upower (hibernate, suspend). Group bluetooth for bluez. Group network for networkmanager?(Just throwing ideas...) So... any comments before I just pick what I think is best and commit the .pkla files (or not). I'm really 50-50 on this... Would like to get this decided before p.masking HAL. As others have already mentioned, I'd like to have the option to live without the *kit mess. One of the nice features about Linux, and Gentoo in particular, is being able to understand what's going on under the hood and the *kit movement seems to be about magic and not bothering users and not about being simple and clear. Futhermore I would like the baselayout package to create the groups decided here, be it wheel (already there), plugdev, or more fine grained storage/power ones. I think the distribution policy (be it the general consensus on this thread) on this should be reflected in there. And it's the most convinient place, then packages don't have to worry about creating them... just follow About baselayout default users, we should split this topic to another thread as the releng team also needs something along these lines to get new stages with bl2 / openrc to build[1]. [1] - https://bugs.gentoo.org/show_bug.cgi?id=53269 - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN0m8GAAoJEC8ZTXQF1qEPpJsP/iMIo0RSFAEerpPH+6Mi+5QP zrw26lCyX6palAFxFfthueF7hT9ARsLdJSx8p9ERMS7BBrmjKk8bnq20vm7kNcEC mcohegWYr5cxe51YofMjPwRTbhpSZRJYrjYeUGYz6xZ9X85LlON6UA6331KTcklb v1qewoalKn4lCKykBmd2xAj1ok4VshX4MgxtZJsMJY+eqWITUou6RYJfGOPYn/Hh qvNLDoxdlyszJeD6aCi5xLK2tLTVEfVKO718jBz4EKOOk2jatwDi8ojRCUYHS+Mp pBBdfvOivqgA1N1c9MOHf7z2vllVao5h/PckYJEwnff828SE6E9Ox/DdBbETBkfV jDCwKmec65kSJ4bVcCtr0d2QZcUNq57GX1mrCoaPHKRSETiEW1TCf4Fw2to0kbbo t9x5Je+sAs4yAHMnD5u1mnQqkNjXkJ5MS9GFPyoTYQ1rux5zsSRNWSs50/ihKjL4 QtHafz/xYUIoCM4bQ2jIuf+ZOxVJ0SLPwaeYQGWZQOteLDhtqBI7UpWAPQNUoRYv AxbgokNVwIcvhkjfi4iljKPPjD5jy5vlAUIPx1uanTIOE1ZdYsYg8fO0OxOhAz5H DS9b3xrXGednbBSuvsqygbnJKQQpD3r5ca4nXFz/1YjDOCq7OM0BjjzMRkaU0jk5 eGf9UkN3EHKkIm316Ges =UGFI -END PGP SIGNATURE-
Re: [gentoo-dev] Crossdev / glib news item
On 05/15/2011 09:24 PM, Andreas K. Huettel wrote: -- If you are cross-compiling to a 32-bit architecture such as ARM, or if you are using a 32-bit architecture and have sys-devel/crossdev installed, please be warned that - unless you follow the advice below - your system may become seriously broken. We have recently fixed bug 367351 in sys-devel/crossdev, where the size of the pthread_mutex_t type was hardwired incorrectly into configure scripts. Unfortunately, if the size was incorrect before, switching to the correct value changes the ABI of libgthread. All binaries linked against the previous glib may thus simply crash. You will have to ensure the ABI stability before upgrading crossdev. Information on how to fix this is available at the following URL: http://blog.flameeyes.eu/2011/05/15/ --- Opinions? Please post the full news item with headers. For example the filter headers are quite central. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] rfc: use of the /run directory
All, I think we should support the /run directory [1] [2]. The issue is that there are at least two packages, udev and dracut, in gentoo, which support the use of this directory. Support for it is being worked on in openrc, and systemd will use it once it comes into the tree. For now, it is optionally supported in udev, but udev upstream plans to make this mandatory at some point in the future. I, as well as several others, believe we should proactively create this directory in a new release of baselayout, so that we will avoid bugs in the future when packages start requiring it. What does everyone else think? William [1] https://lwn.net/Articles/436012/ [2] http://bugs.gentoo.org/show_bug.cgi?id=361349 pgp6LSzVtFxax.pgp Description: PGP signature
Re: [gentoo-dev] PyXML
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() Is this use_pyxml upstream? From what you are saying, it is not. In that case, we have just made patches for every package that will never be allowed upstream. Why not do something more worthwhile than waste the time of having to support something that might just become a problem to maintain in the future? -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
Re: [gentoo-dev] PyXML
On Tue, May 17, 2011 at 01:11:57PM -0400, Mark Loeser wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() Is this use_pyxml upstream? From what you are saying, it is not. In that case, we have just made patches for every package that will never be allowed upstream. Why not do something more worthwhile than waste the time of having to support something that might just become a problem to maintain in the future? -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com I second that. Why do we need to make all the work fixing packages instead of letting upstream do their job? I am not so excited to fix every package I maintain as it is quite possible to introduce regressions in the process. Furthermore, I don't understand your first message. You say that you will provide xml.use_pyxml() function on python-2.7. Is this code official or you are just patching the official python releases? Anyway, as I said, I'd rather wait for upstream to fix their packages instead of me. Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpg9ShUGrWb3.pgp Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
В Втр, 17/05/2011 в 11:57 -0500, William Hubbs пишет: I think we should support the /run directory [1] [2]. I, as well as several others, believe we should proactively create this directory ... What does everyone else think? I've read https://lwn.net/Articles/436012/ and that convinced me. Until there is better solution, please, do it. Also I think it's good idea if it'll be on tmpfs, as it should, from the very beginning. -- Peter.
Re: [gentoo-dev] PyXML
2011-05-17 19:32:23 Markos Chandras napisał(a): On Tue, May 17, 2011 at 01:11:57PM -0400, Mark Loeser wrote: Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() Is this use_pyxml upstream? From what you are saying, it is not. In that case, we have just made patches for every package that will never be allowed upstream. Why not do something more worthwhile than waste the time of having to support something that might just become a problem to maintain in the future? I second that. Why do we need to make all the work fixing packages instead of letting upstream do their job? I am not so excited to fix every package I maintain as it is quite possible to introduce regressions in the process. Furthermore, I don't understand your first message. You say that you will provide xml.use_pyxml() function on python-2.7. Is this code official or you are just patching the official python releases? Anyway, as I said, I'd rather wait for upstream to fix their packages instead of me. Some upstreams are dead and some packages using PyXML will never be ported by upstreams to use something else than PyXML (e.g. lxml). $ python2.7 Python 2.7.1+ (2.7:572fbd9ca28f+, May 16 2011, 21:40:05) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. import xml, _xmlplus xml_modules = set(xml.__all__) _xmlplus_modules = set(_xmlplus.__all__) xml_modules - _xmlplus_modules set(['etree']) _xmlplus_modules - xml_modules set(['xpath', 'utils', 'schema', 'marshal', 'xslt']) -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PyXML
Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: I second that. Why do we need to make all the work fixing packages instead of letting upstream do their job? I am not so excited to fix every package I maintain as it is quite possible to introduce regressions in the process. Furthermore, I don't understand your first message. You say that you will provide xml.use_pyxml() function on python-2.7. Is this code official or you are just patching the official python releases? Anyway, as I said, I'd rather wait for upstream to fix their packages instead of me. Some upstreams are dead and some packages using PyXML will never be ported by upstreams to use something else than PyXML (e.g. lxml). Then those packages should get removed from the tree. Do not start introducing Gentoo specific hacks to work around the problem. -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 11:41 PM, Peter Volkov p...@gentoo.org wrote: В Втр, 17/05/2011 в 11:57 -0500, William Hubbs пишет: I think we should support the /run directory [1] [2]. I, as well as several others, believe we should proactively create this directory ... What does everyone else think? I've read https://lwn.net/Articles/436012/ and that convinced me. Until there is better solution, please, do it. Also I think it's good idea if it'll be on tmpfs, as it should, from the very beginning. I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] PyXML
2011-05-17 19:11:57 Mark Loeser napisał(a): Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() Is this use_pyxml upstream? Python 2 is dead, so new features will never be added to Python 2 by Python upstream. Before addition of xml.use_pyxml(), if user had many packages installed, which use xml module, and 1 package installed, which needs PyXML, then the other packages were suffering from using old code with more bugs. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PyXML
2011-05-17 20:24:16 Mark Loeser napisał(a): Arfrever Frehtes Taifersar Arahesis arfre...@gentoo.org said: I second that. Why do we need to make all the work fixing packages instead of letting upstream do their job? I am not so excited to fix every package I maintain as it is quite possible to introduce regressions in the process. Furthermore, I don't understand your first message. You say that you will provide xml.use_pyxml() function on python-2.7. Is this code official or you are just patching the official python releases? Anyway, as I said, I'd rather wait for upstream to fix their packages instead of me. Some upstreams are dead and some packages using PyXML will never be ported by upstreams to use something else than PyXML (e.g. lxml). Then those packages should get removed from the tree. Do not start introducing Gentoo specific hacks to work around the problem. Majority of packages from http://tinderbox.dev.gentoo.org/misc/rindex/dev-python/pyxml seem to have active upstreams, which doesn't mean they are actively working on porting these packages to use something else than PyXML. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] PyXML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a): PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() This code works with previous versions of Python, so no changes in dependencies are needed. As I already asked, what problem do we have to keep PyXML in main tree to be used with python2. Your specific hack introduce different behaviour for python2.7.1-r2 where you do not explain the need for it at all. It is just python2 thing and we can happily use PyXML as it works even with latest python-2.7. So where is the problem? Failing python tests? Then patch PyXML itself to use it properly, but keep it as is. When app migrate to py3 they will have to loose the PyXML dependency anyway. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3SwdEACgkQHB6c3gNBRYenyACeOMsOpUJwgPLBeyAZtcHeVVAH j7sAn0B8f8/UINM4xVsws9xDsURrnYGj =H8Jw -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: use of the /run directory
On Tuesday 17 May 2011 20:28:56 Nirbheek Chauhan wrote: On Tue, May 17, 2011 at 11:41 PM, Peter Volkov p...@gentoo.org wrote: В Втр, 17/05/2011 в 11:57 -0500, William Hubbs пишет: I think we should support the /run directory [1] [2]. I, as well as several others, believe we should proactively create this directory ... What does everyone else think? I've read https://lwn.net/Articles/436012/ and that convinced me. Until there is better solution, please, do it. Also I think it's good idea if it'll be on tmpfs, as it should, from the very beginning. I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. The lwn article is definitely interesting to read, I welcome the new /run. I wouldn't make /tmp as tmpfs though, there are some packages (wireshask I'm looking at you) that can fill the directory fairly easy. Regards, -- Angelo Arrifano AKA MiKNiX Gentoo Embedded developer GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, May 18, 2011 at 12:13 AM, Ângelo Arrifano mik...@gentoo.org wrote: On Tuesday 17 May 2011 20:28:56 Nirbheek Chauhan wrote: I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. The lwn article is definitely interesting to read, I welcome the new /run. I wouldn't make /tmp as tmpfs though, there are some packages (wireshask I'm looking at you) that can fill the directory fairly easy. I wonder what Fedora and Ubuntnu do to fix that. Maybe we should do the same thing. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 11:58:56PM +0530, Nirbheek Chauhan wrote: On Tue, May 17, 2011 at 11:41 PM, Peter Volkov p...@gentoo.org wrote: В Втр, 17/05/2011 в 11:57 -0500, William Hubbs пишет: I think we should support the /run directory [1] [2]. I, as well as several others, believe we should proactively create this directory ... What does everyone else think? I've read https://lwn.net/Articles/436012/ and that convinced me. Until there is better solution, please, do it. Also I think it's good idea if it'll be on tmpfs, as it should, from the very beginning. I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. Once /run is in place, /var/run will be a symbolic link to /run and /var/lock will be a symbolic link to /run/lock. So that will cover /var/run. William pgpScc5KEIqLu.pgp Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
В Втр, 17/05/2011 в 20:43 +0200, Ângelo Arrifano пишет: On Tuesday 17 May 2011 20:28:56 Nirbheek Chauhan wrote: I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. The lwn article is definitely interesting to read, I welcome the new /run. I wouldn't make /tmp as tmpfs though, there are some packages (wireshask I'm looking at you) that can fill the directory fairly easy. Hm, may be I miss something... but how wireshark fills /run? As far as I see dumps go into /tmp. -- Peter.
Re: [gentoo-dev] PyXML
2011-05-17 20:43:29 Tomáš Chvátal napisał(a): Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a): PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() This code works with previous versions of Python, so no changes in dependencies are needed. As I already asked, what problem do we have to keep PyXML in main tree to be used with python2. Your specific hack introduce different behaviour for python2.7.1-r2 where you do not explain the need for it at all. I had already explained it in many places. It is just python2 thing and we can happily use PyXML as it works even with latest python-2.7. So where is the problem? Fixes for at least the following bugs are absent when PyXML is installed: http://bugs.python.org/issue4877 http://bugs.python.org/issue6098 http://bugs.python.org/issue5762 http://bugs.python.org/issue5027 http://bugs.python.org/issue9054 http://bugs.python.org/issue777884 http://bugs.python.org/issue1433694 http://bugs.python.org/issue847665 http://bugs.python.org/issue1472827 http://bugs.python.org/issue1094164 http://bugs.python.org/issue1309009 http://bugs.python.org/issue1262320 http://bugs.python.org/issue925152 -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: use of the /run directory
On Tuesday 17 May 2011 21:11:12 Peter Volkov wrote: В Втр, 17/05/2011 в 20:43 +0200, Ângelo Arrifano пишет: On Tuesday 17 May 2011 20:28:56 Nirbheek Chauhan wrote: I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. The lwn article is definitely interesting to read, I welcome the new /run. I wouldn't make /tmp as tmpfs though, there are some packages (wireshask I'm looking at you) that can fill the directory fairly easy. Hm, may be I miss something... but how wireshark fills /run? As far as I see dumps go into /tmp. -- Peter. Either one of us is needing a break away from the computer to relax the eyes, which one is it? :P -- Angelo Arrifano AKA MiKNiX Gentoo Embedded developer GPE maintainer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] rfc: use of the /run directory
On 23:58 Tue 17 May , Nirbheek Chauhan wrote: ... I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. Hi, A quick look at the size of my desktop's /tmp is: spirit@Vereniki ~ $ du -sh /tmp/ 641M/tmp/ spirit@Vereniki ~ $ Maybe it's just me (cause of the way I'm using /tmp, eg. I use that dir to unpack sources of packages I want to temporarily look inside and for anything else *temporary*, also some programs (eg. browsers) use it for temporary storage) but if there are others like me, I don't think we'd like to do this in RAM space (tmpfs). For /run and /var/run dirs it's ok I suppose. -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpczdEWGTyQt.pgp Description: PGP signature
Re: [gentoo-dev] PyXML
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 17.5.2011 21:12, Arfrever Frehtes Taifersar Arahesis napsal(a): 2011-05-17 20:43:29 Tomáš Chvátal napisał(a): Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a): PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() This code works with previous versions of Python, so no changes in dependencies are needed. As I already asked, what problem do we have to keep PyXML in main tree to be used with python2. Your specific hack introduce different behaviour for python2.7.1-r2 where you do not explain the need for it at all. I had already explained it in many places. It is just python2 thing and we can happily use PyXML as it works even with latest python-2.7. So where is the problem? Fixes for at least the following bugs are absent when PyXML is installed: http://bugs.python.org/issue4877 http://bugs.python.org/issue6098 http://bugs.python.org/issue5762 http://bugs.python.org/issue5027 http://bugs.python.org/issue9054 http://bugs.python.org/issue777884 http://bugs.python.org/issue1433694 http://bugs.python.org/issue847665 http://bugs.python.org/issue1472827 http://bugs.python.org/issue1094164 http://bugs.python.org/issue1309009 http://bugs.python.org/issue1262320 http://bugs.python.org/issue925152 2 options 1) fix PyXML 2) drop all packages including PyXML Altering system package is not the option. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3SyswACgkQHB6c3gNBRYcoHQCfbfQ/s7YQ2vJanRJ7JFppaE28 oWMAnicY/HXe2RQF+anhOLQ4pBj6aP0i =xauv -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 10:20:56PM +0300, Panagiotis Christopoulos wrote: On 23:58 Tue 17 May , Nirbheek Chauhan wrote: ... I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. Hi, A quick look at the size of my desktop's /tmp is: spirit@Vereniki ~ $ du -sh /tmp/ 641M /tmp/ spirit@Vereniki ~ $ Maybe it's just me (cause of the way I'm using /tmp, eg. I use that dir to unpack sources of packages I want to temporarily look inside and for anything else *temporary*, also some programs (eg. browsers) use it for temporary storage) but if there are others like me, I don't think we'd like to do this in RAM space (tmpfs). For /run and /var/run dirs it's ok I suppose. If you want /tmp to be a tmpfs, that is pretty easy to do through fstab (I do that here actually). I'm not sure whether we want to force that on a distribution level or not though. The directories that would be affected by having /run on tmpfs would be /var/run and /var/lock. The suggested way of doing this is to have /var/run linked to /run and /var/lock linked to /run/lock. William pgpCsw5QUlPJc.pgp Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, May 18, 2011 at 12:50 AM, Panagiotis Christopoulos pchr...@gentoo.org wrote: On 23:58 Tue 17 May , Nirbheek Chauhan wrote: ... I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. Hi, A quick look at the size of my desktop's /tmp is: spirit@Vereniki ~ $ du -sh /tmp/ 641M /tmp/ spirit@Vereniki ~ $ Maybe it's just me (cause of the way I'm using /tmp, eg. I use that dir to unpack sources of packages I want to temporarily look inside and for anything else *temporary*, also some programs (eg. browsers) use it for temporary storage) but if there are others like me, I don't think we'd like to do this in RAM space (tmpfs). For /run and /var/run dirs it's ok I suppose. Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, 2011-05-18 at 01:18 +0530, Nirbheek Chauhan wrote: Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. Having /tmp and /var/tmp as tmpfs sounds like a terrible idea.. I don't think we should facilitate it in any way. -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 17 May 2011 16:00:41 -0400 Olivier Crête tes...@gentoo.org wrote: On Wed, 2011-05-18 at 01:18 +0530, Nirbheek Chauhan wrote: Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. Having /tmp and /var/tmp as tmpfs sounds like a terrible idea.. I don't think we should facilitate it in any way. I always thought we're having two separate temporary directories because /tmp is for small data (i.e. suitable for tmpfs) while /var/tmp is for larger one. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
Excerpts from Olivier Crête's message of Tue May 17 22:00:41 +0200 2011: On Wed, 2011-05-18 at 01:18 +0530, Nirbheek Chauhan wrote: Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. Having /tmp and /var/tmp as tmpfs sounds like a terrible idea.. I don't think we should facilitate it in any way. I think he just meant that /var/tmp should be used for bigger temporary stuff. This how I use it. /tmp for tiny temporary stuff and /var/tmp/ for bigger which would be good to have preserved between reboots. And this is somehow correct with FHS afaik. -- Amadeusz Żołnowski PGP key fpr: C700 CEDE 0C18 212E 49DA 4653 F013 4531 E1DB FAB5 signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On 01:18 Wed 18 May , Nirbheek Chauhan wrote: ... Maybe you should use /var/tmp for that? Or ~/tmp/ ? Yes, I can do that. But the real question here, from my perspective, is why we need /run, /var/run or /tmp on tmpfs. Other distros do it is not an answer. Yes, I needed those dirs on tmpfs twice in my life, once when I was building a cluster with diskless nodes (with / on readonly NFS) and once more when I was working with an LTSP alike system, but these were exceptions, at that time. As I don't have the knowledge for this and I currently don't have the time to google/search it myself, can someone explain why other linux distibutions / Unix systems (wikipedia says that Solaris had /tmp on tmpfs from 1994) started putting directories on tmpfs and technically speaking what an average user would benefit from having /run, /tmp etc. directories on tmpfs? -- Panagiotis Christopoulos ( pchrist ) ( Gentoo Lisp Project ) pgpXFaaaXSwyW.pgp Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
2011/5/17 Olivier Crête tes...@gentoo.org: On Wed, 2011-05-18 at 01:18 +0530, Nirbheek Chauhan wrote: Maybe you should use /var/tmp for that? Or ~/tmp/ ? OTOH, we could use an rc.conf configuration variable to control whether /tmp is mounted as tmpfs. Having /tmp and /var/tmp as tmpfs sounds like a terrible idea.. I don't think we should facilitate it in any way. I've run my system this way for ages - even back when I had 2GB of RAM running kde, samba, mythtv, mysql, and apache. Usually not a problem. Unfortunately the kernel swapping logic isn't perfect, which can cause it to bog down if you're compiling something like chromium or openoffice. When you think about it tmpfs on swap should be no slower than ext3. If anything it should be faster since it doesn't need to journal. In practice it doesn't always work this way, but I'd consider this a bug. With a filesystem, anything you write ends up on disk within 30 seconds or whatever. With a tmpfs, some of the stuff you write ends up on disk, and the kernel has more freedom with how it goes about doing this. Then problem comes when the kernel decides to swap out mysql or whatever in order to hang onto some pages full of .so files or whatever from your latest build. Rich
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 17 May 2011 23:20:59 +0300 Panagiotis Christopoulos pchr...@gentoo.org wrote: As I don't have the knowledge for this and I currently don't have the time to google/search it myself, can someone explain why other linux distibutions / Unix systems (wikipedia says that Solaris had /tmp on tmpfs from 1994) started putting directories on tmpfs and technically speaking what an average user would benefit from having /run, /tmp etc. directories on tmpfs? For me, the most important advantage is that files get removed whenever the system crashes for some reason. It's just simpler (and more error prone) to have them gone automagically than to add services to remove all of them on each boot. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
WH == William Hubbs willi...@gentoo.org writes: WH Once /run is in place, WH /var/run will be a symbolic link to /run and /var/lock will WH be a symbolic link to /run/lock. There are files which need to be in /var/lock and which should survive a reboot, so it is not a good idea to make /var/lock a symlink to /run/lock. (And I don't just mean .keep files.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 04:35:00PM -0400, James Cloos wrote: WH == William Hubbs willi...@gentoo.org writes: WH Once /run is in place, WH /var/run will be a symbolic link to /run and /var/lock will WH be a symbolic link to /run/lock. There are files which need to be in /var/lock and which should survive a reboot, so it is not a good idea to make /var/lock a symlink to /run/lock. (And I don't just mean .keep files.) -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6 James, Can you please provide some examples that require /var/lock to survive a reboot? Regards, -- Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 pgpFHIROhLSPu.pgp Description: PGP signature
Re: [gentoo-dev] PyXML
2011-05-17 21:21:48 Tomáš Chvátal napisał(a): Dne 17.5.2011 21:12, Arfrever Frehtes Taifersar Arahesis napsal(a): 2011-05-17 20:43:29 Tomáš Chvátal napisał(a): Dne 10.5.2011 23:21, Arfrever Frehtes Taifersar Arahesis napsal(a): PyXML is dead: http://mail.python.org/pipermail/xml-sig/2004-November/010735.html http://mail.python.org/pipermail/xml-sig/2006-June/011545.html PyXML provides _xmlplus module, which replaces xml module (from standard library) at run time, which might result in various problems. I'm planning to implement the following solution: - Python =2.7.1-r2:2.7 will provide xml.use_pyxml() function. Calling of this function will be necessary to use replace xml module with _xmlplus module. Python =2.7.1-r2:2.7 will be added to the tree in next week and will be temporarily package.masked. Later this change will be backported to new versions in older slots. - All packages, which use PyXML, will have to be patched to call xml.use_pyxml(). The following code should be added before first import of anything from xml module: import xml if hasattr(xml, use_pyxml): xml.use_pyxml() This code works with previous versions of Python, so no changes in dependencies are needed. As I already asked, what problem do we have to keep PyXML in main tree to be used with python2. Your specific hack introduce different behaviour for python2.7.1-r2 where you do not explain the need for it at all. I had already explained it in many places. It is just python2 thing and we can happily use PyXML as it works even with latest python-2.7. So where is the problem? Fixes for at least the following bugs are absent when PyXML is installed: http://bugs.python.org/issue4877 http://bugs.python.org/issue6098 http://bugs.python.org/issue5762 http://bugs.python.org/issue5027 http://bugs.python.org/issue9054 http://bugs.python.org/issue777884 http://bugs.python.org/issue1433694 http://bugs.python.org/issue847665 http://bugs.python.org/issue1472827 http://bugs.python.org/issue1094164 http://bugs.python.org/issue1309009 http://bugs.python.org/issue1262320 http://bugs.python.org/issue925152 2 options 1) fix PyXML 2) drop all packages including PyXML Altering system package is not the option. Changing of any package is always an option, when given change fixes or works around a problem and its benefits outweigh costs. The patches for about 20 packages will be easy to maintain, since there is easy algorithm of generation of these patches (addition of constant 3-line code before first import of xml module). -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 2011-05-17 at 23:20 +0300, Panagiotis Christopoulos wrote: Yes, I can do that. But the real question here, from my perspective, is why we need /run, /var/run or /tmp on tmpfs. Other distros do it is not an answer. The main reason is that you want /run to be writable super early in the boot process, before even / has been fscked and re-mounted. That means you can do stuff like starting udevd in parallel with fsck of / which means faster boot. This is one of the things required to get 1 second boot. See http://lwn.net/Articles/436012/ -- Olivier Crête tes...@gentoo.org Gentoo Developer signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] rfc: use of the /run directory
2011/5/18 Olivier Crête tes...@gentoo.org: On Tue, 2011-05-17 at 23:20 +0300, Panagiotis Christopoulos wrote: Yes, I can do that. But the real question here, from my perspective, is why we need /run, /var/run or /tmp on tmpfs. Other distros do it is not an answer. The main reason is that you want /run to be writable super early in the boot process, before even / has been fscked and re-mounted. That means you can do stuff like starting udevd in parallel with fsck of / which means faster boot. This is one of the things required to get 1 second boot. See http://lwn.net/Articles/436012/ Related is that you don't need to manually wipe /tmp /var/run /var/lock via a service. They're automatically wiped when you reboot. This saves time during bootup. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
Nirbheek Chauhan nirbh...@gentoo.org wrote: 2011/5/18 Olivier Cr??te tes...@gentoo.org: The main reason is that you want /run to be writable super early in the boot process, before even / has been fscked and re-mounted. That means you can do stuff like starting udevd in parallel with fsck of / which means faster boot. This is one of the things required to get 1 second boot. See http://lwn.net/Articles/436012/ Related is that you don't need to manually wipe /tmp /var/run /var/lock via a service. They're automatically wiped when you reboot. This saves time during bootup. Even if you don't have to wipe them with a service, you're going to need to mount them with a service. You'll need to mount /run as tmpfs, create the /run/lock directory, and then mount /run/lock as tmpfs. Do you really want to add that to localmount? -- Confucius is inscrutable. God is ineffable. Beer is inevitable.
Re: [gentoo-dev] rfc: use of the /run directory
* Drake Wyrm schrieb am 18.05.11 um 00:26 Uhr: Nirbheek Chauhan nirbh...@gentoo.org wrote: 2011/5/18 Olivier Cr??te tes...@gentoo.org: The main reason is that you want /run to be writable super early in the boot process, before even / has been fscked and re-mounted. That means you can do stuff like starting udevd in parallel with fsck of / which means faster boot. This is one of the things required to get 1 second boot. See http://lwn.net/Articles/436012/ Related is that you don't need to manually wipe /tmp /var/run /var/lock via a service. They're automatically wiped when you reboot. This saves time during bootup. Even if you don't have to wipe them with a service, you're going to need to mount them with a service. You'll need to mount /run as tmpfs, create the /run/lock directory, and then mount /run/lock as tmpfs. Do you really want to add that to localmount? Why mount /run/lock as tmpfs? If its created within /run its already tmpfs -Marc -- 8AAC 5F46 83B4 DB70 8317 3723 296C 6CCA 35A6 4134
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, May 18, 2011 at 3:56 AM, Drake Wyrm w...@haell.com wrote: Nirbheek Chauhan nirbh...@gentoo.org wrote: Even if you don't have to wipe them with a service, you're going to need to mount them with a service. You'll need to mount /run as tmpfs, create the /run/lock directory, and then mount /run/lock as tmpfs. Do you really want to add that to localmount? (a) You don't need to mount anything except /run (b) Creating a directory in tmpfs takes so little time it's not even worth measuring. The same cannot be said of rotating media. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 17 May 2011 11:57:48 -0500 William Hubbs willi...@gentoo.org wrote: I think we should support the /run directory [1] [2]. I would be interested to hear how you plan to do the migration, given that everyone else has managed to screw it up... -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 03:26:11PM -0700, Drake Wyrm wrote: Nirbheek Chauhan nirbh...@gentoo.org wrote: 2011/5/18 Olivier Cr??te tes...@gentoo.org: The main reason is that you want /run to be writable super early in the boot process, before even / has been fscked and re-mounted. That means you can do stuff like starting udevd in parallel with fsck of / which means faster boot. This is one of the things required to get 1 second boot. See http://lwn.net/Articles/436012/ Related is that you don't need to manually wipe /tmp /var/run /var/lock via a service. They're automatically wiped when you reboot. This saves time during bootup. Even if you don't have to wipe them with a service, you're going to need to mount them with a service. You'll need to mount /run as tmpfs, create the /run/lock directory, and then mount /run/lock as tmpfs. Do you really want to add that to localmount? Actually the code to do this is already in openrc git, and it is much earlier than localmount. Also, you don't need a separate tmpfs for /run/lock since /run is already tmpfs. William pgpeErzEqWrMD.pgp Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
MC == Markos Chandras hwoar...@gentoo.org writes: MC Can you please provide some examples that require /var/lock to MC survive a reboot? Not everything is part of the distribution. The one which first comes to mind are lock files placed to prevent certain cron-initiated jobs from running right after a reboot. Or locks preventing certain daemons from accepting connections. Such locks often are used to protect net bandwidth when it is needed for real-time use. A reboot of some random box on the lan should not break such locks. And /var/lock is the standard place to put and look for lock files. Got to run; can't contiue to write right now -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 11:50:32PM +0100, Ciaran McCreesh wrote: On Tue, 17 May 2011 11:57:48 -0500 William Hubbs willi...@gentoo.org wrote: I think we should support the /run directory [1] [2]. I would be interested to hear how you plan to do the migration, given that everyone else has managed to screw it up... I'm not sure what you mean here. Openrc git will mount a tmpfs on /run if it exists and create a lock directory inside the tmpfs. To make it work, I just need a new release of baselayout to make the /run directory. Then, I also need to figure out where in the boot process to make the symbolic links from /var/lock to /run/lock and from /var/run to /run. what else am I missing? William pgp6j9ObSYXp0.pgp Description: PGP signature
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, May 17, 2011 at 08:06:46PM -0400, James Cloos wrote: MC == Markos Chandras hwoar...@gentoo.org writes: MC Can you please provide some examples that require /var/lock to MC survive a reboot? Not everything is part of the distribution. The one which first comes to mind are lock files placed to prevent certain cron-initiated jobs from running right after a reboot. Or locks preventing certain daemons from accepting connections. Such locks often are used to protect net bandwidth when it is needed for real-time use. A reboot of some random box on the lan should not break such locks. According to what I am reading in the fhs, /var/lock is not sharable between multiple systems. Also, the contents of the lock file is supposed to be the pid of the process that holds the lock [1]. Given that, a lock will automatically be invalid when you reboot, so it should be forgotten about on a reboot. William [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES pgpLHHQsLku6r.pgp Description: PGP signature
[gentoo-dev] Genkernel needs more hands
Hello, Genkernel's situation (reduced to the three currently most active players) looks like this to me: - aidecoe - is focussed on the transition to Dracut and related things - is fixing bugs in present genkernel from time to time - xake - is fixing bugs in the current genkernel releases - likes his patches to be reviewed - cannot do releases as he has no developer account, yet - sping (me) - writes and applies patches from time to time. (Commitment varies, at a low right now.) - has never used half of the many technologies involved himself (iSCSI, dmraid, netboot, ...) - is the bottleneck on some reviews and releases There are various bugs around, some just need attention, some could use insider knowledge that we lack. Furthermore the kernel configs shipped by Genkernel are mainly from a time before the three of us took over and need fixes, a concept and documentation too. There is no test suite (virtual machines?) that I knew of catching regressions (of which we had few only, in that light). Nevertheless genkernel has fun aspects: it's in much better shape than 3.4.10.907 was, including documentation. It's a core Gentoo tool used by quite a few people so the work you do on Genkernel matters. With that in mind: Are you interested in joining Genkernel? Thanks, Sebastian
[gentoo-dev] Re: rfc: use of the /run directory
William Hubbs posted on Tue, 17 May 2011 14:46:49 -0500 as excerpted: On Tue, May 17, 2011 at 10:20:56PM +0300, Panagiotis Christopoulos wrote: On 23:58 Tue 17 May, Nirbheek Chauhan wrote: ... I'd add that if we want /run to be on tmpfs, /var/run and /tmp should both be on tmpfs by default. I've been doing this manually for a year, and so have other distributions. If you want /tmp to be a tmpfs, that is pretty easy to do through fstab (I do that here actually). I'm not sure whether we want to force that on a distribution level or not though. The directories that would be affected by having /run on tmpfs would be /var/run and /var/lock. The suggested way of doing this is to have /var/run linked to /run and /var/lock linked to /run/lock. Absolutely true. I've run /tmp on tmpfs (with /var/tmp a symlink to it tho that took a bit of additional setup) for some time now and love it, but it's easy enough to do for those that want it that way, and controversial enough for others that IMO Gentoo doesn't need to get into that policy game, /especially/ not when it unnecessarily complicates the otherwise entirely separate /run discussion. So let's leave /tmp (and /var/tmp) well enough alone and concentrate on the subject at hand, /run and the /var/run symlinks to it. Since I'm posting, I'd personally prefer keeping things pretty much as they are, or arguably creating a /dev/run for the same benefits without a new root directory. But I'm resigned to the fact that what will be will be, and /run seems to have enough momentum behind it that it will be. Given that, we might as well get it over with and get /run in place now, before our lack of it starts causing serious problems and we have to develop workarounds that must then be undone when we finally /do/ break down and go with /run. So reluctantly... but I say go for it. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] rfc: use of the /run directory
On Tue, 17 May 2011 14:46:49 -0500 William Hubbs willi...@gentoo.org wrote: The directories that would be affected by having /run on tmpfs would be /var/run and /var/lock. The suggested way of doing this is to have /var/run linked to /run and /var/lock linked to /run/lock. wrt /var/run on tmpfs, I recall packages installing daemons that expect their specific directories to be present in /var/run, and that do not play nice when that directory turns out empty, but we should be able to work around that by creating the directory in the init.d script before we execute the daemon. jer
Re: [gentoo-dev] rfc: use of the /run directory
On Wed, May 18, 2011 at 03:36:48AM +0200, Jeroen Roovers wrote: wrt /var/run on tmpfs, I recall packages installing daemons that expect their specific directories to be present in /var/run, and that do not play nice when that directory turns out empty, but we should be able to work around that by creating the directory in the init.d script before we execute the daemon. Yes. Some examples: https://bugs.gentoo.org/show_bug.cgi?id=332633 https://bugs.gentoo.org/show_bug.cgi?id=334245 https://bugs.gentoo.org/show_bug.cgi?id=334437 https://bugs.gentoo.org/show_bug.cgi?id=342049 https://bugs.gentoo.org/show_bug.cgi?id=333783 Basically, if we are going to to do the move to /run, we should have a policy of /var/run and /var/lock can and will be on tmpfs and init scripts should handle this correctly or something similar. -- Eray Aslan Developer, Gentoo Linux eras at gentoo.org pgpq76fWyxOul.pgp Description: PGP signature
