Re: [gentoo-dev] [discussion] GitHub eclass
On 22/02/2013 08:37, Kent Fredric wrote: > I'd make sure to add some sort of easy support to switch to > snapshotted tar.gz installs instead of live git checkouts, ie: > > GH_SNAPSHOT=deadbeef # use commit id 'deadbeef' by fetching a tar.gz > from github instead of a git clone This is not going to fly because a live git checkout does not need digests in the manifest, but a tar.gz snapshot does. I'm not against having a common way to deal with github project as they are common, but just having a wrapper for a few variables is not worth it IMHO. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] [discussion] GitHub eclass
On 22 February 2013 19:53, Vadim A. Misbakh-Soloviov wrote: > Hi there! > > Since we have tons of ebuild (including -) for software, that uses > GitHub for sourcecode hosting — I've got an idea to write something > like GitHub eclass, which will ease creating of such ebuilds (by > providing "sugar" functions) and, (main goal for me) by adding > possibility to switch between forks (by redefining variables on emerge > run). For example (theoretical usecase): > > We have, for example, lua-socket-, that uses: > GH_AUTHOR=diegonehab > GH_PROJECT=lua-socket > GH_BRANCH=unstable > > So, then I fork it and provide some features. And then I want to > reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do: > # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket- > and it repulls sources from my fork, reemerge it and installs fine. I'd make sure to add some sort of easy support to switch to snapshotted tar.gz installs instead of live git checkouts, ie: GH_SNAPSHOT=deadbeef # use commit id 'deadbeef' by fetching a tar.gz from github instead of a git clone -- Kent
[gentoo-dev] [discussion] GitHub eclass
Hi there! Since we have tons of ebuild (including -) for software, that uses GitHub for sourcecode hosting — I've got an idea to write something like GitHub eclass, which will ease creating of such ebuilds (by providing "sugar" functions) and, (main goal for me) by adding possibility to switch between forks (by redefining variables on emerge run). For example (theoretical usecase): We have, for example, lua-socket-, that uses: GH_AUTHOR=diegonehab GH_PROJECT=lua-socket GH_BRANCH=unstable So, then I fork it and provide some features. And then I want to reemerge it from my fork, but I don't want to rewrite ebuild. So, then I do: # GH_AUTHOR="msva" GH_BRANCH=master emerge =lua-socket- and it repulls sources from my fork, reemerge it and installs fine. Any ideas/suggestions/objections/critic? Let's discuss! -- Best regards, mva signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: linux-firmware
On Thu, Feb 21, 2013 at 6:18 PM, Rich Freeman wrote: > On Thu, Feb 21, 2013 at 5:44 PM, Greg KH wrote: >> This should be a cross-distro issue/solution, so I suggest working with >> the Linux Foundation on this. Anyone object to me doing that? > > Go for it (speaking only for myself, but I can't imagine the other > Trustees would be opposed)! > > Rich > Hi Greg, I would appreciate your help. Thanks, David -- David Abbott (dabbott) Gentoo http://dev.gentoo.org/~dabbott/
Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
On Thu, Feb 21, 2013 at 8:42 PM, Anthony G. Basile wrote: > there is the kernel source tree > (/usr/src/linux if it exists and is configured) The kernel can also be split (KV_DIR + KV_OUT_DIR), with relevant headers located in both directories. E.g., [1]. [1] https://bugs.gentoo.org/show_bug.cgi?id=424816 -- Maxim Kammerer Liberté Linux: http://dee.su/liberte
Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
On 02/21/2013 06:12 PM, Doug Goldstein wrote: On Thu, Feb 21, 2013 at 12:42 PM, Anthony G. Basile wrote: Hi everyone, This issue has come up in a few bugs so I want to bounce it off the community. When building packages that need a configured kernel source tree, many ebuilds inherit linux-info to find configuration info about the kernel. However, there is the running kernel with its configuration (/proc/config.gz if it exists), there is the kernel source tree (/usr/src/linux if it exists and is configured) and both of these can be of a different version than linux-headers. Since building modules consumes headers from /usr/include/linux, but uses code from /usr/src/linux and then these modules are expected to insmod against the running kernel, all of which can be mismatched, we have a lot of room for breakage. Eg. bug #458014. Any ideas about how to deal cleanly with situations like that? -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 Kernel modules never use /usr/include/linux. That's the uapi headers, which are now broken out in 3.7 and newer. Kernel modules always use /usr/src/linux. There have been a number of issues with the differences between the user space bits and the kernel space bits wrt to netfilter post 3.0, so its not surprising that a userspace component is trying to use /usr/include/linux to frame up a structure to pass into kernel space via netlink and running into an issue. This is one of the reasons behind kapi/uapi to make it clear you shouldn't play with or touch this field/structure/value from user space. I'm not sure the separation is so clean. I know userland should only use /usr/include/linux, but modules could source both indirectly via an include from /usr/include/linux [1]. But there's still the issue between the running kernel and /usr/src/linux? In the eclass, linux_config_path() first tries to find /usr/src/linux/.config and then falls back on /proc/config.gz. This is too hackly since packages building kernel modules could use the wrong config file. Ref. [1] Take a look at Pablo's rewrite of a patch I submitted to get into the kernel: http://www.spinics.net/lists/netfilter-devel/msg19833.html There he includes in /usr/src/linux/include/net/netfilter/nf_conntrack_tuple.h So even though the later is kapi, the division from uapi is not so clean. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] Re: linux-firmware
On Thu, Feb 21, 2013 at 5:44 PM, Greg KH wrote: > This should be a cross-distro issue/solution, so I suggest working with > the Linux Foundation on this. Anyone object to me doing that? Go for it (speaking only for myself, but I can't imagine the other Trustees would be opposed)! Rich
Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
On Thu, Feb 21, 2013 at 12:42 PM, Anthony G. Basile wrote: > Hi everyone, > > This issue has come up in a few bugs so I want to bounce it off the > community. When building packages that need a configured kernel source > tree, many ebuilds inherit linux-info to find configuration info about the > kernel. However, there is the running kernel with its configuration > (/proc/config.gz if it exists), there is the kernel source tree > (/usr/src/linux if it exists and is configured) and both of these can be of > a different version than linux-headers. Since building modules consumes > headers from /usr/include/linux, but uses code from /usr/src/linux and then > these modules are expected to insmod against the running kernel, all of > which can be mismatched, we have a lot of room for breakage. Eg. bug > #458014. > > Any ideas about how to deal cleanly with situations like that? > > -- > Anthony G. Basile, Ph. D. > Chair of Information Technology > D'Youville College > Buffalo, NY 14201 > (716) 829-8197 > Kernel modules never use /usr/include/linux. That's the uapi headers, which are now broken out in 3.7 and newer. Kernel modules always use /usr/src/linux. There have been a number of issues with the differences between the user space bits and the kernel space bits wrt to netfilter post 3.0, so its not surprising that a userspace component is trying to use /usr/include/linux to frame up a structure to pass into kernel space via netlink and running into an issue. This is one of the reasons behind kapi/uapi to make it clear you shouldn't play with or touch this field/structure/value from user space. -- Doug Goldstein
Re: [gentoo-dev] Re: linux-firmware
On Thu, Feb 21, 2013 at 09:44:12PM +0100, Ulrich Mueller wrote: > > On Thu, 21 Feb 2013, Greg KH wrote: > > > Has anyone asked the upstream linux-firmware developers about these > > files? > > I don't know. I haven't, for my part. But maybe we should first try > to produce a more complete list, instead of reporting each file > separately? Given that most of the files are being distributed since > years, another few days cannot matter. Such a list would be wonderful to have. > > thanks for the detailed descriptions, much appreciated. > > > I think this is something that the Board needs to decide, after > > discussing it with our lawyers, it's not something that non-legal > > people (like myself) should be saying is the definitive answer. > > I fully agree. And IANAL, so anything that I say about license issues > should be taken with a grain of salt. I am willing to work with lawyers, who know these type of things quite well, to get upstream straightened out, given that I was the one who originally added firmware files to the kernel, oh so many years ago, causing this problem... This should be a cross-distro issue/solution, so I suggest working with the Linux Foundation on this. Anyone object to me doing that? thanks, greg k-h
[gentoo-dev] Re: linux-firmware
Greg KH posted on Thu, 21 Feb 2013 11:55:34 -0800 as excerpted: > On Thu, Feb 21, 2013 at 07:33:48PM +0100, Ulrich Mueller wrote: >> > On Thu, 21 Feb 2013, Greg KH wrote: >> >> >> Ulrich Mueller (ulm) wrote this on the 16th: >> >> >> >> > Look into the WHENCE file and be horrified. Taking just the first >> >> > ten items (of a total 114): >> >> > >> >> >Unknown license (3 times) >> >> > Which ones specifically? >> >> Driver: snd-korg1212 -- Korg 1212 IO audio device Driver: kaweth -- USB >> KLSI KL5USB101-based Ethernet device Driver: dvb-ttusb-budget -- >> Technotrend/Hauppauge Nova-USB devices > > As these originally came from the kernel source tree, they are "by > default" ok. Well, not entirely. It's exactly this sort of issue that's the reason many people were uncomfortable with firmware in the kernel at all, and why all the ongoing work to separate it out. >> >> >GPL, but without source (3 times) >> >> > Really? Which? >> >> Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM >> NIC. >> Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device Driver: >> qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support > > Some of these came from the kernel source tree originally, others don't, > but they all imply that the GPL really isn't for the firmware itself. > Odd. Again... precisely why this stuff's being gradually kicked out of the kernel in the first place. >> >> >"All rights reserved" >> >> > That's not an issue, unless it is alone, is there something else in >> > the license as well? >> >> Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices >> >> According to WHENCE, it is: >> "Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved." >> Nothing else. > > That's a copyright notice, not a license, so I don't know what to > suggest :) See above... >> >> >BSD, without source >> >> > There's no problem with that. >> > >> Driver: advansys - AdvanSys SCSI >> >> Right, and it's the only one out of the first ten that we're allowed to >> redistribute. =:^) >> >> >Right for redistribution not granted >> >> > Huh? Which? >> >> Driver: smctr -- SMC ISA/MCA Token Ring adapter > > Token ring drivers were dropped from the kernel already, so this isn't > an issue. It's only an issue to the extent that we're still shipping it. >> >> >"Permission is hereby granted for the distribution [...] as >> >> >part of >> >> >a Linux or other Open Source operating system kernel" >> >> > What is wrong with that? We happen to be distributing a Linux >> > operating system. >> >> Driver: keyspan -- USB Keyspan USA-xxx serial device >> >> We distribute it in a separate package. And it doesn't say "part of an >> OS" but explicitly "part of a kernel". > > Ah, that's because at the time, that's the way it was originally > distributed. Given that the company isn't around anymore, I don't think > this is going to be an issue :) But what about whoever bought up the rights? In practice, that's precisely when many of these things BECOME an issue, when a new owner decides they can monetize... In general, this is an ongoing problem for the entire community. It's gradually being straightened out, but it's a years-long, likely decades long, project. In practice, as long as nobody's suing, and because the overall trend is to clean things up, that's why most distros kind of wink and nudge and don't talk about it much. But it's also one of the BIG reasons for the "firmwareless kernel" projects. While they're not entirely practical for most people on their own, they DO serve the purpose of demonstrating that it's possible under limited circumstances and measuring how far we have to go... -- 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: Building against /usr/src/linux and linux-info.eclass
Markos Chandras posted on Thu, 21 Feb 2013 21:25:30 + as excerpted: >>> Eg. bug #458014. >>> >>> Any ideas about how to deal cleanly with situations like that? >>> >>> >> I'm no expert, but I always thought that modules are supposed to >> consume headers from the kernel source directory, not from >> /usr/include/linux. I believe I've read that somewhere quite authoritative (like LWN) as well. Kernel modules, kernel sources. Userspace, the cleaned up Linux- headers. In fact, there has been quite some kernel work recently (3.7 I believe, the commit log was heavy with related commits) done in ordered to make the separation cleaner. >> As well, the modules should be installed for whatever kernel version is >> present in /usr/src/linux (or KERNEL_DIR. This may be distinct from the >> currently running kernel. This problem is much worse with gentoo than with a typical binary distro that much more strictly controls both the kernel and headers shipped. AFAIK, that's one of the major reasons the eclass is there, to semi- standardize both the handling and the relative priority of the various possibilities, but no solution's going to hit every corner-case, and if something's breaking on specific user's systems, in the end it's them that may have to either standardize their system (and build practices) to some degree, or handle their own breakage if they choose not to. But userspace definitely should be using the installed linux-headers. And in-treeing kernel modules is STRONGLY encouraged upstream exactly due to this and other issues, to the point that while out-of-tree modules are tolerated as a fact of life, they're very much on a "the responsible dev (and users who choose to use his code) gets to keep his pieces" policy. That being the upstream policy, there's definitely limits on what gentoo can do to unbreak what upstream has already declared broken, 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] Building against /usr/src/linux and linux-info.eclass
On 21 February 2013 18:49, Mike Gilbert wrote: > On Thu, Feb 21, 2013 at 1:42 PM, Anthony G. Basile > wrote: >> Hi everyone, >> >> This issue has come up in a few bugs so I want to bounce it off the >> community. When building packages that need a configured kernel source >> tree, many ebuilds inherit linux-info to find configuration info about the >> kernel. However, there is the running kernel with its configuration >> (/proc/config.gz if it exists), there is the kernel source tree >> (/usr/src/linux if it exists and is configured) and both of these can be of >> a different version than linux-headers. Since building modules consumes >> headers from /usr/include/linux, but uses code from /usr/src/linux and then >> these modules are expected to insmod against the running kernel, all of >> which can be mismatched, we have a lot of room for breakage. Eg. bug >> #458014. >> >> Any ideas about how to deal cleanly with situations like that? >> > > I'm no expert, but I always thought that modules are supposed to > consume headers from the kernel source directory, not from > /usr/include/linux. > > As well, the modules should be installed for whatever kernel version > is present in /usr/src/linux (or KERNEL_DIR. This may be distinct from > the currently running kernel. > > I think the headers in /usr/include/linux are there for building > userspace programs, which would utilize the more stable userspace <-> > kernel API. > Yes, I think this is the case as well. I am not sure if modules use the headers in /usr/include/linux. It feel wrong to me -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Re: linux-firmware
On Thu, Feb 21, 2013 at 3:44 PM, Ulrich Mueller wrote: >> On Thu, 21 Feb 2013, Greg KH wrote: >> I think this is something that the Board needs to decide, after >> discussing it with our lawyers, it's not something that non-legal >> people (like myself) should be saying is the definitive answer. > > I fully agree. And IANAL, so anything that I say about license issues > should be taken with a grain of salt. My recommendation would be to have the licensing team get things as organized as they can, and escalate to the Trustees any cases where the legal situation is unclear. We can certainly seek legal counsel, but as with all matters it is best for the licensing team to just take care of issues which aren't controversial. Rich
Re: [gentoo-dev] Re: linux-firmware
> On Thu, 21 Feb 2013, Greg KH wrote: > Has anyone asked the upstream linux-firmware developers about these > files? I don't know. I haven't, for my part. But maybe we should first try to produce a more complete list, instead of reporting each file separately? Given that most of the files are being distributed since years, another few days cannot matter. > thanks for the detailed descriptions, much appreciated. > I think this is something that the Board needs to decide, after > discussing it with our lawyers, it's not something that non-legal > people (like myself) should be saying is the definitive answer. I fully agree. And IANAL, so anything that I say about license issues should be taken with a grain of salt. Ulrich
Re: [gentoo-dev] Re: linux-firmware
On Thu, Feb 21, 2013 at 07:33:48PM +0100, Ulrich Mueller wrote: > > On Thu, 21 Feb 2013, Greg KH wrote: > > >> Ulrich Mueller (ulm) wrote this on the 16th: > >> > >> > Look into the WHENCE file and be horrified. Taking just the first ten > >> > items (of a total 114): > >> > > >> >Unknown license (3 times) > > > Which ones specifically? > > Driver: snd-korg1212 -- Korg 1212 IO audio device > Driver: kaweth -- USB KLSI KL5USB101-based Ethernet device > Driver: dvb-ttusb-budget -- Technotrend/Hauppauge Nova-USB devices As these originally came from the kernel source tree, they are "by default" ok. > >> >GPL, but without source (3 times) > > > Really? Which? > > Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM NIC. > Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device > Driver: qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support Some of these came from the kernel source tree originally, others don't, but they all imply that the GPL really isn't for the firmware itself. Odd. > >> >"All rights reserved" > > > That's not an issue, unless it is alone, is there something else in the > > license as well? > > Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices > > According to WHENCE, it is: > "Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved." > Nothing else. That's a copyright notice, not a license, so I don't know what to suggest :) > >> >BSD, without source > > > There's no problem with that. > > Driver: advansys - AdvanSys SCSI > > Right, and it's the only one out of the first ten that we're allowed > to redistribute. > > >> >Right for redistribution not granted > > > Huh? Which? > > Driver: smctr -- SMC ISA/MCA Token Ring adapter Token ring drivers were dropped from the kernel already, so this isn't an issue. > >> >"Permission is hereby granted for the distribution [...] as part of > >> >a Linux or other Open Source operating system kernel" > > > What is wrong with that? We happen to be distributing a Linux operating > > system. > > Driver: keyspan -- USB Keyspan USA-xxx serial device > > We distribute it in a separate package. And it doesn't say "part of > an OS" but explicitly "part of a kernel". Ah, that's because at the time, that's the way it was originally distributed. Given that the company isn't around anymore, I don't think this is going to be an issue :) > > >> > With one exception, we are not even allowed to redistribute these. > > > I don't understand, please explain all of these in detail so that we can > > fix this upstream. > > >> This is what we've been discussing about. This is not really about > >> Gentoo by itself, but the ability to distribute the sources at all, be > >> it from us or somebody else. > > > I understand, and as an upstream developer, I want to see that fixed > > because all distros need to be able to distribute these files for the > > kernel to work properly. > > > Oh, and other distros, with lots of lawyers, are distributing these > > firmware images as a single package, so this needs to be resolved either > > by realizing that our interpretation is incorrect, or that everyone is > > wrong here. > > Can you show me a distro that distributes above-mentioned files? > Debian, for example, doesn't distribute them (AFAICS). As far as I can tell, both SuSE and Red Hat distribute these today. And so does Canonical, but really, that can't be taken as "valid legal usage" at all :) Has anyone asked the upstream linux-firmware developers about these files? thanks for the detailed descriptions, much appreciated. I think this is something that the Board needs to decide, after discussing it with our lawyers, it's not something that non-legal people (like myself) should be saying is the definitive answer. greg k-h
Re: [gentoo-dev] Building against /usr/src/linux and linux-info.eclass
On Thu, Feb 21, 2013 at 1:42 PM, Anthony G. Basile wrote: > Hi everyone, > > This issue has come up in a few bugs so I want to bounce it off the > community. When building packages that need a configured kernel source > tree, many ebuilds inherit linux-info to find configuration info about the > kernel. However, there is the running kernel with its configuration > (/proc/config.gz if it exists), there is the kernel source tree > (/usr/src/linux if it exists and is configured) and both of these can be of > a different version than linux-headers. Since building modules consumes > headers from /usr/include/linux, but uses code from /usr/src/linux and then > these modules are expected to insmod against the running kernel, all of > which can be mismatched, we have a lot of room for breakage. Eg. bug > #458014. > > Any ideas about how to deal cleanly with situations like that? > I'm no expert, but I always thought that modules are supposed to consume headers from the kernel source directory, not from /usr/include/linux. As well, the modules should be installed for whatever kernel version is present in /usr/src/linux (or KERNEL_DIR. This may be distinct from the currently running kernel. I think the headers in /usr/include/linux are there for building userspace programs, which would utilize the more stable userspace <-> kernel API.
[gentoo-dev] Building against /usr/src/linux and linux-info.eclass
Hi everyone, This issue has come up in a few bugs so I want to bounce it off the community. When building packages that need a configured kernel source tree, many ebuilds inherit linux-info to find configuration info about the kernel. However, there is the running kernel with its configuration (/proc/config.gz if it exists), there is the kernel source tree (/usr/src/linux if it exists and is configured) and both of these can be of a different version than linux-headers. Since building modules consumes headers from /usr/include/linux, but uses code from /usr/src/linux and then these modules are expected to insmod against the running kernel, all of which can be mismatched, we have a lot of room for breakage. Eg. bug #458014. Any ideas about how to deal cleanly with situations like that? -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197
Re: [gentoo-dev] Re: linux-firmware
> On Thu, 21 Feb 2013, Greg KH wrote: >> Ulrich Mueller (ulm) wrote this on the 16th: >> >> > Look into the WHENCE file and be horrified. Taking just the first ten >> > items (of a total 114): >> > >> >Unknown license (3 times) > Which ones specifically? Driver: snd-korg1212 -- Korg 1212 IO audio device Driver: kaweth -- USB KLSI KL5USB101-based Ethernet device Driver: dvb-ttusb-budget -- Technotrend/Hauppauge Nova-USB devices >> >GPL, but without source (3 times) > Really? Which? Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM NIC. Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device Driver: qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support >> >"All rights reserved" > That's not an issue, unless it is alone, is there something else in the > license as well? Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices According to WHENCE, it is: "Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved." Nothing else. >> >BSD, without source > There's no problem with that. Driver: advansys - AdvanSys SCSI Right, and it's the only one out of the first ten that we're allowed to redistribute. >> >Right for redistribution not granted > Huh? Which? Driver: smctr -- SMC ISA/MCA Token Ring adapter >> >"Permission is hereby granted for the distribution [...] as part of >> >a Linux or other Open Source operating system kernel" > What is wrong with that? We happen to be distributing a Linux operating > system. Driver: keyspan -- USB Keyspan USA-xxx serial device We distribute it in a separate package. And it doesn't say "part of an OS" but explicitly "part of a kernel". >> > With one exception, we are not even allowed to redistribute these. > I don't understand, please explain all of these in detail so that we can > fix this upstream. >> This is what we've been discussing about. This is not really about >> Gentoo by itself, but the ability to distribute the sources at all, be >> it from us or somebody else. > I understand, and as an upstream developer, I want to see that fixed > because all distros need to be able to distribute these files for the > kernel to work properly. > Oh, and other distros, with lots of lawyers, are distributing these > firmware images as a single package, so this needs to be resolved either > by realizing that our interpretation is incorrect, or that everyone is > wrong here. Can you show me a distro that distributes above-mentioned files? Debian, for example, doesn't distribute them (AFAICS). Ulrich
Re: [gentoo-dev] Re: linux-firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/02/13 12:26 PM, Greg KH wrote: > "Permission is hereby granted for the distribution [...] as > part of a Linux or other Open Source operating system > kernel" > What is wrong with that? We happen to be distributing a Linux > operating system. > "...as part of a Linux (...) *kernel*." This (linux-firmware) isn't being distributed as part of the kernel, or even with the kernel; it's being distributed separately right? When these particular firmwares were being distributed in-kernel, the license would've been fine.. The license needs to be adjusted to replace "as part of" with "for use with" or some similar change. My interpretation of this is the concern you had also, ulm? Apologies for jumping in without fully reading the backlog (it seems to have been going on for days) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEmXQEACgkQ2ugaI38ACPA3rwEApkmWZZISrLyB1RoFEOG+KsoS vlalAvqcQr82mdIZ5qYBAKYziTD2OcHQ47SwaOegmooaPqHSHRj9P5G1APoNSpMr =erNV -END PGP SIGNATURE-
Re: [gentoo-dev] Re: linux-firmware
On Wed, Feb 20, 2013 at 07:51:15PM +0100, Diego Elio Pettenò wrote: > On 20/02/2013 19:43, Greg KH wrote: > > Really? What firmware files are that way, I just did a quick scan > > through the upstream linux-firmware.git tree and didn't see anything > > that would prevent Gentoo from doing this. > > No, not really. Greg, please don't expect everybody's word here to be > the Project's as you did already once - especially not if they are not > even really involved in it. Of course not, I know better than that from -dev, I've been around long enough :) That's why I was asking for specifics. > Ulrich Mueller (ulm) wrote this on the 16th: > > > Look into the WHENCE file and be horrified. Taking just the first ten > > items (of a total 114): > > > >Unknown license (3 times) Which ones specifically? > >GPL, but without source (3 times) Really? Which? > >"All rights reserved" That's not an issue, unless it is alone, is there something else in the license as well? > >BSD, without source There's no problem with that. > >Right for redistribution not granted Huh? Which? > >"Permission is hereby granted for the distribution [...] as part of > >a Linux or other Open Source operating system kernel" What is wrong with that? We happen to be distributing a Linux operating system. > > With one exception, we are not even allowed to redistribute these. I don't understand, please explain all of these in detail so that we can fix this upstream. > This is what we've been discussing about. This is not really about > Gentoo by itself, but the ability to distribute the sources at all, be > it from us or somebody else. I understand, and as an upstream developer, I want to see that fixed because all distros need to be able to distribute these files for the kernel to work properly. Oh, and other distros, with lots of lawyers, are distributing these firmware images as a single package, so this needs to be resolved either by realizing that our interpretation is incorrect, or that everyone is wrong here. thanks, greg k-h
Re: [gentoo-dev] [PATCH multilib-build] Tee the build logs to ABI-specific files.
On 02/21/2013 09:03 AM, Michał Górny wrote: > On Thu, 21 Feb 2013 08:55:45 -0800 > Zac Medico wrote: >> Maybe use EBUILD_DEATH_HOOKS to display the locations of the logs? > > Is this documented somewhere? No, it doesn't seem to be documented in PMS, though some eclasses have been using it for a very long time. See java-utils-2, multiprocessing, and toolchain eclasses. It's also used in the sys-apps/sandbox and www-client/chromium ebuilds. Portage documents the related register_die_hook function in `man 5 ebuild`. -- Thanks, Zac
Re: [gentoo-dev] [PATCH multilib-build] Tee the build logs to ABI-specific files.
On Thu, 21 Feb 2013 08:55:45 -0800
Zac Medico wrote:
> On 02/21/2013 03:27 AM, Michał Górny wrote:
> > This makes reading them a bit easier, especially with phases run
> > in parallel.
> > ---
> > gx86/eclass/multilib-build.eclass | 7 ---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/gx86/eclass/multilib-build.eclass
> > b/gx86/eclass/multilib-build.eclass
> > index feac748..93c4335 100644
> > --- a/gx86/eclass/multilib-build.eclass
> > +++ b/gx86/eclass/multilib-build.eclass
> > @@ -100,7 +100,8 @@ multilib_foreach_abi() {
> > local ABI
> > for ABI in $(multilib_get_enabled_abis); do
> > multilib_toolchain_setup "${ABI}"
> > - BUILD_DIR=${initial_dir%%/}-${ABI} "${@}"
> > + local BUILD_DIR=${initial_dir%%/}-${ABI}
> > + "${@}" | tee -a "${T}/build-${ABI}.log"
> > done
> > }
> >
> > @@ -127,8 +128,8 @@ multilib_parallel_foreach_abi() {
> > multijob_child_init
> >
> > multilib_toolchain_setup "${ABI}"
> > - BUILD_DIR=${initial_dir%%/}-${ABI}
> > - "${@}"
> > + local BUILD_DIR=${initial_dir%%/}-${ABI}
> > + "${@}" 2>&1 | tee -a "${T}/build-${ABI}.log"
> > ) &
> >
> > multijob_post_fork
> >
>
> Maybe use EBUILD_DEATH_HOOKS to display the locations of the logs?
Is this documented somewhere?
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] [PATCH multilib-build] Tee the build logs to ABI-specific files.
On 02/21/2013 03:27 AM, Michał Górny wrote:
> This makes reading them a bit easier, especially with phases run
> in parallel.
> ---
> gx86/eclass/multilib-build.eclass | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gx86/eclass/multilib-build.eclass
> b/gx86/eclass/multilib-build.eclass
> index feac748..93c4335 100644
> --- a/gx86/eclass/multilib-build.eclass
> +++ b/gx86/eclass/multilib-build.eclass
> @@ -100,7 +100,8 @@ multilib_foreach_abi() {
> local ABI
> for ABI in $(multilib_get_enabled_abis); do
> multilib_toolchain_setup "${ABI}"
> - BUILD_DIR=${initial_dir%%/}-${ABI} "${@}"
> + local BUILD_DIR=${initial_dir%%/}-${ABI}
> + "${@}" | tee -a "${T}/build-${ABI}.log"
> done
> }
>
> @@ -127,8 +128,8 @@ multilib_parallel_foreach_abi() {
> multijob_child_init
>
> multilib_toolchain_setup "${ABI}"
> - BUILD_DIR=${initial_dir%%/}-${ABI}
> - "${@}"
> + local BUILD_DIR=${initial_dir%%/}-${ABI}
> + "${@}" 2>&1 | tee -a "${T}/build-${ABI}.log"
> ) &
>
> multijob_post_fork
>
Maybe use EBUILD_DEATH_HOOKS to display the locations of the logs?
--
Thanks,
Zac
Re: [gentoo-dev] [PATCH multilib-build] Tee the build logs to ABI-specific files.
On Thu, Feb 21, 2013 at 3:27 AM, Michał Górny wrote:
> This makes reading them a bit easier, especially with phases run
> in parallel.
> ---
> gx86/eclass/multilib-build.eclass | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/gx86/eclass/multilib-build.eclass
> b/gx86/eclass/multilib-build.eclass
> index feac748..93c4335 100644
> --- a/gx86/eclass/multilib-build.eclass
> +++ b/gx86/eclass/multilib-build.eclass
> @@ -100,7 +100,8 @@ multilib_foreach_abi() {
> local ABI
> for ABI in $(multilib_get_enabled_abis); do
> multilib_toolchain_setup "${ABI}"
> - BUILD_DIR=${initial_dir%%/}-${ABI} "${@}"
> + local BUILD_DIR=${initial_dir%%/}-${ABI}
> + "${@}" | tee -a "${T}/build-${ABI}.log"
> done
> }
>
> @@ -127,8 +128,8 @@ multilib_parallel_foreach_abi() {
> multijob_child_init
>
> multilib_toolchain_setup "${ABI}"
> - BUILD_DIR=${initial_dir%%/}-${ABI}
> - "${@}"
> + local BUILD_DIR=${initial_dir%%/}-${ABI}
> + "${@}" 2>&1 | tee -a "${T}/build-${ABI}.log"
> ) &
>
> multijob_post_fork
> --
> 1.8.1.2
>
>
Definitely seems like a good idea.
Re: [gentoo-dev] g-elisp repository helper
21.02.13 16:18, Ulrich Mueller написав(ла): > It looks promising. I only wonder why you need to define your own > fetch function instead of assigning SRC_URI? This will cause the > ebuilds to be live ebuilds and there will be no possibility for the > user to verify the integrity of the downloaded package. Or have I > missed something? > > > Cheers, > Ulrich > Thanks. The problem with SRC_URI is that if it is defined, manifests should include hashes of the source files. As g-elisp is aimed to dynamically generate overlays on user's computer it means that during this generation all the sources from elisp repos will be downloaded. It isn't very nice. The integrity of sources could be verified in ebuild, but I have not found any hashes in elpa's repository info. May be I just failed in my googling, so if you know a solution of this problem, I will implement it with great pleasure. Best regards, Jauhien signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] g-elisp repository helper
> On Thu, 21 Feb 2013, Ulrich Mueller wrote: > No problem with posting it to the gentoo-dev list. I'm answering in > semi-private (Gentoo Emacs team in CC) because the topic is Emacs > specific. I fail.
Re: [gentoo-dev] g-elisp repository helper
> On Wed, 20 Feb 2013, Jauhien Piatlicki wrote: > I do not know whether this list is an appropriate place, so sorry if it > is not ) Hi, No problem with posting it to the gentoo-dev list. I'm answering in semi-private (Gentoo Emacs team in CC) because the topic is Emacs specific. > Recently I've wrote some little scripts that implement interface for > g-common type repositories of layman[1]. And I would ask those who is > interested to test them. > I've created two packages: g-common (interacts with layman) and g-elisp > (generates ebuilds). g-elisp is aimed to automatically create layman > overlays for repositories of elisp packages supported by package.el, so > those packages could be installed by portage. > To test it you can add an overlay described by this xml-file: > https://github.com/jauhien/jauhien-overlay/blob/master/jauhien-overlay.xml > and then `emerge g-elisp` > After emerging it you will be able to add two layman repositories of > type g-common: gnu-elpa and marmalade. It looks promising. I only wonder why you need to define your own fetch function instead of assigning SRC_URI? This will cause the ebuilds to be live ebuilds and there will be no possibility for the user to verify the integrity of the downloaded package. Or have I missed something? > g-common and g-elisp are still in the very beta, also I'm a very > beginner in python, so I will appreciate any feedback and criticism. I fear that I won't be able to help you with the Python. Cheers, Ulrich
[gentoo-dev] [PATCH multilib-build] Tee the build logs to ABI-specific files.
This makes reading them a bit easier, especially with phases run
in parallel.
---
gx86/eclass/multilib-build.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index feac748..93c4335 100644
--- a/gx86/eclass/multilib-build.eclass
+++ b/gx86/eclass/multilib-build.eclass
@@ -100,7 +100,8 @@ multilib_foreach_abi() {
local ABI
for ABI in $(multilib_get_enabled_abis); do
multilib_toolchain_setup "${ABI}"
- BUILD_DIR=${initial_dir%%/}-${ABI} "${@}"
+ local BUILD_DIR=${initial_dir%%/}-${ABI}
+ "${@}" | tee -a "${T}/build-${ABI}.log"
done
}
@@ -127,8 +128,8 @@ multilib_parallel_foreach_abi() {
multijob_child_init
multilib_toolchain_setup "${ABI}"
- BUILD_DIR=${initial_dir%%/}-${ABI}
- "${@}"
+ local BUILD_DIR=${initial_dir%%/}-${ABI}
+ "${@}" 2>&1 | tee -a "${T}/build-${ABI}.log"
) &
multijob_post_fork
--
1.8.1.2
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On 21 February 2013 09:09, Michał Górny wrote: > On Mon, 18 Feb 2013 23:27:46 + > "Robin H. Johnson" wrote: > >> Recommendations: >> >> 3. Dedicated Gentoo signing subkey of EITHER: >> 3.1. DSA 2048 bits >> 3.2. RSA 4096 bits > > As a note for those who didn't know this; to make gpg use the dedicated > subkey, you need to append an exclamation mark (!) to it. Like: > > PORTAGE_GPG_KEY="9627F456F9DA7643!" > > Otherwise, GPG will just use this as a reference to the whole key, > and may use other subkey. > > -- > Best regards, > Michał Górny Thanks for that. I didn't know it and I couldn't find any references in the manpages. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] RFC: Gentoo GPG key policies
On Mon, 18 Feb 2013 23:27:46 + "Robin H. Johnson" wrote: > Recommendations: > > 3. Dedicated Gentoo signing subkey of EITHER: > 3.1. DSA 2048 bits > 3.2. RSA 4096 bits As a note for those who didn't know this; to make gpg use the dedicated subkey, you need to append an exclamation mark (!) to it. Like: PORTAGE_GPG_KEY="9627F456F9DA7643!" Otherwise, GPG will just use this as a reference to the whole key, and may use other subkey. -- Best regards, Michał Górny signature.asc Description: PGP signature
