Re: [gentoo-dev] Packages needing new maintainers
Robin H. Johnson wrote: > Software, I picked up maintenance of autofs when the previous maintainer went > AWOL several years ago, and ran with it because I needed AutoFS-LDAP. I don't > have access to any AutoFS-LDAP setups anymore, and upstream has moved on. > There > is a 7Kb init.d script that badly needs complete rewriting due to upstream and > kernel changes: > net-fs/autofs I'll see what I can do with this one. I won't have access to my network for a couple weeks, but when I get back home I'll poke into it. Kevin signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages needing new maintainers
On Tuesday 10 July 2007, Robin H. Johnson wrote: > For various reasons, I've got a couple of packages that I'm not really > very well suited to maintain going on. I added them over the course of past > jobs and university courses, but I have no further need of them, and they > really could use people that actually use them. for any of the sys-* ones, you probably already have base-system listed, but just in case, you can add it as the herd ... > Hardware, for tuning network cards. In new enough kernels (should be most > of 2.6), this is obsoleted by mii-tools and ethtool: > sys-apps/nictools i think we should scrub mii-tools, ethtool, and nictools ... latest net-tools should provide all of these i believe -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Packages needing new maintainers
Hi Folks, For various reasons, I've got a couple of packages that I'm not really very well suited to maintain going on. I added them over the course of past jobs and university courses, but I have no further need of them, and they really could use people that actually use them. This first batch deal with IPMI hardware. I used IPMI hardware in my last two jobs, but in the present one, we don't use it, and the packages do need maintenance with testing to make sure they actually work on the hardware. sys-apps/ipmitool sys-apps/ipmiutil sys-libs/freeipmi sys-libs/openipmi sys-libs/openhpi Again hardware related. You can deploy an iSCSI solution with just iscsitarget and open-iscsi as a pair, but I have previously tried to test open-iscsi with a hardware target, and iscsitarget with some other initiator (Windows or Solaris). sys-block/open-iscsi sys-block/iscsi-initiator-core-tools sys-block/iscsitarget Again, hardware related, with an software implementation possible. sys-block/aoetools sys-block/vblade Hardware, SCSI stuff dealing with enclosures and arrays: sys-block/scsirastools Hardware, SAS stuff (remote possibility I might come back for it if I get hardware for it): sys-block/smp_utils Hardware, NUMA-capable boxes: sys-process/numactl Hardware, Fibre-Channel: sys-apps/hbaapi sys-block/qla-fc-firmware sys-block/fwdl Hardware, for tuning network cards. In new enough kernels (should be most of 2.6), this is obsoleted by mii-tools and ethtool: sys-apps/nictools Hardware, Firewire IEEE1394: sys-apps/fwcrv sys-block/endpoint Hardware, flash disks: sys-fs/mtd-utils (this was the replacement for sys-fs/mtd) Software, QEMU frontend: app-emulation/qenv Hardware, programming PIC embedded microcontrollers (the herd might end up with these, but somebody with the hardware to use them would be nice): dev-embedded/icdprog dev-embedded/pikdev dev-embedded/xgpasm Software, I picked up maintenance of autofs when the previous maintainer went AWOL several years ago, and ran with it because I needed AutoFS-LDAP. I don't have access to any AutoFS-LDAP setups anymore, and upstream has moved on. There is a 7Kb init.d script that badly needs complete rewriting due to upstream and kernel changes: net-fs/autofs Networking, Linux ethernet Bridging. net-misc/bridge-utils Networking, SCTP protocol. net-misc/lksctp-tools Networking, SLIP over file descriptors. net-misc/vmnet Networking, VLAN management for managed switches: net-misc/vmpsd Networking, admin tool for some networked printers and JetDirect-style adapter boxes: net-print/npadmin Networking, modelling and predictive applications: sys-apps/tcng net-analyzer/nam net-analyzer/ns -- Robin Hugh Johnson Gentoo Linux Developer & Council Member E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpEMx5gNHbCT.pgp Description: PGP signature
Re: [gentoo-dev] iuse defaults example
On Tuesday 10 July 2007, Thomas de Grenier de Latour wrote: > On 2007/07/10, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > the no* flags were introduced more to address default behavior than > > the -* case, so yes we can kick many of the no* USE flags > > To address only the default behavior, adding "foo" to the profile USE > instead of using a "nofoo" flag would have been enough. This could > have been done long ago, but my understanding has always been that it > was not considered a good enough solution because it was not -*-proof. for some flags yes ... for others, i dislike that idea for the exact same reason for the other profile-based suggestions: these defaults should live in the ebuild, not the profile -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Tue, Jul 10, 2007 at 05:37:46PM -0300, Kevin Lacquement wrote: > Greg KH wrote: > > On Tue, Jul 10, 2007 at 07:10:35PM +0200, Dominique Michel wrote: > Can you explain more. If the kernel can be tivoized by someone > >>> I'm sorry, but "tivoized" is not a verb. Please explain what you mean > >>> by this. > >> I mean if someone distribute a kernel with a licence that forbid to remove > >> the > >> functions he added even if we don't want them (as example drm at the kernel > >> level as in Vista), > > > > But that's impossible with the current Linux kernel license, so how > > could that ever happen? Why even try to discuss an impossiblity? > > > > I understood it to mean that you're allowed to change the source, but > the hardware has locks on it to prevent you from using the changed > source. So yes, you're allowed to modify the code and pass it on (as > permitted by the GPL), but you can't actually run it (eg due to code > signing requirements) The GPLv2 is all about distribution, not use cases, so yes, this is the case and is perfictly legal with GPLv2 (even the FSF explicitly told Tivo that what they were doing was legal and acceptable.) So, what is the problem here? The kernel is not going to change licenses any time soon, so I don't understand your objections. thanks, greg k-h -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] iuse defaults example
On 2007/07/10, Mike Frysinger <[EMAIL PROTECTED]> wrote: > > the no* flags were introduced more to address default behavior than > the -* case, so yes we can kick many of the no* USE flags > To address only the default behavior, adding "foo" to the profile USE instead of using a "nofoo" flag would have been enough. This could have been done long ago, but my understanding has always been that it was not considered a good enough solution because it was not -*-proof. -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
Greg KH wrote: > On Tue, Jul 10, 2007 at 07:10:35PM +0200, Dominique Michel wrote: Can you explain more. If the kernel can be tivoized by someone >>> I'm sorry, but "tivoized" is not a verb. Please explain what you mean >>> by this. >> I mean if someone distribute a kernel with a licence that forbid to remove >> the >> functions he added even if we don't want them (as example drm at the kernel >> level as in Vista), > > But that's impossible with the current Linux kernel license, so how > could that ever happen? Why even try to discuss an impossiblity? > I understood it to mean that you're allowed to change the source, but the hardware has locks on it to prevent you from using the changed source. So yes, you're allowed to modify the code and pass it on (as permitted by the GPL), but you can't actually run it (eg due to code signing requirements) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] iuse defaults example
On Tuesday 10 July 2007, Thomas de Grenier de Latour wrote: > On 2007/07/10, Thilo Bangert <[EMAIL PROTECTED]> wrote: > > - we could finally kick all the no* USE flags. USE flags are use > > flags - they determine what should be used. not what should not be > > used... > > Because of the way USE flags stack in Portage (the USE_ORDER variable), > IUSE defaults are not a solution for dropping no* flags: > http://thread.gmane.org/gmane.linux.gentoo.devel/43137/focus=43175 > As Zac pointed out in his reply to this post, dropping nocxx and > friends is more a job for use.force / package.use.force. the no* flags were introduced more to address default behavior than the -* case, so yes we can kick many of the no* USE flags also, use.force isnt exactly a nice solution ... more like brute force, i'm not sure any no* flag would be appropriate -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] iuse defaults example
On 2007/07/10, Thilo Bangert <[EMAIL PROTECTED]> wrote: > - we could finally kick all the no* USE flags. USE flags are use > flags - they determine what should be used. not what should not be > used... Because of the way USE flags stack in Portage (the USE_ORDER variable), IUSE defaults are not a solution for dropping no* flags: http://thread.gmane.org/gmane.linux.gentoo.devel/43137/focus=43175 As Zac pointed out in his reply to this post, dropping nocxx and friends is more a job for use.force / package.use.force. -- TGL. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Watch out for license changes to GPL-3.
On Tue, Jul 10, 2007 at 07:10:35PM +0200, Dominique Michel wrote: > > > > Can you explain more. If the kernel can be tivoized by someone > > > > I'm sorry, but "tivoized" is not a verb. Please explain what you mean > > by this. > > I mean if someone distribute a kernel with a licence that forbid to remove the > functions he added even if we don't want them (as example drm at the kernel > level as in Vista), But that's impossible with the current Linux kernel license, so how could that ever happen? Why even try to discuss an impossiblity? > > > , who will use this kernel? How can this affect the software xyz that > > > have a v3 licence? > > > > I do not understand the question, can you reprase it? > > > > who will use this kernel when we can get a vanilla kernel and plenty of > patches and do whatever we want to do with them? As creating such a kernel is not possible with the current Linux kernel, again, I don't see how anyone could even use it. > Will this affect the licencing or the distribution of the software xyz? The license of the Linux kernel has no affect on the license or distribution of any sofware that runs on top of it, so I do not see how it would matter. thanks, greg k-h -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] should we do an EAPI bump now with features that are already implemented?
Ciaran McCreesh kirjoitti: > On Tue, 10 Jul 2007 20:26:59 +0300 > Petteri Räty <[EMAIL PROTECTED]> wrote: >> Written maybe but it should be discussed on gentoo-dev too I would >> give a week or two at least. > > Well, I believe the idea here was to get out the already-implemented, > already-agreed-upon, highly useful, low cost stuff as soon as possible. > Hence slot deps... There's no technical reason for slot deps not to be > available right now. > Agreed. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] should we do an EAPI bump now with features that are already implemented?
On Tue, 10 Jul 2007 20:26:59 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote: > Written maybe but it should be discussed on gentoo-dev too I would > give a week or two at least. Well, I believe the idea here was to get out the already-implemented, already-agreed-upon, highly useful, low cost stuff as soon as possible. Hence slot deps... There's no technical reason for slot deps not to be available right now. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] should we do an EAPI bump now with features that are already implemented?
Ciaran McCreesh kirjoitti: > On Tue, 10 Jul 2007 19:50:47 +0300 > Petteri Räty <[EMAIL PROTECTED]> wrote: >> Well thinking that it will get some time to write the EAPI-1 spec and >> getting it approved by the council it will be probably useful to put >> it in initially and see where Portage is when it comes time to vote. > > If EAPI-1 is slot deps and IUSE defaults, the spec can easily be done > within a day. PMS is written to allow additions of that nature to be > done trivially. > Written maybe but it should be discussed on gentoo-dev too I would give a week or two at least. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] should we do an EAPI bump now with features that are already implemented?
On Tue, 10 Jul 2007 19:50:47 +0300 Petteri Räty <[EMAIL PROTECTED]> wrote: > Well thinking that it will get some time to write the EAPI-1 spec and > getting it approved by the council it will be probably useful to put > it in initially and see where Portage is when it comes time to vote. If EAPI-1 is slot deps and IUSE defaults, the spec can easily be done within a day. PMS is written to allow additions of that nature to be done trivially. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Watch out for license changes to GPL-3.
> > Can you explain more. If the kernel can be tivoized by someone > > I'm sorry, but "tivoized" is not a verb. Please explain what you mean > by this. I mean if someone distribute a kernel with a licence that forbid to remove the functions he added even if we don't want them (as example drm at the kernel level as in Vista), > > > , who will use this kernel? How can this affect the software xyz that > > have a v3 licence? > > I do not understand the question, can you reprase it? > who will use this kernel when we can get a vanilla kernel and plenty of patches and do whatever we want to do with them? Will this affect the licencing or the distribution of the software xyz? > thanks, > > greg k-h You are welcome, Dominique -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] should we do an EAPI bump now with features that are already implemented?
Zac Medico kirjoitti: > Petteri Räty wrote: >> Zac Medico kirjoitti: >>> Hi everyone, >>> >>> Bug 174380 [1] has a growing list of features that may be included in >>> EAPI-1. >>> Some of the features are already implemented but can't be used in the >>> portage >>> tree until we do an EAPI bump. The ones that are currently implemented >>> include >>> slot deps [2] and iuse defaults [3]. Are these features important enough to >>> warrant an EAPI bump or should we wait for more features to materialize? >>> >> I know Java would heavily use slot deps. What is the ETA for use based >> depends? > > Hopefully within 2 months or so. I'm planning to implement the infrastructure > that's necessary for it together with other stuff that will be needed for the > new dependency resolver. The exact time that it will be ready is difficult to > estimate because it depends on how much time I have to spend on it and how > fruitful the time is, both of which vary a lot. > > Zac Well thinking that it will get some time to write the EAPI-1 spec and getting it approved by the council it will be probably useful to put it in initially and see where Portage is when it comes time to vote. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] iuse defaults example
Mike Frysinger <[EMAIL PROTECTED]> said: > On Tuesday 10 July 2007, William Hubbs wrote: > > On Mon, Jul 09, 2007 at 11:26:19PM +0100, Ciaran McCreesh wrote: > > > As for IUSE defaults... There were objections against that feature > > > on the grounds that it's unnecessary and increased maintenance. Do > > > they really offer any benefit over package.use? > > > > Would iuse defaults not be appropriate when a certain use flag is > > recommended as the default for most users for a package?? > > other examples that make sense and are a pain with package.use: > - local USE flags (suddenly not so local huh) > - local USE flags and changing names > - defaults based on version (feature sucked <= 1.x and then rocked >= > 2.x) - developing new ebuilds for personal use > - developing new ebuilds for merging into tree (btw: need to update - we could finally kick all the no* USE flags. USE flags are use flags - they determine what should be used. not what should not be used... /usr/portage/profiles $ grep :no use.local.desc | wc -l 87 Thilo pgpCq4ecWgN3q.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] should we do an EAPI bump now with features that are already implemented?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: > Zac Medico kirjoitti: >> Hi everyone, >> >> Bug 174380 [1] has a growing list of features that may be included in EAPI-1. >> Some of the features are already implemented but can't be used in the portage >> tree until we do an EAPI bump. The ones that are currently implemented >> include >> slot deps [2] and iuse defaults [3]. Are these features important enough to >> warrant an EAPI bump or should we wait for more features to materialize? >> > > I know Java would heavily use slot deps. What is the ETA for use based > depends? Hopefully within 2 months or so. I'm planning to implement the infrastructure that's necessary for it together with other stuff that will be needed for the new dependency resolver. The exact time that it will be ready is difficult to estimate because it depends on how much time I have to spend on it and how fruitful the time is, both of which vary a lot. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (GNU/Linux) iD8DBQFGk61G/ejvha5XGaMRAop7AJ98ulIK/24Obs70t/40XWmIke4XpwCbBT1X 8gBX20/Bt9XHM9UWgyvQWp0= =AfXK -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Watch out for license changes to GPL-3.
Dominique Michel <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Mon, 09 Jul 2007 21:37:52 +0200: > So in fact, it doesn't matter in regard of tivoization if the tre is > under v2 or v3. I am not a layer, but I will be very surprised if I am > wrong on that point. Agreed. Tivoization shouldn't be an issue in this case for several reasons. The Gentoo alternative just doesn't make sense for someone trying to tivoize, as there are better alternatives (virtually anything package manager designed primarily to work with binaries, as opposed to source). > I don't know if an individual patches in some ebuild-xyz/files folder > can be under v3 or v2 and later in order to be able to legally patch a > gpl-v3 xyz software. > > The situation is: the ebuild-xyz have a patch under gpl-v2 in its files > folder because it is in the tree and the whole tree is v2 only. And the > software xyz is under gpl-v3. The problem is at I think at it will not > be allowed by the software xyz because gpl-v3 is not compatible with a > patch under the gpl-v2 only licence. The patch's licence must be gpl-v2 > or later, gpl-v3, or gpl-v3 or later. That's not an issue, because the copyright and license on the tree is on the collective whole, not on the components, which if copyrightable will have their own licenses. That's a very common and legally well supported principle, that the collection gets its own copyright apart from the components. Related but a slightly different angle is the "mere aggregation" clause of the GPLv2 (and I believe v3 as well, I don't know it as well yet). That a collection of otherwise uncopyrightable "trivials" or information in the public domain can yet be copyrighted is also legally well supported. Databases and phonebooks are precedents there. Lest anyone get a very wrong idea, IANAL, tho the area is of some interest to me, so I follow it to some degree. -- 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] iuse defaults example
On Tuesday 10 July 2007, Petteri Räty wrote: > Mike Frysinger kirjoitti: > > On Tuesday 10 July 2007, William Hubbs wrote: > >> On Mon, Jul 09, 2007 at 11:26:19PM +0100, Ciaran McCreesh wrote: > >>> As for IUSE defaults... There were objections against that feature on > >>> the grounds that it's unnecessary and increased maintenance. Do they > >>> really offer any benefit over package.use? > >> > >> Would iuse defaults not be appropriate when a certain use flag is > >> recommended as the default for most users for a package?? > > > > other examples that make sense and are a pain with package.use: > > - local USE flags (suddenly not so local huh) > > [EMAIL PROTECTED] /usr/portage/profiles $ cat base/package.use > # This file requires >=portage-2.1.2 (see bug #61732) > > # Strongly recommended, otherwise all logos, icons, etc. appear in b/w. > app-editors/emacs xpm > app-editors/emacs-cvs xpm > > Seems local to me... you missed the point ... ideally local USE flags should not appear outside of an ebuild. if i had a solution for it, i'd propose getting rid of use.local.desc ... > > - local USE flags and changing names > > Normally you would only have to change base/package.use "normally" doesnt cut it. package.use is stackable and can appear in any profile directory which means these flags can be listed anywhere. > > - defaults based on version (feature sucked <= 1.x and then rocked >= > > 2.x) > > package.use should accept version atoms > > > - developing new ebuilds for personal use > > /etc/portage/package.use > > > - developing new ebuilds for merging into tree (btw: need to update all > > these other files in profiles/ instead of just committing the one ebuild) > > base/package.use your replies have just backed up my point: it's a [pain]ita when it should be a [pleasent]ita. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] iuse defaults example
Mike Frysinger kirjoitti: > On Tuesday 10 July 2007, William Hubbs wrote: >> On Mon, Jul 09, 2007 at 11:26:19PM +0100, Ciaran McCreesh wrote: >>> As for IUSE defaults... There were objections against that feature on >>> the grounds that it's unnecessary and increased maintenance. Do they >>> really offer any benefit over package.use? >> Would iuse defaults not be appropriate when a certain use flag is >> recommended as the default for most users for a package?? > > other examples that make sense and are a pain with package.use: > - local USE flags (suddenly not so local huh) [EMAIL PROTECTED] /usr/portage/profiles $ cat base/package.use # This file requires >=portage-2.1.2 (see bug #61732) # Strongly recommended, otherwise all logos, icons, etc. appear in b/w. app-editors/emacs xpm app-editors/emacs-cvs xpm Seems local to me... > - local USE flags and changing names Normally you would only have to change base/package.use > - defaults based on version (feature sucked <= 1.x and then rocked >= 2.x) package.use should accept version atoms > - developing new ebuilds for personal use /etc/portage/package.use > - developing new ebuilds for merging into tree (btw: need to update all > these > other files in profiles/ instead of just committing the one ebuild) > -mike base/package.use Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC] should we do an EAPI bump now with features that are already implemented?
On Tue, 10 Jul 2007 08:14:57 +0200 Stefan Schweizer <[EMAIL PROTECTED]> wrote: > Can you please also list #138792 as implemented? It has a patch > attached. An unreleased (an incomplete regarding EAPI) patch does not count as being implemented. Marius -- Marius Mauch <[EMAIL PROTECTED]> -- [EMAIL PROTECTED] mailing list
