Re: udeb migration now that 2.6.15 is in testing
On Fri, Feb 10, 2006 at 02:19:41AM -0800, Steve Langasek wrote: On Thu, Feb 09, 2006 at 01:30:19PM -0500, Joey Hess wrote: Frans Pop wrote: I'm not sure how the following package should be hinted as it used to have a deb, but now only has a udeb: network-console network-console-config needs to be removed from testing (should happen semiautomatically), and then normal udeb sync. This will only happen if the package is hinted in via britney, AFAIK. Hint added. This worked, and so did all the other udeb propagations. --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Feb 11, Steve Langasek [EMAIL PROTECTED] wrote: Why temporary, out of curiosity? This doesn't seem like a temporary problem; I think this is an issue that will be just as applicable for etch+1 as it is for etch, and I think we should be honest about that. Because maybe in 5-10 years from now most hardware devices will have a free firmware. I do not really believe that this will happen, but by proposing an exception with a much limited scope than the past GR I hope that it will be less controverial and easier to be approved. Also note that I wrote distribute on install media and not allow in main. I also think it's within the realm of reason for us to decide that source for things like firmware, fonts, and documentation is less important than it is for programs. I also plan a GR to accept in main less free artwork which if removed does not change the functionality of the software using it (e.g. the firefox logo). -- ciao, Marco signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
On Sat, Feb 11, 2006 at 10:33:32AM +0100, Marco d'Itri wrote: On Feb 11, Steve Langasek [EMAIL PROTECTED] wrote: Why temporary, out of curiosity? This doesn't seem like a temporary problem; I think this is an issue that will be just as applicable for etch+1 as it is for etch, and I think we should be honest about that. Because maybe in 5-10 years from now most hardware devices will have a free firmware. I do not really believe that this will happen, but by proposing an exception with a much limited scope than the past GR I hope that it will be less controverial and easier to be approved. Also note that I wrote distribute on install media and not allow in main. As the install media are built our of main though, this is probably not going to cut it without proof that it can be done on a technical point of view. Why not simply have a non-free set of install media, and be done with it, sounds like a much sanner proposal, without legal hurdle, just in need of technical work. Friendly, Svne Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Feb 11, Sven Luther [EMAIL PROTECTED] wrote: As the install media are built our of main though, this is probably not going to cut it without proof that it can be done on a technical point of view. It could be main or a subset of non-free or a new section, it's just a detail which I do not consider important. Why not simply have a non-free set of install media, and be done with it, sounds like a much sanner proposal, without legal hurdle, just in need of technical work. Because I am interested in improving Debian, not some non-free derivative. -- ciao, Marco signature.asc Description: Digital signature
Firefox logo (Was: Re: making udev require 2.6.15 kernels)
On Sat, Feb 11, 2006 at 10:33:32AM +0100, Marco d'Itri [EMAIL PROTECTED] wrote: I also plan a GR to accept in main less free artwork which if removed does not change the functionality of the software using it (e.g. the firefox logo). The main problem with the firefox logo is not its non-freeness, but the trademarks infringment associated with its use. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
openssl for testing.
Hi, Could you please hint the openssl 0.9.8a-7 version into testing? Note that it has a udeb, so it needs to get approved. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Sat, Feb 11, 2006 at 11:07:02AM +0100, Marco d'Itri wrote: On Feb 11, Sven Luther [EMAIL PROTECTED] wrote: As the install media are built our of main though, this is probably not going to cut it without proof that it can be done on a technical point of view. It could be main or a subset of non-free or a new section, it's just a detail which I do not consider important. well, as the installer packages (and thus the install media) are autobuilt in main, i think this is the clue of the problem. Why not simply have a non-free set of install media, and be done with it, sounds like a much sanner proposal, without legal hurdle, just in need of technical work. Because I am interested in improving Debian, not some non-free derivative. So, what is the difference in having non-free firmware in the non-free section of the debian archive, or having non-free firmware somewhere as of yet undefined, and then magically added to the installation media, which would then be held in the debian archive. I think having a non-free set of installation media together with a free one is by far the more promising solution, and the more honest as well, and on top of that doesn't need a GR. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
This one time, at band camp, Marco d'Itri said: [EMAIL PROTECTED] wrote: In this case, does it make any sense to treat the two versions of udev similarly to how we treat library transitions? I.e., rename the new udev to udev-$min-kernel-ver or something? (the name is ugly, but you It's not clear which problem this would solve, exactly. It could solve the 'I have overwritten the udev that worked with this kernel with a udev that dies and leaves me unable to function' problem. It is not a perfect idea, and I don't particularly like it (for aesthetic reasons if nothing else). But if the best we can do is run time checks to determine which kernel we are running on, then we may need to support multiple udev versions. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: Preparation of the next stable Debian GNU/Linux update (I)
Martin Schulze wrote: would you entertain a one-line fix removing the deluser command from the postrm of chipcard-tools (source package libchipcard). [...] Please go ahead. Normally, such a change wouldn not warrant a fix in a stable release, but in this case the package in question is not available in the subsequent distribution so it will be removed in either way, hence an update. OK, I've uploaded 0.9.1-7sarge0. Thank you for the quick reply and assessment. Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
requesting testing removal of saoimage (was Re: Processed: Re: Is Tinguaro Barreno Delgado [EMAIL PROTECTED] MIA; OR, Can we remove saoimage?)
On Sun, Feb 12, 2006 at 03:30:50AM +0100, Jeroen van Wolffelaar wrote: On Sat, Feb 11, 2006 at 09:26:43PM -0500, Justin Pryzby wrote: On Sun, Feb 12, 2006 at 03:24:18AM +0100, Jeroen van Wolffelaar wrote: On Sat, Feb 11, 2006 at 06:18:09PM -0800, Debian Bug Tracking System wrote: retitle -1 Please remove saoimage from testing Bug#352466: saoimage: Fails to call MAKEDEV to create devices Changed Bug title. Ftp-master doesn't deal with testing removals, that's the release team's prerogative. And for unstable, we're awaiting Tinguaro's reply. Is there a release BTS page I can use? Or, what is the procedure? Ask -release. Will happen semi-automagically if there's an RC bug. Right; release team, please consider removing saoimage from testing: 1 RC bug; unresponsive maintainer; obsoleted (by my own package saods9); unmaintained upstream; last release Dec 2003; I'd like to wait before removing it from unstable, to see if anyone will adopt it, if we hear back from Tinguaro, or even just if anyone is using it. Thanks Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: requesting testing removal of saoimage (was Re: Processed: Re: Is Tinguaro Barreno Delgado [EMAIL PROTECTED] MIA; OR, Can we remove saoimage?)
On Sat, Feb 11, 2006 at 10:03:18PM -0500, Justin Pryzby wrote: On Sun, Feb 12, 2006 at 03:30:50AM +0100, Jeroen van Wolffelaar wrote: On Sat, Feb 11, 2006 at 09:26:43PM -0500, Justin Pryzby wrote: On Sun, Feb 12, 2006 at 03:24:18AM +0100, Jeroen van Wolffelaar wrote: On Sat, Feb 11, 2006 at 06:18:09PM -0800, Debian Bug Tracking System wrote: retitle -1 Please remove saoimage from testing Bug#352466: saoimage: Fails to call MAKEDEV to create devices Changed Bug title. Ftp-master doesn't deal with testing removals, that's the release team's prerogative. And for unstable, we're awaiting Tinguaro's reply. Is there a release BTS page I can use? Or, what is the procedure? Ask -release. Will happen semi-automagically if there's an RC bug. Right; release team, please consider removing saoimage from testing: 1 RC bug; Er, an RC bug that you *just* filed. Packages are removed from testing periodically by the release team according to various criteria; please don't ask for testing removals for packages that aren't yours or that don't need to be removed in order to get other fixes into testing -- all RC bugs eventually leave testing anyway, and for packages that you think should be removed from unstable as well, getting the ftp team to remove them from unstable means fewer people have to be involved. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
