Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Tue, Aug 08, 2006 at 04:49:33PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Well, it reads to me that we won't screw our users without second thought like some here are proposing. In my opinion, we have been screwing our users for years by lying to them about whether their software was free. We would even say things like hardware such-and-such is supportable with free software and then ship them a non-free driver. Well, its a different sort of screwing. But then my position on this has always been to be clear, and say things plainly as they are, and not like others or other distribs or upstream to ignore the issue and hope it does go away. At this point we have those possible choices : 1) move the kernel to non-free, and be done with it. 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. 3) reverse-engineer and reimplement those firmwares, or convince upstream to free them. 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. 2) (and 1) also mean the cooperation of the d-i team, which we have not been getting on this so far, all to the contrary, since they need to fix d-i to load more than one apt source, and since the d-i folk probably consider the etch d-i as frozen right now, ... So, this leaves us what, as reasonable solution for etch ? 1 and 4, and 1 will be too disruptive, so only 4 is left. It is not as if the issue is new though, we have been knowing about this since almost a year, and many voiced their concern or support at various time, but actual help was few and far between (partly our fault in one case though at least). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. This is certainly the last resort, in my opinion, but it isn't crippled. Merely not supporting particular pieces of hardware, in a world in which Linux *already* fails to support lots of popular hardware, is not a disaster. It's a shame, and we should avoid it if we can, but it's a shame. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. Life is rough. The kernel team has had *ample* warning, since it was midway through *sarge* that the rules became clear. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:57:36AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 2) either move the individual affected drivers or just their firmware if possible to non-free, and keep the cripled kernel in main. This is certainly the last resort, in my opinion, but it isn't crippled. Merely not supporting particular pieces of hardware, in a world in which Linux *already* fails to support lots of popular hardware, is not a disaster. It's a shame, and we should avoid it if we can, but it's a shame. 3) would be nicest, but it is a never ending task, and we can't do it. We could do 2), but even this will mean some serious work and possibly a delay of the etch release schedule, especially as we don't have a full audit of what files are exactly affected. Life is rough. The kernel team has had *ample* warning, since it was midway through *sarge* that the rules became clear. Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. Now, this is a long term *UPSTREAM* kind of work, and we simply don't have the ressources of undertaking it. As for me, i have been bogged down into defending against the multiple tentatives to get ride of me since early marsh, and could thus produce no useful work of this nature during this time, Andres Salomon left because his tentative of exclusion of me from debian failed, others have been assortedly busy too. And it is not as if *YOU* had not ample warning about the ressource problems, since we mentioned the lack of manpower and ressources regularly since a almost as long as the issue surfaced. And this is not really a work which can be done without diverting ressources from normal maintenance work, which would be detrimental. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? Well, again, the offer is open, and i already multiple times proposed those like you to start helping and providing an exhaustive list of those files which are involved, as well as a basic classification of the nature of their problem. This is assuredly within the reach of each debian maintainer or associated, and doesn't need any particular kernel-coding skill, but some legal/licencing knowledge. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Sven Luther [EMAIL PROTECTED] writes: On Wed, Aug 09, 2006 at 12:58:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: 4) pass a GR explaining the issue as is, and admitting our incapacity to fix it with 2 or 3 due to lack of ressources. We do not need a GR to simply follow our existing procedures. Sure, we do, because wehad a pre-sarge GR, which allowed to ignore the firmware (and other issues), but only for the sarge release, remember ? We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. However, what started this thread IIRC was a complaint that the kernel team was *closing* the relevant bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Hinting of linux-ntfs.
Hello, developers. I have seen that linux-ntfs 1.13.1 is not advancing to testing due to the freeze. I thought that fjp was looking into it. We ran into problems with 1.13.1 (see #379628), but in fact it turned out to be a problem in how the partition size is chosen (size units, really). I guess that the freeze for udeb's will be until d-i beta3. Maybe it would be interesting to have 1.13.1 in Beta3, wouldn't it? Best regards, Ender. -- Uh, we had a slight weapons malfunction, but uh... everything's perfectly all right now. We're fine. We're all fine here now, thank you. How are you? -- Han Solo (Star Wars). -- Desarrollador de Debian Debian developer pgpkKKH98wjE8.pgp Description: PGP signature
Re: Hinting of linux-ntfs.
On Wednesday 09 August 2006 12:17, David Martínez Moreno wrote: Hello, developers. I have seen that linux-ntfs 1.13.1 is not advancing to testing due to the freeze. I thought that fjp was looking into it. We ran into problems with 1.13.1 (see #379628), but in fact it turned out to be a problem in how the partition size is chosen (size units, really). I guess that the freeze for udeb's will be until d-i beta3. Maybe it would be interesting to have 1.13.1 in Beta3, wouldn't it? Unfortunately the build failure on alpha delayed linux-ntfs too much to rename the dependency in partman for the udeb in time for Beta 3. This means that partman in Beta 3 still depends on the old ntfstools-udeb. I therefore decided to release Beta 3 with the old version of linux-ntfs (i.e: have the old version included on Beta 3 CDs). I have also tested that the Provides: in ntfsprogs-udeb does work and so migrating linux-ntfs to testing after the release of Beta 3 will not break Beta 3, so I will request to unblock linux-ntfs probably next week. The above also means that the Provides: will need to be kept at least until after the next d-i release. Cheers, FJP pgpk5nhKlB4Jl.pgp Description: PGP signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On Wed, Aug 09, 2006 at 02:01:33AM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Nope, the issue only surfaced early after the sarge release, a bit less than a year ago, when the new kernel team formed. It was discussed *before* sarge was released that there was non-free firmware in the kernel, and we decided to ignore it for the sarge release. We explicitly did *not* decide to ignore it forever. Maybe, but the kernel team was really operational, and not saddled with broken legacy packaging only after the sarge release. So, basically, you are criticizing the kernel team for not having devoted enough of their *volunteer* time to this issue, and at the same time you expect us to provide good quality kernel packages to debian ? No. I would be content with a we don't support that hardware decision, though it would be less than the best thing. I'm willing to wait for this work to be finished before etch is released. Yep, but the question is, are the rest of the DDs willing to wait too ? This is best answered by a GR, not sure if it needs 3:1 supermajority or not, i think if it is only a delay-it-once-more, it does not need that, contrary to a changing of the wording of the social contract would be. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Scores in that thread: who how many -- A. Spragg 1 A. Thornton1 B. Gerardo 1 D. Dickinson 1 F. Schueler1 G. Danchev 1 G. von Brederlow 4 J. Smedegaard 2 J. Neal1 M. d'Itri 10 M. Hommey 1 N. Nerode 2 (deserve a bonus as the thread launcher) R. Johnson 2 S. Luther 16 T. Seufer 1 T. Bushnell 15 == Grand total 60 Special mention to the 3 that did (more than) 66% of the noise. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpk9zXSdsxIi.pgp Description: PGP signature
Need advice regarding gettext 0.15
Hello. In order not to repeat sarge mistakes, I have a simple question for the release managers: Am I in time to upload gettext 0.15? This is the upstream NEWS file: === Version 0.15 - July 2006 * GUI program support: - PO files can now contain messages constrained to a certain context. Most often such a context is a menu, dialog or panel identification. The syntax in the PO file is msgctxt context msgid original msgstr translation - The xgettext program can be told through the --keyword flag which function/macro argument has the role of a context. It also supports the GNOME glib convention to specify the context and original string in the same string literal: context|original. - The (non-public) include file gettext.h defines macros pgettext, dpgettext etc. that take a context argument. For more information, see the node Contexts in the manual. * msgfmt's format string checking is now stricter in the presence of plural forms. For example, in German, with nplurals=2 and plural=(n != 1), the translation #, c-format msgid %d fatal error msgid_plural %d fatal errors msgstr[0] ein fataler Fehler msgstr[1] fatale Fehler was earlier considered valid and now gives an error when msgfmt --check is used: number of format specifications in 'msgid' and 'msgstr[1]' does not match * msggrep has a new option -v/--invert-match that acts like grep's -v option. * msggrep has a new option -X/--extracted-comment that allows to search for a pattern in the extracted comments. * xgettext's --keyword option now allows to specify an extracted comment on the command line, rather than in program's source code. * msgmerge is much faster now, when using a large compendium. * A new program recode-sr-latin is provided, that converts Serbian text from the Cyrillic script to the Latin script. The command msgfilter recode-sr-latin can be used to convert a Serbian Cyrillic PO file (sr.po) to a Serbian Latin PO file ([EMAIL PROTECTED]). * Programming languages support: - C++ with Boost: xgettext has a new option --boost that triggers the recognition and marking of boost::format strings. - Python: xgettext now recognizes the source encoding from a coding: comment among the first two lines. The default encoding is now ASCII, no longer ISO-8859-1. * libgettextpo library: - The error handler type passed to po_file_read(), po_file_write(), po_message_check_format() has changed. This is an incompatible change: Programs using the library *must* update their code. Binary compatibility is guaranteed, however. * The 'mkinstalldirs' shell script is no longer needed and no longer installed by gettextize. * Portability: - Building on mingw is now supported. - Building shared libraries (--enable-shared) on Cygwin and mingw is now supported. * Interoperability with expat version 2.0.0. * Documentation: A complete example showing the use of GNU gettext with the wxWidgets GUI toolkit has been added. === I see a lot of improvements here and there, but also several dangerous things. However, I don't know how much dangerous they are: * msgfmt is now more strict. This is potentially dangerous, but maybe it's not after all for packages which do msgmerge at build time (debconf et al), as the wrong strings would be treated as fuzzy translations anyway. * libgettextpo library. I believe this definitely not to be dangerous, as there is not a single package in sid which depends on libgettextpo0. My opinion is that this release is not particularly risky (looking at gnu.utils.bug I only see a problem in xgettext, which would be fixed in Debian anyway, as there is a patch), but I would like the opinion of the release managers. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
Hallo, On Wed, Aug 09, 2006 at 02:02:42AM -0700, Thomas Bushnell BSG wrote: We can simply take our time to do (2). It is the job of a package maintainer to check the licenses of their software; if the kernel team cannot do so by December, even with help, I don't mind waiting. then, please, send patches. Best regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Please reschedule libgnomesu 0.9.5-3 on ARM
Hello, libgnomesu 0.9.5-3 initialy FTBFS to temporary uninstallable build-depends and when vorlon re-scheduled on july 31st it suffered the same fate as the directfb transition temporarily wreaked havoc. Please rerescedule it. Thanks. cu and- release goal: Only one version of gnutls in etch -reas signature.asc Description: Digital signature
Upload of version of the cron package (comments?)
Hi there release team,
I have made a few (minor) improvements to cron that I would like to squeeze
into before base is frozen. Attached is the .changes file of the package I
have ready to upload. Unlike the gettext one (Santiago's) I don't intend
to do an update to the latest upstream, but it's in my TODO list (not for
etch, though)
A summary of the changes:
- typo fixes to manpages
- two example scripts (increases the size of the package in 15K) that can
prove to be very useful (specially the stats-cron code I wrote recently
together with the -L 2 option introduce in -95)
- a change in how cron.{deny,allow} files are handled. In -95 an previous a
user that is both in the deny and allow file will be granted access to
cron task definition, with the change if a user is in both he is denied
access by default. Either case, root access to cron is always assured
- introduced code to use libaudit [1], but its disabled by default as it
is not (yet) available in Debian kernels (or userspace)
Does this look OK to upload?
Regards
Javier
[1] Steve Grubb's Audit daemon whttp://people.redhat.com/sgrubb/audit/, these
changes (and kernel changes) are required for Common Criteria certification,
The patch is based on the one available in Fedora, but rewritten for Debian
as I have done for previous patches and intend to do for many more.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Wed, 9 Aug 2006 01:07:40 +0200
Source: cron
Binary: cron
Architecture: source i386
Version: 3.0pl1-96
Distribution: unstable
Urgency: low
Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Description:
cron - management of regular background processing
Closes: 379230
Changes:
cron (3.0pl1-96) unstable; urgency=low
.
* Fix error in manpage that prevent a line from being presented (Closes:
#379230)
* Introduce Steve Grubb's patch to emit audit log message on crontab denial
based on the patch from Fedora, and adapted to Debian's cron version. The
main difference is that audit logs are generated if cron is compiled to
'ALLOW_ONLY_ROOT'. This patch is currently disabled
since LSPP's audit library is not yet available.
* Change misc.c so that a user that is *both* in the cron.deny and
cron.allow files will be denied access (previously he would be permitted
access)
* Add two example scripts:
- stats-cron.pl: A script written by myself that can be used to audit
the behaviour of cron and benefits from the new cron logging (-L 2)
option to log the *end* of a cronjob.
- crontab2english.pl: A script written by Sean M. Burke that translates
the crontab notation to natural language.
* Adjust debian/copyright to acknowledge the (c) and license of the above
scripts.
Files:
480284dd741e37a451669546ec86d736 801 admin important cron_3.0pl1-96.dsc
0cfbbf5e7962e2bc43ac5f11c6fff88b 64813 admin important cron_3.0pl1-96.diff.gz
0c2c11c2dc2db6f09ee7e891181f1506 76396 admin important cron_3.0pl1-96_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
iQCVAwUBRNk8k/tEPvakNq0lAQL87gQAoym0ph/b22ZGCbRuEmWgjfGxwc1lpshv
dP8e+jBaTAP+/q3TC8m5UWy2JHuNfj7J2RAAOg2hMEbqcOXAuDWWB90PzsjySBK8
JjbKxub5ZMP6ZZLIAsd74Dhqoa9uGwGLqet1DuXv+Azi6qfnzi9DQLxU2IX0ZNQx
w+LvyVxmNl8=
=g03p
-END PGP SIGNATURE-
signature.asc
Description: Digital signature
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
On 08/02/06 22:17, Nathanael Nerode wrote: Start with drivers/char/drm/mga_ucode.h. This is distributable, because it's under a BSD license, but it's not free software, because there's no source code. There is no source code, because there never was any source code. What do you think should be done if source code doesn't make sense or can't be made? Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch timeline is unrealistic because non-free firmware is NOT being dealt with
I apologize for responding to Marco's post; in retrospect he was clearly trolling and I should not have responded to him. The point of my initial message was not to argue: it was that the etch timeline is unrealistic, because I see no progress on removing the substantial number of sourceless binaries from the Linux kernel source package, and it's *after* the kernel was supposed to have frozen! Is there a plan for dealing with this fast enough to avoid delaying the release of etch? If so, please post it. If not, I suggest the following process improvements: For each driver containing a sourceless binary, someone (probably me) will file a single bug against the source package linux-2.6. Currently there is a single bug (242866/243022) covering multiple issues, against 'kernel', which is a pseudo-package. Looking at the list of antique bugs against 'kernel', I don't think anyone is reading them. Also, with the planned removal of pre-2.6 kernel packages, a bug against linux-2.6 seems sufficient to cover everything. Why one bug per driver? Because each driver's bug is slightly different and I expect each to be fixed in a slightly different way. Some bugs are distributability issues, while some are clearly distributable and simply non-free. Some may be fixed by a new upstream version. Some may be fixed by implementing firmware loading and a non-free firmware package; some may be fixed by moving the driver to an out-of-tree kernel module; others may be fixed by removing the driver entirely; others (where the firmware is unimportant) may be fixed by removing the firmware and the support for whatever feature it enables. In the case of the DRM modules, the result may depend on the implementation of features in X, and bugs may block on that. The point is that each case is going to be different. The progress on the different drivers is already different. This should make tracking the issues significantly clearer: specifically it will make it clear exactly what needs to be done to fix this. It would also make it look a bit less like an infinite tentacled monster, perhaps making it easier for people to bite off one bug at a time. (Certainly I get confused posting fixes for different drivers to the same bug.) We would then convert 242866 to a meta-bug blocking on each individual bug. How does that sound? http://wiki.debian.org/KernelFirmwareLicensing is grossly out-of-date, but I will integrate the relevant information from that in the process. Alternative option: the Wiki page could be revived and used to coordinate the process. Unfortunately it's quite out-of-date, and it's unwieldly. I prefer the BTS option because it's more permanent, harder to ignore, and better at holding patches and whatnot. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Please reschedule libgnomesu 0.9.5-3 on ARM
On Wed, Aug 09, 2006 at 08:05:22PM +0200, Andreas Metzler wrote: Hello, libgnomesu 0.9.5-3 initialy FTBFS to temporary uninstallable build-depends and when vorlon re-scheduled on july 31st it suffered the same fate as the directfb transition temporarily wreaked havoc. Please rerescedule it. Thanks. Done. Thanks, -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BinNMU to get rid of libtasn1-2 dependencies
On Mon, Jul 31, 2006 at 07:46:35PM +0200, Andreas Metzler wrote: On 2006-07-31 Steve Langasek [EMAIL PROTECTED] wrote: On Sat, Jul 22, 2006 at 10:36:24AM +0200, Andreas Metzler wrote: On 2006-07-20 Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Jul 16, 2006 at 11:02:49AM +0200, Andreas Metzler wrote: [...] Could you please schedule a +b2 binNMU for amd64 and s390? These two archs had an old +b1 binNMU and where not rebuilt. (I'll try to provide this kind of information when I request a rebuild next time.) Queued now. Built and uploaded, now. ;-) In which form would I need to provide NMU requests to generate as little work for you as possible? Is this ok, or is their another representation you'd favour (perhaps you need the complete Debian version for example)? --- gsasl (amd64 and s390 +b1, all archs except s390 need a rebuild.) --- thanks, cu andreas The ideal form would be [package]_[source-version], [reason], [binNMU number], [list of archs] repeated for each (package,binNMU number) tuple. I've queued the gsasl binNMUs now. Thanks, -- 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
