[gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? FWIW... I run a monolithic kernel here, no modules /to/ load. As a result, for quite some time I had module-init-tools in package.provided, because I really didn't need it at all. Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. But it was required to build, just because someone decided people had no valid reason to run a monolithic kernel system any longer, and that people who did so apparently no longer mattered, udev-wise. That's only one such decision of a whole list following a similar pattern, simply deciding that some segment of the Linux-using populace or another no longer matters, because it's not the segment that the udev folks are focused on. In many cases, they've already said they're not interested in patches resolving the issues, too. Thus, no, submitting the patches for inclusion upstream isn't working. Seems reason enough for a fork, to me. Back on subtopic, yes, I'm definitely interested in a udev fork that doesn't force the otherwise useless on my systems kmod as a build-time dep. package.provided worked for years as a workaround for the module- init-tools @system dep. And I'd like to get back to not having to have a module-loader package installed at all, since I don't have any modules to load anyway. -- 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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote: On 05/09/2012 06:36 PM, Greg KH wrote: On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote: I foresee a new udev fork then. Please feel free to do so, the code has been open since the first day I created it. Remember, forks are good, there's nothing wrong with them, I strongly encourage people to do them if they wish to, it benefits everyone involved. If udev is going to end up like avahi is, this is *highly* probable. That's an odd transition... With avahi is ... I actually mean, one single tarball blob depending on the whole world and its solar system and galaxy. Hyperbole, how nice :( Please stop throwing lennartware at people. FailAudio has been enough, thanks. The use of these terms is both rude and totally uncalled for. You should be ashamed of yourself. Seriously, that's unacceptable behavior from anyone. No one forces you to use any of this software if you do not want to. There are lots of other operating systems out there, feel free to switch to them if you do not like the way this one is working out, no one is stopping you. But for you to disparage someone who has given immense bodies of work to the community, and you, for free, is horrible behavior and needs to stop right now. greg k-h Greg, would you clarify what you meant by this? Meant by what part of the above response? Written 6 months ago? Your recent comments suggest to me that you did not mean what I thought you meant. What did you think I meant about what? Again, I have no objection to people forking projects, it's great, and fun to watch happen. Fork away on your own site, with whom ever you want to. But if this fork is now the official Gentoo fork, owned by the Gentoo Foundation, and it's the way forward that Gentoo the distro is going to take with regards to how the boot process works on the system, then I have something to say about it, as it affects me, a Gentoo developer. And that is how this thread started, I wanted to know what was the resolution of the council meeting with the very unclear and vague meeting minutes. I have yet to get that answer, which is troubling. thanks, greg k-h
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 11/18/2012 03:08 AM, Greg KH wrote: On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote: On 05/09/2012 06:36 PM, Greg KH wrote: On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote: I foresee a new udev fork then. Please feel free to do so, the code has been open since the first day I created it. Remember, forks are good, there's nothing wrong with them, I strongly encourage people to do them if they wish to, it benefits everyone involved. If udev is going to end up like avahi is, this is *highly* probable. That's an odd transition... With avahi is ... I actually mean, one single tarball blob depending on the whole world and its solar system and galaxy. Hyperbole, how nice :( Please stop throwing lennartware at people. FailAudio has been enough, thanks. The use of these terms is both rude and totally uncalled for. You should be ashamed of yourself. Seriously, that's unacceptable behavior from anyone. No one forces you to use any of this software if you do not want to. There are lots of other operating systems out there, feel free to switch to them if you do not like the way this one is working out, no one is stopping you. But for you to disparage someone who has given immense bodies of work to the community, and you, for free, is horrible behavior and needs to stop right now. greg k-h Greg, would you clarify what you meant by this? Meant by what part of the above response? Written 6 months ago? Your recent comments suggest to me that you did not mean what I thought you meant. What did you think I meant about what? Again, I have no objection to people forking projects, it's great, and fun to watch happen. Fork away on your own site, with whom ever you want to. But if this fork is now the official Gentoo fork, owned by the Gentoo Foundation, and it's the way forward that Gentoo the distro is going to take with regards to how the boot process works on the system, then I have something to say about it, as it affects me, a Gentoo developer. And that is how this thread started, I wanted to know what was the resolution of the council meeting with the very unclear and vague meeting minutes. I have yet to get that answer, which is troubling. thanks, greg k-h You are the one claiming that this is our official fork. None of us are. This will be an official Gentoo project when we make the announcement in the next few days. That makes it one project of many. GLEP 0039 clearly states how this works. If you are unhappy with GLEP 0039, then you should discuss that with the council. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote: You are the one claiming that this is our official fork. None of us are. It's on the Gentoo github site, and it has the Gentoo Foundation copyright all over all of the files in one of the branches, reviewed by you. I think I would be pretty foolish if I somehow thought it was _not_ an official fork :) This will be an official Gentoo project when we make the announcement in the next few days. That makes it one project of many. GLEP 0039 clearly states how this works. If you are unhappy with GLEP 0039, then you should discuss that with the council. I fail to see how 0039 has to do with this, please explain. I also don't see the copyright issue here, nor do I see where the decision of the council was made. Again, that's my original question, What is the decision of the council regarding this issue? thanks, greg k-h
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/2012 00:08, Greg KH wrote: But if this fork is now the official Gentoo fork, owned by the Gentoo Foundation, and it's the way forward that Gentoo the distro is going to take with regards to how the boot process works on the system, then I have something to say about it, as it affects me, a Gentoo developer. Please note that I would be the first one, from a QA point of view, to raise a huge question mark if somebody is planning to make this the default anytime soon. You want to keep it around as an option? Sure, feel free. Moving as default? Over my dead public key. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 11/18/2012 03:19 AM, Greg KH wrote: On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote: You are the one claiming that this is our official fork. None of us are. It's on the Gentoo github site, and it has the Gentoo Foundation copyright all over all of the files in one of the branches, reviewed by you. I think I would be pretty foolish if I somehow thought it was _not_ an official fork :) This will be an official Gentoo project when we make the announcement in the next few days. That makes it one project of many. GLEP 0039 clearly states how this works. If you are unhappy with GLEP 0039, then you should discuss that with the council. I fail to see how 0039 has to do with this, please explain. I also don't see the copyright issue here, nor do I see where the decision of the council was made. Again, that's my original question, What is the decision of the council regarding this issue? thanks, greg k-h I am sick of the harassment that I have received from you and a few others both in public and in private. The public branch has been deleted. Come back after we have done our first release. Otherwise, leave us alone. That is all that I have to say. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote: On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote: You are the one claiming that this is our official fork. None of us are. It's on the Gentoo github site, and it has the Gentoo Foundation copyright all over all of the files in one of the branches, reviewed by you. I think I would be pretty foolish if I somehow thought it was _not_ an official fork :) Oh, and the README file says it is a Gentoo project: This is a Gentoo sponsored project and testing is currently being done with openrc. However, we aim to be distro neutral and welcome contribution from others using a variety of system initializations. We also aim towards POSIX compliance. So why would I think otherwise? thanks, greg k-h
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
El dom, 18-11-2012 a las 00:27 -0800, Greg KH escribió: On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote: On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote: You are the one claiming that this is our official fork. None of us are. It's on the Gentoo github site, and it has the Gentoo Foundation copyright all over all of the files in one of the branches, reviewed by you. I think I would be pretty foolish if I somehow thought it was _not_ an official fork :) Oh, and the README file says it is a Gentoo project: This is a Gentoo sponsored project and testing is currently being done with openrc. However, we aim to be distro neutral and welcome contribution from others using a variety of system initializations. We also aim towards POSIX compliance. So why would I think otherwise? thanks, greg k-h Looks like we think different about what a Gentoo project means, lets read: http://devmanual.gentoo.org/general-concepts/herds-and-projects/index.html That would explain why both, eudev and systemd Gentoo projects can coexist: http://www.gentoo.org/proj/en/base/systemd/index.xml 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]
On 18/11/12 10:21, Diego Elio Pettenò wrote: On 18/11/2012 00:08, Greg KH wrote: But if this fork is now the official Gentoo fork, owned by the Gentoo Foundation, and it's the way forward that Gentoo the distro is going to take with regards to how the boot process works on the system, then I have something to say about it, as it affects me, a Gentoo developer. Please note that I would be the first one, from a QA point of view, to raise a huge question mark if somebody is planning to make this the default anytime soon. You want to keep it around as an option? Sure, feel free. Moving as default? Over my dead public key. Amen.
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:06 AM, Duncan 1i5t5.dun...@cox.net wrote: Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? FWIW... I run a monolithic kernel here, no modules /to/ load. As a result, for quite some time I had module-init-tools in package.provided, because I really didn't need it at all. Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. But it was required to build, just because someone decided people had no valid reason to run a monolithic kernel system any longer, and that people who did so apparently no longer mattered, udev-wise. That's only one such decision of a whole list following a similar pattern, simply deciding that some segment of the Linux-using populace or another no longer matters, because it's not the segment that the udev folks are focused on. In many cases, they've already said they're not interested in patches resolving the issues, too. Thus, no, submitting the patches for inclusion upstream isn't working. Seems reason enough for a fork, to me. Back on subtopic, yes, I'm definitely interested in a udev fork that doesn't force the otherwise useless on my systems kmod as a build-time dep. package.provided worked for years as a workaround for the module- init-tools @system dep. And I'd like to get back to not having to have a module-loader package installed at all, since I don't have any modules to load anyway. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K/var/tmp/portage/sys-apps/kmod-11-r1/image/
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 18/11/12 07:19, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? Exactly what I had in mind. So far I see bunch of regressions (back to bundling code :() in the eudev repository and more it deviates from the orig. upstream the less attractive it's looking... What should be done, at most, is to cherry-pick and revert the things that killed the sep. /usr support, put it behind an USE flag to the current udev's ebuild, perhaps IUSE=+vanilla, and be done with it. - Samuli
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 10:29 AM, Greg KH gre...@gentoo.org wrote: I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) As I posted elsewhere, working on a project based on hate only lasts so long. I should know, that's the reason I started udev in the first place over 9 years ago[1]. [1] Long story, best told over beers, take me up on it the next time you see me, I'll buy. Not everybody can have a chance to have a beer with you. Would you mind spending maybe an hour to write it down and share it with everybody? -- Duy
[gentoo-dev] net-misc/openconnect up for grabs
As talked with Dagger via mail, feel free to get it Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
El dom, 18-11-2012 a las 11:13 +0200, Samuli Suominen escribió: On 18/11/12 07:19, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? Exactly what I had in mind. So far I see bunch of regressions (back to bundling code :() in the eudev repository and more it deviates from the orig. upstream the less attractive it's looking... What should be done, at most, is to cherry-pick and revert the things that killed the sep. /usr support, put it behind an USE flag to the current udev's ebuild, perhaps IUSE=+vanilla, and be done with it. - Samuli +1 @eudev maintainers, Wouldn't that be possible? signature.asc Description: This is a digitally signed message part
[gentoo-dev] Apache team is inactive
apache team is currently composed by nelchael (that is inactive since May 2012) and trapni (that is not taking care of that packages) If you are interested please join. If it's still inactive in next week, I will assign apache bugs to maintainer-needed (I am still unsure about if, in that case, apache herd should be kept in CC for an hypothetical future resurrection or the herd should be dropped entirely) signature.asc Description: This is a digitally signed message part
[gentoo-dev] lastrite: dev-vcs/gitosis, dev-vcs/gitosis-gentoo (dead upstream)
# Robin H. Johnson robb...@gentoo.org (18 Nov 2012) # Dead upstream, replaced by gitolite dev-vcs/gitosis dev-vcs/gitosis-gentoo -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
[gentoo-dev] Some trapni packages up for grabs
As Trapni is not taking care of them at all, we (retirement team) decided to drop him from their maintainership to reflect reality and give others the opportunity to know they need a maintainer and get them if possible: media-sound/teamspeak-server-bin - assigned not to proxy-maint as looks some users want to take care of it media-sound/teamspeak-client-bin sys-apps/newrelic-sysmond signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 04:48 AM, Pacho Ramos wrote: El dom, 18-11-2012 a las 11:13 +0200, Samuli Suominen escribió: On 18/11/12 07:19, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? Exactly what I had in mind. So far I see bunch of regressions (back to bundling code :() in the eudev repository and more it deviates from the orig. upstream the less attractive it's looking... What should be done, at most, is to cherry-pick and revert the things that killed the sep. /usr support, put it behind an USE flag to the current udev's ebuild, perhaps IUSE=+vanilla, and be done with it. - Samuli +1 @eudev maintainers, Wouldn't that be possible? What began as me experimenting and moving code around to see what was the best approach to begin addressing several issues has suddenly turned into a war. Pacho, I am not sure whether it is possible or the best way to proceed. I say that with neutrality because I haven't figured out everything that's there. The two edged sword here is that, while I want to do the thinking out loud where people can see what I'm considering in code changes and participate, I opened the flood gate for a lot of anger. I woke up to see the name of the repo changed and a legal threats being thrown around. I know that by my very sending of this email, I will have a lot of CC's coming back at me with criticisms about things I didn't know I had even taken a stand on. There is one pressing issue though. It is my understanding that the council would like to see where this gets in one months time and stayed off a vote on udev. There are strong feelings for openrc and a systemd-less udev. These will not go away irrespective of this project. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 8040 5A4D 8709 21B1 1A88 33CE 979C AF40 D045 5535 GnuPG ID : D0455535
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
By the way, Diego, what is you current point of view on Gentoo default init system? i.e., what do you personally prefer to see as default init here: SystemD or OpenRC? [Just asking because all you angry answers to some devs make me think that you're on SysD side, when tons of Gentoo users and Gentoo devs are on non-SysD-related udev side.] And, if anyone is interested in my opinion: I *HATE* when somebody (will it be distro maintainers or RedHat corporation) forcing me their opinion on _what_ should I use and _how_ should I use this. Thats why I hate Ubuntu, Debian, CentOS, RHEL, SuSE and so on. Thats why I'm using Gentoo and Gentoo-derivatives (Sabayon, for example) for almost 10 years. Thats why I am an evangelist of Gentoo and it's derivatives. More of that, thats why Daniel Robbins created Gentoo itself. So, I really hope, that Gentoo will not obey RedHat's will and will not force SystemD as default init system, and not drop pretty OpenRC to trash. And I hope, that ryao's eudev will be most used (if not default) variant of udev, since I'm sad with last vanilla udev functionality downgrades. -- Best, mva 18.11.2012 15:21, Diego Elio Pettenò пишет: On 18/11/2012 00:08, Greg KH wrote: But if this fork is now the official Gentoo fork, owned by the Gentoo Foundation, and it's the way forward that Gentoo the distro is going to take with regards to how the boot process works on the system, then I have something to say about it, as it affects me, a Gentoo developer. Please note that I would be the first one, from a QA point of view, to raise a huge question mark if somebody is planning to make this the default anytime soon. You want to keep it around as an option? Sure, feel free. Moving as default? Over my dead public key. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Reminder: open season on robbat2's packages
Over the years, I've come to be the maintainer a huge number of packages (~300 or so, and I just gave up ~100 of those back to relevant herds). Many of them are from inheriting packages when other developers have retired - the upstream may also be dead, but there is nothing that supersedes the functionality of the package, so if I use it, it lives. If you're a developer waiting for an action on one of them, and you've attached a fix to a bug, you should mostly feel free to go ahead any just apply your patch. If you break it, I'll hunt you down. Exceptions: dev-db/mariadb, dev-db/mysql - mysql herd MogileFS, Perlbal - me sys-libs/db - base-system LVM - please be careful! Packages where I am the upstream: app-admin/diradm app-shells/localshell sys-apps/readahead-list dev-perl/WattsUp-Daemon Packages sent for lastrite: dev-vcs/gitosis-gentoo dev-vcs/gitosis Here's a list of every package where I'm a maintainer and there is no herd listed (but their might be other maintainers): app-admin/cancd app-arch/duff app-arch/unadf app-backup/mirdir app-crypt/af_alg app-crypt/gpg-ringmgr app-crypt/mhash app-emulation/qenv app-misc/ddccontrol-db app-misc/ddccontrol app-misc/dnetc app-misc/egads app-misc/interceptty app-text/binfind app-text/convmv app-text/sloccount app-text/unrtf dev-cpp/threadpool dev-db/libdbi-drivers dev-db/libdbi dev-db/redis dev-lang/snobol dev-libs/bglibs dev-libs/libmcal dev-libs/libmelf dev-libs/libmemcached dev-libs/libmemcache dev-libs/OpenSRF dev-libs/yaz dev-util/checkbashisms dev-util/fuzz dev-util/idutils dev-util/its4 dev-util/mpatch dev-util/pscan dev-util/rats dev-util/re2c dev-util/sgb dev-util/wiggle dev-vcs/cvs2svn dev-vcs/git media-gfx/monica media-gfx/springgraph media-sound/dbmeasure net-analyzer/ipaudit net-analyzer/poink net-analyzer/raddump net-analyzer/sslsniff net-analyzer/thrulay net-dns/ndu net-firewall/ipset net-libs/cvm net-libs/libmonetra net-mail/vqadmin net-misc/adjtimex net-misc/aggregate-flim net-misc/aggregate net-misc/dcetest net-misc/ifenslave net-misc/memcached net-misc/netdate net-misc/nstx net-misc/openrdate net-misc/pcapfix net-misc/rdate net-misc/tiers net-misc/valve net-misc/vmnet net-misc/vmpsd net-misc/zsync net-nds/led net-nds/nsscache net-proxy/piper net-wireless/bss sys-apps/clrngd sys-apps/hwinfo sys-apps/input-utils sys-apps/linux-misc-apps sys-apps/usbmon sys-auth/icmpdn sys-auth/nss_ldap sys-block/btrace sys-block/fio sys-block/scsiping sys-block/scsirastools sys-block/seekwatcher sys-block/tw_cli sys-fs/lvm2 sys-libs/openhpi sys-power/iasl sys-power/nut sys-process/audit -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Matt Turner schrieb: Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K /var/tmp/portage/sys-apps/kmod-11-r1/image/ I think the complaint was not about the installed size. Some people have install as little unnecessary code as possible as part of their security concepts. Best regards, Chí-Thanh Christopher Nguyễn
[gentoo-dev] Re: Apache team is inactive
On Sun, Nov 18, 2012 at 10:28 AM, Pacho Ramos pa...@gentoo.org wrote: apache team is currently composed by nelchael (that is inactive since May 2012) and trapni (that is not taking care of that packages) If you are interested please join. If it's still inactive in next week, I will assign apache bugs to maintainer-needed (I am still unsure about if, in that case, apache herd should be kept in CC for an hypothetical future resurrection or the herd should be dropped entirely) I'd say drop the herd. Like we dropped www-servers. Individual maintainers can take over the packages. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] About unresolved bugs assigned to mobile for ages
El lun, 29-10-2012 a las 12:16 +, Markos Chandras escribió: On Mon, Oct 29, 2012 at 11:10 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 28/10/12 14:26, Pacho Ramos wrote: Hello I would like to know about mobile team status and also show that this team has important bugs assigned to them for a long time, some of them with patches (and reporters angry because of seeing things untouched for a long time). If anyone has time to join to the team and help, nice, if the team needs to drop from some packages maintainership due lack of manpower, please tell us what packages do you want up for grabs. Thanks I've been maintaining sys-power/acpid since nobody in mobile@ has been for ages now I've never seen anyone from mobile@ replying to any of the bugs, *any* of the bugs So yeah, +1 for m-needed@, the herd clearly doesn't work as random HW specific packages are assigned to it Perfect. Lets remove the project+email+herd altogether with an immediate announcement of this action and which packages are not maintained anymore. Pacho can you take care of this like you did in the past for other dead teams? How do you want me to proceed with project removal? Should I simply remove the project web page? Regarding mail alias, I have just opened: https://bugs.gentoo.org/show_bug.cgi?id=443768 as I don't have permissions for doing that signature.asc Description: This is a digitally signed message part
[gentoo-dev] Packages up for grabs due mobile herd removal
app-admin/longrun app-laptop/fnfx app-laptop/hdapsd app-laptop/ibam app-laptop/laptop-mode-tools app-laptop/radeontool app-laptop/spicctrl app-laptop/tp_smapi app-laptop/tpb app-misc/gpsdrive app-mobilephone/obex-data-server media-libs/sbc net-misc/xsupplicant net-wireless/acx-firmware net-wireless/acx net-wireless/adm8211 net-wireless/airsnort net-wireless/ap-utils net-wireless/at76c503a net-wireless/atmel-firmware net-wireless/b43-firmware net-wireless/b43-fwcutter net-wireless/bcm43xx-fwcutter net-wireless/blueman net-wireless/bluez-firmware net-wireless/bluez-hcidump net-wireless/bluez net-wireless/crda net-wireless/fsam7400 net-wireless/gnome-bluetooth net-wireless/gobi_loader net-wireless/hostap-utils net-wireless/hostapd net-wireless/ipw2100-firmware net-wireless/ipw2200-firmware net-wireless/ipw3945-ucode net-wireless/ipw3945 net-wireless/ipw3945d net-wireless/irda-utils net-wireless/kismet net-wireless/linux-wlan-ng-firmware net-wireless/linux-wlan-ng-modules net-wireless/linux-wlan-ng-utils net-wireless/linux-wlan-ng net-wireless/madwifi-ng-tools net-wireless/madwifi-ng net-wireless/madwimax net-wireless/ndiswrapper net-wireless/opd net-wireless/orinoco-fwutils net-wireless/orinoco-usb net-wireless/prism54-firmware net-wireless/rfkill net-wireless/rfswitch net-wireless/rt61-firmware net-wireless/rt73-firmware net-wireless/rtl8180 net-wireless/spectools net-wireless/ussp-push net-wireless/wavemon net-wireless/wifi-radar net-wireless/wifiscanner net-wireless/wimax-tools net-wireless/wimax net-wireless/wireless-regdb net-wireless/wireless-tools net-wireless/wpa_supplicant net-wireless/zd1201-firmware sys-apps/915resolution sys-apps/apmd sys-apps/i2c-tools sys-apps/i2c sys-apps/lm_sensors sys-apps/pcmciautils sys-apps/tuxonice-userui sys-firmware/iwl1000-ucode sys-firmware/iwl2000-ucode sys-firmware/iwl2030-ucode sys-firmware/iwl3945-ucode sys-firmware/iwl4965-ucode sys-firmware/iwl5000-ucode sys-firmware/iwl5150-ucode sys-kernel/tuxonice-sources sys-libs/libacpi sys-power/acpi sys-power/acpid sys-power/acpitool sys-power/cpudyn sys-power/cpufreqd sys-power/cpufrequtils sys-power/hibernate-script sys-power/ncpufreqd sys-power/pmtools sys-power/powermgmt-base sys-power/powernowd sys-power/powertop sys-power/yacpi virtual/pcmcia Feel free to take them, some of them are already maintained by others, but if you are interested, they will surely welcome help with your preferred package signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 18.11.2012 06:00, Richard Yao wrote: but we are doing AGILE development, so long term goals have not been well defined. [...] With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. Can you spot the problem? Regards, Wulf -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlCozb4ACgkQnuVXRcSi+5pGWQCgnXEc3jZWbz36kXhUMnalonoC hLIAnRoJO5ihyTDS4BroP0SlEmhhEGvt =OSbk -END PGP SIGNATURE-
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Wow, that's some kind of thread you started... :) I'll respond in general to a bunch of stuff on this list by topic. COUNCIL MEETING On Sat, Nov 17, 2012 at 10:29 PM, Greg KH gre...@gentoo.org wrote: So, that's a nice summary, but, what is the end result here? Speaking as somebody who was there, but not for the council, the summary was the end result OF THE COUNCIL MEETING. The council was asked to set a deadline for everybody with a separate /usr to adopt one of the proposed mitigation solutions, like using a script, initramfs, or whatever. That is ALL that it was asked to decide on, and that was all it did decide on. The whole business about some devs wanting to fork udev came out about a day in advance, and speaking personally it only had a little influence on my vote. The reason I agree with chainsaw's proposal to defer the decision one month was that there seemed to be enough blockers on this that nothing was going to happen for almost another month anyway (best-case), and getting people to move to initramfs or mdev or [nu/eu]dev[-ng]/whatever wasn't actually going to be holding anything up for a while. I'd also have been willing to approve a plan to set a target for something like 90 days after all the necessary tools (like genkernel) were stable and news was sent out. Based on my questions for williamh I did not get the sense that delaying a month was actually hindering the udev project (the established udev). They were encouraged to continue working on their blockers, preparing news items, and so on - everything but having a deadline/go-ahead to break systems that didn't follow the news. So, a bunch of ideas were floating around in the meeting, and I embraced the wait a month option since that seemed to have the most support of any of the options out there. If williamh had identified some actual impact of delay on the udev team I'd have probably pushed for setting the deadline now, but just putting it far enough out there (90 days from genkernel/etc being ready) that all the various teams would have a shot at it. If the udev team gets their news items all worked out and perhaps even sent out (sans deadline) and all the blockers cleared before the next meeting I'd be supportive of setting the deadline around 60 days, but that would be just moral support since I'm not on the council. OFFICIAL UDEV PROJECT I have nothing to do with the new udev project, but I did pass the staff quiz with much help from calchan. :) Read the GLEPs - any Gentoo developer can start a project at any time. That's how things work around here. If I wanted to start a linux kernel fork as an official Gentoo project I could do so tomorrow. That doesn't mean that the new udev will become the default udev, any more than Gentoo hardened will ever become the default experience for new Gentoo users. Gentoo is about choice, and if we have devs interested in maintaining something new then we'll offer that choice to our users for as long as somebody takes care of it. If anybody wants to change the defaults/etc, I'd expect that to get a lot of discussion, and almost certainly a council vote. COPYRIGHT I think this issue is best dealt with on the side - it has no bearing on any of the really contentious points here. I note that the owners of the copyright on udev have announced to the world that (emphasis mine): You may modify your copy or copies of the Library or ANY PORTION OF IT, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions... None of those conditions included keeping the copyright line intact. Anybody can therefore alter the copyright line as they wish, as they have been given explicit permission to do so. They need only comply with the other terms in the LGPL to do so (the most important being licensing it under the LGPL and making the source available. In fact, (L)GPL v3 has an optional attribution clause, and the fact that they made this explicit is because some projects might not want to give out this authorization. So, if you want an official ruling from the trustees we would need to meet/vote on it and perhaps discuss with counsel, but my thinking is that anybody distributing work under the (L)GPL has waived their right to be named on the copyright line of any copies distributed by others, and as far as I can tell I have found nothing to the contrary from any authoritative source. The only way I think you could argue that removing copyright notices for a (L)GPL work is illegal is if you argue that an author doesn't have the legal power to license that right to another. However, I'd still think that promissory estoppel would probably interfere with any kind of recourse - you can't give somebody permission to do something, and then sue them for actually doing it. So, legal or not anybody with standing to sue over this has likely given up their rights to do
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Sun, Nov 18, 2012 at 6:11 AM, Vadim A. Misbakh-Soloviov m...@mva.name wrote: So, I really hope, that Gentoo will not obey RedHat's will and will not force SystemD as default init system, and not drop pretty OpenRC to trash. And I hope, that ryao's eudev will be most used (if not default) variant of udev, since I'm sad with last vanilla udev functionality downgrades. I'm sure all of the options will be offered as options for as long as people care to take care of them. With the number of anti-systemd posts on -dev I don't see openrc going away anytime soon. I'm sure the default will stay as it is unless a substantial majority want it otherwise - we can't go flipping that every time the latest whatever comes along. And frankly, I could care less what it is since I can change it. If I wanted to be rigidly bound by defaults there are a lot of distros easier to maintain than Gentoo. iOS comes to mind. :) I run OpenRC on my main box, and systemd on a VM hosted within it. I wouldn't be surprised if I move to systemd some day as my experience with it has been a good one, but I'll use the tools I think are best for the problem at hand, and not what somebody else chooses for me, and I'll be the last to force a choice on anybody else. That said, Gentoo can only offer the options that devs step up and maintain, so if you care greatly about something start writing patches. That is my biggest concern over a lot of this mess - and Greg KH did a good job putting it into words in the six-month old thread that was just resurrected. Lennart et al only have the power you give to them - anybody can fork at any time or keep an old project going. If you don't like Gnome 3 then start writing code for Gnome 2. This is all FREE software, and it only exists when people take the time to write it. If nobody bothers to maintain the alternatives, then I guess collectively we're going to be stuck with whatever people take the time to write. So, feel free to offer advice/comments/etc. However, let's keep the tone civil. Unless you're their employer, the guys writing the software you don't like owe you precisely nothing. Rich
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 18.11.2012 08:57, Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote: 1) systemd-udev will require systemd. Stated by the systemd maintainers themselves as a thing they want to do in the future. Some users don't want to use systemd. We could go into detail as to why; but I think that is not as important as one may think. The point is that the desire is there, and thusly there are users who want to make other systems (namely openrc) work. People like openrc. My VMs for instance, boot reasonably quickly. Booting 5 seconds faster may be super duper, but not at the cost of an existing reliable solution. So is this the goal? Great, someone say that then, that's all I'm asking for here. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it matures and is good enough, then add it to the distro like all other packages are added. My main point here is the fact that this is now being seen as an act by Gentoo, the distro / foundation. And that happened in private, without any anouncement. Which is not good on many levels. I'm unsure on what grounds you disapprove. People start (and abandon) projects often in Gentoo. Suddenly you dislike one such project and object to this practice? Certainly if we had to get some sort of Foundation consensus (for anything) nothing would happen. We can't even get more than 40% of foundation members to vote. I object if this is seen as a Gentoo blessed fork of a community project that is worked on by all other major Linux distros. That is the type of decision that can be made by the Gentoo Council, which is fine, but it sure would be nice if it were publicly stated, instead of having to see it on the Gentoo github site instead. Hi, I've seen this argument being repeated all over this thread and I'd like to clarify: http://github.com/gentoo (nor it's bitbucket.org counterpart) was never meant to host Gentoo blessed forks/projects and it *doesn't*. Sole purpose of it, was to encourage more contribution from users using web goodies like click a button to fork, since most of the people are very comfortable with github's workflow. We (gentoo-science team) have seen significant increase of interest since we've started using github. Cheers, Kacper P.s. Just to emphasise it even more: There's a pornview fork there too. I don't recall Gentoo Council acknowledging it as default imageviewer. We should definitely put it into agenda. /reductio ad absurdum And if that is the decision of the council, I would expect the ability to have some type of discussion about it, wouldn't you? Also, the whole issue with the copyrights is very serious, for the reasons I've stated before. Don't mess with copyrights, developers, and companies, take them very serious, as they are the basis for our licenses. thanks, greg k-h signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On Fri, Nov 16, 2012 at 10:43 AM, justin j...@gentoo.org wrote: On 16/11/12 09:48, Samuli Suominen wrote: does this mean it puts the binary-only package, nvidia-cg-toolkit, to the default search path when you call the linker (compiler)? please don't do that, it is counterproductive with the purpose of putting libraries to /opt. binary only packages should be isolated. it was already once reverted for the package... it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags -L/opt/... or similar. thanks +*nvidia-cg-toolkit-3.1.0013-r1 (16 Nov 2012) + + 16 Nov 2012; Justin Lecher j...@gentoo.org +files/80cgc-opt-3, + +nvidia-cg-toolkit-3.1.0013-r1.ebuild, +files/nvidia-cg-toolkit.pc.in, + +files/nvidia-cg-toolkit-gl.pc.in: + Don't add binary packages to global linker search path; instead using + pkg-config. Thanks ssuominen pointing this out + This is a shared library, used by the plugin google-talkplugin. If there is no LDPATH set, browsers using that plugin will crash mysteriously and unpredictably. You can't use chrpath to change the rpath because lengthof(/opt/nvidia-cg-toolkit/lib64)lengthof(/opt/google/talkplugin/lib) and we don't have the sources, so we can't really recompile. And it's being dl-opened so LD_LIBRARY_PATH is a no-go, unless we want to add magic to all browser that sets it to the correct path before starting them. So please re-add the LDPATH to the env.d file. Pretty please. Just cause it's binary doesn't mean it has to be cordoned off and isolated like it's got the spanish flu. /Peter PS pkgconfig is irrelevant if it's only gentoo that's shipping them. HTH. HAND.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On 11/18/2012 03:08 PM, Peter Alfredsen wrote: On Fri, Nov 16, 2012 at 10:43 AM, justin j...@gentoo.org wrote: On 16/11/12 09:48, Samuli Suominen wrote: does this mean it puts the binary-only package, nvidia-cg-toolkit, to the default search path when you call the linker (compiler)? please don't do that, it is counterproductive with the purpose of putting libraries to /opt. binary only packages should be isolated. it was already once reverted for the package... it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags -L/opt/... or similar. thanks +*nvidia-cg-toolkit-3.1.0013-r1 (16 Nov 2012) + + 16 Nov 2012; Justin Lecher j...@gentoo.org +files/80cgc-opt-3, + +nvidia-cg-toolkit-3.1.0013-r1.ebuild, +files/nvidia-cg-toolkit.pc.in, + +files/nvidia-cg-toolkit-gl.pc.in: + Don't add binary packages to global linker search path; instead using + pkg-config. Thanks ssuominen pointing this out + This is a shared library, used by the plugin google-talkplugin. If there is no LDPATH set, browsers using that plugin will crash mysteriously and unpredictably. You can't use chrpath to change the rpath because lengthof(/opt/nvidia-cg-toolkit/lib64)lengthof(/opt/google/talkplugin/lib) and we don't have the sources, so we can't really recompile. And it's being dl-opened so LD_LIBRARY_PATH is a no-go, unless we want to add magic to all browser that sets it to the correct path before starting them. So please re-add the LDPATH to the env.d file. Pretty please. Just cause it's binary doesn't mean it has to be cordoned off and isolated like it's got the spanish flu. /Peter PS pkgconfig is irrelevant if it's only gentoo that's shipping them. HTH. HAND. this is also breaking dev-games/ogre linking works fine (since we got proper pkgconfig fils), runtime is broken.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-gfx/nvidia-cg-toolkit/files: 80cgc-opt-2
On 18/11/12 16:11, hasufell wrote: On 11/18/2012 03:08 PM, Peter Alfredsen wrote: On Fri, Nov 16, 2012 at 10:43 AM, justin j...@gentoo.org wrote: On 16/11/12 09:48, Samuli Suominen wrote: does this mean it puts the binary-only package, nvidia-cg-toolkit, to the default search path when you call the linker (compiler)? please don't do that, it is counterproductive with the purpose of putting libraries to /opt. binary only packages should be isolated. it was already once reverted for the package... it is up the the ebuilds using nvidia-cg-toolkit to append-ldflags -L/opt/... or similar. thanks +*nvidia-cg-toolkit-3.1.0013-r1 (16 Nov 2012) + + 16 Nov 2012; Justin Lecher j...@gentoo.org +files/80cgc-opt-3, + +nvidia-cg-toolkit-3.1.0013-r1.ebuild, +files/nvidia-cg-toolkit.pc.in, + +files/nvidia-cg-toolkit-gl.pc.in: + Don't add binary packages to global linker search path; instead using + pkg-config. Thanks ssuominen pointing this out + This is a shared library, used by the plugin google-talkplugin. If there is no LDPATH set, browsers using that plugin will crash mysteriously and unpredictably. You can't use chrpath to change the rpath because lengthof(/opt/nvidia-cg-toolkit/lib64)lengthof(/opt/google/talkplugin/lib) and we don't have the sources, so we can't really recompile. And it's being dl-opened so LD_LIBRARY_PATH is a no-go, unless we want to add magic to all browser that sets it to the correct path before starting them. So please re-add the LDPATH to the env.d file. Pretty please. Just cause it's binary doesn't mean it has to be cordoned off and isolated like it's got the spanish flu. /Peter PS pkgconfig is irrelevant if it's only gentoo that's shipping them. HTH. HAND. this is also breaking dev-games/ogre linking works fine (since we got proper pkgconfig fils), runtime is broken. umm, indeed... that's why I had ? marks in my original post. runtime is OK to add, so LDPATH should be fine. sorry for any confusion. - Samuli
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote: [Just asking because all you angry answers to some devs make me think that you're on SysD side, when tons of Gentoo users and Gentoo devs are on non-SysD-related udev side.] The fact you're asking means you really haven't been following anything I've been doing lately. As many other developers can easily attest, I don't use systemd and I'm not planning to use it anytime soon. So your whole rant picking up on my post is completely misdirected. And let this be a reminder that you can still disagree with the systemd everywhere, and only crowd while still not becoming laughing stock. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/12 17:04, Diego Elio Pettenò wrote: On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote: [Just asking because all you angry answers to some devs make me think that you're on SysD side, when tons of Gentoo users and Gentoo devs are on non-SysD-related udev side.] The fact you're asking means you really haven't been following anything I've been doing lately. As many other developers can easily attest, I don't use systemd and I'm not planning to use it anytime soon. So your whole rant picking up on my post is completely misdirected. Same here. I haven't even tried it and got no plans to. I'm still happy enough with building udev out from systemd tree and letting sep. /usr consept from 90s to finally die in favour of simplifying the system. The BIOSes have been upgraded last century to support booting from larger partitions, the need has long past. Nobody has ever provided a valid reason for using sep. /usr in the ML either. - Samuli
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18-11-2012 17:16:18 +0200, Samuli Suominen wrote: Nobody has ever provided a valid reason for using sep. /usr in the ML either. No need for a reason. It is a fact that it is in use *right now*. (Existing systems/installs that are not to be phased out anywhere near soon.) Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/2012 07:16, Samuli Suominen wrote: I'm still happy enough with building udev out from systemd tree and letting sep. /usr consept from 90s to finally die in favour of simplifying the system. The BIOSes have been upgraded last century to support booting from larger partitions, the need has long past. Nobody has ever provided a valid reason for using sep. /usr in the ML either. Ibidem. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
To be honest, in my opinion, «killing of separate /usr» can reasonable be continued by moving all it's content to / (/usr/bin - /bin, /usr/lib - lib, and so on) in despite of all objections, as it was invented just because of disk space exhaustion. 18.11.2012 22:16, Samuli Suominen пишет: On 18/11/12 17:04, Diego Elio Pettenò wrote: On 18/11/2012 03:11, Vadim A. Misbakh-Soloviov wrote: [Just asking because all you angry answers to some devs make me think that you're on SysD side, when tons of Gentoo users and Gentoo devs are on non-SysD-related udev side.] The fact you're asking means you really haven't been following anything I've been doing lately. As many other developers can easily attest, I don't use systemd and I'm not planning to use it anytime soon. So your whole rant picking up on my post is completely misdirected. Same here. I haven't even tried it and got no plans to. I'm still happy enough with building udev out from systemd tree and letting sep. /usr consept from 90s to finally die in favour of simplifying the system. The BIOSes have been upgraded last century to support booting from larger partitions, the need has long past. Nobody has ever provided a valid reason for using sep. /usr in the ML either. - Samuli signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Chí-Thanh Christopher Nguyễn posted on Sun, 18 Nov 2012 12:14:48 +0100 as excerpted: Matt Turner schrieb: Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K /var/tmp/portage/sys-apps/kmod-11-r1/image/ I think the complaint was not about the installed size. Some people have install as little unnecessary code as possible as part of their security concepts. That's true, but as a long-term gentooer, I've found over the years it's more than that. Every single installed package is another package that must be repeatedly rebuilt, as upgrades come in and/or as the system core toolchain changes over time and one wants to be sure the whole system is consistent and still buildable (emerge --emptytree @world). Every installed package I don't use is thus an installed package I'll spend a lot of otherwise unnecessary time on, over the years, simply keeping it and the system in general upto date. As one realizes the cost over time, one gets a rather higher motivation to keep the system as lean and mean as possible. I look at it this way, it's just that much more incentive to practice what has always been known as good security practice in any case, keeping everything off the system that doesn't have a solid, known reason, for being there. kmod itself is trivial in size time and space requirements, but it's the principle as much as anything, and in the case of an unneeded module loader there's an additional security concern as well, since an opportunity to load kernel modules is just that much more opportunity to install a kernel module that hides otherwise visible tell-tail (logs, strange open ports on netstat, strange startup services, etc) signs of being rooted. Sure, if someone has module-loading access already, it's not a big increased risk, but given that it's an unnecessary, any non- negative non-zero increase in risk or maintenance cost over time is unacceptable, and on a monolithic kernel gentoo system, a kernel module loader increases both, trivially sure, but when there's no justifiable reason for it in the first place... -- 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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/2012 07:34, Vadim A. Misbakh-Soloviov wrote: To be honest, in my opinion, «killing of separate /usr» can reasonable be continued by moving all it's content to / (/usr/bin - /bin, /usr/lib - lib, and so on) in despite of all objections, as it was invented just because of disk space exhaustion. Well, the objection to that was what actually caused this udev fork, so... Also, I doubt anybody would argue that it's not commutative (move to /usr, move to /) — it's just pragmatic, most stuff uses /usr anyway as base, so the move / - /usr is infinitely less painful than /usr - /. To me, I don't care. I haven't even used /boot in years. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
The fact you're asking means you really haven't been following anything I've been doing lately. Nope ;) I knew that, but as far as I read some of your emails, it was thoughts that you protect udev+sysD integration and followed udev's functionality downgrade. So your whole rant picking up on my post is completely misdirected. Sorry, if I write it in that manner, that last part looks like adressed to you. I tried to write it mostly for GregKH and people, that protect SystemD-way distro-development path. And let this be a reminder that you can still disagree with the systemd everywhere, and only crowd while still not becoming laughing stock. And, by the way, I doubt, that people laugh about eudev (previously named udev-ng) creation. Mostly they just can't understand why gentoo devs created third udev's fork, where it was already done (and maintained) fork for LFS (somewhere on bitbucket) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote: And, by the way, I doubt, that people laugh about eudev (previously named udev-ng) creation. Mostly they just can't understand why gentoo devs created third udev's fork, where it was already done (and maintained) fork for LFS (somewhere on bitbucket) People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and IRC as well. But yes, many more can't understand that... and neither do I. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 11/18/2012 04:34 PM, Vadim A. Misbakh-Soloviov wrote: To be honest, in my opinion, «killing of separate /usr» can reasonable be continued by moving all it's content to / (/usr/bin - /bin, /usr/lib - lib, and so on) in despite of all objections, as it was invented just because of disk space exhaustion. And since we have lots of wonderful file systems, a neat and interesting device mapper and a plethora of fun way to shot ourselves in the foot not only you have a separate /usr but even fun separate /usr/bin from /usr/share and other strange layout that some people prepared to solve some of their problems. The radical solution is to have a rich early boot able to do this kind of setup, for the transition you might want to not have init and udev non-workable because somebody decided that is useful using glib or some other library residing in /usr/ lu
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18-11-2012 07:42:40 -0800, Diego Elio Pettenò wrote: Also, I doubt anybody would argue that it's not commutative (move to /usr, move to /) — it's just pragmatic, most stuff uses /usr anyway as base, so the move / - /usr is infinitely less painful than /usr - /. You end up with a symlink (e.g. bin - ./usr/bin) from one place to the other regardless, so it doesn't matter much. -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18-11-2012 07:47:22 -0800, Diego Elio Pettenò wrote: On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote: And, by the way, I doubt, that people laugh about eudev (previously named udev-ng) creation. Mostly they just can't understand why gentoo devs created third udev's fork, where it was already done (and maintained) fork for LFS (somewhere on bitbucket) People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and IRC as well. It's your choice to participate on those social platforms. Please don't make it our problem. It doesn't add anything useful to this discussion. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: Digital signature
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 11/18/2012 04:47 PM, Diego Elio Pettenò wrote: But yes, many more can't understand that... and neither do I. Then would be nice if everybody shuts up, let people play with their toys and if something useful happens evaluate the result. According to the people that asked me to help the whole thing would had been an experiment to see if would be possible to have a smaller and cleaner udev. I liked the idea since I like alternatives and I consider many choices from upstream a tad narrow minded (beside the entertaining posts from Linus about their bug management). Nobody wanted hype there, just more people willing to chip in some time and effort to get there. lu
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 18/11/2012 07:54, Fabian Groffen wrote: It's your choice to participate on those social platforms. Please don't make it our problem. It doesn't add anything useful to this discussion. It adds. Because, while I don't know about you, I rely on Gentoo on my job. And many others do, too. And making Gentoo the laughing stock (_again_, I'd add) is something that is detrimental to all of us there, as it makes it harder to let it be seen for what it is (a very real, quit reliable distribution) rather than a juvenile effort to be different from the rest. How long did it take us to get rid of the Gentoo is rice fame? Do we want to go back to that? _I_ don't think so. So yes, the social platforms matter and are our problem. And it appals me that a member of the council can't see that. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 18/11/2012 03:11, Robin H. Johnson wrote: net-libs/libmonetra Maybe time to get rid of this one? https://bugs.gentoo.org/show_bug.cgi?id=341721 -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 11:38 AM, Kacper Kowalik xarthis...@gentoo.org wrote: On 18.11.2012 08:57, Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote: 1) systemd-udev will require systemd. Stated by the systemd maintainers themselves as a thing they want to do in the future. Some users don't want to use systemd. We could go into detail as to why; but I think that is not as important as one may think. The point is that the desire is there, and thusly there are users who want to make other systems (namely openrc) work. People like openrc. My VMs for instance, boot reasonably quickly. Booting 5 seconds faster may be super duper, but not at the cost of an existing reliable solution. So is this the goal? Great, someone say that then, that's all I'm asking for here. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it matures and is good enough, then add it to the distro like all other packages are added. My main point here is the fact that this is now being seen as an act by Gentoo, the distro / foundation. And that happened in private, without any anouncement. Which is not good on many levels. I'm unsure on what grounds you disapprove. People start (and abandon) projects often in Gentoo. Suddenly you dislike one such project and object to this practice? Certainly if we had to get some sort of Foundation consensus (for anything) nothing would happen. We can't even get more than 40% of foundation members to vote. I object if this is seen as a Gentoo blessed fork of a community project that is worked on by all other major Linux distros. That is the type of decision that can be made by the Gentoo Council, which is fine, but it sure would be nice if it were publicly stated, instead of having to see it on the Gentoo github site instead. Hi, I've seen this argument being repeated all over this thread and I'd like to clarify: http://github.com/gentoo (nor it's bitbucket.org counterpart) was never meant to host Gentoo blessed forks/projects and it *doesn't*. Sole purpose of it, was to encourage more contribution from users using web goodies like click a button to fork, since most of the people are very comfortable with github's workflow. We (gentoo-science team) have seen significant increase of interest since we've started using github. Cheers, Kacper Hi, Well, if yoiu fork a big community project, like udev, in a github account called gentoo, people *will* think it is a Gentoo project. If these organizations aren't governed by Gentoo they should have some disclaimers, saying that the projects hosted there aren't sponsored by Gentoo, but this udev-ng/eudev/whatever thing does the opposite and actually advertise the Gentoo sponsorship with the sentence This is a Gentoo sponsored project and testing is currently being done with openrc. in their README I don't think that someone can claim this sponsorship without a council vote. I disagree with this fork, and tend to agree with what Greg and Diego said before in this thread. BR, Rafael P.s. Just to emphasise it even more: There's a pornview fork there too. I don't recall Gentoo Council acknowledging it as default imageviewer. We should definitely put it into agenda. /reductio ad absurdum You really want to compare pornview, that was dead and someone kindly resurrected, with udev, that is actively maintained and the quality of the fork is questionable? :( And if that is the decision of the council, I would expect the ability to have some type of discussion about it, wouldn't you? Also, the whole issue with the copyrights is very serious, for the reasons I've stated before. Don't mess with copyrights, developers, and companies, take them very serious, as they are the basis for our licenses. thanks, greg k-h -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
It depends on who is actually laughing I'd say. just my 0.01c. -- Fabio Erculiani
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
El 18/11/12 04:39, Greg KH escribió: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. So I made a mistake coming out from a missunderstanding on a commit on a branch that didn't even get merged since I was expecting approval from somebody else before that. Cool. The amount of damage caused by this action is around the same as publishing a patch and not applying it. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Check european copyright laws please, they are quite different from yours. I at least have had to read and understand the spanish copyright laws a few times and its not funny. So please don't speak of a normal body of copyright law there is not such thing and some of us have enough with the normalizations USA based lobbies are trying to impose on ours. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 11:14 AM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: If these organizations aren't governed by Gentoo they should have some disclaimers, saying that the projects hosted there aren't sponsored by Gentoo, but this udev-ng/eudev/whatever thing does the opposite and actually advertise the Gentoo sponsorship with the sentence This is a Gentoo sponsored project and testing is currently being done with openrc. in their README I don't think that someone can claim this sponsorship without a council vote. Read GLEP 39. Any dev can create a project. Granted, most Gentoo projects don't follow the GLEP to the letter, and as long as nothing goes wrong it isn't a big problem. The council can step in if necessary, but having some source out on github won't kill anybody. Keep in mind though that using github exclusively isn't exactly aligned with the social contract - I would encourage having the sources on Gentoo servers. That said, I don't think it matters where people do the work vs what is the mirror - just nobody should be forced to use github (proprietary) to contribute. As long as everybody behaves Gentoo devs can work on whatever they want to. None of us are paid to do this. If a bunch of strangers made the same claim I'd be more concerned. If anybody feels a Gentoo project is out of line feel free to submit a bug to the Council or Trustees as appropriate. However, please save that for things like they're breaking the law or they refuse to have elections for a lead or whatever, and not I don't like what they're working on. The recourse for the latter is to adjust your profile/USE-flags/killfile as appropriate. Rich
[gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
Rich Freeman posted on Sun, 18 Nov 2012 07:26:17 -0500 as excerpted: I'm sure all of the options will be offered as options for as long as people care to take care of them. With the number of anti-systemd posts on -dev I don't see openrc going away anytime soon. I'm sure the default will stay as it is unless a substantial majority want it otherwise - we can't go flipping that every time the latest whatever comes along. [For close followers of the discussion, this is a repeat. But it's worth repeating in the hope that the message gets out to gentoo users who don't follow so closely.] Based on previous posts from other gentoo users, this point seems to have been lost on some, but it's absolutely true. As I've pointed out before as well, even if by some miracle all of gentoo turned on a dime and became a virulently pro-systemd distro today, in practice it'd take time for that to work into the implementation. We're looking at probably a year minimum, more practically closer to two, before end-users could really be forced over, and that's if somehow the policy changed on a dime, today, which isn't going to happen. So even if gentoo ultimately heads that direction, and I think the default _may_ _eventually_ be systemd but with *SERIOUS* stress on BOTH _MAY_ and _EVENTUALLY_, in reality we're looking at 3-5 years. And in the free software world, a _LOT_ happens in 3-5 years! So much so that five years really is at the horizon in any case -- there will be enough currently unforeseen changes between now and then that it's really hard to predict anything out that far anyway, and MOST people attempting to do so in anything but trivial ways will get MAJOR parts of their prediction wrong, simply because events will overtake them. And frankly, I could care less what it is since I can change it. If I wanted to be rigidly bound by defaults there are a lot of distros easier to maintain than Gentoo. iOS comes to mind. :) That's a point that should be near and dear to any serious gentooer's heart! =:^) I run OpenRC on my main box, and systemd on a VM hosted within it. I wouldn't be surprised if I move to systemd some day as my experience with it has been a good one, but I'll use the tools I think are best for the problem at hand, and not what somebody else chooses for me, and I'll be the last to force a choice on anybody else. With the previous caveats about trying to predict anything in the FLOSS world too far out, in 2-3 years, I expect I'll be on systemd myself. But there's no rush, and I intend to wait until it stabilizes somewhat, first. At present it's simply evolving too fast for my tastes, for something so system-basic. I enjoy running alphas and betas as much as the next guy and it's a rare time indeed that I don't have /something/ not-absolutely stable running on my systems, but that doesn't mean I want /all/ of my system unstable and shifting out from under me, and system init is an area where I'm just not ready to make a change as big as systemd, when it's still actively growing and changing at the rate it seems to be doing so today. That said, I _do_ run openrc-, mainly because I found the changes of ~arch openrc too coarse-grained and hard to troubleshoot when things go wrong. By running the live-git version and examining git-whatchanged every time I update, often looking at the diffs for individual commits, I get the incremental changes as they come in, and can much faster pinpoint where a particular problem is when I see it, making the necessary changes locally and of course bug-filing upstream as I need to, to get it fixed. But running a live-git version of something I'm already on, in ordered to more closely follow individual commits and pinpoint and resolve bugs faster, is quite different from deciding I'm going to switch to something with as much churn as systemd seems to still have, engulfing and extinguishing entire projects like some ravenous black hole or gray goo. Yes, I expect at some point I'll be assimilated myself, but there's no reason that point needs to be now, and the future where I expect it to happen remains to be written, with a good chance the plot line will change significantly between now and then, such that I may never be assimilated after all. For all I know, the whole worldview will change between now and then, and other events might well overtake this gray goo that now seems to be engulfing everything that it touches, such that it never does in fact engulf me and my systems. That said, Gentoo can only offer the options that devs step up and maintain, so if you care greatly about something start writing patches. This too is a point that's often lost on people. Take kde as an example. Yes, kde3 was relegated to the kde-sunset overlay, where it's being maintained in some state by users (see the gentoo-desktop list for the discussion on that, if interested). But that was simply
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 2:36 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Nov 18, 2012 at 11:14 AM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: If these organizations aren't governed by Gentoo they should have some disclaimers, saying that the projects hosted there aren't sponsored by Gentoo, but this udev-ng/eudev/whatever thing does the opposite and actually advertise the Gentoo sponsorship with the sentence This is a Gentoo sponsored project and testing is currently being done with openrc. in their README I don't think that someone can claim this sponsorship without a council vote. Read GLEP 39. Any dev can create a project. Granted, most Gentoo projects don't follow the GLEP to the letter, and as long as nothing goes wrong it isn't a big problem. The council can step in if necessary, but having some source out on github won't kill anybody. Yeah, but I think that there's a big difference about any developer being allowed to create a project under the gentoo umbrella and create a project and claim it as Gentoo sponsored without any review of the council. I agree that it can exists in the Github account, or even in our own infrastructure, but say that Gentoo supports it without a previous analysis of the council is wrong IMHO. Keep in mind though that using github exclusively isn't exactly aligned with the social contract - I would encourage having the sources on Gentoo servers. That said, I don't think it matters where people do the work vs what is the mirror - just nobody should be forced to use github (proprietary) to contribute. As long as everybody behaves Gentoo devs can work on whatever they want to. None of us are paid to do this. If a bunch of strangers made the same claim I'd be more concerned. If anybody feels a Gentoo project is out of line feel free to submit a bug to the Council or Trustees as appropriate. However, please save that for things like they're breaking the law or they refuse to have elections for a lead or whatever, and not I don't like what they're working on. The recourse for the latter is to adjust your profile/USE-flags/killfile as appropriate. Rich -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Hey guys, Just read through this entire thread, and one concern still rings loud and clear -- what is the purpose of this fork? The various responses I've read so far are something like: - Because Linus yelled a lot when udev/Kay broke firmware loading. Except both Linus and the udev people fixed the problem. Linus added direct filesystem loading in the kernel [1], and I'm told the udev folks also fixed their hang and async situation. - Because udev requires systemd. Except the patches to build udev without systemd are not very large. - Because of kmod. Still required for things, even if its indirectly removed. - Because we want to have separate /usr working again. Will udev alone actually fix the separate /usr functionality? What's required here? Don't bother responding to the above bullet points, even if they're garbage. Instead, read on to what I'm really after. In general, what I'm looking for is some kind of well-written, well-thought out mission statement, that clearly says okay here are the issues, here's generally how we're going to solve them, and here's why you should feel good about this being a Gentoo project. At the moment, I haven't found anything like this, and the fact that it's an official Gentoo project consuming the time and hearts of intelligent developers makes me concerned, since I'm in the dark as to its purpose and motivation. All I'm asking is some kind of coherent mission statement. If the aggregated responses to the bullet points above are inaccurate, don't bother responding to those inaccuracies on a point by point basis or bikeshed on them, or whatever happens on mailing lists. Just, please, tell everybody what exactly you want to do, why you want to do it, and what this is all about. Thanks a lot, Jason [1] http://git.zx2c4.com/linux/commit/drivers/base/firmware_class.c?id=abb139e75c2cdbb955e840d6331cb5863e409d0e -- Jason A. Donenfeld Gentoo Linux Security zx...@gentoo.org www.zx2c4.com
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 10:48:33AM +0100, Pacho Ramos wrote: El dom, 18-11-2012 a las 11:13 +0200, Samuli Suominen escribió: On 18/11/12 07:19, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? Exactly what I had in mind. So far I see bunch of regressions (back to bundling code :() in the eudev repository and more it deviates from the orig. upstream the less attractive it's looking... What should be done, at most, is to cherry-pick and revert the things that killed the sep. /usr support, put it behind an USE flag to the current udev's ebuild, perhaps IUSE=+vanilla, and be done with it. - Samuli +1 @eudev maintainers, Wouldn't that be possible? Anything is possible. The issue right now is the relationship between ryao and the udev team (at least me). I don't want to bore the list with the details, but ryao misunderstood some action (or lack of action) on my part as ignoring him. Samuli, myself and robbat2 are the udev team for gentoo. What I do not know is if ryao spoke to the other team members, but what I do know is that a private irc conversation months ago is fine, but, from my perspective, it would have made sure that I didn't lose track of things if bugs had been filed, and they were not, so that is the only reason I lost track of his concerns. I asked him several times about joining the udev team, but for whatever reason, he feels that starting this fork was the best option, and he has told me he can't stop it. I'm with gregkh on the separate /usr issue though. It isn't just udev that has issues when /usr is split off. I think the myth that udev is the only culprit came out of the April 2012 council meeting. I'm pretty sure that what I'm about to say will be dismissed by the supporters of separate /usr without an initramfs or without using the sep-usr option we now have in our busybox ebuild, but in truth, splitting / from /usr is broken another way that we have been ignoring for a decade. We have been getting around part of the issue by moving shared libraries from /usr/lib* to /lib* and using gen_usr_ldscript to make sure the linker knows what we have done with them. The other breakage is any program that reads data from /usr/share does not work right if / and /usr are split and that program starts in early boot. I don't know what else would have to be fixed off the top of my head, but I can tell you that locales/nls are broken for early boot without an initramfs if / and /usr are split. Basically, if we want separate /usr without an initramfs and we want to do it right, we have to create /share and start copying things from /usr/share/* to /share/* and patching code to support reading both locations, starting with gettext/NLS support. So here is the question I'll pose. Is it worth all of that extra work for us to support separate /usr correctly, or should we just tell everyone to start using initramfs or, if they don't want to use initramfs and they are just using plain filesystems, the busybox[sep-usr] option once all of the tools are stable? I used separate /usr for a long time here without an initramfs, but after studying why this was broken, I switched over to an initramfs, and have been running one for months, because that seems to be the cleanest way forward. There is one other issue right now, and I don't know what util-linux is doing with it since our bug hasn't been updated in some time [1]. William [1] https://bugs.gentoo.org/show_bug.cgi?id=410605 pgp7ju7SI1WgL.pgp Description: PGP signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: Yeah, but I think that there's a big difference about any developer being allowed to create a project under the gentoo umbrella and create a project and claim it as Gentoo sponsored without any review of the council. I agree that it can exists in the Github account, or even in our own infrastructure, but say that Gentoo supports it without a previous analysis of the council is wrong IMHO. In practice there is no difference. About the only sponsorship Gentoo projects get most of the time is hosting, and considering that they stuck this one on Github they're not really even getting that. That said, I see no reason why this project would be any less eligible for other forms of sponsorship than other projects are, assuming that somebody can make a compelling pitch for the Trustees. The Foundation is aimed to further Gentoo in particular in FOSS in general, so obviously we don't spend a lot on individual projects. When we do it tends to be in proportion to how it benefits the entire community, and I'm sure that community sentiments would be balanced accordingly. However, there aren't real projects and wanna-be projects in Gentoo. Rich
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: Yeah, but I think that there's a big difference about any developer being allowed to create a project under the gentoo umbrella and create a project and claim it as Gentoo sponsored without any review of the council. I agree that it can exists in the Github account, or even in our own infrastructure, but say that Gentoo supports it without a previous analysis of the council is wrong IMHO. In practice there is no difference. About the only sponsorship Gentoo projects get most of the time is hosting, and considering that they stuck this one on Github they're not really even getting that. That said, I see no reason why this project would be any less eligible for other forms of sponsorship than other projects are, assuming that somebody can make a compelling pitch for the Trustees. The Foundation is aimed to further Gentoo in particular in FOSS in general, so obviously we don't spend a lot on individual projects. When we do it tends to be in proportion to how it benefits the entire community, and I'm sure that community sentiments would be balanced accordingly. However, there aren't real projects and wanna-be projects in Gentoo. Rich Hmm, pretty cool! Then I can create a stupid project, put it on gentoo infra and claim it as being Gentoo sponsored. Good to know, thanks! -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:22 PM, William Hubbs willi...@gentoo.org wrote: So here is the question I'll pose. Is it worth all of that extra work for us to support separate /usr correctly, or should we just tell everyone to start using initramfs or, if they don't want to use initramfs and they are just using plain filesystems, the busybox[sep-usr] option once all of the tools are stable? My two cents: My thoughts - no, it isn't worth all that work. However, I'm not the one doing the work, so I'll let those who are judge for themselves whether it is worth it, and I'm not going to knock volunteer work done to benefit the Gentoo community. I hope they succeed. I also hope they don't diverge so far that it affects other packages, and I trust everybody to work together to prevent that. As far as separate /usr goes and all that, I just see this as one more option to offer our users alongside mdev, initramfs, an early boot script, or whatever. Add it to the news item, and let the users decide what they want to do. As far as I'm concerned eudev is just another option like systemd, and if at some point in the future a majority of the community/devs are behind changing the defaults, then we can consider that. Otherwise, stick it in news items, docs, wiki pages, or even the handbook as makes sense. Gentoo is about choice. Would I rather see some of these devs working on something else, like my favorite package? Maybe. But, if so I'm better off sending them an email to try to persuade them, or throwing money at them. What we ought not to do is knock their work. Rich
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Duncan wrote: kmod itself is trivial in size time and space requirements, but it's the principle as much as anything, and in the case of an unneeded module loader there's an additional security concern as well I'm afraid this is flawed. If you want to hinder modules from being loaded then you need to disable modules in the kernel, and not rely on insmod not being installed on the system. Look at insmod in asmutils, my guess is that actual work of loading a module is less than 42 instructions. risk or maintenance cost .. on a monolithic kernel gentoo system, a kernel module loader increases both Forget about the loader. Your knob is in a different configuration, specifically CONFIG_MODULES=n in the kernel. That said, it's a perfectly good point that kmod is a useless dependency on your system and all like it, and that it would be nice for Gentoo to know about this and not pull it in. I guess this could be accomplished with a USE=kernelmodules flag that makes the dep optional and applies a simple patch or two before building udev from systemd sources, and I guess that patches for the udev ebuild are welcome. :) //Peter
Re: [gentoo-dev] Reminder: open season on robbat2's packages
Le dimanche 18 novembre 2012 à 11:11 +, Robin H. Johnson a écrit : net-nds/nsscache sys-auth/nss_ldap If nobody else want them and I don't forget about them, I'll take care of these. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] Re: Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On Sun, 2012-11-18 at 17:19 +, Duncan wrote: Diego Elio Pettenò posted on Sun, 18 Nov 2012 07:47:22 -0800 as excerpted: On 18/11/2012 07:43, Vadim A. Misbakh-Soloviov wrote: And, by the way, I doubt, that people laugh about eudev (previously named udev-ng) creation. Mostly they just can't understand why gentoo devs created third udev's fork, where it was already done (and maintained) fork for LFS (somewhere on bitbucket) People _are_ laughing at it. On G+, on Twitter, I suppose identi.ca and IRC as well. There's worse things than being laughed it. In fact, what's the oft-used- in-MS/Linux-context quote (Gandi if I'm not mistaken), something along the lines of... First they ignore you, then they laugh at you, then they fight you, then you win! If they're laughing, they're beyond the ignore stage. And we see evidence of the fight stage now too. If the idea behind that quote is correct... People keep repeating that quote implying that whenever somebody laughs at an idea it's because the idea is worth something, but that's illogical and in fact false: just because B(worthy idea) was preceded by A(laughter) doesn't mean that whenever there's A(laughter) then B(worthy idea) ensues http://xkcd.com/386/ -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. http://common-lisp.net/project/iolib signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Rich Freeman wrote: I think that there's a big difference about any developer being allowed to create a project under the gentoo umbrella and create a project and claim it as Gentoo sponsored without any review of the council. I agree that it can exists in the Github account, or even in our own infrastructure, but say that Gentoo supports it without a previous analysis of the council is wrong IMHO. In practice there is no difference. This thread demonstrates that there was significant *perceived* difference, and as has been pointed out Greg was just the voice of the internets. (Thanks Greg!) In practise, it is a git repo with commits by a few individuals. But because of where the git repo is located, because of the contents of the commits, and perhaps also because of misunderstanding, it was *perceived* to be something other than what it is. I think it's important to be attentive when such misperception occurs, both to be able to stop it from occuring again in the future, and to attempt clarification of things as quickly as possible. About the only sponsorship Gentoo projects get most of the time is hosting, and considering that they stuck this one on Github they're not really even getting that. The Gentoo brand is a lot more than infra's lovely hosting. That said, I see no reason why this project would be any less eligible for other forms of sponsorship than other projects are, assuming that somebody can make a compelling pitch for the Trustees. I don't think the issue was ever with eligibility, but with how $internet perceived that the Gentoo brand was acting. Yes, that's layers of fail, but the world isn't big on facts. In the end the brand that we all know and love got an unneccessary new dent, and the only thing we can do is to learn from that, to try to avoid that it happens again. However, there aren't real projects and wanna-be projects in Gentoo. Is this a good thing? I think both yes and no. A case could certainly be made for having sunrise projects, like there are sunrise ebuilds. //Peter
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 3:37 PM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: Yeah, but I think that there's a big difference about any developer being allowed to create a project under the gentoo umbrella and create a project and claim it as Gentoo sponsored without any review of the council. I agree that it can exists in the Github account, or even in our own infrastructure, but say that Gentoo supports it without a previous analysis of the council is wrong IMHO. In practice there is no difference. About the only sponsorship Gentoo projects get most of the time is hosting, and considering that they stuck this one on Github they're not really even getting that. That said, I see no reason why this project would be any less eligible for other forms of sponsorship than other projects are, assuming that somebody can make a compelling pitch for the Trustees. The Foundation is aimed to further Gentoo in particular in FOSS in general, so obviously we don't spend a lot on individual projects. When we do it tends to be in proportion to how it benefits the entire community, and I'm sure that community sentiments would be balanced accordingly. However, there aren't real projects and wanna-be projects in Gentoo. Rich Hmm, pretty cool! Then I can create a stupid project, put it on gentoo infra and claim it as being Gentoo sponsored. Good to know, thanks! Just to make it clear: I'm not saying that any of the people involved with udev-ng/eudev/whatever, or even the project itself, is stupid. I was just interpreting rich0's answer. Do whatever you people want, I'll stop caring about this topic. Best Regards, -- Rafael Goncalves Martins Gentoo Linux developer http://rafaelmartins.eng.br/
[gentoo-dev] gstreamer eclass review
Hi list,
gstreamer-1 has been around for some time now and it is needed for gnome
3.6 to enter the tree. Since gstreamer devs have been a bit busy irl, a
few guys from gnome herd decided to take a look at it and try to bump
everything. I had an itch to scratch wrt current eclass writing so I
decided to start with that and bump all plugins using these new eclasses
to see how they fare. The results seems to be a lot more pleasant to
read and easier to understand.
Since this is basically a rewrite, I'll attach the full files for review
and three ebuilds using it (one regular plugin, one plugin linking to
installed gstreamer libs and one of the ebuilds with no external
dependency.
The goal of these new eclasses is mainly to drop all revision dependent
code while maintaining (to some extent) backward compatibility with 0.10
slot ebuilds.
We are currently not planning on dropping the mostly empty eclasses just
in case there is a need for pack specific changes in the future.
The eclasses were already overlooked by gstreamer herd but I'd like more
eyes to go over them beforing pushing this to the tree.
Since this is mostly privates eclasses, I'd like to proceed to tree
inclusion by next week. There should be little to no breakage and this
would help bump last 0.10 releases as well.
--
Gilles Dartiguelongue e...@gentoo.org
Gentoo
# Copyright 1999-2012 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
# @ECLASS: gst-plugins10.eclass
# @MAINTAINER:
# gstrea...@gentoo.org
# @AUTHOR:
# Gilles Dartiguelongue e...@gentoo.org
# Saleem Abdulrasool compn...@gentoo.org
# foser fo...@gentoo.org
# zaheerm zahe...@gentoo.org
# @BLURB: Manages build for invididual ebuild for gst-plugins.
# @DESCRIPTION:
# Eclass to make external gst-plugins emergable on a per-plugin basis and
# to solve the problem with gst-plugins generating far too much unneeded
# dependancies.
#
# GStreamer consuming applications should depend on the specific plugins they
# need as defined in their source code.
#
# In case of spider usage, obtain recommended plugins to use from Gentoo
# developers responsible for gstreamer gstrea...@gentoo.org or the application
# developer.
# XXX: what was GST_ORC intended for. Isn't it better to leave it to the
# ebuild reponsability ?
inherit eutils multilib toolchain-funcs versionator
GST_EXPF=
case ${EAPI:-0} in
1|2|3|4|5)
GST_EXPF=${GST_EXPF} src_configure src_compile src_install
;;
0)
die EAPI=\${EAPI}\ is not supported anymore
;;
*)
die EAPI=\${EAPI}\ is not supported yet
;;
esac
EXPORT_FUNCTIONS ${GST_EXPF}
# @ECLASS-VARIABLE: GST_LA_PUNT
# @DESCRIPTION:
# Should we delete all the .la files?
# NOT to be used without due consideration.
if has ${EAPI:-0} 0 1 2 3; then
: ${GST_LA_PUNT:=no}
else
: ${GST_LA_PUNT:=yes}
fi
# @ECLASS-VARIABLE: GST_ORC
# @DESCRIPTION:
# Ebuild supports dev-lang/orc.
: ${GST_ORC:=no}
# @ECLASS-VARIABLE: GST_PLUGINS_BUILD
# @DESCRIPTION:
# Defines the plugins to be built.
# May be set by an ebuild and contain more than one indentifier, space
# seperated (only src_configure can handle mutiple plugins at this time).
GST_PLUGINS_BUILD=${PN/gst-plugins-/}
# @ECLASS-VARIABLE: GST_PLUGINS_BUILD_DIR
# @DESCRIPTION:
# Actual build directory of the plugin.
# Most often the same as the configure switch name.
GST_PLUGINS_BUILD_DIR=${PN/gst-plugins-/}
# @ECLASS-VARIABLE: GST_TARBALL_SUFFIX
# @DESCRIPTION:
# Most projects hosted on gstreamer.freedesktop.org mirrors provide tarballs as
# tar.bz2 or tar.xz. This eclass defaults to bz2 for EAPI 0, 1, 2, 3 and
# defaults to xz for everything else. This is because the gstreamer mirrors
# are moving to only have xz tarballs for new releases.
if has ${EAPI:-0} 0 1 2 3; then
: ${GST_TARBALL_SUFFIX:=bz2}
else
: ${GST_TARBALL_SUFFIX:=xz}
fi
# Even though xz-utils are in @system, they must still be added to DEPEND; see
# http://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
if [[ ${GST_TARBALL_SUFFIX} == xz ]]; then
DEPEND=${DEPEND} app-arch/xz-utils
fi
# @ECLASS-VARIABLE: GST_ORG_MODULE
# @DESCRIPTION:
# Name of the module as hosted on gstreamer.freedesktop.org mirrors.
# Leave unset if package name matches module name.
: ${GST_ORG_MODULE:=$PN}
# @ECLASS-VARIABLE: GST_ORG_PVP
# @INTERNAL
# @DESCRIPTION:
# Major and minor numbers of the version number.
: ${GST_ORG_PVP:=$(get_version_component_range 1-2)}
DESCRIPTION=${BUILD_GST_PLUGINS} plugin for gstreamer
HOMEPAGE=http://gstreamer.freedesktop.org/;
SRC_URI=http://gstreamer.freedesktop.org/src/${GST_ORG_MODULE}/${GST_ORG_MODULE}-${PV}.tar.${GST_TARBALL_SUFFIX};
LICENSE=GPL-2
SLOT=${GST_ORG_PVP}
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
# Do not run test phase for invididual plugin ebuilds.
RESTRICT=test
fi
RDEPEND=${RDEPEND}
[gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
Peter Stuge posted on Sun, 18 Nov 2012 19:00:59 +0100 as excerpted: Forget about the loader. Your knob is in a different configuration, specifically CONFIG_MODULES=n in the kernel. Just to note now that the specific topic has come up, yes, I am aware of and have that kernel option set to disable module loading. I was simply focusing on userland side, and thus didn't believe the kernel option apropos to that specific discussion. Still, just having a module loading userland on the system doesn't /increase/ security, and in fact, it slightly decreases it, on a system where a deliberate choice has been made to turn kernel module loading functionality off. -- 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
[gentoo-dev] Re: gstreamer eclass review
Gilles Dartiguelongue posted on Sun, 18 Nov 2012 20:06:30 +0100 as
excerpted:
It's admittedly a style thing thus pretty much up to the author, purely
bikeshedding in the original sense of the essay's trivial color choice,
but...
# Even though xz-utils are in @system, they must still be added to DEPEND; see
#
http://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
if [[ ${GST_TARBALL_SUFFIX} == xz ]]; then
DEPEND=${DEPEND} app-arch/xz-utils
fi
Single-clause conditional tests (without an else clause) such as the above
can be trivially rewritten like so:
[[ ${GST_TARBALL_SUFFIX} == xz ]] \
DEPEND=${DEPEND} app-arch/xz-utils
Two lines (or one if short enough) instead of three and more concise (fi
line omitted entirely, if omitted, ; then replaced with ).
It's possible to do similar with if/then/else - /||, but that may
require {} for clarity if not bash parsing, and IMO is not nearly as
clear as the more straightforward no-else-clause case. So if there's
an else clause, I prefer if/then/else; if not, I prefer the or || logic.
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
# Do not run test phase for invididual plugin ebuilds.
RESTRICT=test
fi
Another example, this one definitely a one-liner (plus comment,
invididual typo left intact)...
# Do not run test phase for invididual plugin ebuilds.
[[ ${PN} != ${GST_ORG_MODULE} ]] RESTRICT=test
Or, avoiding that ! in the test and changing the to ||...
[[ ${PN} == ${GST_ORG_MODULE} ]] || RESTRICT=test
Also, while we're here, test is a string-literal with no possibility of
spaces or anything else that could otherwise confuse bash, so needs no
quotes. And I'm not sure if the != pattern matching trigger was
deliberate or not (see bash's help [[ output). Thus...
[[ ${PN} = ${GST_ORG_MODULE} ]] || RESTRICT=test
... or...
[[ ${PN} == ${GST_ORG_MODULE} ]] || RESTRICT=test
... with the single vs. double equals making the string match (single) vs
pattern match (double) explicit. If the test-internal-not form is
retained, the string match form would be...
[[ ${PN} ! = ${GST_ORG_MODULE} ]] RESTRICT=test
... while the pattern match form would retain the != that was used
(the distinction being the separating space, != is a pattern match
as is ==, ! = is a string match as is a single = ).
# added to remove circular deps # 6/2/2006 - zaheerm
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
RDEPEND=${RDEPEND} media-libs/${GST_ORG_MODULE}:${SLOT}
fi
Ditto... Further examples skipped.
# @FUNCTION: gst-plugins10_src_install gst-plugins10_src_install() {
gst-plugins10_find_plugin_dir
if has ${EAPI:-0} 0 1 2 3 ; then
emake install DESTDIR=${D} || die
[[ -e README ]] dodoc README
else
default
fi
[[ ${GST_LA_PUNT} = yes ]] prune_libtool_files --modules
}
Here (last line before the function-closing }, as I said above, I prefer
if/then/else where there's an else clause, so wouldn't change the upper
conditional) we see a counter-example, doing it just as I suggested.
The if/then version (keeping function indent) would look like this.
if [[ ${GST_LA_PUNT} = yes ]]; then
prune_libtool_files --modules
fi
Of course regardless of that, the quotes around yes may be omitted as
it's a string literal. (And here, the explicit single-equals string-
literal match is used, as opposed to the double-equals pattern match. Of
course either one would work here as it's a trivial pattern, just noting
it for consistency.)
[[ ${GST_LA_PUNT} = yes ]] prune_libtool_files --modules
But as I said up top, that's (mostly, the pattern matching vs string
matching will occasionally bite if you're not on the lookout for it)
trivial style stuff. You may well prefer the way it is now. But in that
case, why the counter-example, omitting if/then? (You may of course
fairly point out that consistency is a trivial style thing too. =:^)
--
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] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 2:39 PM, Duncan wrote: Peter Stuge posted on Sun, 18 Nov 2012 19:00:59 +0100 as excerpted: Forget about the loader. Your knob is in a different configuration, specifically CONFIG_MODULES=n in the kernel. Just to note now that the specific topic has come up, yes, I am aware of and have that kernel option set to disable module loading. I was simply focusing on userland side, and thus didn't believe the kernel option apropos to that specific discussion. Still, just having a module loading userland on the system doesn't /increase/ security, and in fact, it slightly decreases it, on a system where a deliberate choice has been made to turn kernel module loading functionality off. Pointing out as a general statement, and not in response to anyone in particular, while I, too, am in the camp of minimalistic userlands, there is a kind of threshold one hits in this regard where keeping or removing something like a couple of module-loading utilities or systemd text files around really isn't going to increase or decrease your security /by that much/. /run-on-sentence I mean, if someone gains unauthorized access to the userland and somehow uses these unused components to launch an attack, successful or not, well, then there's a LOT of bigger problems to worry about. The goal of security isn't to prevent someone from gaining unauthorized access to a system, it's to deter them or otherwise make the effort required more than the potential gain. Design network firewalls well, audit the user accounts and review logs periodically, enabled hardened options, use PaX/grsec/selinux, deploy an IDS/IPS and a SEIM, etc...there's a lot of other things one can do that will have a bigger ROI on security than gutting module-loading tools or systemd scripts off of a system. Do I like them there? Not really (unless I'm developing a kernel driver, then modules come in handy). But it is what it is. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 2:04 PM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: On Sun, Nov 18, 2012 at 3:37 PM, Rafael Goncalves Martins Hmm, pretty cool! Then I can create a stupid project, put it on gentoo infra and claim it as being Gentoo sponsored. Good to know, thanks! Just to make it clear: I'm not saying that any of the people involved with udev-ng/eudev/whatever, or even the project itself, is stupid. I was just interpreting rich0's answer. However, your interpretation is perfectly correct - from GLEP 39: Note that this GLEP does not provide for a way for the community at large to block a new project, even if the comments are wholly negative. Arguably if somebody wants to be disruptive they can accomplish a lot more by trolling the lists than by starting projects. Judging by the general traffic on -dev, I'd say that everybody figured that out a long time ago. Oh, while anybody can start a project, the fact is that they all still fall under either the Council or Trustees, and they must abide by the policies set by both. Developers who cause trouble are still subject to Devrel. As somebody pointed out to me in email - the barriers to becoming a dev are high, but once you're in you have fairly free reign. I'd like to think that most of us would use that for the benefit of the community. What I can tell you for sure is that no amount of rules or bureaucracy is going to solve people problems - at best they just stifle them, and everything else. Rich
[gentoo-dev] Packages up for grabs due beandog retirement
app-misc/dailystrips app-misc/gramps dev-php/PEAR-PEAR dev-php/pear games-misc/fortune-mod-mormon games-misc/fortune-mod-scriptures media-libs/libbluray media-tv/ivtv-utils media-tv/ivtv media-video/mplayer-resume sys-fs/mhddfs x11-themes/gdm-themes Some of them are co-maintained but, if you want to take care of them, feel free to add you to metadata Thanks signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: gstreamer eclass review
Le dimanche 18 novembre 2012 à 20:45 +, Duncan a écrit : Gilles Dartiguelongue posted on Sun, 18 Nov 2012 20:06:30 +0100 as excerpted: [...] But as I said up top, that's (mostly, the pattern matching vs string matching will occasionally bite if you're not on the lookout for it) trivial style stuff. You may well prefer the way it is now. But in that case, why the counter-example, omitting if/then? (You may of course fairly point out that consistency is a trivial style thing too. =:^) I admittedly didn't really look for consistency in these details. I picked stuff from the 4 eclasses and merged them in one, having the gnome2 eclasses open for reference which might explain some inconsistencies in style. Anyway if you read all that up and only mailed about this, I guess you found no problem with the rest, right ? -- Gilles Dartiguelongue e...@gentoo.org Gentoo signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: gstreamer eclass review
On Sun, Nov 18, 2012 at 12:45 PM, Duncan 1i5t5.dun...@cox.net wrote:
Gilles Dartiguelongue posted on Sun, 18 Nov 2012 20:06:30 +0100 as
excerpted:
It's admittedly a style thing thus pretty much up to the author, purely
bikeshedding in the original sense of the essay's trivial color choice,
but...
# Even though xz-utils are in @system, they must still be added to DEPEND;
see
#
http://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
if [[ ${GST_TARBALL_SUFFIX} == xz ]]; then
DEPEND=${DEPEND} app-arch/xz-utils
fi
Single-clause conditional tests (without an else clause) such as the above
can be trivially rewritten like so:
[[ ${GST_TARBALL_SUFFIX} == xz ]] \
DEPEND=${DEPEND} app-arch/xz-utils
Two lines (or one if short enough) instead of three and more concise (fi
line omitted entirely, if omitted, ; then replaced with ).
http://www.quickmeme.com/meme/3ru1zx/
It's possible to do similar with if/then/else - /||, but that may
require {} for clarity if not bash parsing, and IMO is not nearly as
clear as the more straightforward no-else-clause case. So if there's
an else clause, I prefer if/then/else; if not, I prefer the or || logic.
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
# Do not run test phase for invididual plugin ebuilds.
RESTRICT=test
fi
Another example, this one definitely a one-liner (plus comment,
invididual typo left intact)...
# Do not run test phase for invididual plugin ebuilds.
[[ ${PN} != ${GST_ORG_MODULE} ]] RESTRICT=test
Or, avoiding that ! in the test and changing the to ||...
[[ ${PN} == ${GST_ORG_MODULE} ]] || RESTRICT=test
Also, while we're here, test is a string-literal with no possibility of
spaces or anything else that could otherwise confuse bash, so needs no
quotes. And I'm not sure if the != pattern matching trigger was
deliberate or not (see bash's help [[ output). Thus...
[[ ${PN} = ${GST_ORG_MODULE} ]] || RESTRICT=test
... or...
[[ ${PN} == ${GST_ORG_MODULE} ]] || RESTRICT=test
... with the single vs. double equals making the string match (single) vs
pattern match (double) explicit. If the test-internal-not form is
retained, the string match form would be...
[[ ${PN} ! = ${GST_ORG_MODULE} ]] RESTRICT=test
... while the pattern match form would retain the != that was used
(the distinction being the separating space, != is a pattern match
as is ==, ! = is a string match as is a single = ).
# added to remove circular deps # 6/2/2006 - zaheerm
if [[ ${PN} != ${GST_ORG_MODULE} ]]; then
RDEPEND=${RDEPEND} media-libs/${GST_ORG_MODULE}:${SLOT}
fi
Ditto... Further examples skipped.
# @FUNCTION: gst-plugins10_src_install gst-plugins10_src_install() {
gst-plugins10_find_plugin_dir
if has ${EAPI:-0} 0 1 2 3 ; then
emake install DESTDIR=${D} || die
[[ -e README ]] dodoc README
else
default
fi
[[ ${GST_LA_PUNT} = yes ]] prune_libtool_files --modules
}
Here (last line before the function-closing }, as I said above, I prefer
if/then/else where there's an else clause, so wouldn't change the upper
conditional) we see a counter-example, doing it just as I suggested.
The if/then version (keeping function indent) would look like this.
if [[ ${GST_LA_PUNT} = yes ]]; then
prune_libtool_files --modules
fi
Of course regardless of that, the quotes around yes may be omitted as
it's a string literal. (And here, the explicit single-equals string-
literal match is used, as opposed to the double-equals pattern match. Of
course either one would work here as it's a trivial pattern, just noting
it for consistency.)
[[ ${GST_LA_PUNT} = yes ]] prune_libtool_files --modules
But as I said up top, that's (mostly, the pattern matching vs string
matching will occasionally bite if you're not on the lookout for it)
trivial style stuff. You may well prefer the way it is now. But in that
case, why the counter-example, omitting if/then? (You may of course
fairly point out that consistency is a trivial style thing too. =:^)
--
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] Reminder: open season on robbat2's packages
On Sun, Nov 18, 2012 at 08:11:49AM -0800, Diego Elio Pettenò wrote: On 18/11/2012 03:11, Robin H. Johnson wrote: net-libs/libmonetra Maybe time to get rid of this one? https://bugs.gentoo.org/show_bug.cgi?id=341721 Gone. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 11:59 AM, Jason A. Donenfeld wrote: All I'm asking is some kind of coherent mission statement. How can we define a mission statement when we are still in the process of understanding the codebase, what it does well and what it can do better? A project announcement should answer your question. The reason we have not done it is because are still in the process of defining such things. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 12:37 PM, Rafael Goncalves Martins wrote: On Sun, Nov 18, 2012 at 3:32 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Nov 18, 2012 at 11:52 AM, Rafael Goncalves Martins rafaelmart...@gentoo.org wrote: Yeah, but I think that there's a big difference about any developer being allowed to create a project under the gentoo umbrella and create a project and claim it as Gentoo sponsored without any review of the council. I agree that it can exists in the Github account, or even in our own infrastructure, but say that Gentoo supports it without a previous analysis of the council is wrong IMHO. In practice there is no difference. About the only sponsorship Gentoo projects get most of the time is hosting, and considering that they stuck this one on Github they're not really even getting that. That said, I see no reason why this project would be any less eligible for other forms of sponsorship than other projects are, assuming that somebody can make a compelling pitch for the Trustees. The Foundation is aimed to further Gentoo in particular in FOSS in general, so obviously we don't spend a lot on individual projects. When we do it tends to be in proportion to how it benefits the entire community, and I'm sure that community sentiments would be balanced accordingly. However, there aren't real projects and wanna-be projects in Gentoo. Rich Hmm, pretty cool! Then I can create a stupid project, put it on gentoo infra and claim it as being Gentoo sponsored. Good to know, thanks! Those are the rules. We checked before we started. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2012-11-18 23h59 UTC
The attached list notes all of the packages that were added or removed from the tree, for the week ending 2012-11-18 23h59 UTC. Removals: app-crypt/cryptoapi 2012-11-15 18:15:12 pinkbyte x11-misc/pnmixer2012-11-17 18:07:22 hasufell sci-geosciences/qlandkarte 2012-11-18 11:19:45 hwoarang gnome-extra/wp_tray 2012-11-18 11:29:30 hwoarang dev-libs/mpatrol2012-11-18 11:31:00 hwoarang net-p2p/sancho-bin 2012-11-18 11:33:30 hwoarang media-sound/audtty 2012-11-18 11:37:48 hwoarang dev-vcs/svk 2012-11-18 11:40:14 hwoarang net-libs/libwww 2012-11-18 13:52:38 kensington net-libs/libmonetra 2012-11-18 23:13:08 robbat2 dev-php/pecl-mcve 2012-11-18 23:13:08 robbat2 Additions: sci-libs/suitesparseconfig 2012-11-12 01:44:44 bicatali games-strategy/s25rttr 2012-11-12 23:07:17 hasufell app-crypt/af_alg2012-11-13 00:47:18 robbat2 x11-wm/qtile2012-11-13 05:03:09 radhermit app-arch/pixz 2012-11-13 23:37:20 zerochaos dev-haskell/cereal 2012-11-14 22:02:35 slyfox dev-haskell/dbus2012-11-14 22:03:47 slyfox dev-embedded/dfu-programmer 2012-11-15 12:20:19 chainsaw dev-libs/fddl 2012-11-15 18:02:52 pinkbyte dev-util/obs-service-download_src_package 2012-11-15 20:00:31 scarabeus dev-util/obs-service-download_url 2012-11-15 20:05:00 scarabeus dev-util/obs-service-extract_file 2012-11-15 20:10:39 scarabeus dev-util/obs-service-generator_driver_update_disk 2012-11-15 20:46:01 scarabeus dev-util/obs-service-recompress 2012-11-15 20:50:30 scarabeus dev-util/obs-service-set_version2012-11-15 20:54:04 scarabeus dev-util/obs-service-verify_file2012-11-15 20:57:01 scarabeus dev-util/obs-service-meta 2012-11-15 21:03:58 scarabeus dev-util/obs-service-tar_scm2012-11-15 21:13:46 scarabeus x11-misc/pnmixer2012-11-16 00:20:24 hasufell dev-python/socketpool 2012-11-16 02:39:07 idella4 sci-mathematics/msieve 2012-11-16 03:32:43 patrick sci-mathematics/gmp-ecm 2012-11-16 03:58:16 patrick media-libs/elementary 2012-11-16 17:28:10 tommy dev-python/cov-core 2012-11-16 18:47:46 chutzpah dev-python/pytest-cov 2012-11-16 18:50:48 chutzpah games-kids/memonix 2012-11-17 07:56:14 mr_bones_ sec-policy/selinux-dbadm2012-11-17 16:20:02 swift media-plugins/evas_generic_loaders 2012-11-17 17:04:02 tommy media-sound/pnmixer 2012-11-17 18:05:11 hasufell sys-process/procenv 2012-11-17 21:23:51 radhermit dev-haskell/filemanip 2012-11-18 07:45:20 gienah sec-policy/selinux-logsentry2012-11-18 08:03:29 swift dev-haskell/unordered-containers2012-11-18 08:13:29 gienah dev-haskell/geniplate 2012-11-18 08:14:13 gienah sec-policy/selinux-makewhatis 2012-11-18 08:16:49 swift sec-policy/selinux-rtorrent 2012-11-18 09:28:22 swift dev-python/django-endless-pagination2012-11-18 12:04:34 idella4 dev-python/django-setuptest 2012-11-18 12:24:13 idella4 dev-haskell/async 2012-11-18 12:56:20 gienah media-libs/emotion 2012-11-18 18:39:41 tommy -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Removed Packages: app-crypt/cryptoapi,removed,pinkbyte,2012-11-15 18:15:12 x11-misc/pnmixer,removed,hasufell,2012-11-17 18:07:22
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 3:25 PM, Richard Yao r...@gentoo.org wrote: On 11/18/2012 11:59 AM, Jason A. Donenfeld wrote: All I'm asking is some kind of coherent mission statement. How can we define a mission statement when we are still in the process of understanding the codebase, what it does well and what it can do better? Most people would have a reason to fork before forking. Or maybe mission statement != reasons and we're having a communication breakdown.
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 01:51:14AM -0600, Canek Pel??ez Vald??s wrote ... systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important features one could have. https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 You're missing the point entirely. Yes, the systemd people are working for the good of systemd. Nobody denies that. Your post does not address the fact that Kay and Lennart hold standalone udev in contempt, and treat it as a 2nd-class citizen. Note that Richard Yao is *NOT* forking systemd. He is forking udev, which addresses the issue of Kay's+Lennart's hostility to standalone udev on non-systemd setups. I, and a lot of other people, would like to use a sane standalone udev (from the Greg KH days) without systemd's dependancies/restrictions. That is the target market for a udev fork. -- Walter Dnes waltd...@waltdnes.org We are apparently better off trying to avoid udev like the plague. Linus Torvalds; 2012/10/03 https://lkml.org/lkml/2012/10/3/349
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:52:22PM -0800, Greg KH wrote
Yes, I know all about the firmware issue with media drivers. It's now
resolved and fixed, in two different ways (the kernel now loads firmware
directly, and on older kernels, udev has fixed the issue.) So that's no
longer an issue for anyone.
The fact that they went ahead with changes, knowing full well it would
break stuff, is reason enough to distrust them in future. It should not
require a rant from Linus, or a workaround in the kernel, to get them to
fix their bugs.
It's also a pretty simple set of patches that Gentoo can keep around
if it's really a serious issue for people.
That may be true today. But as udev gets more tightly integrated into
systemd, those patches will become a dead end, to use Lennart's words.
Note, a separate /usr has been broken for a while now, udev is just
pointing the issue out. And again, if you want a separate /usr, just
use an initrd, the solution is simple.
I have 4 broken Gentoo systems running just fine, without an
initrd, thank you. There have always been a few edge-case setups that
won't work with a separate /usr, without an initrd. What annoys me is
this dog-in-the-manger attitude that if a separate /usr is broken for a
few people, then by golly, it should be broken for everybody.
The fact that Gentoo is alone in wanting to build udev, without systemd
dependencies being on the system, is something that if I were the
systemd maintainer, I would reject.
There is obviously no point in us continuing this debate. You are in
favour of systemd, I am not.
--
Walter Dnes waltd...@waltdnes.org
We are apparently better off trying to avoid udev like the plague.
Linus Torvalds; 2012/10/03 https://lkml.org/lkml/2012/10/3/349
[gentoo-dev] Copyright issues (Was: udev-ng?)
On Sun, Nov 18, 2012 at 07:06:50AM -0500, Rich Freeman wrote: COPYRIGHT I think this issue is best dealt with on the side - it has no bearing on any of the really contentious points here. I note that the owners of the copyright on udev have announced to the world that (emphasis mine): You may modify your copy or copies of the Library or ANY PORTION OF IT, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions... None of those conditions included keeping the copyright line intact. True, but removing a copyright line doesn't change the real copyright of a file, although it is generally considered something that you really should not do at all (see your local copyright laws/rules for details.) Anybody can therefore alter the copyright line as they wish, as they have been given explicit permission to do so. They need only comply with the other terms in the LGPL to do so (the most important being licensing it under the LGPL and making the source available. Heh, wait, no, you can not do that. You can not modify a copyright line to add your own, without first doing one of the two things I discussed in the beginning. Otherwise, don't you think that all of those big companies that are using Linux and other open source projects would have done something like this already? In fact, (L)GPL v3 has an optional attribution clause, and the fact that they made this explicit is because some projects might not want to give out this authorization. Changing the lines in the comment block in the code files is not what attribution clauses are about at all. I could go into details about copyright, and how it works, and how you need to treat it if you are a programmer, but I'm not a lawyer, and the rules are different in different countries and even states. I have, however, worked with a very large number of lawyers, and companies, and have the basics down, and none of what you say above is really allowed at all, sorry. Also note, if you just remove code from a file, you don't get copyright of the file, which is a fun thing to think about if you are trying to remove features from a product, or doing 'git revert' of specific patchsets. So, if you want an official ruling from the trustees we would need to meet/vote on it and perhaps discuss with counsel, but my thinking is that anybody distributing work under the (L)GPL has waived their right to be named on the copyright line of any copies distributed by others, Again, no, this is flat out not right. Please discuss with counsel if you disagree and they can go into the details. and as far as I can tell I have found nothing to the contrary from any authoritative source. Talk to a copyright lawyer please. I'm sure there is one that the Foundation uses, right? Again, that's my two cents and not a license for anybody to do anything. This topic did come up recently with regard to accepting some other kind of outside work into Gentoo, and as I recall there was some debate over whether the copyright notices could be changed. I'd have to dig up the details - I think the issue might have been mooted before any kind of formal decision was reached... I think this is something that the Foundation's counsel better get set up properly, as it really is a big deal, and can come back to cause big problems if done wrong. I say this as someone who has been part of lawsuits dealing with this type of thing, and as someone who has worked with lawyers on copyright issues for open source projects for a very long time[1]. But as always, talk to a lawyer, I suggest that the Foundation do this to set up the proper guidelines and rules that all Gentoo developers need to follow. That will clear all of this confusion up properly. thanks, greg k-h [1] I've worked with them so much, that I'm a continuing education credit for lawyers in the USA when I give one of my various talks about how open source projects are developed, and how the copyright and license issues work within them.
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 08:50:07PM -0500, Walter Dnes wrote:
On Sat, Nov 17, 2012 at 11:52:22PM -0800, Greg KH wrote
Yes, I know all about the firmware issue with media drivers. It's now
resolved and fixed, in two different ways (the kernel now loads firmware
directly, and on older kernels, udev has fixed the issue.) So that's no
longer an issue for anyone.
The fact that they went ahead with changes, knowing full well it would
break stuff, is reason enough to distrust them in future. It should not
require a rant from Linus, or a workaround in the kernel, to get them to
fix their bugs.
That's the fun of working with people you don't have direct control
over. Bugs get fixed on different schedules than what you sometimes
like. This specific issue, as it was hit by only a very small number of
people, and two distros had work-around patches in their udev packages,
was missed by a lot of people, myself included. I honestly thought that
it had been fixed months ago.
Sometimes a rant, or just reminding people, is all that is needed to get
issues fixed. And it worked here quite well, don't you think?
Actually, I would argue that it worked even better than if the issue had
been worked-around in udev in the very beginning when it first came up.
Now the kernel has changed to allow udev to remove the whole firmware
loading logic, which arguably, should have been done in the very
beginning. So you might say that because of people forgetting about
this, and people ranting, everyone is much better off in the end.
It's a bizarre development model, I know. :)
It's also a pretty simple set of patches that Gentoo can keep around
if it's really a serious issue for people.
That may be true today. But as udev gets more tightly integrated into
systemd, those patches will become a dead end, to use Lennart's words.
What patches? udevd builds for me just fine without building the
systemd binary. The developers even have a whole web page set up for
how to do this properly if you need to do so.
Note, a separate /usr has been broken for a while now, udev is just
pointing the issue out. And again, if you want a separate /usr, just
use an initrd, the solution is simple.
I have 4 broken Gentoo systems running just fine, without an
initrd, thank you. There have always been a few edge-case setups that
won't work with a separate /usr, without an initrd. What annoys me is
this dog-in-the-manger attitude that if a separate /usr is broken for a
few people, then by golly, it should be broken for everybody.
Again, udev isn't the problem here. It hasn't broken the standalone
/usr issue at all. There isn't anything in udev to change for this. I
don't understand why you are thinking that udev has anything to do with
this issue at all. It's other packages that are the problem here. Are
people forking and changing them to resolve the problem? If not, why
not?
thanks,
greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 08:13:55PM -0500, Walter Dnes wrote: On Sun, Nov 18, 2012 at 01:51:14AM -0600, Canek Pel??ez Vald??s wrote ... systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important features one could have. https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 You're missing the point entirely. Yes, the systemd people are working for the good of systemd. Nobody denies that. Your post does not address the fact that Kay and Lennart hold standalone udev in contempt, and treat it as a 2nd-class citizen. Note that Richard Yao is *NOT* forking systemd. He is forking udev, which addresses the issue of Kay's+Lennart's hostility to standalone udev on non-systemd setups. I, and a lot of other people, would like to use a sane standalone udev (from the Greg KH days) without systemd's dependancies/restrictions. That is the target market for a udev fork. Heh, you really don't want udev from back in the Greg KH days. Seriously, if you want that, go use mdev, but even then, it has more features than when I was still running the udev project. I find it a bit funny that people are so stuck on using udev now, they seem to have forgotten all of these same kinds of arguments way back when udev first came out (No one is going to force me to use udev!). Thanks to Kay's fine work, that is no longer an issue at all. Without him, you wouldn't be arguing to keep using it so much. And note, Kay and Lennart are _not_ treating udev as a second-class citizen. It's required for systemd to work properly, and other distros (like Ubuntu), use it for their systems to work properly in a stand-alone manner. So breaking that will not happen, lots of people will ensure that that does not happen, myself included. thanks, greg k-h
Re: [gentoo-dev] Copyright issues (Was: udev-ng?)
On Sun, Nov 18, 2012 at 9:58 PM, Greg KH gre...@gentoo.org wrote: True, but removing a copyright line doesn't change the real copyright of a file, although it is generally considered something that you really should not do at all (see your local copyright laws/rules for details.) Agreed that removing the line does not change the actual copyright of the file, well, aside from anything new you stick on that line. I'm not convinced that it is something you can't do if you're explicitly given permission to do so by the copyright holder. Again, no, this is flat out not right. Please discuss with counsel if you disagree and they can go into the details. Well, certainly something worth doing in any case. I think any answer given by anybody is going to be speculative, as doubt that any court has ruled on whether removing names from a copyright line licensed under the GPL is illegal. There are fairly few rulings of any kind concerning the GPL. Copyright just wasn't really written with copyleft in mind. I suspect, as a result, that most lawyers would basically listen to my argument and say well, sure, you can argue that, and a judge might or might not buy it, but do you really want to be sued over this to find out? That's the issue with the law in most jurisdictions - the only way you can truly find out if something is illegal is for somebody to try it and go to court. After all, who would have thought that you could patent round corners? Suppose I send you a program that I've copyrighted. It has a line on it saying Copyright 2012 - Richard Freeman - see accompanying license file. on it. I tell you that I don't mind if you remove the copyright line. Can you remove it? Now, suppose instead I tell you that you can make any change you want in the file - can you remove it now? Now suppose I tell you that you can make any change in the file that you want, as long as the copyright line says see accompanying license file and that file is intact. Can you remove the name? That's the issue here - the copyright owner has given me a license to do various things, including modify the file, and the file contains the copyright line. So, what normally would be illegal may in fact be legal after all. But, the only way to really be sure is to try it and get sued. And if you want to know how the law works in every country, you'd need to be sued in every country. Certainly interested in arguments to the contrary. Rich
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 10:06 PM, Greg KH wrote:
On Sun, Nov 18, 2012 at 08:50:07PM -0500, Walter Dnes wrote:
It's a bizarre development model, I know. :)
Works better than Windows' model:
http://moishelettvin.blogspot.com/2006/11/windows-shutdown-crapfest.html
(Okay, old, and I know MS has since fixed this, but it's still funny)
Note, a separate /usr has been broken for a while now, udev is just
pointing the issue out. And again, if you want a separate /usr, just
use an initrd, the solution is simple.
I have 4 broken Gentoo systems running just fine, without an
initrd, thank you. There have always been a few edge-case setups that
won't work with a separate /usr, without an initrd. What annoys me is
this dog-in-the-manger attitude that if a separate /usr is broken for a
few people, then by golly, it should be broken for everybody.
Again, udev isn't the problem here. It hasn't broken the standalone
/usr issue at all. There isn't anything in udev to change for this. I
don't understand why you are thinking that udev has anything to do with
this issue at all. It's other packages that are the problem here. Are
people forking and changing them to resolve the problem? If not, why
not?
Correct me if wrong, but didn't the issue start with udev wanting to put the
PCI ID database/file into /usr/share from /etc? Then kmod was changed to
link against libs in /usr/lib, and then udev made dependent on kmod? I
think that led to a scenario where openrc starts udev up before localmount
has run, and then things fall apart.
Not that I'm saying that implicates udev as the center of the sep-usr thing,
but if my memory is correct, that's kinda what got the ball rolling down the
hill. Or something close to it, anyways.
In any event, I did the switch to mdev, and it works. It is a hack, though,
I'll admit that. But if you're one of those types that runs a fairly
vanilla, not-very-fancy system that has had a separate /usr for a number of
years (2005 for most of my machines), it's a relatively painless transition
and it doesn't require the initramfs and it avoids having to
backup/format/restore each system. Obviously, if I need more advanced
functionality on any of my systems, I'll probably have to switch back, but
we'll see what the future holds.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3 2011-03-28
The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between.
--Emperor Turhan, Centauri Republic
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 18/11/2012 19:38, Joshua Kinard wrote: Correct me if wrong, but didn't the issue start with udev wanting to put the PCI ID database/file into /usr/share from /etc? Then kmod was changed to link against libs in /usr/lib, and then udev made dependent on kmod? I think that led to a scenario where openrc starts udev up before localmount has run, and then things fall apart. I honestly can't remember if pci.ids was ever in /etc — I always knew it in /usr/share/misc... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Copyright issues (Was: udev-ng?)
On 11/18/2012 09:58 PM, Greg KH wrote: On Sun, Nov 18, 2012 at 07:06:50AM -0500, Rich Freeman wrote: COPYRIGHT I think this issue is best dealt with on the side - it has no bearing on any of the really contentious points here. I note that the owners of the copyright on udev have announced to the world that (emphasis mine): You may modify your copy or copies of the Library or ANY PORTION OF IT, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions... None of those conditions included keeping the copyright line intact. True, but removing a copyright line doesn't change the real copyright of a file, although it is generally considered something that you really should not do at all (see your local copyright laws/rules for details.) Anybody can therefore alter the copyright line as they wish, as they have been given explicit permission to do so. They need only comply with the other terms in the LGPL to do so (the most important being licensing it under the LGPL and making the source available. Heh, wait, no, you can not do that. You can not modify a copyright line to add your own, without first doing one of the two things I discussed in the beginning. Otherwise, don't you think that all of those big companies that are using Linux and other open source projects would have done something like this already? In fact, (L)GPL v3 has an optional attribution clause, and the fact that they made this explicit is because some projects might not want to give out this authorization. Changing the lines in the comment block in the code files is not what attribution clauses are about at all. I could go into details about copyright, and how it works, and how you need to treat it if you are a programmer, but I'm not a lawyer, and the rules are different in different countries and even states. I have, however, worked with a very large number of lawyers, and companies, and have the basics down, and none of what you say above is really allowed at all, sorry. Also note, if you just remove code from a file, you don't get copyright of the file, which is a fun thing to think about if you are trying to remove features from a product, or doing 'git revert' of specific patchsets. So, if you want an official ruling from the trustees we would need to meet/vote on it and perhaps discuss with counsel, but my thinking is that anybody distributing work under the (L)GPL has waived their right to be named on the copyright line of any copies distributed by others, Again, no, this is flat out not right. Please discuss with counsel if you disagree and they can go into the details. and as far as I can tell I have found nothing to the contrary from any authoritative source. Talk to a copyright lawyer please. I'm sure there is one that the Foundation uses, right? Again, that's my two cents and not a license for anybody to do anything. This topic did come up recently with regard to accepting some other kind of outside work into Gentoo, and as I recall there was some debate over whether the copyright notices could be changed. I'd have to dig up the details - I think the issue might have been mooted before any kind of formal decision was reached... I think this is something that the Foundation's counsel better get set up properly, as it really is a big deal, and can come back to cause big problems if done wrong. I say this as someone who has been part of lawsuits dealing with this type of thing, and as someone who has worked with lawyers on copyright issues for open source projects for a very long time[1]. But as always, talk to a lawyer, I suggest that the Foundation do this to set up the proper guidelines and rules that all Gentoo developers need to follow. That will clear all of this confusion up properly. thanks, greg k-h We develop open source software in public repositories. A developer decided it would be helpful to change the software name systemd to eudev, among other things, in various files after misunderstanding what the Foundation officers in charge of legal matters had approved. You objected to it. I asked for clarification after seeing that your name had not been removed from any copyright notices. You explained your complaint. I asked you to wait for the person who wrote the commit to fix it. It was fixed. That is all that was necessary. Whining on the list did not wake the author of that commit sooner. Furthermore, the changes that you wanted would have been made in a few days had you not become involved. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Copyright issues (Was: udev-ng?)
On Sun, Nov 18, 2012 at 11:05:05PM -0500, Richard Yao wrote: On 11/18/2012 09:58 PM, Greg KH wrote: an on-topic discussion about copyright thread response from me snipped We develop open source software in public repositories. A developer decided it would be helpful to change the software name systemd to eudev, among other things, in various files after misunderstanding what the Foundation officers in charge of legal matters had approved. You objected to it. I asked for clarification after seeing that your name had not been removed from any copyright notices. You explained your complaint. I asked you to wait for the person who wrote the commit to fix it. It was fixed. That is all that was necessary. Whining on the list did not wake the author of that commit sooner. Furthermore, the changes that you wanted would have been made in a few days had you not become involved. None of the words you wrote here seem to me to be related to my response about copyright, the Gentoo Foundation, and how copyright works for software projects at all. So I'm a bit confused, what are you concerned about here? greg k-h
[gentoo-dev] Re: gstreamer eclass review
Gilles Dartiguelongue posted on Sun, 18 Nov 2012 23:59:44 +0100 as excerpted: Anyway if you read all that up and only mailed about this, I guess you found no problem with the rest, right ? Yes, but I already admitted to bikeshedding the easy stuff, so I'd honestly not assign too much review weight to 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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 07:42:11PM -0800, Diego Elio Pettenò wrote: On 18/11/2012 19:38, Joshua Kinard wrote: Correct me if wrong, but didn't the issue start with udev wanting to put the PCI ID database/file into /usr/share from /etc? Then kmod was changed to link against libs in /usr/lib, and then udev made dependent on kmod? I think that led to a scenario where openrc starts udev up before localmount has run, and then things fall apart. I honestly can't remember if pci.ids was ever in /etc — I always knew it in /usr/share/misc... Yes, it was always in /usr/somewhere. And the pci.ids file came from the pciutils package, not udev. But note, we are moving that file out of pciutils (and the usb.ids file out of usbutils) and they will eventually be generated from the udev package itself, as it holds the master hardware database. But that's a totally different topic than the one at hand, and is still being worked on by the developers of the different upstream packages. thanks, greg k-h
Re: [gentoo-dev] Copyright issues (Was: udev-ng?)
On Sun, Nov 18, 2012 at 10:29:35PM -0500, Rich Freeman wrote: On Sun, Nov 18, 2012 at 9:58 PM, Greg KH gre...@gentoo.org wrote: True, but removing a copyright line doesn't change the real copyright of a file, although it is generally considered something that you really should not do at all (see your local copyright laws/rules for details.) Agreed that removing the line does not change the actual copyright of the file, well, aside from anything new you stick on that line. I'm not convinced that it is something you can't do if you're explicitly given permission to do so by the copyright holder. Talk to a lawyer if you disagree with this. The area of copyright law, and software, is very well defined (with one exception of the major change to add your copyright, and even then, there's an agreed apon standard to follow). Because of that, I disagree that you think this is something that is unknown at all. But I'm not going to be able to change your mind :) Please get the Foundation to write up the rules apon which Gentoo developers need to handle the copyright mark, so that there's no disagreement as to what to do, in any type of situation. thanks, greg k-h
Re: [gentoo-dev] Copyright issues (Was: udev-ng?)
On Sun, Nov 18, 2012 at 11:21:20PM -0500, Richard Yao wrote: On 11/18/2012 11:22 PM, Greg KH wrote: On Sun, Nov 18, 2012 at 11:05:05PM -0500, Richard Yao wrote: On 11/18/2012 09:58 PM, Greg KH wrote: an on-topic discussion about copyright thread response from me snipped We develop open source software in public repositories. A developer decided it would be helpful to change the software name systemd to eudev, among other things, in various files after misunderstanding what the Foundation officers in charge of legal matters had approved. You objected to it. I asked for clarification after seeing that your name had not been removed from any copyright notices. You explained your complaint. I asked you to wait for the person who wrote the commit to fix it. It was fixed. That is all that was necessary. Whining on the list did not wake the author of that commit sooner. Furthermore, the changes that you wanted would have been made in a few days had you not become involved. None of the words you wrote here seem to me to be related to my response about copyright, the Gentoo Foundation, and how copyright works for software projects at all. So I'm a bit confused, what are you concerned about here? greg k-h Your issue has been resolved. You can stop beating the dead horse now. I was responding to a discussion about how copyright works, and how it should be marked as such for Gentoo-related projects, that was not correct in my knowledge of copyright law. It had nothing to do with my issue, or the udev issue at all, which is why I even changed the subject. Oh well. *plonk*
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 18/11/2012 20:28, Greg KH wrote: But note, we are moving that file out of pciutils (and the usb.ids file out of usbutils) and they will eventually be generated from the udev package itself, as it holds the master hardware database. But that's a totally different topic than the one at hand, and is still being worked on by the developers of the different upstream packages. *cough* Gentoo already moved them out of the respective packages into hwids btw, which I've been bumping almost daily for a while and weekly now because I got bored. And while at it I'm also always submitting any new data to the master databases since I end up often enough having some extra gadget around... (If you're thinking of replacing pci/usb ids with a formatted complex database, yai! Finally you guys followed my suggestion from 2008 ;)). /off topic -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On 18 November 2012 16:41, Robin H. Johnson robb...@gentoo.org wrote: [...] media-sound/dbmeasure I'll take this one, since it's tangentially related to PulseAudio. Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 11:28 PM, Greg KH wrote: Yes, it was always in /usr/somewhere. And the pci.ids file came from the pciutils package, not udev. But note, we are moving that file out of pciutils (and the usb.ids file out of usbutils) and they will eventually be generated from the udev package itself, as it holds the master hardware database. But that's a totally different topic than the one at hand, and is still being worked on by the developers of the different upstream packages. Okay, maybe it's just the kmod thing I am thinking of then. Thanks! -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Reminder: open season on robbat2's packages
On Mon, Nov 19, 2012 at 10:43:44AM +0530, Arun Raghavan wrote: On 18 November 2012 16:41, Robin H. Johnson robb...@gentoo.org wrote: [...] media-sound/dbmeasure I'll take this one, since it's tangentially related to PulseAudio. Speaking of PA, are you still upstream? If so, can you please merge the patch I submitted to the -discuss list? -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
RE : [gentoo-dev] Ohloh Organizations - Gentoo Linux
That's probably some topic for gentoo-project ml.
