[gentoo-dev] GPL violations with net-misc/vpnc?
Hi, as URL:http://www.gnome.org/~markmc/openssl-and-the-gpl.html states, distributing binaries of GPL programs linked against OpenSSL is illegal. New 0.5.0 has optional support for hybrid certificate authentication which can be enabled by editing the Makefile (using OpenSSL). While we are not distributing binaries, I could easily add a USE flag to enable it; the user compiles it himself, so it is all fine. But now regard the existence of binary hosts, are they distributions of then illegal binaries? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] GPL violations with net-misc/vpnc?
Hi, While we are not distributing binaries, I could easily add a USE flag to enable it; the user compiles it himself, so it is all fine. But now regard the existence of binary hosts, are they distributions of then illegal binaries? isn't bindist useflag made for this purpose ? $ grep bindist /usr/portage/profiles/use.desc bindist - Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues) Alexis. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] baselayout-2 LVM
Is it *supposed* to NOT startup automatically out of the box?
Looks like there are some emails on this list about there being only
stubs to support LVM, etc. I found some startup functions in
rcscripts/addons, but nothing to actually call them at startup? There
is some stuff in conf.d/volumes which suggests that there is support for
changing the scan order, but again, couldn't spot anything which used it?
I simply copied /etc/init.d/device-mapper and tweaked it as shown below
and now LVM starts up at boot for me (note that I am using it on top of
md raid1 in case that's relevant). Perhaps this could be added to the
new baselayout unless there is a better solution?
Cheers
Ed W
#!/sbin/runscript
# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: Exp $
depend() {
if [ -e /lib/librc.so ]; then
# on baselayout-1 this causes
# a dependency loop with checkroot (before *)
before checkroot
fi
}
start() {
if [ ! -e /lib/librc.so ]; then
eerror The ${SVCNAME} init script is written for
baselayout-2
eerror Please do not use it with baselayout-1
return 1
fi
. /lib/rcscripts/addons/lvm-start.sh
}
stop() {
if [ ! -e /lib/librc.so ]; then
eerror The ${SVCNAME} init script is written for
baselayout-2
eerror Please do not use it with baselayout-1
return 1
fi
. /lib/rcscripts/addons/lvm-stop.sh
}
--
[EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 LVM
On Friday 31 August 2007 09:18:53 Ed W wrote: Is it *supposed* to NOT startup automatically out of the box? Looks like there are some emails on this list about there being only stubs to support LVM, etc. I found some startup functions in rcscripts/addons, but nothing to actually call them at startup? There is some stuff in conf.d/volumes which suggests that there is support for changing the scan order, but again, couldn't spot anything which used it? Well, the scripts got phased out to the packages that actually *provide* this functionality. You will basically need to remerge sys-fs/lvm2 and sys-fs/device-mapper and add them (/etc/init.d/device-mapper and /etc/init.d/lvm) to your boot runlevel. Regards, Christian -- Christian Heim phreak at gentoo.org GPG key ID: 9A9F68E6 Fingerprint: AEC4 87B8 32B8 4922 B3A9 DF79 CAE3 556F 9A9F 68E6 signature.asc Description: This is a digitally signed message part.
[gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Hi there! What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Friday 31 of August 2007 12:37:57 Matthias Schwarzott wrote: What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. That's what I did locally so fine by me. -- Best Regards, Piotr Jaroszyński -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 LVM
You will basically need to remerge sys-fs/lvm2 and sys-fs/device-mapper and Darn, sorry for the noise Didn't think to check the masked packages - however, there it is clear as day in the changelog... Thanks Ed W -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] baselayout-2 LVM
On Freitag, 31. August 2007, Ed W wrote: You will basically need to remerge sys-fs/lvm2 and sys-fs/device-mapper and Darn, sorry for the noise Didn't think to check the masked packages - however, there it is clear as day in the changelog... Well, this is not true, because neither device-mapper not lvm2 are listed in package.mask. Checking the ebuilds: device-mapper: 30 Apr 2007; Daniel Drake [EMAIL PROTECTED] +files/device-mapper.rc, +device-mapper-1.02.18-r1.ebuild: Add baselayout-2 init script The latest stable version of device-mapper is 1.02.19-r1 and this contains the init-script. lvm2: 09 May 2007; Doug Goldstein [EMAIL PROTECTED] +files/lvm.rc, lvm2-2.02.17.ebuild: added baselayout-2 compatible init script from bug #175983 For lvm2 this was added without increasing the ebuild revision, but later there were some updates of lvm2, so all users of ~arch that are up to date should have this. Maybe baselayout2 could get some blockers against too old versions of device-mapper/lvm2. Greetings Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? Matthias Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Fri, 31 Aug 2007 16:12:52 +0300 Petteri Räty [EMAIL PROTECTED] wrote: Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? Matthias Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? No, that wouldn't work. However they could add '-/etc/udev/rules.d' to CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT. Marius -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Friday 31 August 2007, Marius Mauch wrote: Petteri Räty [EMAIL PROTECTED] wrote: Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: Hi there! What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? No, that wouldn't work. However they could add '-/etc/udev/rules.d' to CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT. either solution sucks the question is, should people be modifying the default rules ? is there something in the default rules file that they cant accomplish in a sep rules file ? if so, then the dir cant be masked ... -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: GPL violations with net-misc/vpnc?
Alexis Ballier [EMAIL PROTECTED]: While we are not distributing binaries, I could easily add a USE flag to enable it; the user compiles it himself, so it is all fine. But now regard the existence of binary hosts, are they distributions of then illegal binaries? isn't bindist useflag made for this purpose ? Great. Thanks...so what is common practice? Should the ebuild die, telling people a feature will not be included or just exclude it with an ewarn only? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Packages UP for grabs
On Thu, 30 Aug 2007 19:46:39 +0200 Alexis Ballier [EMAIL PROTECTED] wrote: video: - media-video/qc-usb (liquidx) wouldn't tv be better suited here ? Only if you point your qc-usb at your tv. :) Kind regards, JeR -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
Hi! On Fri, 31 Aug 2007, Mike Frysinger wrote: On Friday 31 August 2007, Marius Mauch wrote: Petteri Räty [EMAIL PROTECTED] wrote: Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? No, that wouldn't work. However they could add '-/etc/udev/rules.d' to CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT. either solution sucks the question is, should people be modifying the default rules ? is there something in the default rules file that they cant accomplish in a sep rules file ? if so, then the dir cant be masked ... I find the persisten-net-generator.rules particularly annoying (for various reasons including, but not limited to system images and system cloning). So I have an empty file of that name and happily nuke whatever comes along with udev updates. I could of course unmask that file if it were to be masked in the future. Still, this reeks of layers upon layers of customization to me. I'd prefer a more elegant solution - although know of none. The classic approach would be a USE flag to toggle installation of the shipped udev files - which wouldn't work for me, as I only have gripes about *one* of them. There probably simply isn't a simple, elegant solution that is a) not wrong and b) works for just about everybody. Regards, Tobias -- In the future, everyone will be anonymous for 15 minutes. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: GPL violations with net-misc/vpnc?
On Fri, 2007-31-08 at 16:31 +0200, Christian Faulhammer wrote: Alexis Ballier [EMAIL PROTECTED]: While we are not distributing binaries, I could easily add a USE flag to enable it; the user compiles it himself, so it is all fine. But now regard the existence of binary hosts, are they distributions of then illegal binaries? isn't bindist useflag made for this purpose ? Great. Thanks...so what is common practice? Should the ebuild die, telling people a feature will not be included or just exclude it with an ewarn only? With bindist, you should just disable any non-distributable feature and print a ewarn.. Dieing is not nice since its used to build the stages, etc. -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: GPL violations with net-misc/vpnc?
Christian Faulhammer wrote: Alexis Ballier [EMAIL PROTECTED]: While we are not distributing binaries, I could easily add a USE flag to enable it; the user compiles it himself, so it is all fine. But now regard the existence of binary hosts, are they distributions of then illegal binaries? Definitely. IIRC distribution within an organisation doesn't count as distribution under the GPL but I am not a lawyer. (Nor do I like that acronym: my eyeballs survive reading it tho ;) Any public binhost like tinderbox[1] would be unable to make binaries available. isn't bindist useflag made for this purpose ? Great. Thanks...so what is common practice? Should the ebuild die, telling people a feature will not be included or just exclude it with an ewarn only? Dunno what common practice is, but from a user perspective, it's much better if the binhost compiles without the feature than dies altogether. An ewarn/elog about bindist is sufficient for any competent admin (and newbs can search site:forums.gentoo.org or whinge on IRC, where they shall be gently enlightened ;) [1] http://tinderbox.dev.gentoo.org/html/default-linux/ -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: GPL violations with net-misc/vpnc?
Olivier Crête [EMAIL PROTECTED]: Great. Thanks...so what is common practice? Should the ebuild die, telling people a feature will not be included or just exclude it with an ewarn only? With bindist, you should just disable any non-distributable feature and print a ewarn.. Dieing is not nice since its used to build the stages, etc. Olivier, Steve, thanks. So I will just emit an ewarn in the ebuild...that way Gentoo will be the only major distribution shipping hybrid auth in vpnc. Yay! Other source based will offer it, too, though. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Fri, 2007-08-31 at 18:13 +0200, Tobias Klausmann wrote: I find the persisten-net-generator.rules particularly annoying (for various reasons including, but not limited to system images and system cloning). So I have an empty file of that name and happily nuke whatever comes along with udev updates. I could of course unmask that file if it were to be masked in the future. INSTALL_MASK = [space delimited list of file names] Use this variable if you want to selectively prevent certain files from being copied into your file system tree. This does not work on symlinks, but only on actual files. Useful if you wish to filter out files like HACKING.gz and TODO.gz. Philipp -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK
On Freitag, 31. August 2007, Tobias Klausmann wrote: Hi! On Fri, 31 Aug 2007, Mike Frysinger wrote: On Friday 31 August 2007, Marius Mauch wrote: Petteri Räty [EMAIL PROTECTED] wrote: Matthias Schwarzott kirjoitti: On Freitag, 31. August 2007, Matthias Schwarzott wrote: What do you think about adding /etc/udev/rules.d/ to CONFIG_PROTECT_MASK. This will no longer bother the user with updating these files. Thus it will reduce the number of bugs triggered by forgotten config-file updates. If user needs home-brewn rules he is requested to add own files, and not use the already existing ones. Only problem I see: What to do with people having custom modifications inside the default rules-files? Can they add /etc/udev/rules.d back to CONFIG_PROTECT in make.conf? No, that wouldn't work. However they could add '-/etc/udev/rules.d' to CONFIG_PROTECT_MASK or add individual files to CONFIG_PROTECT. either solution sucks the question is, should people be modifying the default rules ? is there something in the default rules file that they cant accomplish in a sep rules file ? if so, then the dir cant be masked ... I find the persisten-net-generator.rules particularly annoying (for various reasons including, but not limited to system images and system cloning). So I have an empty file of that name and happily nuke whatever comes along with udev updates. I could of course unmask that file if it were to be masked in the future. Still, this reeks of layers upon layers of customization to me. I'd prefer a more elegant solution - although know of none. The classic approach would be a USE flag to toggle installation of the shipped udev files - which wouldn't work for me, as I only have gripes about *one* of them. There probably simply isn't a simple, elegant solution that is a) not wrong and b) works for just about everybody. If your only regard is disabling persistent-net stuff you also can archive this without need to modify any files. 1. For almost all decisions udev does it is possible to overwrite them later, or assign a value with := instead of = before. 2. In special case of persistent-net: 75-persistent-net.rules does only catch a devices if no name is set at that point, that means it can by bypassed simply be doing this in some rule-file before: SUBSYSTEM==net, NAME=%k We have already thought about adding a config option to disable persistent-net, but we have not yet find a nice (from developer and user view) solution. 3. If there are annoyances in udev-rules, please inform us about this. We might have some kind of hardware, but there are lots of different possible configurations we have no idea of, so please bug us (best with solution ;) ). Matthias -- Matthias Schwarzott (zzam) -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Gentoo Bugday Monthly reminder
Greetings everybody! As welp is still unavailable, it's my pleasure to tell you all *It's a Bugday!* As always join #gentoo-bugs on irc.freenode.net to participate in all the fun bugfixing :) Regards, -- ,-. | Dawid Węgliński | | [EMAIL PROTECTED] | | cla @ irc.freenode.net | | GPG: 295E72D9 | `-' signature.asc Description: To jest część listu podpisana cyfrowo
