Re: On the freeness of a BLOB-containing driver
Goswin von Brederlow wrote: >If it comes down to "the driver, on its own, would not be acceptable for >main because it is not functional; but as a practical matter, we allow >it aggregated with the rest of the kernel because splitting individual >drivers into contrib is a pain for everyone involved and not worth the >theoretical benefits", I can live with that. Yes, yes! Let me say that this is precisely what I think. >"contrib" exists for software which is free but fails SC#1, "we will never >make the system depend on an item of non-free software". Moving something >from contrib to main that does, in fact, depend on such an item is a pretty >basic violation of Debian's principles. Suppose the thing being moved is not a vital part of the system. Then, although the item being moved depends on non-free software, does the *system* really depend on it? Then it pretty much comes down to what you said above. :-) -- This space intentionally left blank.
Re: Are BLOBs source code?
Goswin von Brederlow wrote: (and it really was him this time -- sorry about last time; hand-quoting is tricky stuff): >Is the pseudo source file enough for BSD or Artistic license? It's enough for BSD. (Which doesn't actually require source.) >On the same subject but going in a totally different direction: > >As you say many blobs have been identified as code. Having pseudo >source files under a free license would give everyone the right to >disassemble the code. Reverese engeneering of the firmware would be >allowed. Allowing pseudo source might be benefitial because it alows >this. Yes. BSD-licensed BLOBs could be legally disassembled, decompiled, cleaned up, commented, improved, and the result could be Free.
Re: On the freeness of a BLOB-containing driver
Goswin von Brederlow wrote: [EMAIL PROTECTED] (Nathanael Nerode) writes: Goswin von Brederlow wrote: ^^ This is wrong. Glenn Maynard? If it comes down to "the driver, on its own, would not be acceptable for main because it is not functional; but as a practical matter, we allow it aggregated with the rest of the kernel because splitting individual drivers into contrib is a pain for everyone involved and not worth the theoretical benefits", I can live with that. Yes, yes! Let me say that this is precisely what I think. "contrib" exists for software which is free but fails SC#1, "we will never make the system depend on an item of non-free software". Moving something from contrib to main that does, in fact, depend on such an item is a pretty basic violation of Debian's principles. Suppose the thing being moved is not a vital part of the system. Then, although the item being moved depends on non-free software, does the *system* really depend on it? Then it pretty much comes down to what you said above. :-) -- This space intentionally left blank. You misquoted. That wasn't me. Oops, very sorry. Glenn Maynard? Hand-quoting sucks, but I've been reduced to it recently.
Re: New author/maintainer for pinfo needed
Bas Zoetokouw wrote: >I do actually use it, so unless anyone else wants to take it, I'd be >happy to take it over. I don't think I'm ready to "take it over" alone at this point, but I also use it heavily and would like to help work on it. Nathanael Nerode
Re: Resignation and uploads
Wouter Verhelst wrote: > Oh, and here's something else to ponder: Maybe, just maybe, James has > more time to go to Ubuntu below zero than he has to handle keyring > updates because he prioritizes by what gets the bills paid. As most of > us do, I suppose. Maybe, just maybe, someone else should be authorized to update the keyring then, if James is so busy he can't handle it. This sort of thing has happened repeatedly with James Troup, who has clearly volunteered for more than he can manage -- many thanks to his giving heart, but it's obvious additional people need to be assigned the power to do these jobs. Branden? -- Nathanael Nerode <[EMAIL PROTECTED]> This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mixing different upstream sources in one package
Jay Berkenbilt wrote: > >>From time to time, someone announces an intention to package some tiny > script or program, and people suggest including it in some other > package instead to avoid pollution of the archive with lots of tiny > packages. Although I understand the reasoning and the issues here > (additional overhead for each package), this has always bothered me a > little. I'm not sure that, as an upstream author, I would necessarily > want the debian version of my package to be bundled with other > software that was similar in functionality but otherwise unrelated to > my package. I think this really does depend on size, and on how the tiny program is used. If the program is really tiny, and it is generally used in conjunction with your package and by people who use your package, it should probably be added to your package. Ideally it would be added upstream, and if not, it can be added to the .diff.gz. If the program is likely to be used by people who won't be using the rest of your package, then it's inappropriate to put it in your package. If it's sufficiently large and complicated that it would trouble the maintenance of your packages, then you shouldn't put it in your package. > I've recently taken over maintenance of psutils and am gradually > working through the outstanding bugs on that package. A few of the > bugs suggest adding external programs. Assuming there are no other > impediments (like licensing problems), do people generally think that > it's reasonable to do this even if the other packages aren't really > part of the upstream package? If so, are there usual mechanisms for > doing this? Put it in the .diff.gz. If it's too large for that to seem reasonable to you, then you proabably shouldn't put it in your package. :-) -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: I am still on the keyring. With my old key.
Chip Salzenberg wrote: > Who does a developer have to fuck around here to get his key deleted? Same one he has to fuck to get a new key added, presumably. It's a pity the DPL hasn't anointed a less-busy person with authority to alter the keyring. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Blrgh!
OK. So I was working on the problem of fixing dpkg-dev so that
foo Depends: foo-data {SourceVersion}, foo-libs {BinaryVersion}
or something similar actually works. By parsing the version numbers.
Now it's apparently been changed under our noses, in such a way that my
proposed
scheme won't work -- and furthermore anyone who implemented their own
version
of such code, in their own package, will find it magically broken.
Thanks to Goswin and Henrique for *notifying* people of this, since
apparently whoever changed it didn't think about the impacts on other
developers.
Instead binNMU versions are now made by adding +b1 (+b2, +b3) to the
version and containing a "Source: foo (non-NMU version)" line. The
later makes it possible to reliable associate binNMUs with their
source.
So how do we write a package Depends: line now? Apparently the buildd uses
the original source,
and adds a changelog entry -- *but what happens to the {SourceVersion}
substitution?* Does the buildd
alter the substvars file before compiling? Does the {SourceVersion}
substitution end up being the original 1.2-3 source version, or the 1.2-3+b4
version? Whichever it ends up being, *how do we get the other one* if we
need it?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
SDL producing bogus dependencies or packages misusing SDL?
I wanted to verify this. I've been looking at a number of packages which have picked up dependencies on libartsc0, libasound2, libaudio2, libaudiofile0, libsed0, libjpeg62, libpng12-0, and many others, without actually build-depending on any of the corresponding dev packages. The common factor is that they depend on libsdl-image1.2, libsdl-mixer1.2, and/or libsdl1.2debian. Clearly they're suffering from recursive library dependency disease. The question is this: is this due to some script in the SDL packages? They're complex enough that I couldn't actually tell. The alternative possibility is of course that each of these packages generated the bad recursive list on its own, which is just as likely. I'm wondering where to file the bugs. :-) -- Nathanael Nerode <[EMAIL PROTECTED]> A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Michael Banck wrote: >The main problem of the arm port is *not* the buildd maintenance, but >rather the lack of people fixing actual bugs, which is *not* the job of >the buildd admin but of the porters. Saying it doesn't make it true. In fact, people who have volunteered to diagnose bugs in the past -- specifically Thomas Bushnell BSD -- have stated that they have become dispirited and unwilling to do so *because* of the behavior of the buildd maintainers; to wit, ignoring their diagnosis work. So, provide better evidence for your claim please. >Unfortunately, you do not seem to trust James' opinion on this, but why >do you not trust our beloved Release Manager, either, who said he knew >of no serious issues with buildd maintenance right now? Why should either of them know, to be perfectly frank? This is argument by authority, not an actual argument. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
Petter Reinholdtsen wrote: > > Perhaps it is time for a replacement buildd network, and a new > > delegation from the DPL for keyring maintenence? Anthony Towns wrote: > Whatever for, exactly? Transparency. You understand transparency, I know, since you practice a great deal of transparency in your own Debian work, as is clear from your blog. Many kudos to you for that. Another developer who practices transparency to a great degree is Steve Langasek, who *always* seems to have time to answer a question -- or even to respond to a comment, which is actually more than is needed. When things go wrong, there is no useful contact address for the buildd maintainers or admins. There is also no feedback from buildd maintainers/admins or keyring maintainers regarding whether a request has been receieved. It's like dropping wishes into a wishing well and then waiting to see whether they come true. The fact that the wishing well appears to be working unusually well at the moment is almost beside the point. >The buildd network's working better today than >it has since woody released, IMO. Yes. I wonder why? There's no way to tell what's changed, who's done it, or when it will stop being true. Meanwhile, buildd.debian.org *still* isn't using Ingo Juergesmann's much-much-better buildd.net status scripts. For no apparent reason. Certain buildd admins aren't cooperating with the buildd status lines on that site either. For no apparent reason. There's nobody to contact to explain why, because the contact points for these things act like wishing wells. To respond preemptively to one expected reply: "I don't have time to answer these questions" is not a reasonable excuse, because if they don't have time, they need to ask for help. If they don't think that anyone is skilled or trustworthy enough to help with the work they're already doing, then (a) they're probably wrong, and (b) at any rate there is certainly someone skilled and trustworthy enough to act as 'press secretary' for them, collecting all the questions from the outside and returning the answers to the outside! >I also see the keyring's been updated >earlier this week, including both a replacement key for Horms from late >last month, and Chip's requested updates. Indeed, complaining on debian-devel appears to get results, doesn't it? At least, that's the conclusion that a rational outside observer would come to. If that's an inaccurate conclusion, it indicates that there's something seriously wrong in the transparency of the processes. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
CC:ing you because this is sufficiently important I want to make sure you notice that I'm actually answering what may have been a rhetorical question. >What problems are there today with buildd administration, please? No clearly-documented contact addresses for buildd administrators (as noted upthread). Mail to any of the apparent contact addresses receives no replies. Accordingly, there is no way to tell whether a message has been heard. If a package is requeued (or whatever) there is no way to tell which of the several addresses you sent mail to had an effect, or if it happened on its own. If nothing happens, there is no way to tell whether your mail was lost in transit, or whether the buildd administrator retried it and found some problem without telling you, or whether the package is in some kind of dependency-wait state for reasons you don't know about. This lack of transparency and lack of contact addresses is particularly annoying for packages which have built and not been uploaded, which should be trivial to deal with, but aren't. Plus, no useful contact address for buildd.debian.org, and effectively no way to get any improved scripts moved onto it. That enough problems for you? :-P Contrast to the incredibly transparent operations of debian-release, or the ease of getting patches added to the PTS (packages.qa.debian.org) scripts. Or indeed the less-transparent but still fairly responsive BTS maintainers. It is of course possible that for you, all the correct email addresses are known, and all the people at them reply to you. If so, please know that that is not how it is working for most people. The only replies I've ever received from contacting (what I thought was) a buildd admin address were "Sorry, I'm not the buildd admin". Apologies for the thread-breaking, I'm reading on the web pages again. :-/ -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd administration
This is an omnibus reply. Sorry about the thread-breaking, but I'm on yet *another* computer, and I can't seem to find a mailer which respects the In-Reply-To headers from the web pages or lets me add my own. == I would like to note that I have made a practical and *new* suggestion for dealing with some of these problems (contrary to suggestions that I'm just flaming), because nobody's picked up on my idea. From http://lists.debian.org/debian-devel/2005/12/msg00298.html: If they don't think that anyone is skilled or trustworthy enough to help with the work they're already doing (b) at any rate there is certainly someone skilled and trustworthy enough to act as 'press secretary' for them, collecting all the questions from the outside and returning the answers to the outside! I haven't heard this suggested before as a means to assist overworked people in key positions with the problem of communication. It would reduce the number of people the overworked people have to communicate with to one, removing the need to explain anything more than once. That one secretary could receive status reports and use them to generate answers for all outside questions, while batching together unanswered questions into groups. In addition, that secretary could provide a contact addresses which is properly advertised -- clearly not a task which requires great trust, but one which does require close contact with the people actually doing the job. Perhaps it would be more acceptable to the people involved than the other suggested alternatives. It has the virtue of removing some of the need for the people with the key technical skills to also be the people with the key social skills. I'm sure there are people who will volunteer for this role. I will volunteer, since I certainly have the motivation, but I don't really have the right temperment for it, or all of the right set of social skills (though I do have a few skills in that area, believe it or not), and I might be an unpopular choice. The overworked people should clearly be allowed to choose their own "press secretaries" from among the volunteers. == In response to something someone quoted that I wrote a while back: yes, I should have found a better way of dealing with people who are behaving idiotically than insulting them. I constantly try to find better ways. I would expect that everyone should try to do that (after all, all of us behave like idiots sometimes, me certainly included, and I had been behaving idiotically by insulting people). That quote actually demonstrates that I do *not* think that insulting people is effective. Pity, since I'm so naturally good at insulting people in ways which really get under their skin (really useless skill, but there you are ;-/ ). == Regarding specific points. The scripts at www.buildd.net are clearly better at presenting the information than the ones at buildd.debian.org (yes, it's mostly the same information, but presentation matters). I agree that their source code should be made publicly available, and it's a bad thing that they aren't. :-P Ingo, could you fix that? The 'status leds' for the buildds, together with the admin information for each buildd, is a valuable addition beyond what's present on buildd.debian.org, and if done properly would eliminate lots of "what's wrong with the foo-arch buildds?" questions. It's sort of half-present, with occasionally inaccurate admin info, at the moment, which renders it less useful, but that would be fixed purely by cooperation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Solving recursive dependency disease in KDE-based packages
Most KDE and KDE-dependent packages have an 'admin' directory with various evil and unnecessary files in it. I think I've found a recipe for removing the recursive dependencies from such KDE packages. (1) Relibtoolizing. This is much trickier than normal. First install Debian's libtool and autotools-dev. Run all these commands from the top level directory. libtoolize --copy --force Make sure that ltmain.sh, config.guess, and config.sub have been replaced in admin. KDE likes to use its own copy of libtool.m4, so appease it by copying your version into place. cp /usr/share/aclocal/libtool.m4 admin/libtool.m4.in Regenerating acinclude.m4, aclocal.m4, configure.in, and finally configure, can be a pain in the neck. In some packages, it's done by admin/cvs.sh But if that fails you have to work out the individual steps involved. Sometimes the code is in admin/Makefile.common, so you can run make -f admin/Makefile.common configure.in Check that the right version of libtool.m4 got copied into acinclude.m4 and aclocal.m4. You may have to do stuff like make -f admin/Makefile.common acinclude.m4 (2) Possibly fixing acinclude.m4.in In my experience the redefinition of AC_FOREACH sometimes fights with the new libtool. It's just an optimization, so if autoconf crashes building configure, delete that section from admin/acinclude.m4.in and rebuild everything up to and including configure, as noted under (1). (3) Fixing *_LDADD, *_LIBADD, *_LDFLAGS in the Makefile.am files. Replace stuff like $(LIBFOO) with -lfoo, and get rid of stuff like $(all_libraries). $(LIBPTHREAD) is never needed on Linux and should be removed; there will be other libraries like that, where you should just remove the $(LIBFOO) entry entirely. This takes some trial and error. The configure script may dump stuff into LDFLAGS, in which case your best bet is to delete that and replace it with an explicit list of libraries. It's OK to do these changes unconditionally because KDE never builds static libraries. To work out which libraries you're linked to which you don't actually need, ldd -u is invaluable. Rebuild your Makefile.in by running the correct version of automake, and then -- this is very important -- running admin/am_edit All the KDE packages edit the Makefile.in generated by automake with this script before actually using them. If you've managed to get a working Makefile, you may be able do this rebuild with 'make (subdir)/Makefile.in' The configure script will be figuring out a lot of useless stuff, but it's easiest to let it waste its time. admin/acinclude.m4.in has a lot of 'foo-config' type code for working out recursive dependencies, and we want to ignore most of it, but it's rather hard to delete it without deleting code we actually want. In the long run, it might be advisable to make a Debian-specific version of it with all the hideous cruft removed, and then all KDE-based packages could be fixed just by updating it; but that's a lot of work. (4) Remove any cruft generated during the rebuild. Sometimes this process leaves extra files hanging around which weren't there before. :-P I license this message as if it were public domain; please copy it anywhere it might help and edit it as needed. -- Nathanael Nerode <[EMAIL PROTECTED]> A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: question towards "freetype transition; improved library handlingneeded for all C/C++ packages"
[EMAIL PROTECTED] wrote: > I believe my package is affected by the issues stated by Steve, > depending on libraries which I do not directly use. Most of them are > probably pulled in through the QT library I am depending on. My package, > packagesearch, uses qmake as a build tool. The linking command line > contains loads of other libraries including freetype (collected by > qmake). The long-term solution is to fix qmake. Maybe I'll give it a poke. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ldd -u (Re: Solving recursive dependency disease in KDE-based packages)
[EMAIL PROTECTED] wrote: > * Nathanael Nerode [Sun, 11 Dec 2005 07:35:41 -0500]: > > > To work out which libraries you're linked to which you don't actually need, > > ldd -u is invaluable. > > This seems like not the case _at all_ to me (the "invaluable" bit): Yes, it definitely gives lots of false positives. I haven't seen it give a false negative yet though, which makes it a reasonable starting point. >For now, I > plan on sticking to Henning Makholm's "libneeded" lintian check: Great if you've got it working; I hadn't. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Solving recursive dependency disease in KDE-based packages
>On Sun, 11 Dec 2005, Nathanael Nerode wrote: >> Regenerating acinclude.m4, aclocal.m4, configure.in, and finally configure, >> can be a pain in the neck. In some packages, it's done by Henrique de Moraes Holschuh wrote: >autoreconf ? NO NO NO. That does not work for these KDE-based packages, which is the whole reason I said it was a pain in the neck. > Replace stuff like $(LIBFOO) with -lfoo, and get rid of stuff like > >Is not this used to find the correct libfoo in the configure script? NO. (Well, sometimes that's a small part of what it does.) It's used to find all the things which need to be put on the link line in order to link with libfoo. Unfortunately it does this assuming that all the recursive dependencies need to be put in. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
buildd.debian.org (was Re: buildd administration
So for various reasons the buildd.net status code is not considered ready to be integrated on buildd.debian.org, either by its author or by its maintainer or by Ryan Murray. Fine, I understand. Well, after looking at http://buildd.debian.org/~jeroen/status/ , I concur that it's as good a general interface to buildd status as buildd.net, and much better than the http://buildd.debian.org/ interface. (The contact addresses and machine up/down statuses are a valuable part of buildd.net which *isn't* there, but that's another matter entirely, which requires different and additional work.) However, even though this is on the same machine, this isn't linked from the main http://buildd.debian.org webpage, or from the Developer's Corner. Meanwhile, the andrea link on http://buildd.debian.org is completely dead. (http://buildd.debian.org/andrea/) I politely request that a prominent link to http://buildd.debian.org/~jeroen/status/ be placed on http://buildd.debian.org/, and that the andrea link be either fixed or removed. This should take less than five minutes for someone with access to the web pages. Sending to rmurray as the listed maintainer of the webpages. Cc:ing debian-devel on the theory that publicizing such a request will prevent duplicate requests. -- Nathanael Nerode neroden fastmail.fm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Yes, ftpmaster is getting efficient at the routine processing. Congrats! Moritz Muehlenhoff wrote: > Petter Reinholdtsen wrote: >> But it is not doing a great job with processing a few old uploads. I >> consider it a problem that no decision have been taken on the few >> really old uploads (xvidcap, rte, mplayer). Indeed, the unfortunate part is the uploads which appear to have been stalled in limbo. > One of the FTP masters (I forgot who) once said that the best way to > help get mplayer into the archive would be to present an overview of > the patent situation surrounding MPEG and the like. ffmpeg has such > an overview in README.patents, which might serve as a good basis, as > the core library code of mplayer, ffmpeg and xvidcap is identical. > (libavcodec/libavformat) Hmm, good idea. mplayer has had all of its long-standing copyright licensing problems dealt with in recent years and debian-legal would be sad to see that go to waste. It looks like the packagers of mplayer and xvidcap have not been notified of the potential problems with their packages, and *that* is disturbing. I'm sure Javier Fernandez-Sanguino Pen~a would be willing to do whatever's needed with xvidcap up to and including repackaging the upstream tarball and removing functionality, and I expect Dariush Pietrzak would do the same. But they haven't been *asked* to. In contrast, Christian Marillat has been asked to and didn't, and the exchange is a matter of record, so the same complaint cannot be made about the ftpmasters' recent behavior regarding rte. Communication from the ftp team regarding these packages would be very helpful, since debian-legal didn't see any copyright problems with them, and all the possibly-patent-encumbered code is already present in other packages in the archive, AFAICS. With regard to rte, the stated problem was the presence of the MPEG encoder -- could this be the problem with the other two? But exactly the same code is also present in the ffmpeg package in the archive already (and in fact any version in Debian would simply use the ffmpeg code from that package rather than using its own copy). So I'm not really sure what the problem is. Is there an unfiled serious bug in ffmpeg? Is there a difference between ffmpeg and the others which I don't know about (perhaps they *are* using their own copies?) Is the problem purely one of documentation, in which case the ffmpeg README.patents file would be sufficient to get such packages in? Do the ftpmasters need help from -legal? Which is it? Similarly, what's wrong with xmovie (1 month)? More importantly, has David Martinez Moreno been *told* what's wrong? (Given what I've heard about the state of the upstream source, I imagine that lots and lots of things could be wrong, but David should at least be told.) Likewise for mozilla-firefox-adblock (2 months), new version of tidy (1 month), xplc (1 month), cvsconnect (1 month), cvssuck (1 month), libmpd (1 month); if there's something wrong with each of these packages, the packager should know by now. Maybe in some cases he does, but in others it appears clear that the packager doesn't know. -- ksig --random| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Russ Allbery wrote: >Assuming that what you say above is correct and FFMPEG is the only issue >(and I have no reason to doubt you), And if it's not, it would be really nice if the ftpmasters let someone know. > I agree that xvidcap and ffmpeg >should be treated the same. However, that is not evidence that xvidcap >should be in Debian -- it's evidence that they should be treated the >same. Perhaps the correct thing to do is file an RC bug on ffmpeg and get >it removed from the archives. I don't know. Correct. >When one doesn't know, the right thing to do is frequently both not make >the problem worse and not overreact, meaning leaving ffmpeg in the archive >and xvidcap in NEW until the situation is clearly understood and resolved >is quite reasonable. Of course, we do need to eventually actually get the >situation resolved and come to a conclusion, after which either both >should be in the archive or neither should. But the current situation of >having one in the archive and one not during a hazy patent/license issue >is *not* evidence of someone doing a bad job. It is evidence of an >incomplete job, which I think everyone, including the ftp-masters, would >agree with. Certainly. Well put. Of course, leaving the job incomplete for this long without any visible signs of progress may be evidence of a job not done. But what *is* evidence of a bad job is that there is one obvious improvement on the current situation which could have been made at any time without making matters any worse. Specifically, xvidcap can be packaged without the ffmpeg code, and if the ftpmasters requested that, I am sure that Javier would be happy to do that as an interim measure until this is sorted out. If the ffmpeg code is the only issue, then it should *not* be delaying xvidcap. If it isn't, then Javier should be told. -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: congratulations to our ftp-master team
Thomas Bushnell BSG <[EMAIL PROTECTED]> wrote: >I think it would be nice if the reasons for long-standing packages >hanging around in the NEW queue were documented publicly, but I do >think in these cases the maintainers actually know the reasons. Well, you're right in the case of Christian Marillat (it's documented neatly in the ITP bug trail), but you're clearly wrong in the case of Javier. Javier has stated that he's just guessing why his package has been stalled and that he really isn't sure. I don't know about the others. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: buildd.debian.org (was Re: buildd administration
Goswin von Brederlow wrote: >> Well, after looking at http://buildd.debian.org/~jeroen/status/ , >> I concur that it's as good a general interface to buildd status as >> buildd.net, >> and much better than the http://buildd.debian.org/ interface. > >Where did you find that url? In a random mailing list message to debian-devel in one of these threads. Not a great way to find information. :-P -- Nathanael Nerode <[EMAIL PROTECTED]> A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debian-menu vs. .desktop
Thomas Viehmann wrote: >P.S.: Could someone give me a pointer about moving to .desktop and why >it is/was considered a bad idea? (Or if it's just a not worth it/noone >has time issue...) I believe it was considered a good idea by everyone and the consensus was that it should be done in the long run. I believe the first hurdle was that a translation scheme had to be provided to convert the rather rich .desktop format to the window manager formats for all the "legacy" window managers, and to arrange for them to be automatically updated; this is already done for Debian's menu format. This would presumably involve some serious hacking on the menu package. I believe the second hurdle was that it was felt that a translation scheme from Debian's menu format to the .desktop format was needed so that not all Debian packages had to switch to .desktop format at once. I believe nobody has had the time or energy to clear the first hurdle, let alone the second. Someone can tell me if I'm wrong. :-) In addition, the last time this issue was brought up, the .desktop format hadn't actually been standardized and wasn't being used by KDE or Gnome really, so it didn't seem worth it at the time; it seems a lot more worth it now. > It seems burdenful for maintainers to provide both >and they're not always well synced (I noticed that emacs21's .desktop >comment used as hint in the Gnome menu was meaningful whereas the menu >file lacked a longtitle that is used as hint in the Debian menu.) -- Nathanael Nerode <[EMAIL PROTECTED]> This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
c2a transition: libraries still needing transition
The following libraries still need to be uploaded with name changes for the c2a transition (http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html): Most are not in testing at the moment. alps-light1 aqsis gnuift -- old version is in testing ivtools -- orphaned, also hadn't undergone c2 transition properly libsigcx libterralib log4cxx omnievents plptools qgis rlog -- old version is in testing sqlxx xalan -- old version is in testing vtk zipios++ -- old version is in testing The following packages appear to have deliberately skipped the renaming, so check what's up with debian-release before uploading: atlas-cpp openalpp-cvs osgal-cvs osgcal openvrml In addition, the following libraries still need to be uploaded with name changes for the *c2* transition: log4cpp -- new maintainer needs a sponsor, see bug 303794 sp-gxmlcpp -- bug 333885, old version is in testing wfnetobjs -- bug 332832, prevents wflogs from transitioning, old version is in testing This is the complete list. (A few other packages are being removed or are in the NEW queue.) I believe that 0-day NMUs are currently permitted for both transitions. It would be very nice to finish these off. Once all these libraries are transitioned, the remaining C++ programs using the old ABI can be queued for automatic binNMUs by the release team, so these are the only source uploads still needed just for the transition (not including uploads to fix FTBFSes, RC bugs, etc.) -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Clogs on packages going into etch cleared!
Amazing! ghc6 is now the top blocker for packages entering testing, and it's only keeping 15 packages out of testing! Hooray! Now to fix those ~= 400 RC bugs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is mesa actually maintained?
Hello! This is one of 5 RC bugs, apparently with no maintainer response. Apparently the list which is listed as the maintainer is rejecting messages (336752), which probably contributes to the problem. Hence the Cc: to debian-devel. This bug is trivial to fix, and because it prevents mesa from building, it's preventing tulip from being built at all. 341479 prevents tulip from being built too. I only noticed this because I'm trying to get the C++ allocator transition finished, which tulip is involved in. So, um, any chance of any progress? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-torrent (WAS: Re: apt PARALLELISM)
> It'll take me some time to find a new, and more appropriate home for
> apt-torrent.
The Debian archive ("experimental" distribution) would be a *very*
appropriate home.
It won't provide a testbed package seeder or place to download .torrent files,
but that can be done later (and by any number of different people, actually).
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Derived distributions and the Maintainer: field
In response to your request for replies to http://lists.debian.org/debian-devel/2005/05/msg00260.html: >1. Most of the source packages in Ubuntu are inherited from Debian > unchanged (example: tetex-base). Then the *source* packages can legitimately use the same Maintainer: field. If they are also compiled with a toolchain unchanged from Debian, the binaries can legitimately have the same Maintainer: field as in Debian, because they are essentially the same package. If not, the binary packages should have different Maintainer: fields, unless the maintainer agrees to have his name on it. For instance, debugging bugs in your package generated by a toolchain you don't have is obnoxious, frustrating, and a waste of time; Ubuntu should be sorting out whether such problems are present in Debian before sending them to the Debian maintainer. Given Ubuntu's practice, this means all the binary packages should have automatic Maintainer: changes. > 2. Some source packages in Ubuntu are modified relative to Debian. These >are assigned a version number of the form >"ubuntu". Of those which >are modified, in most cases the modifications are trivial, such as a >library transition, Python transition or other dependency change >(example: python-adns, > http://people.ubuntu.com/~scott/patches/python-adns/python-adns_1.0.0-6ubuntu3.patch). >In some cases, the packages are modified more extensively (example: >several d-i components, such as partman > http://people.ubuntu.com/~scott/patches/partman-auto/partman-auto_41ubuntu1.patch). These should not have the same Maintainer: field as in Debian (unless the Ubuntu maintainer is in fact the same, of course). "Trivial" dependency changes have much the same effect as toolchain changes in that the Debian maintainer may have good reasons to not want to hear about that version of the package. They should also have their Origin: changed. > If a binary package is built by a third party from unmodified Debian > sources, should its Maintainer field be kept the same as the source > package, or set to the name and address of the third party? Third party. Exception: if it's built with an unmodified Debian toolchain and dependencies. Exception: Maintainer gives explicit permission. > Should Debian-derived distributions change the Maintainer field in source > packages which are modified relative to Debian? If so, should this be > done in all cases, or only if the modifications are non-trivial? Yes, and in all cases; the definition of "trivial" varies with the observer. (Well, if the only change is to rename the .deb file, I guess everyone would agree that that was trivial enough.) Exception: Maintainer gives explicit permission. This doesn't seem like rocket science to me; it's just a matter of accurate attribution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
binNMU version detection
Steve Langasek wrote:
> > Which would be totally pointless until dpkg itself is fixed to give
> > packagers an alternative to ${Source-Version}.
>
Thomas Bushnell BSG wrote:
> I thought we had a fix-strategy in place for addressing these cases.
> I'm sorry if we don't; then of course this strategy doesn't work. :(
I *wrote* one, but then they went and changed the binNMU version numbering.
This *cannot* be done without a consistent numbering scheme for binNMUs which
we can rely on. Given that the numbering scheme was changed silently at a
random time for no apparent reason, I don't know if I can rely on this
numbering scheme being retained.
It appears that nothing prohibits a "b" suffix in a regular source NMU, or
indeed in a regular maintainer upload, for native packages or non-native
packages, so I believe binNMUs can be automatically detected any more.
There's also no documentation of this numbering scheme: does it differ when
applied to a {native, non-native} package? A {maintainer upload, NMU}?
So actually I can't write a fix, period.
Furthermore (sigh) the developer's reference still advises the old numbering
scheme for binNMUs, so we can expect to see it for manual binNMUs for a good
while yet. So any routine will have to handle *both*.
So the silent and unmotivated changes made to binNMU version numbering have
*prevented* this from being fixed. Good example of how not to do things.
I await advice on how to fix this problem now that we are stuck with this
random, unmotivated, undocumented, likely-to-break-things change. Oh, and
I'd like the head of whoever changed it while I'm at it. :-)
--Nathanael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
Eric Dorland <[EMAIL PROTECTED]> wrote: >This has probably been covered ad nauseum, but where do we stand in >respect to getting mplayer in Debian? IIRC, the copyright issues were carefully worked out and solved after several years, finally reaching the approval of debian-legal. At which point it went into the NEW queue, to be silently ignored forever by the ftpmasters with no explanation. You know where to bitch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apology for MIA, Retiring, RFA: x-symbol, xmix, oneko
>I'd like to offer these three packages for adoption: x-symbol, xmix, and oneko. I'll take oneko if Joey Hess doesn't want it. (But frankly he'll probably do a better job at maintaining it than me.) (On third thought, I'd be happy to be a co-maintainer for it.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNMU version detection
[EMAIL PROTECTED] wrote: > How did bin-NMU numbers work for the old numbering scheme on native > packages? In a Complicated Way. Essentially, the debian revision and NMU revision were filled in with 0s (which were, accordingly, not supposed to be used in normal version numbers). >What prohibited -3.0.1 numbers from occurring in such uploads before? It >was just a matter of convention (codified in documentation), no? Yes. And that's my only real objection here: we've switched to something undocumented. I think for various reasons the distinction between binary-only upload version numbers and source upload version numbers ought to be codified in policy, not just in the developer's reference, but that's another matter. > > Furthermore (sigh) the developer's reference still advises the old numbering > > scheme for binNMUs, so we can expect to see it for manual binNMUs for a good > > while yet. So any routine will have to handle *both*. > > Let's patch that and solve that problem. (I'll try to do that within the > next couple days, although I should probably be overruled by someone who > knows a little bit more about it than I do.) If policy is patched to describe the new binNMU version number format and to tell people not to use that format for sourceful uploads; and the developer's reference is patched to match; that would satisfy, oh, *all* my complaints. :-) Later, Steve Langasek wrote: > The primary aim of this change was to address the fact that there was no > consistent numbering scheme that satisfies the constraint > binNMU < security NMU < source NMU. The problems with this were due to security NMUs, weren't they? The old binNMU numbering scheme makes them consistently and reliably less than the source NMU numbering. So the binNMU numbering was changed so as to make it possible for the security team to name their uploads while guaranteeing that they would sort above binNMUs and below regular NMUs? Despite this, the current security team upload naming *doesn't work*. I've seen "5.8.4-8sarge3" in a recent upload of perl: $dpkg --compare-versions 5.8.4-8sarge3 gt 5.8.4-8+b1 || echo false false So this sorts below the binNMU. And I've seen "1.3.5-4.sarge.2" in a recent koffice upload: $dpkg --compare-versions 1.3.5-4.sarge.2 lt 1.3.5-4.1 || echo false false And this sorts above the source NMU. So this change has not yet addressed this problem. > And contrary to Nathanael's > protestations, this was discussed publically on debian-devel -- a year ago > -- and this solution arrived at with the input of an ftpmaster and the > then-current dpkg maintainer, among others. Ah. I must have missed that discussion. Pointer? I would appreciate knowing what was decided on for security uploads, since it's obviously not being used. Or did you decide to change the version numbering for regular NMUs instead? If so, that's certainly not being used. > It just didn't get implemented > until after wanna-build & co. gained support for binNMUs, making them > commonplace: The binNMU version changes could have been implemented long before that by changing the documentation and announcing to people that the new format should be used. They weren't. As a matter of fact, this clearly should have been done before implementing it in wanna-build. It wasn't. And the security upload version changes -- the original motivation for the whole thing -- clearly haven't been implemented at all. Even though this requires only one thing: getting the security team to agree to do it. It would work, except for native packages, if the security team switched to using "+sarge?" suffixes. (Well, as long as Debian never picked a code name starting with "a".) For native packages, it would work as long as binNMUs and security uploads always added a "0" debian revision number before the +b? or +sarge? suffix. Worse, the security team could have made this change well before the binNMU changes, because it's better than the existing (and common) "5.8.4-8sarge3" naming. But they didn't. So, this still seems to me like a really half-assed way to have done things. Are there plans to straighten this out? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
aj@azure.humbug.org.au: > MJ Ray's already done such a summary; it's rather trivially inadequate, > due to the information its summarising being equally inadequate. > > http://lists.debian.org/debian-devel/2005/12/msg00901.html So the summary amounts to "patents". Is that right? In other words, the previous (substantial) copyright issues *are* considered to be cleared up. Having it REJECTed with a "needs to have algorithms covered by actively enforced patents identified and removed" would be really helpful. Having a list of specific areas which are considered too dangerous (ffmpeg code, for instance) would be even better. > Coming to a decision on inadequate information isn't particularly clever. "Clever" isn't the issue. I couldn't care less how "clever" the ftpmasters are. Too clever by half, perhaps, with the "leave difficult packages in limbo" policy. Coming to a decision on inadequate information is actually very helpful, when it's done in the form of "This is the information we need before we can consider this package". I haven't seen that. Contrast rte, where the ftpmasters told Marillat exactly what he needed to remove to get the package in Debian, and he didn't do it, and declared that he would keep uploading it. Leaving *that* in limbo is totally reasonable. > Seriously, if you want something useful to happen about this, *thoroughly* > investigate what's actually going on, with an open mind about the > possibility of coming to the conclusion that, eg, it's just too much of > a risk to include mplayer in Debian. Hey, sure. Why is it too much of a risk? Can we get some background here? Originally it was too much of a risk because upstream was really bad about copyrights -- this was a FAQ. Like I said, some people spent literally years straightening that out. Hence the "what the hell is wrong now?" attitude. If it really is FFMPEG patent issues -- and I have no idea whether it is -- then I believe the packagers would be happy to just remove that code, because what some might call a "crippled" mplayer is still better than no mplayer. Incidentally, the current attitude of "we won't include new packages with FFMPEG, but we will include FFMPEG" is legally stupid. It doesn't get you anything if you do get sued; if anything, it helps prove that you knew you had a problem, and so were wilfully infringing. If this is really the issue, we should kick out the existing FFMPEG packages (and I'm happy to file the serious bugs, if that will get things started). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
Apologies to AJ and the ftpmasters. I found the *important* part of the thread, which I'd apparently missed during December, in which the ftpmasters... drumroll explain what would be needed for mplayer to go into Debian now, barring finding additional problems. Congrats Jeroen van Wolfellaar, ftpmaster extraordinare, not afraid to take on the difficult cases (he also managed the REJECT on rte IRRC). From http://lists.debian.org/debian-devel/2005/12/msg00888.html: (Jeroen) >Basicly: Drop mpeg encoding from mplayer source package -> definitely >less problems getting through NEW. ... > I suggest you upload stripping all the mpeg encoding stuff, pending > answer to that difficult question. However, what you do, is your choice > -- if you prefer to wait and are not planning to strip mpeg encoding > support out of the source package, that's not something the ftp-master > team will have any say on. ... > I'm not aware of any fundamental reason why mplayer couldn't be in > Debian. ... > However, removing > encoding stuff would bypass the main problem that we have with mplayer > right now, and then the answer to this question can then be researched > in parallel to an mplayer-with-only-mpeg-decoding being available from > Debian. ... (A Menucc) > > 3) what other problems should we fix ? > > (please read http://people.debian.org/~mjr/legal/mplayer.html > > to know what has been already fixed ) (Jeroen) > I don't know of any at this moment, but I also cannot promise there > won't be any more problems that need fixing found between now and the > package being checked in the NEW queue. And to reiterate: If Debian wants to be legally safe w.r.t. mpeg encoder patents, removing some mpeg encoders and not others -- when the others have been pointed out -- is really a bad idea. They should all be removed until the issue is settled one way or another. I see no way that leaving some in while excluding others for patent reasons is going to help Debian; if anything it can only make Debian's legal situation worse, because it can be used as evidence that Debian knew about the problems but left the patent-covered code in Debian. Which gets you the extra penalties for "wilful" infringement. Is there an objection, or shall I file a serious bug against ffmpeg?
Re: new mplayer 1.0pre7try2 package
I wrote: >> Contrast rte, where the ftpmasters told Marillat exactly what he needed to >> remove to get the package in Debian, and he didn't do it, and declared that >> he would keep uploading it. Leaving *that* in limbo is totally reasonable. Christian Marillat wrote: >I've *never* received any e-mail saying that. Perhaps I have misinterpreted the following message from the bug trail to bug 112699: >From: Joerg Jaspert <[EMAIL PROTECTED]> >To: Christian Marillat <[EMAIL PROTECTED]> >Cc: Joerg Jaspert <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >Subject: Re: rte_0.4-0.0_i386.changes REJECTED >Date: Sat, 19 Mar 2005 14:32:55 +0100 > >On 10233 March 1977, Christian Marillat wrote: > >>> Yes, this is the reject of the rte package which was in NEW until now. >>> Reasons: >>> - It is an encoding thing, which encodes to formats which are patented, and >>> the patent holder are actually enforcing their patents. Found some >>> hits for this with a little question to google. >> Are you serious ? We have ffmpeg (and soon mencoder in the mplayer >> package)in Debian who does exactly what rte does and rte can't enter >> Debian ? ffmpeg should be removed then. > >Yes, ffmpeg encoding stuff shouldnt be there, and no, mplayer wont get >in with mencoder included. I already talked with upstream about it, he >will talk with Debian maintainer to exclude this thing, before we take a >closer look at it. >>> If this reasons are no longer true in the future feel free to >>> re-upload it, but for now it is out. >> Done. I've uploaded 0.5.6-1 > >As written above: ENCODING is still an issue and therefore at least one >reason is still true. So dont hope too much it will get through. > >-- >bye Joerg >Die d??mmsten H??hne haben die dicksten Eier. I read this as "remove MPEG encoding and it will go in." Don't you? -- Nathanael Nerode <[EMAIL PROTECTED]> Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new mplayer 1.0pre7try2 package
aj@azure.humbug.org.au wrote: >mplayer has had an explicit warning from upstream that it's patented; The proposed tarball for Debian has stuff excised left and right in order to guarantee legality. Just check that the patented stuff was excised, right? Alternatively, I would be quite happy with the response "We just can't trust mplayer's upstream enough to include mplayer; we suspect them of having done something underhanded and including illegal code we haven't spotted." >ffmpeg >has an explicit document in its packaging indiciating it's okay. A, the "I stripped the patented parts" comment in README.Debian. All right. Sorry! So, we have a solid summary, which could be a FAQ answer: mplayer should go in if it links to the ffmpeg library in Debian, and its own copies of any mp3 and AAC encoding stuff are removed. Right? Likewise xvidcap, I presume? And rte, as was already stated? (And sorry for not giving credit to Joerg there!) -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Derived distributions and the Maintainer: field
Henning Makholm <[EMAIL PROTECTED]> wrote: >You seem to require a standard of attribution in the Maintainer field >that Debian does not itself follow in our default procedures. To wit: >NMUs _within_ Debian keep the Maintainer field unchanged Good point. If Ubuntu wishes to keep the Maintainer field the same, but use NMU version numbers and add a "Changed-By:" field which is different, that seems perfectly reasonable as well. -- Nathanael Nerode <[EMAIL PROTECTED]> Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Russ Allbery wrote: > (Or is > imake going away completely?) Yep. Imake is still being shipped for the benefit of third-party packages, but it is not used by anything in Xorg 7.0 IIRC. Doing a quick check, I think very few if any other packages in Debian use imake. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Pre-Depends for Xorg 7.0
Russ Allbery wrote: > Here's a list of packages that install binaries into /usr/X11R6/bin and > don't have lintian overrides for it. In spot checks, about a quarter of > these packages use imake. And that's just the packages with binaries; > there are a number of other packages that don't install binaries but that > still use imake (I happen to maintain one of them, a font package). Well, let's see what the scope of imake in the /usr/X11R6/bin issue specifically is. (The fonts issue seems to be more of an issue.) Actually, it seems that there are an even larger percentage than you thought. So I was very wrong. Sigh. Imake is considered dead-except-for-routine-maintenance upstream as far as I can tell, so best practice would be to migrate away from it. Unless someone plans to adopt it. Doing some sorting of this list, I find that these originate from Xorg, so will no longer use Imake: > lbxproxy > proxymngr > twm > xbase-clients > xdm > xdmx > xfs > xfwp > xnest > xserver-common > xserver-xorg > xutils > xvfb These don't build-depend on xutils (so either they don't use imake or they have a serious missing Build-Depends bug): > buici-clock > emelfm > fte-xwindow > fvwm95 (fvwm95 is desperately obsolete software which should really be removed anyway.) > gerstensaft > gipsc > gradio > hamsoft > ibp > lm-batmon > lsb-core > pgaccess Orphaned, QA. > ppxp > ppxp-x11 > qcam > tkdesk > twlog > videogen > wmcpu > wmscope > xclips > xdkcal > xgdipc > xlockmore > xlockmore-gl > xvkbd > yank This leaves a list of possible Imake users. I went through these by hand, and most of them did use Imake. Probable non-imake users: > hanterm-classic > hanterm-xf (These two appear to have both Imake and configure/Make build systems, but the latter is used.) Definite imake users: > bugsx > ctwm -- should be straightforward to convert, by copying configury from twm, of which it is a fork > isdnutils-xtools > ivtools-bin > ivtools-dev ivtools: severely out of date and busted packages, with a particularly insane configuration and build system. > kdrill > kinput2-canna (source kinput2) > kinput2-canna-wnn (source kinput2) > kinput2-wnn (source kinput2) > kterm -- should be trivial to convert, by copying configury from xterm, of which it is a fork > lwm > olvwm (source xview) > olwm (source xview) > mctools-lite > mgp > oneko -- very simple Imakefile, should be an easy conversion > pixmap > plotmtv > seyon > skkinput > vtwm > wmavgload > wmdate > wmnet > xautolock > xbatt > xbattbar > xcal > xcalendar-i18n > xcb > xclip > xdu > xengine > xfaces -- has an alternate "noimake" Makefile > xfishtank > xfm > xinput > xipmsg > xlbiff > xli > xmeter > xmix > xmon > xpostit > xrn > xsysinfo -- orphaned, QA. > xtel > xtoolwait > xtrlock -- has a 'noimake' Makefile > xview-clients (source xview) > xviewg (source xview) > xviewg-dev (source xview) > xxkb > xzoom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: returning emeritus developer, no response from [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote: > I send an email to [EMAIL PROTECTED] over a week > ago, as described here: > > http://lists.debian.org/debian-devel-announce/2005/02/msg3.html > > so far not even a response telling me I'm in a queue. > Is the procedure described above still the right one? DAM is very slow-moving these days. Probably they haven't looked at your mail yet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: returning emeritus developer, no response from [EMAIL PROTECTED]
> > so far not even a response telling me I'm in a queue. > > Is the procedure described above still the right one? > > DAM is very slow-moving these days. Probably they haven't looked at your mail > yet. Um, just in case anyone was wondering, that wasn't intended as a criticism of DAM -- I think it's slowmoving mostly due to having a heavy workload on two people who already do a lot of other work -- but I just realized that it might have come off as a criticism. I was just trying to inform the emeritus developer that DAM was probably a lot slower now than it was back when he (or she) was an active developer, when DAM probably had a lighter workload. And I liked the clarivoyant joke, but as far as I can tell, I'm not, so no need to fast-track me on that account. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
BTS LDAP interface (or something) broken?
bts.turmzimmer.net just went nuts: >Changes at Thu Feb 2 0:10:06 CET 2006: (all but six RC bugs are supposedly "solved" simultaneously) Obviously something broke. Perhaps the ldap interface to the BTS, since packages.qa.debian.org is giving bogus results too. -- Nathanael Nerode <[EMAIL PROTECTED]> This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: move /etc/{protocol,services,rpc} to base-files
[EMAIL PROTECTED] wrote: > Currently there are several packages which Build-Depend on netbase just to > have /etc/protocol and /etc/services available to run tests. Unfortunately, > this means that all of netbase's dependencies also need to be installed -- > and because of bug #162581, pbuilder can't even block inetd from starting in > its chroot, resulting in orphan inetd processes after the build is over. > > So I'd like to propose moving those data files from netbase to base-files. If > it's decided that these files are inappropriate content for an essential > package, I'd at least like to see something like netbase-data which could be > installed without all the heavy dependencies of netbase. I'd especially like > to hear the opinions of the netbase and base-files packages' maintainers on > this. This seems like a very good idea. If there are really packages which are Build-Depending just to get those little database lists, they shouldn't need to Build-Depend on netbase. Actually, those lists have the interesting property of being semi-volatile data which changes (/should change) more often than the rest of netbase. I think this argues for putting them in a separate netbase-data package. In fact, this would solve in a certain sense the long argument about how many protocols/services to include in the lists: alternate packages could Provides: netbase-data if they included any superset of the most basic list. -- Nathanael Nerode <[EMAIL PROTECTED]> "(Instead, we front-load the flamewars and grudges in the interest of efficiency.)" --Steve Lanagasek, http://lists.debian.org/debian-devel/2005/09/msg01056.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
[EMAIL PROTECTED] wrote: > Well, maybe the people who mislabeled the "everything is software" vote > as an "editorial change" and deceived many other developers should have > tought about this. This is an old canard. It *was* an editorial change: we'd already worked out that it *made no difference*. "Debian will remain 100% free software". There are only two choices of how to interpret this. Maybe you still haven't figured that out, perhaps because you're not a native English speaker, so I'll reiterate. (Option 1) Every collection of bits is software. This is what the editorial changes went with. (Option 2) Some things (like documentation) aren't software. In that case, since "Debian will remain 100% free software", Debian mustn't contain any documentation at all period. Is that seriously the position you were advocating? No, it wasn't. Nobody was advocating that position. I strongly suggested, at the time, an GR to change the Social Contract to say something like "The computer programs in Debian will remain 100% free software," which is what you apparently *wanted* it to say. None of you people decrying the "editorial changes" had the honesty or integrity to actually propose such a GR. Damn it, get off your butt and DO it. Propose such a GR and you'll get the respect you don't currently deserve. I'd propose it myself if I were a DD, just to get a clear vote on the actual issue on the record. Incidentally, if I ever become a DD, I *will* immediately propose a GR to amend the Social Contract to explicitly allow unmodifiable license texts in Debian, since it technically doesn't, but everyone agrees that it should. I'd welcome someone else beating me to it. -- Nathanael Nerode <[EMAIL PROTECTED]> A thousand reasons. http://www.thousandreasons.org/ Lies, theft, war, kidnapping, torture, rape, murder... Get me out of this fascist nightmare! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
> On Feb 09, Simon Richter <[EMAIL PROTECTED]> wrote: > > > The binutils package generates part of its documentation from header > > files in order to get the structures and constants right. The headers > > are GPLed, the compiled documentation is under the GFDL. For this > > relicensing to happen, one must be the copyright holder, or have an > > appropriate license, which after a quick glance does not seem to be > > there. Thus, only the FSF may build the binutils package. I'd be very > > surprised if that were to meet your definition of free software. [EMAIL PROTECTED] wrote: > Did you ask FSF what they think about this situation? I raised this issue with the FSF *wy* back when (1998? 2000?), in regards to the libstdc++ header documentation (which is doxygenated). If I remember correctly, they said that *yes*, this was a problem, though not a major one, and that they would introduce a special license exception dual-licensing the Doxygen comments. To date, this has not been done, and it is still technically illegal to generate that portion of the libstdc++ manual unless you're the FSF. Blech. -- Nathanael Nerode <[EMAIL PROTECTED]> Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment to GR on GFDL, and the changes to the Social Contract
[EMAIL PROTECTED] wrote: > Maybe we could suggest another "editorial change" and revert to the > previous wording (not everything is software) > > Uh ? Wouldn't help, as I noted elsewhere. "Debian is 100% free software" doesn't actually leave any room for non-software in Debian. The previous "interpretation" was something which it simply can't mean in English. What you want is a GR which changes it to what you want it to say, such as "The computer programs in Debian will remain 100% free software". PLEASE PLEASE PLEASE PLEASE PLEASE propose such a GR. Then we'd get a real count of how many people believe that the DFSG should apply only to programs and how many think they should apply to everything in Debian. We haven't had such a count yet because the "DFSG should apply only to programs" people have not been willing or able to actually propose a GR which says what they *mean*. -- Nathanael Nerode <[EMAIL PROTECTED]> Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Honesty in Debian (was Re: Amendment to GR on GFDL, and the changes to the Social Contract
This belongs somewhere else. Directing followups to -project. Glenn Maynard wrote: > On Fri, Feb 10, 2006 at 02:31:43AM -0500, Nathanael Nerode wrote: > > Incidentally, if I ever become a DD, I will immediately propose a GR to > > amend the Social Contract to explicitly allow unmodifiable license texts in > > Debian, since it technically doesn't, but everyone agrees that it should. > > I'd welcome someone else beating me to it. > > Then people will start saying things like "the GFDL is free, if the invariant > sections happen to be license texts!" Not if we do it my way: see below. > [1] As an extra-aside, see > http://lists.debian.org/debian-devel/2004/04/msg02344.html for an observation > about the difference between "license texts" and "license terms", > and how one really could apply the DFSG to texts, but not terms, > and end up with something > reasonable. Not really a worthy fight, of course, but if you want to > formalize an exception, then I think knowing the difference is important. Trust me, I know the difference; I'm one of the people who originally described the difference and explained how it mattered to the people drafting the Apache license version 2. The problem is quite specifically that we have unmodifiable license texts, not unmodifiable license terms. These texts are in Debian, making it technically untrue that "Debian will remain 100% free." This is approximately how I would write an exception: "Debian will remain 100% free. (With one exception for license texts, noted below.) " "Works in Debian are usually made available under specific licenses. For convenience, we include these (and only these) licenses directly in the Debian system, and we do not require that the texts of these licenses be Free. However, we promise that all such non-free legal texts will be placed in a few specific, well-documented locations, and nowhere else in the Debian system." This could probably be improved, but it gets the point across very clearly. - The reason I would do this is the same reason I often get so vocal and sometimes angry about these matters: the issue of honesty. I feel that the current situation is one in which Debian is using its Social Contract to lie to its users, and that that has been going on for a long time. The Social Contract used to say "Debian will remain 100% free software." Someone recently said that he thought a valid intepretation of this was "The sotware in Debian will remain 100% free." Well, that is *not* a valid interpretation of the English language sentence "Debian will remain 100% free software". Users expecting Debian to adhere to its Social Contract would be sorely disappointed by that misinterpretation, as I was. To clarify why this is not a valid interpretation: Suppose a public transport agency said "Our transportation fleet will remain 100% eco-friendly trolleybuses." Then suppose they bought a whole lot of diesel buses, and claimed that their promise simply meant "The trolleybuses in our transportation fleet will remain 100% eco-friendly." That's not a valid interpretation, and you'd be right to feel cheated. Suppose I told my homeowner's association, "My front yard will remain 100% green grass." Suppose I then planted half the front yard in myrtle (not a type of grass, FYI). Then suppose I claimed that my promise meant "100% of the grass in my front yard will remain green." That's not a valid interpretation. The homeowner's association would rightly complain that I had lied to them. Suppose I said "These thirty acres will remain 100% organic farmland." Suppose I then built condos on half of them, and said "Well, what my promise meant was that the farmland in those thirty acres would remain 100% organic." You'd call me a liar, and you'd be right. The "Social Contract" is supposed to be a promise to the users of Debian. Now, it is only a promise that Debian will make its best effort to satisfy its side of the contract; it obviously is not a warranty, and doesn't cover accidents or stuff nobody noticed. But if it is to mean anything, it must mean that Debian will make its best effort to give the users what it promised. There is an honest way to allow non-modifiable essays and other works which do not satisfy the DFSG into Debian main. That is to amend the Social Contract to say what you want it to say: "The programs in Debian will remain 100% free." Nobody has tried to do that yet. If that was done, I would *happily* go along with it. I might not personally think it was the best choice for Debian, but I wouldn't really care that much, because it would mean Debian was being honest about what it did. So propose the GR just to
Improving keyring maintenance (was Re: question for all candidates)
If you don't want to read the rant, skip to the bottom where I volunteer to help Anthony Towns wrote: >In the mail to the DPL I mentioned above, James outlined three fairly >significant technical changes that could be implemented to make the >job easier, and could be done by anyone, without requiring any special >priveleges; Why on EARTH didn't he outline these needed changes to *debian-devel*, or put them on the Debian wiki, or in some other way let *everyone* know what needed to be done? Nobody's going to volunteer to do them if nobody knows *what they are*. On the other hand, if he publicized what he needed, I promise he'd get volunteers writing code almost immediately. *This* is what's wrong with James's communication skills. Apparently it's also a problem with the *DPL*, who could equally well have publicized the same needed changes. --- Anyway, thank you for finally describing the issues (in http://lists.debian.org/debian-vote/2006/03/msg00275.html). If I could be pointed to the existing scripts for managing debian-keyring.gpg, I can start work on making them componentised, simple, obviously correct and secure, and fast. That sort of work is what I'm especially good at. I could start an alioth project for "keyring-manangement-scripts" if anyone else is interested in working on this. Hmm, this is going off topic for -vote Replies to -devel please. -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
NEW queue backing up again -- ftpmasters, any explanation or comment?
xvidcap -- 1 year. If the ffmpeg source code is removed from the source package, could this go in? FTPmasters? mozilla-firefox-adblock -- 5 months. Why is this not going in? cvsconnect, cvssuck -- 4 months. Why are these not going in or being rejected? mozilla-thunderbird-locale-cs -- 3 months. Why hasn't this gone in or been rejected? 2 months: firefox-locale-uk kde-style-comix pike7.7 zeroc-ice (et al) 1 month: 10 packages 3 weeks: 34 packages 2 weeks: lots and lots of packages It looks approximately as though nothing has been examined since a month ago. Although that doesn't explain the packages listed up top. -- 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: GFDL question
Norbert Preining wrote: > Dear all! > > Now that the GFDL resolution has been done, I have the following > question: > > Most (some) documents of the FSF have the following license for the > docs: > Permission is granted to copy, distribute and/or modify this document > under the terms of the GNU Free Documentation License, Version 1.1 or > any later version published by the Free Software Foundation; with no > Invariant Sections, with the Front-Cover texts being ``A GNU > Manual'', and with the Back-Cover Texts as in (a) below. A copy of the > license is included in the section entitled ``GNU Free Documentation > License'' in the Emacs manual. > > (a) The FSF's Back-Cover Text is: ``You have freedom to copy and modify > this GNU Manual, like GNU software. Copies published by the Free > Software Foundation raise funds for GNU development.'' > > Ok, there are no invariant sections, but there is (a short) front and > back cover text. > > How do we proceed with these documents? They're non-free, per the GR. Cover Texts are unmodifiable material. -- 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: Regarding the NEW queue (Was: Re: NEW queue backing up again -- ftpmasters, any explanation or comment?)
Lars Wirzenius wrote: > ma, 2006-03-13 kello 14:59 +0100, Jeroen van Wolffelaar kirjoitti: >> On Mon, Mar 13, 2006 at 12:20:38PM +0200, Lars Wirzenius wrote: >> > Is there a reason why the question should be made in private? >> >> It seems as if only problems and annoyances end up on mailinglists, and >> *not* to [EMAIL PROTECTED] The don't specifically need to be made private, >> but >> I don't think it'd be too much to ask for questions to ftpmaster to be >> mailed to the our published contact address? > > Certainly the question should be mailed to ftpmaster@ as well. I just > don't see why it should be mailed there only, when it is an issue that > affects the entire project. If there is a Cc to -devel, then ftpmaster > can, with one reply, efficiently inform the entire project. For some reason my little brain didn't think of this. Mailing ftpmaster with a Cc: to debian-devel was the obviously correct thing to do, and I apologize for not doing it in the first place. For some reason my brain didn't come up with that as a possibility. :-/ -- 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: /usr/lib vs /usr/libexec
> Goswin von Brederlow <[EMAIL PROTECTED]> writes: > > > Which doesn't? Minix maybe. Even ext2/3 has hashes for dir if you > > format it that way. Thomas Bushnell BSG wrote: > > Is this the Debian default for installation? Yes, it is. I just checked and every install I've done turned this on without my knowledge. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More about GFDL
Cesar Martinez Izquierdo wrote: > El Viernes 22 Abril 2005 14:37, Maciej Dems escribió: >> I have a simple question concerning the GFDL discussion. >> >> Does the GFDL documentation which currently does not contain any >> invariant section have to go to non-free as well? Yes, until the GFDL is revised, mainly due to the so-called "anti-DRM clause". First of all, to avoid Invariant-Section-like problems, the document also must include no cover texts. Acknowledgements and Dedications appear to suffer similar problems (though it's unclear). (One of the things which makes these worse than similar requirements in other licenses is that these apparently must be included *in* rather than *alongside* the document, and presumably in the table of contents as well. The title preservation requirements are also troublesome.) But without all of these? Still not free. The "anti-DRM clause", as written, makes the GFDL documentation non-free. (We believe that this is a mistake and hope that it will be fixed in the next version.) In addition, the "transparent and opaque forms" section is of uncertain freeness, and we haven't got a clarification. It's unclear, but the license may also prohibit pseudonymous authorship, which would be non-free, and we haven't got a clarification. -- This space intentionally left blank.
Re: Package priorities: optional vs extra
Peter Samuelson wrote: >In practice, 'extra' is mainly used when Policy forces you to use it: >that is, if your package conflicts with another package which has >priority optional or higher The really sad part is that *this* isn't enforced; there are lots of "optional" packages which conflict with each other. >Probably the best solution is to change Policy to say that 'optional' >and 'extra' mean exactly the same thing, and remove the requirement >that all 'optional' packages be able to coexist. Unless someone is willing to actually enforce the requirement that all optional packages can coexist, this will be necessary to make Policy conform with reality. Personally, I rather like the idea that all optional packages can coexist, but it isn't anywhere near true right now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-uk] Sun have (probably) patented apt-get
On 4 Jul 2005, at 11:44 am, Wookey wrote: > Take a look at this patent (granted this week in europe) > > http://gauss.ffii.org/PatentView/EP1170667 > > I'm fairly sure that apt-get and associated package-integratity > checking tools could be considered infringing. (Does dpkg/apt have > a modular structure?) Clearly not patentable; there's surely gobs of prior art before the filing year of 2000. This attempts to patent a generic package testing framework! It looks to me like dejagnu would "infringe" some of these claims, if they were valid, which they aren't. The only claims which might be even slightly tricky to find prior art for are the claims about assigning a "priority" to each test. It's currently in a nine-month opposition period. Anyone want to do the work to find and send in the opposition material? Gee, patent quality is at an all-time low. :-( -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: should etch be Debian 4.0 ?
I suggested "Debian IV", to *really* get rid of minor version numbers, permanently. Initial release would be Debian IV r0. Point releases would be Debian IV r1, etc. Next release, Debian V, etc. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Recursive Dependency Disease reminder and freetype status
I just finished updating the page http://wiki.debian.org/FreetypeTransition . If your package is listed there, it has a bug: either a missing build-dependency, or recursive dependency disease. We've made a lot of progress, but there are still nearly 200 packages with unneeded and damaging dependencies on libfreetype6. Not to mention the packages with inappropriate recursive dependencies on other packages! libaudio2 is another common excess dependency. For a reminder about recursive dependency disease, see http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html. In the interests of making Debian's dependencies less fragile, I'm bringing this topic up again, since I figure everyone's forgotten about it. If you haven't checked your packages for bogus dependencies, please do so. (Most of the time, a dependency on libfoo without a build-dependency on libfoo-dev indicates either recursive dependency disease or a missing build-dependency. There are rare exceptions; but if you've got *lots* of dependencies like this, you *definitely* have recursive dependency disease.) If you maintain a library which offers a .pc file for pkg-config (or offers a similar tool), please fix it. I will file occasional bugs as I spot them, but given the sheer number of cases, I thought a reminder to all Debian Developers was a better move. If you have difficulty fixing this for your package, I believe several people including me are happy to help. -- Nathanael Nerode <[EMAIL PROTECTED]> Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Stuff the installer does which isn't done on upgrade....
So upgraded systems don't get the benefits of certain changes to the installer's defaults, or defaults in programs used by the installer. I first thought of this when I noticed the change in the default tuning for ext2 partitions created by mke2fs. Notably, dir_index and filetype are turned on by default now; this was not always the case. You used to need to put /proc and /sys in your fstab, but it's unneeded and silly now. There are probably other changes like this floating around. For instance, if we switch to mounting a tmpfs over /tmp in the installer, that will probably end up being another one. Some of these can have substantial impact -- particularly dir_index, which has never been mentioned in release notes. I think they're all appropriate topics for release notes: "things to do after rebooting" is probably the correct category. Perhaps people could comment on other things like this which they've noticed and we could get them into the next release notes, including anything which wasn't covered on previous major upgrades? -- Nathanael Nerode <[EMAIL PROTECTED]> [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
cdrtools alternatives (was Re: cdrtools)
Eduard Bloch wrote: > Then let's see what a user of your software would do, in a > not-so-uncommon use case: > > User A wants to burn a CD-ROM. She gets cdrtools, In reality, as "user A", I switched to using cdrdao for making serious audio CDs and CD-RWs, and for burning disks from .iso files: this uses Schilling's scsilib, but not the rest of cdrecord. (Actually, it can be configured not to use scsilib. So if there are concerns about the licensing of scsilib, it looks like this can be done any time. cdrdao-1.2.1/dao/ScsiIf-linux.cc could use some updating and improvement of course, since the sg driver has changed since version 2.2.6) For DVD burning, of course, I use dvd+rw-tools. This is completely independent of cdrtools. And data CD-RWs are handled out of the box with packet writing as block devices by the kernel as of kernel 2.6.10 (the so-called "pktcdvd" module), also independent of cdrtools. So what does that mean? That means that cdrtools is needed only for TAO writing of CD-R and CD-RW media. The only usage cases for this which are not better served by a different tool are: * incremental additions for data CD-Rs * incremental additions to audio CD-Rs * incremental changes for audio CD-RWs While it would be nice to have a tool in Debian to do those three things for those who want to, it is really not essential. I have stopped using it entirely: for incremental work, I use DVD+RW or DVD+R media, and for archival work I make CDs in DAO mode with cdrdao. -- 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: autotools and programming style (was: Remove cdrtools)
Hendrik Sattler wrote: > You mean the difference between manpages-posix-dev (in non-free) and > manpages-dev (in main)? The first is not proposed by Debian (I still don't > get why anone would want to change a standards document as not changing it > is the whole purpose of its existence.) In order to make a new standard based on the previous standard. Duh. Very common use case. The problem is not permission to "change a standards document" but permission to "make a modified derivative of a standards document". I don't understand why people have such trouble understanding this. -- 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: Remove cdrtools
Steve Greenland wrote: > On 14-Aug-06, 15:59 (CDT), Michael Poole <[EMAIL PROTECTED]> wrote: >> Wouter Verhelst writes: >> > In the case of autotools, the fact is that usually it's configure.ac or >> > Makefile.am being horribly broken, rather than the autotools. Oh yeah. Most people don't know how to write Makefiles, of course, which is a bigger problem. Automake doesn't know how to write them either. Google "Make is an expert system". There should be as little as possible in the procedural code: if you can express something with dependencies, you should do it. Unfortunately Make is missing one crucial feature which would allow most Makefiles to be much, much cleaner. I have been meaning to write a patched version of make which includes it, but I never seem to get around to it. It's very simple: for each target, it should be possible to specify a piece of procedural code which returns 0 if the target is considered 'up-to-date' and 1 if it is not considered 'up-to-date'. Think about the potential uses of that for a minute. :-) > The *real* problem with the whole autotools disaster is that it promotes > a braindead idea of how to achieve portability: a #ifdef branch for > every different system (or library version, or whatever), strewn > throughout the entire codebase. Um, this is the exact opposite of the philosophy promoted by Autoconf since at least version 2.0. "Feature tests, not system tests". I can't speak to other autotools. > Real portability involves understanding > your target systems, learning where the rough edges and corner cases > are, and developing proper abstractions to work around them. Furthermore, 'best practice' use of autoconf is to isolate the feature differences in a single piece of wrapper code, so that your main code only has to deal with (e.g.) 'memmove', and it's emulated where it isn't present. The emulation code is the only code containing #ifdefs, which are then based on the features detected by autoconf. I don't think I'd like to work without autoconf. The alternatives I've seen are all hideous monstrosities. Automake -- well, if you know how to write a Makefile, don't use it, just write your Makefile -- but most people don't. -- 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: Packaging software which does not use autotools
Michael Rasmussen wrote: > Hi list, > > I have some questions I hope some of you have an answer for. > > I intend to package a peace of software which does not use autotools > but only has a plain Makefile. > > 1) Can I use dh_make? > 2) Does Debian policy have something to say about it? No. > 3) Would it be ok if I converted it to use autotools my self? Since you're adopting upstream, certainly. Personally, I tend to convert projects to autoconf but not automake. This usually cleans up the code but leaves simple Makefiles as simple Makefiles. > 4) The project seems to be abandoned by the developers - I have send > more than one email with no response. Would it be in conflict with the > Debian Policy if a adopt the software - it has been released under GPL > so I guess it would be ok to do a fork? Of course it would be OK! Yeah, this is one of the great things about free software. In a certain sense, you're adopting upstream. If you want to be really polite in case upstream comes back, change the application name. If you want to be less polite, just make it very clear that yours is a forked version. > BTW. The application in question is this: http://tptest.sourceforge.net/ -- 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: cdrtools alternatives
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Weimer wrote: > * Nathanael Nerode: > >> In reality, as "user A", I switched to using cdrdao for making serious audio >> CDs and CD-RWs, and for burning disks from .iso files: this uses >> Schilling's scsilib, but not the rest of cdrecord. > > What about mkisofs? Heh -- that's a point. Actually, I don't use it when creating audio CDs (for obvious reasons), and I don't usually create data CDs except by burning *other people's* .iso files, since I use DVDs instead lately. But I noticed that growisofs *does* use mkisofs as a backend. We definitely need a functional mkisofs in Debian. mkisofs is certainly part of cdrtools. But not of cdrecord. Nothing in mkisofs has weird conditions on the GPL, unlike other parts of cdrtools (libscg, cdrecord.c), so it should be straightforward to make a free fork. And it was originally written by Eric Youngdale. Likewise cdda2wav. It looks like the cdrecord package contains all the 'problem areas', and the other packages built from the cdrtools source package contain no problem areas. It's actually tempting to fork those two out as fully independent source packages. They have little to do, code-wise, with CD recording. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE4Z9IRGZ0aC4lkIIRAmLxAJ0eER+arucHyFwThcIAalBTfN+OQgCdGz7X pfAsiX2FHk081X8TMVmtfg8= =DMWp -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bits from the DPL: Freedom and etch
Anthony Towns wrote: > (c) A number of drivers in the Linux kernel include firmware to be > uploaded to the chipsets they support that is provided as > either a sequence of hex codes, or as a separate binary file -- > while modifying the code is allowed, in many if not most or all > such cases, the firmware is effectively being provided without > useful source. It would have been very helpful, Anthony, if you had linked to the list of *exactly* what drivers are at issue. (And exactly what the legal issues are for each one: GPL-without-source and no-license-text drivers are serious and separate issues, and affect far more drivers than properly-licensed sourceless firmware affects.) I suggest a d-d-a post adding this link: http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html -- 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]
The bigger issue is badly licensed blobs (was Re: Firmware poll
Ron Johnson wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Luk Claes wrote: >> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- >> 6c557439-9c21-4eec-ad6c-e6384fab56a8 >> [ 1 ] Choice 1: Release etch on time >> [ 3 ] Choice 2: Do not ship sourceless firmware in main >> [ 2 ] Choice 3: Support hardware that requires sourceless firmware >> [ ] Choice 4: None of the above >> -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > > [Non-DD opinion] > > [ x ] Choice 5: Ship *BLOBs* (does *not* mean closed-source > drivers like nvidia) that can be legally > redistributed, do not ship BLOBs that can > not be legally redistributed. It's worth noting for purposes of discussion the actual numbers here. >From http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html we find: * 14 free pieces of firmware with source code (great) * 46 drivers requesting BLOBs from userland (OK) * 47 BLOBs which can't be legally redistributed (bad) * 6 addditional BLOBs removed from Debian which can't be legally redistributed (bad) * at least 2 BLOBs (radeon and r128) which appear to be shipped with false copyright statements (bad), but if not, then are distributable. * the 12 keyspan BLOBs, removed from Debian, which have a unique license which makes them distributable in the linux kernel package, but makes it unclear whether they can be legally distributed as an addon package! * 1 BLOB in Debian (emi26) with a license like the keyspan BLOBs. * 9 BLOBs which can definitely be legally redistributed (in five drivers: mga_warp, tg3, typhoon, advansys, qla2xxx). So frankly the output of this entire discussion isn't going to cover very many BLOBs: exactly seven drivers will definitely be allowed to go into or stay in main for etch if 'sourceless firmware' is allowed without other changes. Of those, one (tg3) functions without the BLOBs for most cards and has been converted to userland firmware loading, and one (qla2xxx) has firmware loading code included upstream but disabled -- so those two are among the very easiest cases for moving the BLOBs to non-free. I've also volunteered to work on converting advansys to userland firmware loading, and to test anyone else's advansys conversion. The majority of the BLOBs have serious licensing problems, which won't be addressed by any decision regarding free, non-free, source, or sourceless material. Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. However, presumably the manufacturers who (in nearly all cases) provided the BLOBs intended them to be distributed -- although they never granted a proper license. (Of course, for all I know perhaps some of the manufacturers were evil geniuses and knew perfectly well they weren't granting a proper license, intending to cause trouble later.) Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, and Debian continues to ship 47 improperly licensed files in linux-2.6. If I were SCO, I'd buy up the copyrights to them from the original companies, and then I'd have a real case for a lawsuit. -- 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: The bigger issue is badly licensed blobs (was Re: Firmware poll
Joe Smith wrote: > "Sven Luther" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: >>> On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: >>> >>> > Debian must decide whether it wants to ship BLOBs with licensing which >>> > technically does not permit redistribution. At least 53 blobs have >>> > this >>> > problem. Many of them are licensed under the GPL, but without source >>> > code >>> > provided. Since the GPL only grants permission to distribute if you >>> > provide source code, the GPL grants no permission to distribute in >>> > these >>> > cases. >>> Many people disagree with this interpretation. >> >> A few very vocal people do. I guess they can be counted on the fingers of >> both >> hands or so. Probably less. The people who disagree with this interpretation are contradicting the plain text of the GPL, ignoring copyright law, ignoring the stated intent of the drafters of the GPL and the FSF, etc. As I said, the distributors of this unlicensed material probably *intended* to give it a proper distribution license. Should Debian rely on the assumption of good intentions? Debian doesn't do that for copyright issues in *general*. > I think everybody can agree that it would be clearer if the blobs used a > licence that clearly allows distribution without requiring source. > > In the case of the GPL that is definately not clear. > > > About the main issue: > As I see it, there are three possible catagories for drivers using > firmware > that all drivers should ideally fall into assuming the driver part is > free > : > > 1. Module and firmware in free. (The firmware can be compiled into the > module, or can be loaded from a file.) > > 2. Module in free, firmware in nonfree, loaded from file by driver. [One > could argue that the modules belong ion contrib, unless the firmware is > optional (perhaps allowing access to non-essential features)]. > > 3. Module in non-free. [Firmware compiled into module, has not yet be > seperated into seperate file. This is acceptable, but many of these could > be converted to type 2 if somebody puts in the work]. > > > I know we have some modules of type 1. I'm pretty sure we have some > modules of type 3. It has not been clear to me if we currently have any > modules of type 2. Yes, we do. bluez-firmware and atmel-firmware. > Obviously if the infrastucture is not there, that should be fixed. It's there except for d-i. > Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 > modules. This can definately be fixed, but doing it for etch could delay > release. Right. > Besides all of that we have quite a few modules with problematic licences. > Generally the licence problem is on the firmware, although some might > affect the > rest of the driver. Some are type-3 style (firmware hard-coded into > module, firmware lacking source.)Many of those could be shipped as type-3 > modules if licence clarification can be obtained (or preferable: > relicencing). A few are type-2 style, they could be shipped as type-2 if > proper clarification can be obtained. > > > The above is a rough summer of the problems as I understand it. Please > correct be if I am wrong. That's all correct. > So the question I have is how long would etch need to be delayed to add > support for non-free firmware to D-I? Joey Hess estimated 6 months work, but that was to implement a whole bunch of uncommon special cases. I think it is totally unnecessary to implement all, or even any, of those. http://lists.debian.org/debian-vote/2006/08/msg00122.html For (2) from that post, which is the key sticking point for d-i, it needs to be done anyway, and honestly should not take more than a month if someone bothers. So -- point me to the correct parts of the installer. I don't know where to find this "anna". libdebian-installer I'm looking at -- it would be a great help if someone could direct me to the part of the code which loads udebs from disk/network, because I can't find it. Is that all in 'anna', which I can't find? :-/ If I can't find the source code for 'anna', I can't fix it. (3) is trivial and simply requires the will to fix RC bugs. (4) is frankly not nearly as important as Joey makes it out to be. It is very unlikely that someone will have a machine where *both* the CD *and* the NIC *and* the floppy drive if present *and* the USB driver (USB key) need non-free firmware. As long as there is one piece of hardware with fully free drivers which can be used to load
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Sven Luther wrote: > Since the firmware blobs are not derivative works of the kernel, but > constitute mere agregation in the same binary format, the authors of other > pieces of GPLed code fo the linux kernel cannot even sue us for > distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. -- 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: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal >> minefield. That is higher priority than the entire discussion going on >> right now, because it determines whether Debian will distribute these 53 >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > liability. It's the domain of the ftp team to determine whether we can > legally distribute a package on our mirrors. Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. I know this is Debian tradition, but it's worth thinking about whether it really makes sense. Debian-legal has very little legal expertise, and as a result the consensus errs on the side of caution at essentially all times with regard to copyright. Probably too much caution, but without getting an actual legal opinion, that seems like the right thing to do. Should the ftpmasters, who have even less legal expertise, ever take the risk of erring on the side of recklessness? (This risk is currently being taken with the mislicensed 'firmware' BLOBs.) Does this expose anyone but the ftp team to legal liability? Now, if the rest of Debian has repeatedly disavowed all responsibility, it may be that the ftp team and only the ftp team are *personally* liable if Debian makes an illegal distribution, and in that case it would make sense for them to determine such things. I'm not sure the ftpmasters are actually comfortatble with assuming personal legal liability for every package in Debian though. I wouldn't be! -- 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: bug rates
Joey Hess wrote:
> Steve Langasek wrote (elsewhere):
>> something changes in the archive (often for a transition that needs
>> to happen), a large number of packages are broken by this, and some
>> appreciable number of the maintainers don't respond in a reasonable
>> amount of time ("reasonable" defined as "sufficient to make headway
>> against the RC bug count"; average time to bugfix << average interval
>> between archive-breaking transitions).
>
> I wonder if you have any numbers on this? My gut feeling for a while has
> been that part of what's keeping the RC bug levels in balance is that
> we have a constant stream of RC bugs being filed for issues that are not
> new but have only turned up as things get tested.
Yep.
> A certian percentage
> of these affect stable too. One obvious example is security bugs. It
> seems to me that if you look at the RC bug graph, most of the sharp
> spikes and dips are due to the kind of transitional RC bugs you're
> talking about, which says that we do pretty well at dealing with those,
> at least for significant transitions that cause a lot of similar bugs.
>
> One of my problems with our current release process is that it doesn't
> seem to take into account the bugs that exist in stable. By the current
> metrics we could easily be in a position today where testing has many
> fewer RC bugs than stable, but still be far from a release. And even if
> we get the RC bugs to zero and make a release, that release will have
> many undiscovered RC bugs which will turn up later.
Yep.
> That makes it hard
> for me to worry about bringing the count down to zero, since it's really
> just pushing the iceberg underwater for an instant.
Yeah, I think you have a good point here.
Personally, I would prioritize RC bugs which apply to "key" packages
-- the benefit from getting those RC-bug-free is
larger than that of getting other packages RC-bug-free. Unfortunately,
some vital packages like the toolchain packages and the kernel have some of
the oldest and most irritating RC bugs. Licensing
> I wonder if it would be worthwhile to try to quantify this some more,
> by looking at all the RC bugs over a period of time and determining:
>
> a. What percentage were caused by issues in new uploads.
Weirdly, these are often the quickest to be fixed. Exceptions: Bugs
caused by large upstream changes; bugs in packages with inactive
or inattentive maintainers.
> b. What percentage by transitions.
Gah, probably most of them. Time-to-fix is weird for transitions; most
packages are fixed very quickly, and then there's a long tail, primarily
caused by inactive maintainers. Amaya's been working on finishing up
some of those long tails, as have I. Mostly they don't get finished.
> c. What percentage also affect stable.
I try to versiontag for this. This should be a detectable quantity now,
thanks to versiontagging. These, oddly (or perhaps not so oddly) are
often the ones which take the longest to fix. However, they're also where
I put my priorities, because long-standing bugs are substantially more
annoying than new bugs.
A release where we fixed all the (discovered and undiscovered) RC bugs from
the *previous* release would be a very successful release. :-)
> and finding the relative time-to-fix of each of these.
--
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: The bigger issue is badly licensed blobs (was Re: Firmware poll
Toni Mueller wrote: > > > Hello, > > On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: >> On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: >> > Debian must decide whether it wants to ship BLOBs with licensing which >> > technically does not permit redistribution. At least 53 blobs have >> > this >> > problem. Many of them are licensed under the GPL, but without source >> > code >> > provided. Since the GPL only grants permission to distribute if you >> > provide source code, the GPL grants no permission to distribute in >> > these cases. >> Many people disagree with this interpretation. Marco trolled again. FYI, no serious person disagrees with this interpretation. >From the GPL: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Debian is not doing this for the BLOBs b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Debian is not doing this for anything c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) -- Debian is not allowed to do this So Debian isn't satisfying the conditions of clause 3. Therefore, the GPL does not grant Debian permission to distribute the BLOBs in object code or executable form. > I'm not a lawyer, but my take on this is that if someone ships you a > BLOB under the GPL, you have the legal right to demand sources from > him. Unfortunately not. Generally, only a copyright holder can sue for GPL violation. (In contrast, Debian's Social Contract promises that Debian will distribute source code for all the programs in Debian -- so under common law I could sue Debian for false advertising because it isn't distributing source code for some of the programs.) *However*, consider the following case: (1) The driver is written by person A and released properly under the GPL. (2) The firmware is written by corporation B and distributed without source. (3) Either B or person C combines the firmware with the driver to make a single work, and distributes it -- without the source for the firmware. In this case, person A can sue any distributor of the combined work. Arguably, any contributor with copyright in any part of the Linux kernel might be able to sue any distributor of a kernel with firmware in it. Some of the contributors to the kernel are very vociferously against sourceless firmware, and might actually do it. Dropping -vote, setting followups to -legal. -- 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: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: >> Actually, letting an overworked team of four with (to my knowledge) zero >> legal expertise settle questions of legal liability is pretty absurd too. > > They are the team responsible for vetting the legality of what's > distributed > on the mirrors. None of them have any legal expertise to my knowledge; > but they do know where the lawyers are if they have questions, Well, that's good! Do they really have the hotline to the lawyers? Excellent! I hope they actually use it occasionally; I've never heard of them doing so, so if they have gotten any legal opinions, they've kept them secret. (Dammit, when Debian developers attempted to get legal advice on trademark policy, it sunk into a black hole. The advice never really came back, after several years.) > and they > *are* the ones in the hot seat(s). Meaning that they are personally liable and the rest of the Debian developers aren't? :-) I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. It seems to me that the developers have entrusted the ftpmasters with the responsibility of guarding Debian's funds and property against a copyright infringment lawsuit. Is that the general feeling of the developers? Are the ftpmasters comfortable with that responsibility? If so, my proverbial hat is off to them. >> Should the ftpmasters, who have even less legal expertise, > > Judging by some of the nonsense that debian-legal is typically riddled > with, if I were an ftpmaster I would find that claim insulting. There is at least one laywer who posts regularly. Which counts as some legal expertise, and which is exactly what I was referring to when I said "very little". > The only claim to expertise that debian-legal has is in the area of > analyzing license terms and how they stack up against the requirements of > the DFSG. That is an important function, but it is *not* legal expertise. See above. -- 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: The debian boot dependency graph image
Petter Reinholdtsen wrote: > The scripts listed in the upper right corner are all those scripts > without dependency information available. This is the complete list > for my installation: > > hwclockfirst.sh ifupdown-clean modutils hwclock.sh libdevmapper1.01 > libdevmapper1.02 lvm hibernate ifupdown nviboot xserver-xorg vbesave > sysklogd klogd acct acpid apmd apt-index-watcher atftpd cupsys > dbus-1 nullmailer openbsd-inetd rsync snmpd ssh uml-utilities > snmptrapfmt anacron binfmt-support acpi-support libnss-ldap syslog-ng also lacks information. (We should be getting rid of sysklogd and klogd in favor of syslog-ng or metalog; I don't know why we haven't yet.) The udev dependency information is not really accurate: a lot of things depend upon udev running first, and don't say so. This is partly because the long-term plan is to run udev in the chroot, but I think for now probably the dependency should be specified. -- 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: (proposed) Mass bug filing for debconf "abuse" by using low|medium priority debconf notes?
Joey Hess wrote: > Christian Perrier wrote: >> In short, a note should only be used for IMPORTANT stuff, so actually >> all debconf notes should be priority highor should not exist! > > It's better to simply remove them all: If it's an error, use the new > error data type, which will always be displayed no matter the priority. > If it's not an error, put it in NEWS.Debian, README.Debian, etc. > > The only thing stopping me from making debconf notes a no-op is the note > in d-i's nobootloader, which is a fairly legitimate note (not error), that > can't really be put anywhere else, and possibly the partman help note > (though noone reads that note). Hmm. Any time a package has to tell the user "You need to do something manually. It's not being done automatically because we haven't figured out how to do that, but it's really really important to do it manually" -- then a high-priority debconf note is appropriate. Frankly, the kernel's "You NEED to restart your computer SOON" message is a good example, if it's telling the truth. But that cheats by not using debconf. Upgrades which require programs to be restarted should do it automatically. But if for some obscure reason they can't, then a high-priority note is reasonable. Upgrades from really-messed-up versions may also require people to do something manually to clean up from the messed-up version. -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: Orphaning my packages
David Moreno Garza wrote: > Hello, > > I'll be taking a long vacation of Debian and free software activity > for the next couple of months for personal reasons. Because of that, > I'm orphaning my non-comaintained packages. I really think those > packages shouldn't make it to Etch with a non attending maintainer, > just like I'm beginning to become (I already orphaned some of them in > the last couple of months). Once I get more free time or motivation > to work on my packages, I'll be coming back, but since that's not the > case now, I'm stepping back for a while so I don't interfere with the > project. > > If you think you could adopt some of the packages, feel free to do it > (filling an ITA would be nice). Just talk to the Debian Perl Group > first, if thinking on adopting some of the Perl modules; talk first > to the pkg-ruby-extras groups if thinking on adopting some of the > ruby modules, also. This is such a cool thread! Not only have you responsibly orphaned packages when you don't have time to maintain them, but most of them were picked up very quickly! And some have picked up comaintainers almost immediately, which is even better! (Sorry, I'm not picking any of them up.) The ones which haven't been picked up either with ITAs or in this thread, and which aren't lib*-perl or lib*-ruby, are: * dlume * fpm * gxmms * kipina * revolution * rxvt * sendemail * * wallpaper-tray (There are quite a few more -perl and -ruby packages, but I'm not quite sure which ones have been picked up.) I will note that rxvt has 1234 popcon installs, so if anyone's going for brownie points -- 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: gnome 1 packages up for adoption
Steve Langasek wrote: > Hmm, I've looked over the packages mentioned above, and none of the others > seem to be removable. I think someone's been sneaking new GNOME1 packages > into the archive when I wasn't looking. :) > > libcapplet is closest, only python-gnome-1.2 as a reverse-dep after the > other libs we can remove are removed. python-gnome-1.2 is QA-maintained > as well. gal0.x and bonobo should also be removable. I think I covered the GNOME 1 status pretty well at http://lists.debian.org/debian-qa/2006/09/msg00038.html. gnome-print, python-gnome, and oaf are pretty close to removable, but not quite. libglade, gnome-libs, and imlib are definitely hanging around. Adopters welcome for any of the six. :-) -- 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: Orphaning my packages
gregor herrmann wrote: > On Mon, 18 Sep 2006 10:58:31 -0400, Nathanael Nerode wrote: > >> (There are quite a few more -perl and -ruby packages, but I'm not quite >> sure which ones have been picked up.) > > The lib*-perl packages are all already in the Debian Perl Group's svn > repository and will be uploaded soon. Cool! I note also that the -ruby packages have all been picked up by the Debian/Ruby Extras team or others, and so have , revolution. That reduces the complete list of unadopted packages from David to: * dlume -- address book program * fpm -- GNOME 1 password manager program * gxmms -- GNOME panel controls for xmms/beep media player * kipina -- athlete's training log program * rxvt -- very popular x terminal emulator -- the adopter might also want to grab the orphaned rxvt-beta package * sendemail -- does what it says. -- Small and written in perl -- maybe the Debian Perl Group would like it? * wallpaper-tray -- GNOME wallpaper changer program, some nasty bugs Meanwhile, I don't suppose I could convince the Debian Perl Group to pick up some of the *other* orphaned perl libraries?. ;-) The ones I've noticed on a quick run through the orphaned package list are: libapache-authznetldap-perl libbusiness-ups-perl libcdk-perl libcgi-xml-perl libcgi-xmlapplication-perl libcgi-xmlform-perl libclass-prototyped-perl libconfhelper-perl libconvert-ber-perl libcorba-orbit-perl libdb-file-lock-perl libdbix-xml-rdb-perl libdbix-xmlmessage-perl libextutils-f77-perl libfile-counterfile-perl liblingua-en-numbers-ordinate-perl liblingua-ispell-perl libmail-listdetector-perl libmldbm-sync-perl libnet-ftpserver-perl libnewt-perl libpalm-perl libperlmenu-perl libpod-pom-perl libproc-process-perl libqt-perl libtangram-perl libtest-cmd-perl libtie-array-sorted-perl libtie-cache-perl libvcs-perl libxml-sablot-perl perlftlib These perl modules constitute more than 10% of the orphaned packages. (I suspect some of them may be obsolete or folded into the main Perl distribution or other perl modules. Perhaps at least these could be identified and removal bugs filed.) > > gregor > -- 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: (proposed) Mass bug filing for debconf "abuse" by using low|medium priority debconf notes?
Frans Pop wrote: > On Monday 18 September 2006 16:36, Nathanael Nerode wrote: >> Frankly, the kernel's "You NEED to restart your computer SOON" message >> is a good example, if it's telling the truth. But that cheats by not >> using debconf. > > Oh yes it does! > When have you last done a kernel upgrade in testing/unstable? ;-) Not recently enough, I guess! I thought I did it a few weeks ago (in testing). Well, that's cool! :-) -- Nathanael Nerode <[EMAIL PROTECTED]> Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?...
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Goswin von Brederlow wrote: > [EMAIL PROTECTED] (Marco d'Itri) writes: > >> On Aug 31, Nathanael Nerode <[EMAIL PROTECTED]> wrote: >> >>> Marco trolled again. FYI, no serious person disagrees with this >>> interpretation. >> Except every other distribution, which usually retain real lawyers >> to advise them about potential problems like this instead of relying >> on mailing lists posts. >> It's pathetic that you dismiss dissenting opinions as "trolling". >> >> -- >> ciao, >> Marco > > Every other distribution does not concern itself with the question > wether it is legal to distribute this. They are only concerned with > "Will anybody sue us?" and "Do we loose more profit by risking a > lawsuite or by dropping support?". > > MfG > Goswin And we all agree that it is very unlikely that anyone will sue us if we distribute these firmware blobs. I did specify that, didn't I? Now, "Is anyone likely to sue us?" *is* the standard Debian generally uses for patents. I presume this is because most software patents are in fact issued illegally at this point (in the US see the statutes and pre-Federal Circuit caselaw, in the EU see the European Copyright Convention and non-EPO caselaw), and DDs generally consider these illegitimate and unworthy of respect. If we use the "Is anyone likely to sue us?" standard, then definitely these mislicensed lumps should be distributed. However, traditionally Debian has used a higher standard for copyright. (Perhaps because Debian developers generally respect copyright law and think it deserves better treatment than "can we get away with this"? Perhaps for some other reason?) The higher standard has been more like "If the copyright was bought up by EvilCorp and they sued us, would we probably win anyway because we behaved impeccably?" In the case of the mislicensed lumps, we would probably *not* win; we would probably be enjoined from any further distribution at least. Perhaps this is a mistake and Debian should use the "Is anyone likely to sue us?" standard for copyrights as well. Discussion is welcome. Perhaps discussion will clarify why the different standards are used. Discussion on debian-legal please. -- 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: Why are all packages getting so much bigger?
I'm guessing translations. They eat up space really fast. Is there a way to compare packages after localepurge runs? -- Nathanael Nerode <[EMAIL PROTECTED]> This space intentionally left blank. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Ftpmaster bug reports are not processed nearly fast enough.
To start with, congratulations to the ftpmasters for keeping up with the NEW queue. Unfortunately, this email is going to be a case of damning with faint praise I'm seeing bugs which were filed as removal requests as early as August 14 which are still waiting for processing. Unfortunately, they are really beginning to pile up; there are slightly over 100 now, so I think it will take quite a lot of work to catch up. As for the bugs requesting change of priorities in the Overrides file, many appear to simply be ignored permanently. #263887 is the canonical example. I recommend eliminating the overrides file for packages of priority 'standard' and lower, and instead always allowing package maintainers to set their own package priority among 'extra', 'optional', and 'standard', As for bugs requesting stuff which actually needs the manual touch of an ftpmaster, like #224469, they're also ignored. I pinged in August. This bug, for which a trivial solution was described in December 2005, is getting rather urgent; once woody is removed from ftpmaster.debian.org and moved to archive.debian.org, it will be a license violation issue. It's really rather discouraging that the ftpmasters have not fixed this. FTPmaster is *still* one of the biggest bottlenecks in the whole of Debian. (The other one is DAM; "0 applicants became maintainers."). It needs more people, specifically on the routine processing of removals, new packages, and override changes, so that the existing highly-qualified people can focus on the more unusual and complicated problems. There's really no good reason for the removal requests to be delayed like this. There are plenty of people who are competent to go through removal requests and process them, starting with some of the more careful QA people. You don't need to give full ftpmaster powers out in order to do that; set up a system where DDs on the 'privileged list' can trigger package removal, much like DDs on the right 'privileged list' can hint packages into testing. It should be pretty easy to set up for someone who understands the DAK scripts, since it seems that the scripts do most of the removal work already. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Tempfile best practice vs. man pages
The manpages for the various ways of creating a temporary file from C are a bit scary... tmpnam(3): "Never use this function. Use mkstemp(3) or tmpfile(3) instead." mktemp(3): "Never use mktemp()." tempnam(3): "Never use this function. Use mkstemp(3) or tmpfile(3) instead." mkstemp(3): "Don't use this function, use tmpfile(3) instead." tmpfile(3): Not suitable for most applications, because it generates a FILE* and nothing else. tmpfile(1): "tempfile creates a temporary file in a safe manner. It uses tempnam(3) to choose the name and opens it with O_RDWR | O_CREAT | O_EXCL." I'm guessing that the dire warning on tempnam(3) is overblown. Am I right? -- Nathanael Nerode <[EMAIL PROTECTED]> Make sure your vote will count. http://www.verifiedvoting.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Correct fate for emacs20 bugs?
So I'm going through the old bugs list. There are 37 bugs against emacs20. emacs20 is only in oldstable-security at this point. What is the correct fate for these bugs? -- Nathanael Nerode <[EMAIL PROTECTED]> [Insert famous quote here] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can ftpmasters do ONE SIMPLE THING?
Namely, fix bug #224469. It's really trivial and it's been waiting for over three years now. This is just STUPID. Next DPL election, I want to see someone running on the platform of adding an extra ftpmaster *whether or not the current ftpmasters like it*. Someone who will get simple stuff like this DONE. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Thanks to ftpmasters!
I see that the source for the boot-floppies used in woody is now on archive.debian.org along with woody, at the location http://archive.debian.org/pool/main/b/boot-floppies/ Very cool. Thank you very much! You also caught up on over a hundred RM bugs in extraordinary time. *AND* fixed ancient priorities bugs. I'm extremely impressed. Credit where credit is due; nearly all the "easy" longstanding bugs were fixed in a very short amount of time, and the rest had explanations of the problems added to the bug trail, which is *superb*. Thanks Ryan Murray et al! -- Nathanael Nerode <[EMAIL PROTECTED]> Read it and weep. http://rawstory.com/news/2005/Text_of_Gore_speech_0116.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dicussion about patches ... ignoring patches make motivation toprovide them fall
Petter Reinholdtsen wrote: So yes, I believe we need to work on the long-term "ignored" bugs. :) Those are essentially all I work on. It's a good thing I have a thick skin. Some maintainers are genuinely grateful for the assistance, and they're a pleasure to work with. (This includes the X Strike Force, although they are really a bit snowed under and so you have to push a bit to get a bug addressed.) Some maintainers are basically MIA, but won't give up their packages, and they're more annoying, but they usually accede to reality eventually, and are OK to work with. Some few maintainers are obnoxious and anti-helpful. All of these have bugs which have had a patch attached to them for a long time without mantainer comment (not even 'no, this patch doesn't work because X'). However, not all such bugs reflect anti-helpful maintainers; many reflect MIA, busy, or distracted maintainers, so one has to poke them to find out whether one gets a rude reply, no reply, or a "thank you" reply. Sorry about the thread-breaking again. Can't help it on this machine; will try not to post from here again. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Changing the default syslogd (again...)
OK, I brought this up a while back. (For some reason I can't seem to find the
beginning of the topic, but see
http://lists.debian.org/debian-devel/2006/01/msg00238.html )
I got a few comments in favor.
Someone asked what syslog other distros are using. RedHat is still using
sysklogd.
However, they are discussing switching to syslog-ng for Fedora Core 6
(http://fedoraproject.org/wiki/FC6Future). SuSE is using syslog-ng. Mandriva
is
still using sysklogd. I haven't found out about anyone else.
Every admin I know switches to something else. :-(
Issues:
(1) Quality.
sysklogd has 105 open bugs: 3 important (1 with patch), 43 normal (11 with
patches),
11 minor (4 with patches), and 19 wishlist (some of which are really quite
important,
such as 44523)
The source code is a hairy mess, in my opinion, and I can see why these bugs
aren't
being fixed. It's been prone to repeated RC bugs, IMO due to the hairiness of
the
codebase. (I would also really not like to try a licensing audit of this
package.)
Contrast:
syslog-ng: 26 open bugs, 3 important, 9 normal, 2 minor (1 with patch).
metalog: 15 open bugs, 1 RC (patched), 2 normal, 1 minor
inetutils-syslogd: 3 open bugs (2 normal, 1 wishlist).
socklog-run: 1 open bug, wishlist
(2) Upstream status.
There hasn't been a new upstream for sysklogd since 2001.
All of the others are active upstream.
(3) Features.
Essentially all of the others are considered more featureful.
(4) Size.
Installed sizes:
sysklogd: 204
depends on klogd: 132
total 336
inetutils-syslogd: 104
depends on lsb-base ('required'): 24
depends on zlib1g ('required'): 164
depends on netbase ('important'): 188
(depends on some Essential: yes packages as well)
syslog-ng: 492
depends on util-linux ('required'): 992
depends on lsb-base ('required'): 24
(depends on some Essential: yes packages as well)
metalog: 132
depends on libpcre3: 380
total: 512
socklog-run: 148
depends on socklog: 244
depends on runit: 488
depends on ipsvd: 384
depends on libmatrixssl1.7: 100
total: 1364
Conclusion
--
We should change the default syslogd.
Size may be an issue. However, except for socklog-run, the alternate syslog
packages
depend almost entirely on packages which will probably already be installed.
If we want the default syslogd to be small, and assume that netbase will be
installed,
we should default to inetutils-syslogd.
If we aren't so worried about size, we should go with syslog-ng or metalog.
Probably
syslog-ng just for the familiarity of SuSE users.
The installer can use whatever seems most appropriate (does it even log?): but
based on size, I strongly suspect inetutils-syslogd will be the winner, even
over
sysklogd. I expect that most of what it needs from netbase will turn out to
already be available in the installer.
Given the state of sysklogd, I hope that it can be removed entirely from a
future
release of Debian.
--
Nathanael Nerode <[EMAIL PROTECTED]>
Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't
like it.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Sun Java available from non-free
[EMAIL PROTECTED] wrote: By whom? A bunch of people with too much time on their hands. Is there an actual lawyer involved? I don't think so. This is a crazy stupid argument. By this argument, Debian should distribute absolutely anything, no matter what the license, unless a lawyer gets involved. Never mind actually bothering to get a valid copyright license -- there's no actual lawyer involved, so we don't have to worry! Let's distribute copies of some websites which seem interesting! After all, there's no lawyer involved! How about some old movies -- maybe "Gone with the Wind"? After all there's no lawyer involved! Please desist from making completely moronic arguments. If you would like to hire a copyright lawyer and provide his or her services to Debian, it would be much appreciated. Until then, we make do with what we have, and try to work out what licenses mean as best we can. In particular, we tend to demand licenses where we can clearly tell, without being lawyers, that they don't require bad things. It's because we're not lawyers that we err on the side of caution. If you disagree on some point of license interpretation, please argue the merits of the matter. Don't say "Oh, you're not a lawyer, so I can't hear you, la la la". This applies to everyone who likes to slag off debian-legal, by the way. Your other arguments were reasonable and sensible. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-DDs in debian-legal
Ted T'so wrote: > The d-l list has a problem which is shared by many Debian mailing > lists (including debian-vote and debian-devel, and I'm sure it's not > limited to them) which is that far too many people subscribe to the > "last post wins" school of debate. I've seen relatively little of this among the regular, careful-license-analysis types on debian-legal. There are several issues on which we have a definite lack of consensus whether they're non-free or not: they're "is this too much of an infringment on your rights or not?" issues, whch should be settled politically, and perhaps GRs should be proposed on issues like this. In regard to DFSG-freeness, examples are choice-of-venue clauses which apply to suits by the author against the user (not to be confused with choice-of-law clauses or choice-of-venue clauses which apply only to suits against the author); and clauses surrendering the right to trial by jury. In *distributability*, the main contentious points are indemnification clauses. I think we're quite clear on what we disagree about in this kind of situation. In almost all of these cases, after discussion, pretty much everyone agrees that we've found clauses which *should not be* in the license. The question of whether it's a "real problem" or merely a "minor problem" often ends up unresolved, but the desired changes are usually hashed out after much discussion and everyone agrees on what the license *ought* to look like. I do see an obnoxious dismissiveness among a group I might call the "Oh, that's not a real problem, just dump it all in main" types, who seem to say that about every problem. There's a fundamental philosophical disagreement. One group seems to think that we don't actually need licenses which explicitly grant us the permissions we want, and that we should err on the side of assuming that we have been granted permission to do something if we're not sure. Understandably, debian-legal regulars mostly want licenses which actually legally guarantee the rights we want, and would like to err on the side of caution in determining whether a license has granted those permissions. This is primarily a consequence of the rather frightening state of copyright law today. > If everyone participating on the list were mature and grown-up, this > wouldn't be necessary. And I would suspect that the call to restrict > d-l to only DD's is a hope to exclude some of the more immature and > less disciplined posters. The more immature and less disciplined posters? Those are the ones who say "Debian-legal should be ignored, listen to me instead". The regulars are generally very disciplined and mature, and treat licensing analysis like -- well, the best analogy is debugging. -- 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: cdrtools
Eduard Bloch wrote: >#include >* Kevin Bube [Fri, Jul 07 2006, 11:29:21AM]: >> Eduard Bloch <[EMAIL PROTECTED]> writes: >> > * Adam Borowski [Fri, Jul 07 2006, 10:38:32AM]: >> >> >> * dvdrtools, a fork of the last GPLed version, is in non-free >> > >> > Please look at dvdrtools' files, eg. cdrecord.c before claiming that. >> >> What is wrong with that? The blurb [1] seems quite okay (i.e. GPL) to >> me. > >Grep for "not.allowed" and decide yourself whether such remarks are >applicable to the GPL (as applicable in your country). > >Eduard. OK. Here are the "not allowed" elements in dvdrtools: First, cdrecord.c: /* * Warning: you are not allowed to modify or to remove this * version checking code! */ This is false and unacceptable. I believe this constitutes an error on the part of the dvdrtools upstream maintainer, who thought he'd forked from before this was introduced. I suggest reporting this upstream and seeing if there's an earlier version which it can be forked from. librscg/scsi-remote.c libscg/scsi-*.c These are all shim layers for interfacing with different kernels' implementations of SCSI. My suspicion is that the best move would be to replace this library entirely. Doesn't the Linux kernel have a fairly clean and reasonable interface to CD-ROMs these days? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Congrats to the ftpmasters
The NEW queue is down to *22* packages, which is totally unheard of. Only three packages have been waiting longer than a month -- so Javier's package is no longer in the 'endless wait' state. At the same time, the RM bugs are in fairly good shape, and clearly removals are also being processed pretty well. Meanwhile, infrastructure work appears to still be progressing. (The substantial bugs are all very new.) Impressive. :-) As an aside, bug 248043 looks fixed to me, so I closed it. :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: small quirks setting up a cross-compile toolchain
[EMAIL PROTECTED] wrote: > That's exactly what I did: > > apt-get install -y \ > autoconf2.13 \ > toolchain-source toolchain-source-gdb \ > toolchain-source-newlib \ > dpkg-cross dejagnu expect gperf dpatch gobjc cdbs quilt \ > expectk patchutils equivs fakeroot > > cd /usr/src > > tpkg-make arm-linux See, there's your problem. Try: tpkg-make arm-linux-gnu > > cd binutils-arm-linux-* > debuild --no-tgz-check -uc -us > debi > > TPKG_SERVER=ftp.yi.org tpkg-install-libc arm-linux TPKG_SERVER=ftp.yi.org tpkg-install-libc arm-linux-gnu > I end up with a /usr/arm-linux and /usr/arm-linux-gnu :-/ And you should end up with only arm-linux-gnu. For obscure reasons (which I would like to get rid of), some parts of the cross-tools structure care about exactly what form of the system name you give to the tools, while others use the canonical name. If you still end up with two different things come back and complain to whoever's generating arm-linux. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Constitutional amendment: Condorcet/Clone Proof SSD votetallying
Manoj said: >Oh, as a sponsor of the GR, I suppose I should clarify that I > am not going to accept this amendment; I consider it a bad one. This > makes our vote method fail the monoticity criteria > (http://www.electionmethods.org/evaluation.htm). See Scenario 2 below. > > >I'll present two (perhaps contrived, but failing to make > quorum is not a very usual scenario in any case). > > > Scenario A: >Suppose the tech ctte has 10 members, and is trying to vote on > the rainbow vote. The quorum is 4. (If you recall, the rainbow vote > had 10 options). > >All 10 members vote -- and they all like like different > colors, except that two people like red. Most are indifferent about > the colors they did not chose, but they do not feel they should win > -- and express their preferences by either only voting for the color > of their choice. > >In my version, since no option got the needed 4 votes, there > is no winner. > >In this amendment, red wins -- even though only 2 of the 10 > people voted for it (less than the quorum of 4). Red won, even though > 8 out of 10 people did not want to see it as winner. This is inaccurate. With this amendment, no options are excluded by quorum. However, the default option actually *beats* red here. (2 people prefer red to the default, while 8 people prefer to the default to red.) The default option in fact is the Condorcet winner and will win. --Nathanael
Bug#198158: architecture i386 isn't i386 anymore
>* what opcodes need to be emulated? >* all 386->486 opcodes (there's just a few of them, right?) This is the correct answer. :-) Then all programs can be compiled with gcc --arch=i486 --tune=i686 (which should probably be mandated as the standard, in fact). >* do you need SMP on 80386? Is there even such thing as 80386 SMP > machines? Not requiring SMP support would make the ABI change > trivial... I think there is no such thing as SMP for 80386. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Future releases of Debian
David Z Maze <[EMAIL PROTECTED]> wrote: >"Jamin W. Collins" <[EMAIL PROTECTED]> writes: > >> On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: >>> me too! any package that doesn't build on m68k or arm is broken and >>> needs to be fixed, even if it works on x86 by chance! >> >> So, are you volunteering to help those of us without access to either >of >> the above architectures with "bugs" found in our packages? > >But Debian has ~public machines for pretty much every architecture. >I'd say "look on http://db.debian.org/machines.cgi";;, except that's >down; I can at least point you at section 4.4 of the Developer's >Reference, though that doesn't say a whole lot beyond this. I admit >that this doesn't necessarily help for testing installers, but for >your own packages it should be straightforward for you to do testing >and bugfixing even on architectures you don't personally own a machine >for. You forget, perhaps, that Jamin is stuck in the NM queue waiting for DAM approval. Since he's not an official DD yet, he does not have access to those machines... -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Future releases of Debian
fixed recently; I can't tell whether it needs anything else. Sparc seems to be taking a while; s390, m68k, and arm seem to need some serious work. Good luck finding more people to work on those last three. The bugs in installer-related packages are listed at: http://bugs.qa.debian.org/cgi-bin/debian-installer.cgi (Installer people, feel free to correct my impressions if they're wrong.) -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Future releases of Debian
>db2: > This is pretty old... who still uses it, anyway? More specifically, > does anyone use libdb2++, and if so, are they only things which > aren't supposed to be transitioned? OK, this is an odd list: Package: libdb2++ Reverse Depends: libdb4.1++,libdb2++ 2:2.7.7-3 libdb4.0++c102,libdb2++ 2:2.7.7-3 libdb3++c102,libdb2++ 2:2.7.7-3 libdb2++-dev,libdb2++ 2:2.7.7.0-8 animals,libdb2++ 2:2.7.7-4 What exactly is going on here? It appears that apart from 'animals', the only things depending on libdb2++ (the C++ interface to libdb2) are *future* versions of the C++ interface to libdb. Why are they depending on it? This seems odd to me. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Aaargh!
I feel a little like screaming. A few days ago things looked good. KDE had one RC bug open against it, and it seemed likely that it had been fixed by GCC upgrades. Since then, the KDE maintainer decided to upload new KDE. And hit a new bug in GCC (3.3) on ia64, which is fixed in GCC CVS but not in the current GCC upload. The current GCC upload hasn't been built on m68k (it appears to have timed out). Of course, why bother building it when a newer GCC is needed... But for that matter, the current GCC (and presumably any updated version) apparently requires a new version of glibc to go into 'testing'. And the latest glibc needs a rebuild on SPARC. Plus, it has at least 5 RC bugs, so who knows when it'll make it into testing. So now it looks like KDE3 is a lot *further* from getting into sarge than it was last week. I really don't know what can be done about this kind of thing, but it's frustrating. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: [PROPOSAL] Debian Release Plan
Matt Zimmerman said: > I do not think that version number milestones are important for a > release. I think that having a well-integrated, high-quality > distribution is important for a release, and this is not so easily > monitored. Releasing with KDE 2.2, GNOME 1, and a default of GCC 2.95 would be just plain pathetic. So sometimes, version number milestones *are* important for a release. Admittedly, most of the time they are not such a big deal. I guess what really matters here is having versions which aren't ludicrously out of date. Specifically, if something was released upstream over a year ago, and Debian releases with an even *older* version (without good reason), that's not good at all. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: [PROPOSAL] Debian Release Plan
Matt Zimmerman said: >I disagree. If I'm not mistaken, this is the definition of an RC bug. >If >the package has an RC bug, it is not releasable. If there is an RC bug >which does not imply that the package is unreleasable, it has been >assigned >the wrong severity. So you're saying bug #196564 should be downgraded then? I don't think that *possibly* causing a segfault in another package (it's not clear that it still does), on *one* architecture (m68k), when it's *probably* a toolchain issue, and the m68k people don't have the time or interest to reproduce it or track it down, should imply that the package is unreleasable! For that matter, I can't seriously believe that new XFree86 should not be released because of bugs which are pre-existing in old XFree86 (#143825, #185936, #190323). This is actually a *very* common problem; a lot of RC bugs existed in older (released) versions, and so shouldn't be considered blocking if they happen to still be present in newer versions, but the 'testing' scripts don't realize this because the bugs weren't *reported* earlier. (Actually, rumor has it that there's a 'sarge-ignore' tag available now, which may do the right thing for supposedly RC bugs which shouldn't really block release; I don't know much about it though.) Also, you're not taking dependency issues into account. You're also not taking architecture differences into account. KDE 3 has been releasable on i386 for a long time. It has been held up by toolchain issues on various other architectures, one at a time generally. Perhaps the time has come to reconsider the requirement that, to be releaseable, all packages must be release-ready on all 11 previously-released architectures, and in sync on all 11 architectures. That's a lot to keep in sync, especially when upstream doesn't care about some of the architectures. :-( Of course, there are already options individual maintainers can use to deal with such issues, such as declaring their packages to be non-m68k or non-s390 (for instance). Perhaps this should be used more aggressively. :-/
Re: How to install X-Chat in five hours (or more)
>>bootlogd. >>Activating swap. >>fsck 1.35-WIP (01-Aug-2003) >>Running 0dns-down to make sure resolv.conf is ok...done. >>Please contribute if you find this software useful. >>DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5 >>Starting Xprint servers: Xprt. > >If the pause were after fsck and it was showing that it was >checking >the >disk that would let me know the machine is doing something. If the >pause is >after DHCPDISCOVER I can surmise that if the network isn't hooked up >then it >is waiting for a timeout there. I would go further. The first time I saw these messages I didn't know what DHCPDISCOVER or fsck meant. BUT I knew this: * If it hanged after "DHCPDISCOVER", I should look up DHCP on google to find out what went wrong * If it hanged after "fsck", I should look up fsck on google to find out what went wrong. Already useful information. Admittedly, I've seen some less than useful messages on boot (mostly overly generic messages where I couldn't figure out what part of the system could possibly be producing them). Still, most of the messages are really pretty good, if you know how to filter for the key words. -- Nathanael Nerode http://home.twcny.rr.com/nerode/neroden/fdl.html
