Re: Publication du Cahier de l'admin Debian Etch
Le lundi 2 mars 2009 19:35:02 Roland Mas, vous avez écrit : Subject: Publication du Cahier de l'admin Debian Etch Erf... Mais je me réjouis de le lire. :) -- Didier Raboud, proud Debian user. CH-1802 Corseaux did...@raboud.com signature.asc Description: This is a digitally signed message part.
Le p'tit nouveau !
Salutation à l'équipe Debian french ;) Suite au message envoyé par Roland Mas, et après avoir visité la page de Raphael, je me suis dit que c'était le moment que je m'inscrive, et que je m'investisse un peu sur le projet Debian. En espérant que je pourrais apporter ma pierre à l'édifice! Donc me voici parmis vous... Maintenant, la question qui tue... Que puis-je faire pour donner un coup de main à l'équipe Debian? Ce n'est pas claire pour moi! Je me permets donc de vous donner quelques infos sur mes compétences, passion, autres, et n'hésitez pas à me rediriger vers un groupe qui pourrait avoir besoin de moi ;) Utilisateur de Debian depuis plusieurs années, je l'utilise en serveur dédié pour faire de l'hébergement (tutoriel pulbié sur developpez.com sur l'installation et la configuration d'un serveur web sous Sarge puis Etch), et au quotidien (bon, j'avoue, je dois réinstaller Lenny sur mon portable, j'étais passé sous Ubuntu... J'ai honte :p). De formation web developpeur, expert PHP/MySQL, je me mets en amateur en développeur Linux. J'ai encore pas mal a apprendre, mais ce sera avec plaisir ;). Donc voila, a vous de me dire si je peux aider en quoi que ce soit, je suis ouvert. Meme si je ne dipose pas d'énormément de temps, c'est avec plaisir que je le mets à disposition de la communauté ;) Olivier -- Tutoriaux + divers infos: http://www.olivierlange.com/
Re: Le p'tit nouveau !
Bonjour, On Mon, 02 Mar 2009, Olivier Lange wrote: Donc me voici parmis vous... Maintenant, la question qui tue... Que puis-je faire pour donner un coup de main à l'équipe Debian? Ce n'est pas claire pour moi! Je me permets donc de vous donner quelques infos sur mes compétences, passion, autres, et n'hésitez pas à me rediriger vers un groupe qui pourrait avoir besoin de moi ;) Je suis content de voir tant d'enthousiasme mais il faut tout de même prendre un peu de temps pour passer en revue les domaines de contribution possibles (que j'ai plus ou moins présenté sur mon blog dans la catégorie contribuer) pour te faire une idée de ce qui peut t'attirer. Utilisateur de Debian depuis plusieurs années, je l'utilise en serveur dédié pour faire de l'hébergement (tutoriel pulbié sur developpez.com sur l'installation et la configuration d'un serveur web sous Sarge puis Etch), et au quotidien (bon, j'avoue, je dois réinstaller Lenny sur mon portable, j'étais passé sous Ubuntu... J'ai honte :p). De formation web developpeur, expert PHP/MySQL, je me mets en amateur en développeur Linux. J'ai encore pas mal a apprendre, mais ce sera avec plaisir ;). En attendant que tu précises un peu ce qui t'intéresse (packaging, infrastructure, traduction, support technique, documentation, marketing, …), je peux te lancer une première idée directement en rapport avec ce que Roland et moi faisons sur Debian. Nous maintenons alioth.debian.org qui est une installation de Gforge, nos utilisateurs nous signalent des problèmes ou des améliorations désirées via le support tracker suivant: http://alioth.debian.org/tracker/?atid=21group_id=1func=browse Nous allons bientôt passer la machine en Lenny et nous allons donc mettre à jour gforge en même temps. Il serait intéressant de faire une passe sur tous les tickets ouverts et de vérifier si le problème est corrigé avec la nouvelle version de Gforge. S'il n'est pas corrigé, ca serait intéressant de proposer un patch, Roland pourra l'intéger chez FusionForge (remplacant de Gforge) et nos utilisateurs seront satisfaits. Gforge/FusionForge est écrit en PHP/Postgresql, donc cela doit être dans ton domaine de compétences. Note: pour les essais, il vaut mieux installer le paquet gforge dans une machine virtuelle parce qu'il touche la config de plein de services. Pour le temps nécessaire, je ne sais pas, mais tu avances au rythme où tu veux, en fonction de ton temps disponible. Cordialement, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-french-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
On Mon, 2009-03-02 at 03:19 +0100, Sylvain Rochet wrote: Package: wnpp Severity: wishlist Owner: Sylvain Rochet grada...@gradator.net * Package name: mydns Version : 1.2.8.26 Upstream Author : Howard Wilkinsin how...@cohtech.com * URL : http://mydns.pl/ * License : GPLv2 Programming Lang: C Description : DNS server using MySQL or PostgreSQL for data storage Free DNS server for UNIX implemented from scratch and designed to utilise the MySQL or PostgreSQL database for data storage. .. Its primary objectives are stability, security, interoperability, and speed, though not necessarily in that order. .. MyDNS does not include recursive name service, nor a resolver library. .. It is primarily designed for organisations with many zones and/or resource records who desire the ability to perform real-time dynamic updates on their DNS data via MySQL or PostgreSQL. What does this have over PowerDNS? William signature.asc Description: This is a digitally signed message part
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
Steve Langasek wrote: On Sat, Feb 28, 2009 at 06:32:45PM +0100, Giacomo Catenazzi wrote: Hmmm. I partially agree, but then we have an unnecessary exception: such virtual packages must have only one provider, or else there will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency is declared as first dependency [1]. From the definition of the virtual package in question, it should have only one provider at a time. And this is an exception, No, it isn't. why not? Section 3.6: : Sometimes, there are several packages which offer more-or-less the same functionality. : In this case, it's useful to define a virtual package whose name describes that common : functionality. This is the rationale and the explanation of virtual package, which explicitly tell us about several package. And MTA is not a special case: we have the same problem with syslog, possibly also with inetd. In past we had IIRC mass bug reports on transition with modutils. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. This unavoidably couples Debian's choice of a default MTA for users who install the new release, to the behavior for users who are upgrading from a previous release, because users who have such a 'default-mta' package installed will find their MTA changed on dist-upgrade. What about an other level of indirection: package debian-mta: Depends: exim | mta-mail-transfer-agent I think this case will solve upgrades, and changing easily the mta (without causing a failed dependency). I believe that would also work, but it seems unnecessarily complex compared to the use of a virtual package. IMO it the contrary: virtual package seems more complex to me. Advantages: - the default is set by an independent maintainer (release, policy, ...) - easier (IMO) for custom distributions But ok, it you think it is simpler with virtual packages, I'm ok also with it. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Sun, Mar 01, 2009 at 08:25:38PM +0100, Carsten Hey wrote: Among the problems we try to deal with the proposed solutions is, as Daniel wrote in 494422e7.2060...@debian.org, that apt (and/or aptitude) take the alphabetically first package which provides foo and installs that to fulfill the relation to the virtual package foo. Knowing this leads to an possible answer to the following question: On Fri, Feb 27, 2009 at 11:03:20AM -0800, Steve Langasek wrote: On Fri, Feb 27, 2009 at 10:37:19AM +0100, Adam Borowski wrote: Assume that in squeeze, the default changes to exim5. With an actual pseudopackage, someone having both lenny and squeeze (or unstable) in apt's sources will have default-mta either from lenny (-exim4) or from squeeze (-exim5). With mere provides: (a virtual package), you'd have a version of both exim4 and exim5 that provides default-mta. And what problem do you believe the latter will cause, in practice? I hope I'm wrong, but I think if apt would try to solve a dependency on the virtual package default-mta provided by exim4 and exim5 it would, according to Daniel's explanation and my own experience, choose to install exim4 in the described case since it is the alphabetically first package *1. On one of my stable desktops I still have oldstable in the sources.list because I tried to isolate a bug using some packages from oldstable, both oldstable and stable are pinned to 500. I obviously don't want to install a mta from oldstable. Sorry, I don't think this is obvious at all, which is why I asked what the practical problems are. You have a case here where the user has managed to run a complete system for a non-negligible period of time without ever installing an MTA (long enough to either configure oldstable in their sources.list, or for the version of Debian they installed to *become* oldstable). Then the user tries to install a package that depends/recommends default-mta | mail-transport-agent, and pulls in a default. Why does the user care if this pulls in the one from oldstable vs. stable? Ok, if the package in question also exists in stable, then installing the oldstable version means the package will be immediately out-of-date and it will have to be upgraded on the next apt-get run. But in terms of an overall policy, if the user hasn't selected an MTA, *and* has configured their sources.list such that multiple packages providing default-mta are available, I don't see any reason that it matters whether the user gets the old default vs. the new default. A default-mta package would to the right thing and install the mta from stable instead of the one from oldstable since real packages work with pinning and have a version number which ensures that the newest version of two equal-pinned packages with the same name is installed. Yes, you're right that a default-mta that Depends: exim4 | m-t-a would address this. So if there's a sense that this is worth addressing, then I'm ok with that. It does somewhat complicate the dependency graph to have a package with numerous reverse-deps adding an or'ed dependency; this could cause some pain to tools that process package dependencies (not just apt - I'm specifically thinking of britney here), and if it did I would come down on the side of using a virtual package and ignoring this case. But that's just speculation at this point. (BTW, I don't believe it was proposed before to use default-mta Depends: exim4 | m-t-a, no.) Using virtual packages for now and hope apt/aptitude handle virtual packages in a better way until exim5 will be the default mta could be one possible course, but what happens when they do not? Mixing virtual and real packages does not sound that good. shrug mixing virtual and real packages happens all the time in the archive. :) Unless I'm wrong and the virtual packages support is a lot better than I think, it looks like main question is whether it is better to use a real default-mta package or wait for apt and aptitude to be improved. I don't agree at all. I don't see anything here that needs to be improved before a virtual default-mta package would be acceptable. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
On Sat, Feb 28, 2009 at 03:12:09PM +0100, Raphael Hertzog wrote: On Sat, 28 Feb 2009, Julien BLACHE wrote: Raphael Hertzog hert...@debian.org wrote: debian/shlibs.local should help for that. Except symbols files have priority over shlibs and there's no symbols.local. I sense a lack of flexibility in this symbols file feature, hmm. shlibs.local was initially a poor solution for a less than ideal dpkg-shlibdeps that couldn't cope with shlibs just produced by the packages being built. Are you sure this was the reason? shlibs.local support was added to dpkg-shlibdeps in 1996, which I think was before either you or I were involved in Debian... You can certainly obtain a similar result nowadays by putting the dependency that you want in debian/control directly and by using the -x option of dpkg-shlibdeps to strip the dependency that you did not want. Except you could *always* do this, and maintainers preferred to be able to use shlibs.local instead. There's a difference between hard-coding the library as a dependency for your package, and saying for any binaries that need lib foo, use lib bar as the dependency. It sounds like you're unilaterally deprecating the shlibs.local feature, in a way that is likely to cause silent breakage for packages currently using it. $ find /srv/lintian.debian.org/laboratory/source -name shlibs.local | wc -l 100 $ -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Le dimanche 01 mars 2009 à 22:25 -0800, Bill Unruh a écrit : The issue is one of the users. They do not give a damn if Schilling is a difficult and arrogant SOB or if the Debian people put principle above all else. They just want good software, which works, not just on the most popular brands but on all brands of CD, DVD, blueray, ... and to be assured that it will keep working. Surely in all of this it is that user that needs to be kept topmost in mind. The only thing for which you’ll need Schily-based software in Debian is for burning CDs. For DVDs and Blu-Rays, we have dvd+rw-tools already. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: xcdroast does no longer work with wodim: Who to blame?
Michelle Konzack wrote: I have over 16 GByte of coredumps: OpenOffice, Iceweasel, mutt, pidgin, FvwmForm, mimedecode, gimp, mc, ... Some are here: http://devel.debian.tamay-dogan.net/coredumps/ and I can not more upload since I am on GSM and ma sped and traffic is limited Use gdb, get a backtrace and upload that. I doubt anybody wants to have the core file. -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Le lundi 02 mars 2009 à 02:56 +0100, Michelle Konzack a écrit : I have over 16 GByte of coredumps: OpenOffice, Iceweasel, mutt, pidgin, FvwmForm, mimedecode, gimp, mc, ... Some are here: http://devel.debian.tamay-dogan.net/coredumps/ and I can not more upload since I am on GSM and ma sped and traffic is limited Are you aware that your core dumps contain private data? Especially, Iceweasel dumps are likely to contain your passwords or your keys. You should never, ever share full core dumps publicly. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
On Sun, 01 Mar 2009, Steve Langasek wrote: shlibs.local was initially a poor solution for a less than ideal dpkg-shlibdeps that couldn't cope with shlibs just produced by the packages being built. Are you sure this was the reason? shlibs.local support was added to dpkg-shlibdeps in 1996, which I think was before either you or I were involved in Debian... Well, the initial reason was that most libraries had no shlibs at all and maintainer put them in shlibs.local until libraries got the required file (I discovered this while doing some archeology once). But after that shlibs.local has mostly been used as work arounds for situations like the above. You can certainly obtain a similar result nowadays by putting the dependency that you want in debian/control directly and by using the -x option of dpkg-shlibdeps to strip the dependency that you did not want. Except you could *always* do this, and maintainers preferred to be able to use shlibs.local instead. No, the -x feature is a recent addition (added in the lenny cycle). There's a difference between hard-coding the library as a dependency for your package, and saying for any binaries that need lib foo, use lib bar as the dependency. Sure but nowadays with binNMUs and NMU there are no good reasons to override the shlib dependency provided by another package (implying that the auto-provided dependency is wrong, but instead of fixing that we prefer to override it in the package). It sounds like you're unilaterally deprecating the shlibs.local feature, in a way that is likely to cause silent breakage for packages currently using it. Well, given that the addition of symbols file can only be intentional in one's package, I never thought it could be a problem (and the order in which dpkg-shlibdeps looks up dependencies is documented). It might be a mistake, in which case we can always adapt the behaviour. But for this, I want to know how they are used and what are the reasonable use cases. It might be that we have other better means to achieve what we want. I have never refused to modify the behaviour of a tool when it makes sense. $ find /srv/lintian.debian.org/laboratory/source -name shlibs.local | wc -l 100 Some other recent discussion on this topic: http://www.mail-archive.com/debian...@lists.debian.org/msg14962.html Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Josselin Mouette wrote: The only thing for which you’ll need Schily-based software in Debian is for burning CDs. For DVDs and Blu-Rays, we have dvd+rw-tools already. What about libburn + cdrskin and similar tools? -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, Mar 02, 2009 at 02:56:19AM +0100, Michelle Konzack wrote: I wish I had at least a STM-1 at home, I would you send you all 300 coredumps since the release weekend of Lenny... Please report bugs in the appropriate forum, e.g. the BTS. debian-devel is not for general complaints. thanks, Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Monday 02 March 2009, Michelle Konzack wrote: Am 2009-03-02 06:23:26, schrieb Goswin von Brederlow: Since everything seems to be dumping core on your system have you thought about the possibility that it might be your system that is at fault? Such a widespread range of coredumps usualy means one of the core libraries is corrupted on your filesystem or you have faulty ram. Or maybe a root-kit that breaks things? Since the release of Lenny, I have installed arround 60 Workstaions, but making tararchives of the original installation and reinstalled Lenny from scratch, using the first binary DVD and the rest over Net. Nearly 80% of all Workstations do not work properly. Maybe you should start to test Debian-Testing from time to time and report bugs if something doesn't work for you? Just complaining *after* a release isn't really helpful. The half of them is without sound (all Creative LABS) 00:13.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 0a) 00:13.1 Input device controller: Creative Labs SB Live! Game Port (rev 0a) What exactly is the problem? Kernel related? If so try a more recent kernel version or an older version and then report a bug. which is needed for telephony. Then I have a couple of Dual-Screen Workstations with the above card... 01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400/G450 (rev 82) xserver-xor-video-mga does not work... Now I use the framebuffer which is working nicely but I do not know the performance differnce between mga and 2fbdev. The mga driver never worked properly without its binary blob if you wanted more then a single vga connection. Don't know what the situation is now, maybe matrox doesn't provide a recent binary for Lenny's xorg version. If you want, go ahead and check yourself on the matrox site. While Fvwm was working fine under Sarge and Etch, no it stoped working correctly. The first time afte 7 years. Again, test yourself before a release and write bugs. You are definitely not an ordinary helpless user, but you make extensive usage of free software. So the least you can do is to write bug reports. Maybe there is a new config option, but curently I have flying windows arround, I mean, news windows are placed in non-expected places. I want my message boxes ans such back in the center if I do not use explicit geometry. But it is going more strange, because my own GTK2+ application are placed correctly like the OpenOffice ones... I have set EWMH to reserve space for my FvwmButton (Panel) and the FvwmTaskbar but they are now ignored... While reading the huge manpages, nothing has changed... Sorry, no idea, I never liked fvwm. I Given that you only have the core-dumps since Lenny I would suspect something got scrambled during the upgrade. Some bit flipped somewhere. I was thinking this too, and have tared the broken installation like the Etch and Sarge ones and reinstalled the WHOLE thing from scratch. The error persists. Go ahead and check your installation with 'debsums'. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Josselin Mouette j...@debian.org wrote: If you don???t publish this email, we will simply not believe you, that???s all. Using majestetis pluralis in this relation seems to be a bit absurd. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Quoting Josselin Mouette j...@debian.org: Le dimanche 01 mars 2009 à 22:25 -0800, Bill Unruh a écrit : The issue is one of the users. They do not give a damn if Schilling is a difficult and arrogant SOB or if the Debian people put principle above all else. They just want good software, which works, not just on the most popular brands but on all brands of CD, DVD, blueray, ... and to be assured that it will keep working. Surely in all of this it is that user that needs to be kept topmost in mind. The only thing for which you’ll need Schily-based software in Debian is for burning CDs. For DVDs and Blu-Rays, we have dvd+rw-tools already. You don't need Schily-based software for burning CDs. Consider cdrskin and xorriso instead. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Requirement for a “proper manpage” for every command
Howdy all, I'm having a conversation with a Debian packager regarding a manpage that, currently, is a mere placeholder saying “please see foocommand --help”, giving none of the useful information normally found in a manpage. I would like the specific package to remain anonymous at the moment (though, of course, a quick search will reveal it), because in this thread I'm only wanting to understand current practice and expectations, not accuse anyone in particular. Debian policy §12.1 states, in part: = 12.1. Manual pages -- […] Each program, utility, and function should have an associated manual page included in the same package. […] If no manual page is available, this is considered as a bug and should be reported to the Debian Bug Tracking System (the maintainer of the package is allowed to write this bug report themselves, if they so desire). Do not close the bug report until a proper man page is available. […] = The response from the maintainer (who is also the upstream author) so far is, essentially, “Patches welcome, but I'm not interested in maintaining manpages”. I have submitted a manpage as a patch. However, that response pretty much guarantees that the maintainer won't be taking the initiative to keep the manpage up to date. Am I right in thinking that it is nevertheless the maintainer's responsibility to do so? I don't like Debian policy being used as a blunt instrument, but I must admit my mental reaction to the maintainer's response was along the lines of “Too bad; in accepting the role of package maintainer, you accepted the ongoing task of maintaining manpages for every command, utility, and function in the package”. Wording and tone aside, is that expectation reasonable? What course of action is open to a user of the package, with a maintainer who has made it plain they're not interested in following (this part of) policy? -- \ “If you're a horse, and someone gets on you, and falls off, and | `\ then gets right back on you, I think you should buck him off | _o__)right away.” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Joerg Schilling wrote: Josselin Mouette j...@debian.org wrote: If you don???t publish this email, we will simply not believe you, that???s all. Using majestetis pluralis in this relation seems to be a bit absurd. Jörg If you don't publish this email, I will not believe you, that's all. -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Possible gnomeicu removal
Hi, I plan to ask the removal of gnomeicu that neither Sebastien or me are using. I saved it for lenny, but I don't think it's worth keeping for Squeeze. Hence I will request its removal in a few days unless someone pops up and adopts it. http://gnomeicu.sourceforge.net http://sourceforge.net/mailarchive/forum.php?forum=gnomeicu-support http://packages.qa.debian.org/gnomeicu It's almost dead upstream and there are better clients for ICQ nowadays. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
Ben Finney ben+deb...@benfinney.id.au writes: I'm having a conversation with a Debian packager regarding a manpage that, currently, is a mere placeholder saying “please see foocommand --help”, giving none of the useful information normally found in a manpage. ... I have submitted a manpage as a patch. However, that response pretty much guarantees that the maintainer won't be taking the initiative to keep the manpage up to date. How about submitting a patch to use help2man instead? http://www.gnu.org/software/help2man/ Then the man page will be kept up to date with --help output. Possibly the document around the man page requirement could point to help2man as a quick solution in case there is useful --help output but no man page. /Simon -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Sun, Mar 01, 2009 at 09:44:41PM -0800, Steve Langasek wrote: You have a case here where the user has managed to run a complete system for a non-negligible period of time without ever installing an MTA (long enough to either configure oldstable in their sources.list, or for the version of Debian they installed to *become* oldstable). Then the user tries to install a package that depends/recommends default-mta | mail-transport-agent, and pulls in a default. Why does the user care if this pulls in the one from oldstable vs. stable? (Imagine that we did this default-mta-foo years ago) He or she cares because the security support of exim will stop in less than a year and exim4 is a much more sane default than exim, especially for users who don't explicitly install their favorite mta since exim has an ugly pre-debconf initial configuration system. Also remember, that there is no upgrade path from exim to exim4 (release notes do not count here since the user read them months ago when he or she did the dist-upgrade and no one can expect that users remember every side note in them during the whole release cycle) and that the user can expect to to able to remove the old souces.list entry without bad things like no security support for their mta happening (he or she did already do a dist-upgrade with the release notes in mind). I'm not sure if there are many users who put oldstable and stable during an dist-upgrade in their sources.list, but these are also affected by this when a package they use changed its dependency during the last release cycle to include mta or APT::Install-Recommends is set to yes. Ok, if the package in question also exists in stable, then installing the oldstable version means the package will be immediately out-of-date and it will have to be upgraded on the next apt-get run. I think in this case apt would directly install the exim package in stable, i.e. a transitional package (which does not exist for exim). It does somewhat complicate the dependency graph to have a package with numerous reverse-deps adding an or'ed dependency; this could cause some pain to tools that process package dependencies (not just apt - I'm specifically thinking of britney here), using a virtual package and ignoring this case. But that's just speculation at this point. I have no idea whether britney would handle virtual or real default-mta packages in a better way, ftpmaster should be able to answer this if it really matters. Deborphan for example currently handles virtual packages in a suboptimal way (although no false positives are caused by them) but this can be fixed. Maybe one could think about a release goal handle virtual packages in a sane way? Regards Carsten -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Making some tags mandatory
On Fri, 27 Feb 2009, Enrico Zini wrote: The way I see it, the last thread on sections has opened a bit of a can of worms: now first everyone will want a section for their favourite topic, then there is going to be a fight on which one to pick in case packages that could belong to more than one section. Been there, done that :) If you just open this can of worms which is basically about categorizing Debian packages I might throw the method which was invented by Debian Pure Blends effort into it as well. The rationale behind this is that my plan is to find a closer connection between tasks and debtags. For those who have no idea about those tasks you might like to have a look for example at the tasks page of Debian Science[1]. The reason why I rise this issue here is that the following discussion quite regularly pops up: Does package x belong to category A or B. This question is an issue for the section we put some packages into - it is not for DebTags (if I understand debtags correctly this was one of the main reasons to invent it) and it is also not true for tasks because package x can be useful in more than one task and so it can be added to the according task file. For instance the question whether the package octave is a package in the field of mathematics or physics or numericalcomputation just makes no sense. The question is rather: Does a mathematician need octave? Does a physicis need octave? etc. So I would like to bring back the issue of categorisation from a sophisticated scientific discussion about the right category for a package to the user oriented view: I want to solve a certain task - just install all packages which might be useful for this task and please do not force me to understand your complex categorisation scheme (how well thought it might be). There are just different points of view: From a distributors point of view it makes sense to put packages into different sections to give some structure to the archive. From a users point of view these sections sometimes do not make much sense and he has to seek for packages in unexpected sections. Blends try to follow the user oriented view and ask users what package they would like to install to solve a certain task. So far for the theory. I would like to make you think about other use cases of user oriented categorisation in the sense above. For instance I could think about fields like accessibility oriented packages, packages regarding forensics, etc. Just think about whether it would be interesting for users who need a quick overview about the available packages for a certain task (well, in Blends we stretch the system in the tasks pages even further to packages which could be included in the future for some tasks). If the concept works out as promising or successful I plan further integration with DebTags (for instance including DebTagged packages if missing on the tasks pages, adapting DebTags to the available tasks etc.). Kind regards Andreas. [1] http://blends.alioth.debian.org/science/tasks/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Bill Unruh un...@physics.ubc.ca writes: On Mon, 2 Mar 2009, Goswin von Brederlow wrote: Memnon Anon gegendosenflei...@gmail.com writes: But, on the other hand, please do not try to stress that the debian fork is as good as Schillings. It is not necessary, the non-free argument is enough! ACK. At this point the quality of the original and fork are completly irrelevant and I hope more people do see that. In Debians eyes the No they are NOT irrelevant. For the users, that is the key. And surely it is the users ( the customers) who should be the prime consideration. I agree that legal issues are a concern, but they are almost always something that can be worked through. What I'm getting at is that they MUST be worked through before any choice can be made which side to keep. At the moment the only choice for Debian is to use the fork. The original is legally not an option no matter how much user would like to have it (if they do, I don't). The better quality of the original might be an incentive to work through the legal stuff but you have to work through it before you can even think about replacng the fork with it again. original is just undistributable and therefore the fork is the only option, no matter how bad it is (and it works for me [tm]). Ah yes. I works for me, the hell with anyone else. That's not what I'm saying. I just wanted to relativate the no matter how bad it is because I don't see any of the suposed problems and none have been reported in the BTS. To all the maintainers of the fork: I sincerely beg your pardon, if my impression is just wrong, and I really consider every work for debian important. This is my impression, and as this thread more and more circles around bugs in wodim etc., especially, since a posting, stating that wodim does _not_ work for everyone as fine, gets the You sent no bugreport answer (which is true!, but imho reflects the experience of a lot of people out there) , I wanted to share my impression. I think the You sent no bugreport answere reflects some frustration of the authors of the fork. It is verry frustrating to be torn down for how bad the fork is without being given any hint in what way and how it could be fixed. Sorry, that is how it works. He has reported a bug. Here. If what he says is right, namely it does not work with SCSI it is a bug which should have been caught before it ever went out the door Will you buy the maintainer all kinds of scsi burners so they can test each? I myself and several others have used debians cdrecord with scsi just fine so the bug must be some quirk of that specific config. You can never forsee all those quirks. As such dear authors keep your spirits high. Your efforts are highly valued and not wasted. Well, really they are. There is this piece of software which does everything they want it to do, and they are tinkering with an old version of that same software, trying to keep up, and not really wanting to do so. This whole thing would be a farce if it were not a tragedy. Maybe it is impossible to bring Schilling and Debian together. Sometimes tragedies do occur, but that is where the efforts should go. And here we have to disagree. I don't see Schilling moving one iota from his position and trying to compromise with someone so set in stone is just wasted. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: CC Attribution ShareALike (CC-by-sa) 3.0
Holger Levsen holger at layer-acht.org writes: On Freitag, 27. Februar 2009, Cyril Brulebois wrote: ISTR (some of) -legal@ saying not DFSG-compliant, some people on -legal will always disagree, what counts more is the (rough) consenus... Sure, but I thought we had an explicit consensus on discrimination against fields of endeavour, which is seen in CC-By 3.0 4.a about effective technological measures. Happily, that's only a lawyerbomb (in that no-one, even within CC, seemed to agree what it means for debian - is offering source code enough to satisfy it?) and not a current live problem. Beware some of the ported CCs which include the trademark notice by mistake and produced a licence which failed to follow DFSG - and some were incompatible with other CC licences. Hope that helps, -- MJ Ray My Opinion Only, see http://people.debian.org/~mjr/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517852: ITP: libtest-www-mechanize-catalyst-perl -- Test::WWW::Mechanize for Catalyst
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyżaniak (eloy) e...@debian.org * Package name: libtest-www-mechanize-catalyst-perl Version : 0.50 Upstream Author : Ash Berlin a...@cpan.org (current maintiner) * URL : http://search.cpan.org/dist/Test-WWW-Mechanize-Catalyst/ * License : Artistic/GPL Programming Lang: Perl Description : Test::WWW::Mechanize for Catalyst Catalyst is an elegant MVC Web Application Framework. Test::WWW::Mechanize is a subclass of WWW::Mechanize that incorporates features for web application testing. The Test::WWW::Mechanize::Catalyst module meshes the two to allow easy testing of Catalyst applications without starting up a web server. . Testing web applications has always been a bit tricky, normally starting a web server for your application and making real HTTP requests to it. Test::WWW::Mechanize::Catalyst allows you to test Catalyst web applications but does not start a server or issue HTTP requests. Instead, it passes the HTTP request object directly to Catalyst. Thus you do not need to use a real hostname: http://localhost/; will do. However, this is optional. The following two lines of code do exactly the same thing: Now when stable release is out it's time for cleaning some stuffs in Catalyst packages. This package is beginning of libcatalyst-modules-perl cleaning. libcatalyst-modules-perl will contain only packages from Catalyst:: namespace which are actively developed. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Sun, 1 Mar 2009, Russ Allbery wrote: Bill Unruh un...@physics.ubc.ca writes: The license issue is problematic, especially since copyright laws differ in different countries. Derivative works is an especially tricky concept since it is so poorly defined in law, and the courts have been all over the place on it. It would be really really nice if Debian released Moglin's opinion that they received re the cdrtools issue and Schilling released his, and Moglin allowed them to do so. I believe that the relevant legal opinion was given to Ubuntu, not to Debian. I do not believe that Moglin gave a separate legal opinion to Schilling, in private e-mail or anywhere else. So Ubuntu shared it with Debian. In that case I see no obstacle to making it public. It has already been shared and copied to people not the original recipients. I assume the Debian people actually saw it before making their decision. On the license issue, all sides are to a large extent on the same page. Schilling has released his stuff with an open source license (CDDL is certainly that), and the requirement of the GPL that both the source code AND the build system be and remain available to future users is guarenteed. At that point, the fact that the two sides cannot step over the final tiny hurdles is a real shame. You appear to be completely unfamiliar with the licensing issues involved, or any of the other past history that went into this fork. All issues look simple, resolvable, and unfortunate if you ignore 90% of the problem. Yup. That is the way settlements are reached, by ignoring 90% of the problem, since 90% is usually the fraction that is actually completely irrelevant to the dispute-- personal feeling, history, I really do not give a damn about the history of this dispute. I am a user, and I want top class software in my distros. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
Hi, On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote: What does this have over PowerDNS? Probably nothing, else that I am using it and packaging it for my own and thought that it would be a good idea to contribute to Debian, is redundancy a problem ? Sylvain signature.asc Description: Digital signature
Re: Making some tags mandatory
On Sun, Mar 01, 2009 at 03:59:46PM +0100, Carsten Hey wrote: On Sun, Mar 01, 2009 at 01:01:49PM +, Ben Hutchings wrote: On Sun, 2009-03-01 at 02:42 +0100, Carsten Hey wrote: Deborphan needs a way to detect shared libraries ... [...] There is already a role::plugin which should apply to PAM modules. role::plugin seems to fit. How do we ensure that all PAM, Apache, Roxen modules, all DSPAM backends and so on must be tagged role::plugin? Is there some kind of debtag policy where such things can be specified? At the moment there is no way to ensure it; the point of the proposal that I sent Cc-ed to debian-dak is precisely to make at least some debtags tags official enough to expect DDs to use them properly. That will probably have as a side effect the need to clarify several corner cases and formalize and document better the way in which those official tags should be used. The idea, however, would be to have a tag whose point is shared libraries pulled in as dependencies: package managers can safely hide these. deborphan can use that, and it can be formalized by adding deborphan will uninstall these packages if no other package depends on it. role::app-data is probably also something that deborphan can deal with. The reason I haven't pushed for such changes yet, is because I don't have a way to specially control the workflow of tags that need it: once a tool depends on a tag for some important choice, a different workflow is needed where changes to that tag need to be checked more carefully. I am planning a redesign of the Debtags web interface to introduce the possibility of such special workflows (see http://lists.alioth.debian.org/pipermail/debtags-devel/2009-February/001935.html) and the proposal that I just posted to -devel also has the effect to provide special workflow for some tags so that we can rely on them more. sepecial::safely-removable or the existing special::auto-inst-parts. The latter is currently only partly useful for deborphan since only very few libraries are marked with this tag: [...] Are there any plans to either tag all safely removable shared libraries with special::auto-inst-parts or remove this tag from the ones that already got it? Yes, that tag is neglected, and should disappear: the idea is that 'safely removable' packages are already quite identifiable by 'role' tags, and there is no need to repeat that information. It's there until someone feels like reviewing all packages tagged with it and seeing if they indeed all fit in role::shared-lib and role::app-data or if there are other corner cases in significant number worth of special attention. I guess all tags will be included in /var/lib/dpkg/status before sections will be removed from Debian, is this correct? All implementation details have to be decided. By gut feeling I would not bet on 'status', but I would assume that at least 'apt-cache dumpavail' will give you the tags. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature
Re: Making some tags mandatory
On Sun, Mar 01, 2009 at 09:18:05AM +1100, Ben Finney wrote: I don't know the mechanism by which ‘foofacet::TODO’ triggers creation of a new tag, but the meaning is clearer at least. There is currently no such trigger, but it's easy to produce[1] a package list for such a tag and check if there are patterns emerging. Also, once a new tag gets proposed in a facet, listing the *::TODO packages in that facet is a good way to find packages that might need that tag. I've long wanted to have a view in the Debtags website to examine the state of *:TODO packages for a given facet. It's not very... enjoyable to build that with the current backend, so it's yet another thing that I've postponed until I redesign the website. Ciao, Enrico [1] wget wget http://debtags.alioth.debian.org/tags/tags-current.gz zcat tags-current.gz | tagcoll -i grep role::TODO | sort -u -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, Goswin von Brederlow wrote: Bill Unruh un...@physics.ubc.ca writes: On Mon, 2 Mar 2009, Goswin von Brederlow wrote: ... No they are NOT irrelevant. For the users, that is the key. And surely it is the users ( the customers) who should be the prime consideration. I agree that legal issues are a concern, but they are almost always something that can be worked through. What I'm getting at is that they MUST be worked through before any choice can be made which side to keep. At the moment the only choice for Debian is to use the fork. The original is legally not an option no matter how much user would like to have it (if they do, I don't). The better quality of the original might be an incentive to work through the legal stuff but you have to work through it before you can even think about replacng the fork with it again. Agreed, both sides have to come to the conclusion that they are operating legally. On the plus side, Schilling would like to have his software distributed in the distros. He is also strongly of the opinion that there is no legal impediment to that happening. Debian is of the opinion that there IS an impediment. It is not that Schilling recognizes the impediment and refuses to clear it, it is that he does not believe that there is one. Thus both sides are to a large extent on the same page (wanting to distribute and to do so without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. (Note that the chances of any legal action being taken by anyone with respect to cdrtools is miniscule. So it is not fear that stands in the way, but a legal quibble. original is just undistributable and therefore the fork is the only option, no matter how bad it is (and it works for me [tm]). Sorry, that is how it works. He has reported a bug. Here. If what he says is right, namely it does not work with SCSI it is a bug which should have been caught before it ever went out the door Will you buy the maintainer all kinds of scsi burners so they can test each? I myself and several others have used debians cdrecord with scsi just fine so the bug must be some quirk of that specific config. You can never forsee all those quirks. Look I never said that maintaining is easy. It is not. And Schilling has proven himself willing to do it, to buy all kinds of scsi burners or get ahold of them, and make it work. That is worth a HUGE amount. As such dear authors keep your spirits high. Your efforts are highly valued and not wasted. Well, really they are. There is this piece of software which does everything they want it to do, and they are tinkering with an old version of that same software, trying to keep up, and not really wanting to do so. This whole thing would be a farce if it were not a tragedy. Maybe it is impossible to bring Schilling and Debian together. Sometimes tragedies do occur, but that is where the efforts should go. And here we have to disagree. I don't see Schilling moving one iota from his position and trying to compromise with someone so set in stone is just wasted. Well, I think there is the problem. This has come down to personal issues, not legal or technical. Everyone is so dug into their positions that they simply spend time lobbing grenades at each other, rather then trying to work through the problem. Yes, Schilling is difficult but by now, so is Debian. The amount of childish vituperation that has been seen in this discussion mostly but not all coming from the Debian side is pretty disgusting. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517882: RFP: clam-networkeditor -- CLAM Network Editor, prototyping tool for CLAM
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: clam-networkeditor Version : 1.4.0~svn Upstream Author : CLAM Team c...@iua.upf.edu * URL : http://clam.iua.upf.edu * License : GPL Programming Lang: C++ Description : CLAM Network Editor, prototyping tool for CLAM The CLAM Network Editor is a tool for editing CLAM processing networks. Those processing networks can become the processing core of an audio application by using the CLAM::NetworkPlayer class in such program, or by using the CLAM Prototyper to link the network to a Qt Designer interface. This packages provides both the Network Editor and the Prototyper. It also provides a plugin for Qt Designer which adds widgets to display several kinds of CLAM audio objects from a running network. Unofficial Debian Packages are available at upstream. This depends on 'clam' (bug #493282). -- David García Garzón (Work) dgarcia at iua dot upf anotherdot es http://www.iua.upf.edu/~dgarcia -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Monday 02 March 2009 19:59:00 Bill Unruh wrote: --cut-- Agreed, both sides have to come to the conclusion that they are operating legally. On the plus side, Schilling would like to have his software distributed in the distros. He is also strongly of the opinion that there is no legal impediment to that happening. Debian is of the opinion that there IS an impediment. It is not that Schilling recognizes the impediment and refuses to clear it, it is that he does not believe that there is one. Obviously Schilling is not Debian, so the distributor's rules apply... and Debian is not alone in that a decision. Thus both sides are to a large extent on the same page (wanting to distribute and to do so without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. (Note that the chances of any legal action being taken by anyone with respect to cdrtools is miniscule. So it is not fear that stands in the way, but a legal quibble. I see only one way out: talk to Schilling to revert that GPL+CDDL license mixture, and it is all done, and it is cheap and easy. original is just undistributable and therefore the fork is the only option, no matter how bad it is (and it works for me [tm]). Sorry, that is how it works. He has reported a bug. Here. If what he says is right, namely it does not work with SCSI it is a bug which should have been caught before it ever went out the door Will you buy the maintainer all kinds of scsi burners so they can test each? I myself and several others have used debians cdrecord with scsi just fine so the bug must be some quirk of that specific config. You can never forsee all those quirks. Look I never said that maintaining is easy. It is not. And Schilling has proven himself willing to do it, to buy all kinds of scsi burners or get ahold of them, and make it work. That is worth a HUGE amount. Very nice, but do you really believe it? Don't answer me ;-) As such dear authors keep your spirits high. Your efforts are highly valued and not wasted. Well, really they are. There is this piece of software which does everything they want it to do, and they are tinkering with an old version of that same software, trying to keep up, and not really wanting to do so. This whole thing would be a farce if it were not a tragedy. Maybe it is impossible to bring Schilling and Debian together. Sometimes tragedies do occur, but that is where the efforts should go. And here we have to disagree. I don't see Schilling moving one iota from his position and trying to compromise with someone so set in stone is just wasted. Well, I think there is the problem. This has come down to personal issues, not legal or technical. Everyone is so dug into their positions that they simply spend time lobbing grenades at each other, rather then trying to work through the problem. Yes, Schilling is difficult but by now, so is Debian. I don't think that Debian is treating cdrtoos in any specific way, just normal rules apply as usual. And quite frankly I don't see any good reasons why Debian should compromise its principles in the name of cdrtools licensing games. And it is not that there are no good alternatives like dvd+rw-tools, cdrskin, xorriso, xfburn, and finally decent libs like libburn, libisofs, libisoburn so that anyone can benefit from; but I'm not going to beg you using them like Schilling does. For me, cdrtools turn to be the mostly useless pile of bits for the last three years, and it is no more interesting for me whether Schilling is wrong or rigth, but that is me. As we all know, monopoli is not so much a funny game when it is over, and I really wonder why this thread is still alive. -- pub 4096R/0E4BD0AB 2003-03-18 people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Sun, Mar 01 2009, Carsten Hey wrote: On Sun, Mar 01, 2009 at 04:55:23PM +0100, Andreas Metzler wrote: We could have a exim4 upload implementing in sid this rather quickly after receiving a go. In general I much prefer a virtual package over a real one but I think we should wait a bit until the following issues are clarified: On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote: [1] policy 7.5 has only a note: | If you want to specify which of a set of real packages should be the | default to satisfy a particular dependency on a virtual package, you | should list the real package as an alternative before the virtual | one. In my opinion it is a way better practise to first update the policy and then adapt n packages instead of first change them in a way which is possibly against the policy and expect the policy to be updated accordingly. Actually, this is contrary to the accepted practice that policy is not the place to do design; and that you should have a working, tested solution (by convincing and getting a the maintainers of affected packages to implement the solution); _then_ you write that in stone. While there might not be much to design here in this particular case, you can't call on better practice, since policy has never worked that way. RFC 2119 says: | 3. SHOULD This word, or the adjective RECOMMENDED, mean that there | may exist valid reasons in particular circumstances to ignore | a particular item, but the full implications must be understood and | carefully weighed before choosing a different course. The policy uses should in this case, do we understand the full implications of the proposed step carefully weighed before choosing a different course? We are probably on a good way to do this but until now at least I do not fully understand how apt and aptitude would handle all proposed solutions and what all possible negative side effects are. Policy's use of should has little to do with the RFC 2119; indeed, it would need an almost full rewrite to make sure policy starts using RFC 2119 version of SHOULD/MUST. manoj starting to look at policy again -- Take that, you hostile sons-of-bitches! James Coburn, in the finale of _The_President's_Analyst_ Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “pro per manpage” for every command
Simon Josefsson dijo [Mon, Mar 02, 2009 at 11:22:52AM +0100]: How about submitting a patch to use help2man instead? http://www.gnu.org/software/help2man/ Then the man page will be kept up to date with --help output. Possibly the document around the man page requirement could point to help2man as a quick solution in case there is useful --help output but no man page. Hmh, this could even be promoted as a best packaging practice. Many authors do ship properly-formatted --help entries, and our hand-generated manpages can often linger behind the truth. Any strong opinions against? -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Bill Unruh un...@physics.ubc.ca writes: On Sun, 1 Mar 2009, Russ Allbery wrote: Bill Unruh un...@physics.ubc.ca writes: The license issue is problematic, especially since copyright laws differ in different countries. Derivative works is an especially tricky concept since it is so poorly defined in law, and the courts have been all over the place on it. It would be really really nice if Debian released Moglin's opinion that they received re the cdrtools issue and Schilling released his, and Moglin allowed them to do so. I believe that the relevant legal opinion was given to Ubuntu, not to Debian. I do not believe that Moglin gave a separate legal opinion to Schilling, in private e-mail or anywhere else. So Ubuntu shared it with Debian. In that case I see no obstacle to making it public. It has already been shared and copied to people not the original recipients. I assume the Debian people actually saw it before making their decision. Unless you're a copyright lawyer and want to see the opinion so that you can render an informed legal judgement based on your own expertise, I don't see how this accomplishes anything beyond allowing Schilling to waste even more of the (valuable and, in this economy, endangered) time of the SFLC. This is also simply not how lawyers work in the United States; they do not and cannot offer general legal opinions to amorphous clouds of people. They offer context-dependent and situation-dependent legal advice to their clients and discuss those opinions only with their clients. Pasting bits of e-mail messages and the like into a public forum for public debate doesn't add any additional clarity to the legal situation. It just provides an opportunity for lots of ill-informed non-lawyers who think they can read the law to nitpick the situation to death. Of course, I also am not that horribly concerned with the details of the legal judgement, since I believe Debian should not distribute Schilling's software regardless of its legality. I don't believe Debian should package and distribute software with openly hostile upstreams. Debian is a volunteer effort and working on Debian should be fun; having people abuse you in public fora and threaten legal action whenever you do something they don't like isn't fun. To me, this is considerably more important than the relevant technical merits of different applications; among other things, in my experience on open source software, the friendlier project will become technically better in the long run anyway. But even if it doesn't, I see no reason why anyone in Debian should volunteer to put up with this sort of ongoing abuse and threats. If Red Hat wants to pay someone to put up with it, that's their call; it's a lot easier to be polite in the face of an unending stream of personal abuse if you're getting a paycheck for doing it. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “pro per manpage” for every command
On Mon, Mar 02, 2009 at 11:22:52AM +0100, Simon Josefsson wrote: How about submitting a patch to use help2man instead? http://www.gnu.org/software/help2man/ Then the man page will be kept up to date with --help output. help2man is a fine starting point for a manpage, but unless the help messages are very verbose, it is not sufficient. A manpage needs to explain all the possibilities and interactions between different options that are usually not provided by --help output. An excellent example is gpg(1). help2man could provide a very basic starting point, but the resulting manpage would be woefully incomplete. Possibly the document around the man page requirement could point to help2man as a quick solution in case there is useful --help output but no man page. My concern is that people will solely use help2man instead of providing a real manpage. Debian requires manpages for a reason: to provide adequate documentation on how to use installed programs. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only troff on top of XML: http://crustytoothpaste.ath.cx/~bmc/code/thwack OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: Requirement for a “pro per manpage” for every command
* brian m. carlson [Mon, 02 Mar 2009 19:45:22 +]: help2man is a fine starting point for a manpage, but unless the help messages are very verbose, it is not sufficient. A manpage needs to explain all the possibilities and interactions between different options that are usually not provided by --help output. An excellent example is gpg(1). help2man could provide a very basic starting point, but the resulting manpage would be woefully incomplete. This is true. Possibly the document around the man page requirement could point to help2man as a quick solution in case there is useful --help output but no man page. My concern is that people will solely use help2man instead of providing a real manpage. Debian requires manpages for a reason: to provide adequate documentation on how to use installed programs. Many times the problem is that upstreams do provide such adequate documentation... in other formats than man pages. What should the packager do in that case? Create a dummy man page pointing out to eg. /usr/share/doc/foopkg/html/fooprog.html? Copy over the contents of fooprog.html to fooprog.1? Other? -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Ana Torroja - Les Murs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
At Mon, 2 Mar 2009 13:29:06 -0600, Gunnar Wolf wrote: Hmh, this could even be promoted as a best packaging practice. Many authors do ship properly-formatted --help entries, and our hand-generated manpages can often linger behind the truth. Any strong opinions against? Not to rehash an old wontfix :-), but since you ask... Only a minor comment, that help2man could be a bit more flexible about e.g. accepting input on stderr. See the discussion on #138752. I'm not sure how many packages fail to follow the GNU standards document in terms of how they print their help output, but it seems like a potential source of irritation. Of course, if I'm missing something about Debian policy, consider me shushed. d -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Proposal to improve package configuration upgrades
On Thu, Feb 26 2009, Harald Braumann wrote: But there are 3 possible situations here: 1. value has been changed between the last and the new maintainer version 2. value was modified locally 3. both of the above Well, a complete analysis of the situations ucf faces are at [0] and [1], and that discusses more initial states than 3 (the local file removed by user offers an interesting set of states). [2] is an essay into functional programming for ucf, but I wonder about the practicality. manoj 0: http://www.golden-gryphon.com/blog/manoj/blog/2009/02/24/Rethinking_ucf/ 1: http://www.golden-gryphon.com/blog/manoj/blog/2009/03/01/Rethinking_ucf_redux/ 2: http://www.golden-gryphon.com/blog/manoj/miscellaneous/functional_ucf/ -- Sex is hereditary. If your parents never had it, chances are you wont either. Joseph Fischer Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, Mar 02 2009, Bill Unruh wrote: Agreed, both sides have to come to the conclusion that they are operating legally. On the plus side, Schilling would like to have his software distributed in the distros. He is also strongly of the opinion that there is no legal impediment to that happening. Debian is of the opinion that there IS an impediment. It is not that Schilling recognizes the impediment and refuses to clear it, it is that he does not believe that there is one. Thus both sides are to a large extent on the same page (wanting to distribute and to do so without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. That assumes a priori that Debian's position is wrong, and that there is no legal impediments to distributing upstream cdtools. How about countenancing the view that there could actually be a legal issue, as Debian thinks there is? An attempt at mediation that starts from such a biased stance is unlikely to succeed. manoj -- At no time is freedom of speech more precious than when a man hits his thumb with a hammer. -- Marshall Lumsden Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
On Mon, Mar 02 2009, Adeodato Simó wrote: Many times the problem is that upstreams do provide such adequate documentation... in other formats than man pages. What should the packager do in that case? Create a dummy man page pointing out to eg. /usr/share/doc/foopkg/html/fooprog.html? Copy over the contents of fooprog.html to fooprog.1? Other? What I have done in the past is to create a good, current man page with the contents of the upstream provided manual, and add in a caveat that the primary documentation lies elsewhere, and ask users to refer to it for completeness. I submitted the man page upstream (and have had some upstreams reject it). Then, every few revisions, I would resync the man page. I consider this just one of the things that Debian maintainedrs ought to do -- I mean, we are not just glorified packagers. manoj -- Parkinson's Fifth Law: If there is a way to delay in important decision, the good bureaucracy, public or private, will find it. Manoj Srivastava sriva...@debian.org http://www.debian.org/~srivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517906: O: uucp - unix to unix copy
Package: wnpp Severity: normal Hi, I'm orphaning uucp, the unix to unix copy program. I haven't had a UUCP setup it in a few years now, and I therefore haven't had any chance to ensure stuff is continuing to work. Apparently something in lenny broke in.uucpd (see #517726). I should have noticed this but I didn't. If somebody still uses UUCP it would be great if they could take care of it from now on. It isn't exactly a fast moving target, but as this instance has shown it helps if you actually use it from day to day (tho that probably isn't a hard requirement). Cheers, weasel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Bill Unruh un...@physics.ubc.ca wrote: Agreed, both sides have to come to the conclusion that they are operating legally. On the plus side, Schilling would like to have his software distributed in the distros. He is also strongly of the opinion that there is no legal impediment to that happening. Debian is of the opinion that there IS an impediment. It is not that Schilling recognizes the impediment and refuses to clear it, it is that he does not believe that there is one. Thus both sides Well several lawyers have been asked for legal advise. The Sun legal department did a full legal review of the cdrtools source bewteen August 2008 and October 2008. No problem was found. A German lawyer who is specialized on OpenSOurce hast been asked and he also does not see a problem. Eben Moglen has been asked and he also did see no problem. Note that any laywer as a first reply confirms that the claim from the former Debian package maintainer Eduard Bloch who initiated the attacks against me and my software in May 2004 is complete nonsense. There is of course no problem to use a CDDL licensed build system to compile a GPLd project. For the rest of claims seen in the net, it is important to understand that you need to find a single interpratation of the GPL that is not in conflict with - The Copyright - The OpenSource definition http://www.opensource.org/docs/osd - and that does not make OSS distributions illegal All theories from people who claim that there is a problem with the original cdrtools I did see, are either in conflict with the Copyright law, would make the GPL a clearly nonfree license acording to http://www.opensource.org/docs/osd or would disallow to distribute e.g. Linux together with X. The GPL is a work based license (see Copyright law http://www.gesetze-im-internet.de/urhg/index.html) and with a single exception, the rules of the GPL end at the work limit. The single exception is that if you combine a GPLd work with an independent work under a different license, you need to distribute complete source in case you distribute binaries. If you did try to disallow GPLd programs to link against independent non-GPL libraries, you would make _any_ GPLd program undistributable in binary form. without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. (Note that the chances of any legal action being taken by anyone with respect to cdrtools is miniscule. So it is not fear that stands in the way, but a legal quibble. There is a high risk that people, who are involved with distributing the fork, will be sued. There is no risk to distribute the original software. Will you buy the maintainer all kinds of scsi burners so they can test each? I myself and several others have used debians cdrecord with scsi just fine so the bug must be some quirk of that specific config. You can never forsee all those quirks. Look I never said that maintaining is easy. It is not. And Schilling has proven himself willing to do it, to buy all kinds of scsi burners or get ahold of them, and make it work. That is worth a HUGE amount. Let me add that Debian did verify that nobody is willing and able to fix the bugs in wodim or genisoimage. And here we have to disagree. I don't see Schilling moving one iota from his position and trying to compromise with someone so set in stone is just wasted. Well, I think there is the problem. This has come down to personal issues, not legal or technical. Everyone is so dug into their positions that they simply spend time lobbing grenades at each other, rather then trying to work through the problem. Yes, Schilling is difficult but by now, so is Debian. The amount of childish vituperation that has been seen in this discussion mostly but not all coming from the Debian side is pretty disgusting. The whole dispute has been initated by a former Debian package maintainer named Eduard Bloch. This person created a lot of FUD and personal offense under the name Debian, he stopped all activitied on the fork on May 6th 2007 and sice then advtertizes for nerolinux. The incorrect clains against me and my software intruduced by Eduard Bloch are still distributed by Debian. The current state of Eduard Bloch at Debian is suspended. Isn't the party that initiated the dispute responsible for apologizing for creating the dispute? In any case, the original cdrtools is perfectly free software - cdrecord is 100% CDDL - cdda2wav is 100% CDDL and uses an independent library under LGPL - readcd is 100% CDDL - rscsi is 100% CDDK - scgcheck is 100% CDDL - scgskeleton is 100% CDDL - mkisofs is 100% GPL and uses independent libraries under CDDL It is obvious that the people who are responsible for the fact that Debian distributes wodim instead of cdrecord are not interested in legal facts as cdrecord is 100% CDDL. It has
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, Bernd Schubert bernd.schub...@fastmail.fm wrote: Since the release of Lenny, I have installed arround 60 Workstaions, but making tararchives of the original installation and reinstalled Lenny from scratch, using the first binary DVD and the rest over Net. Nearly 80% of all Workstations do not work properly. Maybe you should start to test Debian-Testing from time to time and report bugs if something doesn't work for you? Just complaining *after* a release isn't really helpful. Bernd, I (with my DD or upstream developer hat on) understand your sentiment. But I also (with my consultant or end-user hat on) find it impossible to implement. If I was running a large scale IT environment (say 1000+ users) then I would assign an increasing portion of the help-desk people to run testing as the release became closer and I would allow some of the user-base to run testing when the release was really close. Then after the release I would slowly increase the number of people running the new release so that bugs could be identified and fixed. If a bug hit the 1% of the user-base who were most adventurous and demanding of new versions then it wouldn't be so bad. But however I'm not running a large IT environment and I don't have the resources for such things. Sometimes I do the upgrade after the release and just have to deal with some bugs. That said my results from upgrading to Lenny have been a lot more positive than Michelle reported. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Le lundi 02 mars 2009 à 09:59 -0800, Bill Unruh a écrit : without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. What you mean is: “Both sides should agree that Jörg Schilling is right”. How do you expect anyone else than Schilling himself to buy that? (Note that the chances of any legal action being taken by anyone with respect to cdrtools is miniscule. So it is not fear that stands in the way, but a legal quibble. Jörg Schilling has repeatedly threatened to take legal action, and this is precisely the reason that led to renaming cdrtools to cdrkit. Actually, even if we were to switch back to cdrtools as upstream source, we would still be distributing it under the cdrkit name, otherwise we couldn’t patch it without calling for Lord Schilling’s wrath. Well, I think there is the problem. This has come down to personal issues, not legal or technical. Everyone is so dug into their positions that they simply spend time lobbing grenades at each other, rather then trying to work through the problem. Yes, Schilling is difficult but by now, so is Debian. The amount of childish vituperation that has been seen in this discussion mostly but not all coming from the Debian side is pretty disgusting. I think the Debian members have all been pretty clear on what is asked to work with the project. Some of us are used to deal with upstream developers behaving like assholes, so that is not the problem. The problem is that we cannot distribute cdrecord binaries. Full stop. End of story. Bye bye. The same goes for Gentoo. For Fedora. For OpenSUSE, Mandriva and Ubuntu. Man, so many “difficult” distributors, all refusing to cooperate, and distributing cdrkit instead! Disgusting. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
On Mon, Mar 02, 2009 at 04:42:19PM +0100, Sylvain Rochet wrote: Hi, On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote: What does this have over PowerDNS? Probably nothing, else that I am using it and packaging it for my own and thought that it would be a good idea to contribute to Debian, is redundancy a problem ? Even if you're a perfectly responsible maintainer, a new package still requires some work by ftpmaster, the release team, possibly the security team, and so on. It also increases the number of options a user has to choose between. If the package is redundant, this is a waste of their time. Ben. -- Ben Hutchings Logic doesn't apply to the real world. - Marvin Minsky -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, 3 Mar 2009, Russ Allbery r...@debian.org wrote: If Red Hat wants to pay someone to put up with it, that's their call; it's a lot easier to be polite in the face of an unending stream of personal abuse if you're getting a paycheck for doing it. If Red Hat was to do this, then it would not be the only case of Red Hat having a package that Debian users desire. From time to time I find a situation where a CentOS kernel works better than a Debian kernel, while I agree that it's ideal to try and get the problem in Debian fixed I also have a need to get machines working and sometimes can't invest the necessary amount of time. There is the alien program to convert an RPM to a .deb. Is there a way of also automatically tracking the upstream (Fedora or CentOS) version of the package and downloading a new version (with signature checks) when it becomes available? -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, 03 Mar 2009, Russell Coker wrote: Bernd, I (with my DD or upstream developer hat on) understand your sentiment. But I also (with my consultant or end-user hat on) find it impossible to implement. It's not that it's impossible to implement, it's just that the resources that could implement it are being expended elsewhere. If the deployers of the software don't have the resources to test the software in their deployment, the unfortunate reality is that no one else is likely to have the resources to test it either. A decision has to be made to either expend the resources in testing before the release, or expend resources in living with or fixing the bugs after the release. Blaming others for the reality of that decision is counter-productive, and wastes resources that could be better spent testing for future releases or helping to get the bugs fixed. Don Armstrong -- A Bill of Rights that means what the majority wants it to mean is worthless. -- U.S. Supreme Court Justice Antonin Scalia http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Piotrek's new preferred helper tool - (unfair) decision
[Piotr Ożarowski, 2009-02-18] [...] it's time however to decide which one will be my winner - I'll decide that in next weeks (maybe months, but it will happen sooner than later Since nobody is interested in having the tools binary compatible[1] (and, to be honest, I cared about opinion of two guys only: Matthias voted no by not agreeing to use /usr/lib/pyshared and Joss expressed his disapproval on #debian-python) - I choose python-support to be my preferred tool (no, not the winner, I only wanted to provoke you both to make a consensus and thus not let me decide about anything). I'm not saying one of them is better than the other (although I was more a pycentral guy, Ana knows something about it[2]) - I'm saying I have more influence on how the tool looks like (f.e. via reporting bugs) and changes are more predictable in pysupport. You can now prove me how wrong decision I made but... I don't care ;-P I propose to file bugs against python-support instead (Joss will talk you to death if it's not really a bug ;-) Anyway, as promised: I will convert all my python-central based packages to python-support soon, will *not* sponsor python-central based package anymore (except packages for Lenny) - my FAQ is already updated, and will try to convince other DDs to do the same. PS while converting, remember to add to preinst something like these 3 lines: | if [ $1 = upgrade ] dpkg --compare-versions $2 lt 1.2.3-4; then | pycentral pkgremove python-foo | fi [1] http://lists.debian.org/debian-python/2009/02/msg00099.html [2] ups, I did it again, sorry Ana -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpZ8lkLIH5pV.pgp Description: PGP signature
Bug#517910: RFP: clam-chordata -- CLAM Chordata, chord detection tool
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: clam-chordata Version : 1.0.0~svn Upstream Author : CLAM Team c...@iua.upf.edu * URL : http://clam-project.org * License : GPL Programming Lang: C++ Description : CLAM Chordata, chord detection tool CLAM Chordata is a chord detection tool that can be used to browse the chords of your favourite mp3/ogg/wav music. You can freely move arround the song, listening and getting insight of its tonal features by using several available views: Chord segments, Chord ranking, Tonnetz, Keyspace, Chromatic peaks, PCPgram... This is an example application of the CLAM framework. Unofficial Debian Packages are available at upstream. This depends on 'clam' (bug #493282). -- David García Garzón (Work) dgarcia at iua dot upf anotherdot es http://www.iua.upf.edu/~dgarcia -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517915: ITP: oneswarm -- friend-to-friend client: p2p data sharing with explicit privacy control
Package: wnpp Severity: wishlist Owner: Per Andersson avtob...@gmail.com * Package name: oneswarm Version : 0.5 Upstream Author : Tomas Isdal et al. * URL : http://oneswarm.cs.washington.edu/ * License : GPLv2, LGPL, Apache, nc-sa3, CPLv1 Programming Lang: Java Description : friend-to-friend client: p2p data sharing with explicit privacy control OneSwarm is a fully backwards-compatible BitTorrent client with an explicit privacy control enhancement. OneSwarm uses source address rewriting to protect user privacy. Instead of always transmitting data directly from sender to receiver (immediately identifying both), OneSwarm may forward data through multiple intermedaries, obscuring the identity of both sender and receiver. OneSwarm’s interface is web-based and supports real-time transcoding of many audio and video formats for in-browser playback, eliminating the need for casual users to master a new application’s interface or search for custom media codecs. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
On Mon, Mar 02, 2009 at 09:10:21PM +, Ben Hutchings wrote: On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote: What does this have over PowerDNS? Probably nothing, else that I am using it and packaging it for my own and thought that it would be a good idea to contribute to Debian, is redundancy a problem ? Even if you're a perfectly responsible maintainer, a new package still requires some work by ftpmaster, the release team, possibly the security team, and so on. It also increases the number of options a user has to choose between. If the package is redundant, this is a waste of their time. If it is really redundant then it is also a waste of upstream's time. William, since you're trying to package it, could you compare it in detail to PowerDNS, and if there is really little difference, try to see if both upstreams can work together and merge their efforts? That would help everyone in the end. -- Met vriendelijke groet / with kind regards, Guus Sliepen g...@debian.org signature.asc Description: Digital signature
Re: Piotrek's new preferred helper tool - (unfair) decision
On Mon, Mar 2, 2009 at 4:17 PM, Piotr Ożarowski pi...@debian.org wrote: [Piotr Ożarowski, 2009-02-18] [...] it's time however to decide which one will be my winner - I'll decide that in next weeks (maybe months, but it will happen sooner than later Since nobody is interested in having the tools binary compatible[1] (and, to be honest, I cared about opinion of two guys only: Matthias voted no by not agreeing to use /usr/lib/pyshared and Joss expressed his disapproval on #debian-python) - I choose python-support to be my preferred tool (no, not the winner, I only wanted to provoke you both to make a consensus and thus not let me decide about anything). I'm not saying one of them is better than the other (although I was more a pycentral guy, Ana knows something about it[2]) - I'm saying I have more influence on how the tool looks like (f.e. via reporting bugs) and changes are more predictable in pysupport. You can now prove me how wrong decision I made but... I don't care ;-P I propose to file bugs against python-support instead (Joss will talk you to death if it's not really a bug ;-) I fully agree. Let's just concentrate all our effort on one system, so I am glad you finally made a decision. I'll convert all my packages to python-support soon. Ondrej -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
* Ben Hutchings [Mon, 02 Mar 2009 21:10:21 +]: On Mon, Mar 02, 2009 at 04:42:19PM +0100, Sylvain Rochet wrote: Hi, On Mon, Mar 02, 2009 at 02:02:08AM -0600, William Pitcock wrote: What does this have over PowerDNS? Probably nothing, else that I am using it and packaging it for my own and thought that it would be a good idea to contribute to Debian, is redundancy a problem ? Even if you're a perfectly responsible maintainer, a new package still requires some work by ftpmaster, the release team, possibly the security team, and so on. It also increases the number of options a user has to choose between. If the package is redundant, this is a waste of their time. This is true. However, while increasing the number of options a user has to choose from is a drawback, it's at the same time a benefit. Figuring out which software you want to use for a particular purpose is painful, because all suck in their own ways and you need to find the one that sucks less for you. And when you find it without having to get outside of your distribution's pool, you'll be thankful that somebody made that happen. Sadly, I don't think the decision of deciding which ones will suck less for users can be outsourced to the maintainers, at least not in an unopinionated distribution. Which is of course quite different from saying that we should not be setting a minimum quality bar for all packages, I'm all for that (but how?). So, if mydns is a reasonably fine piece of software, I see no reason why we shouldn't include it. We need less crap in the archive, not less good software as well.¹ Encouraging upstreams to work together is fine, but in practice very seldom will yield results, so I don't have anything against it being done, but I don't think it should be a substitute for packaging the software. (¹) I realize mydns could be complete crap, but the argument still holds. My off-the-top-of-my-heart 2¢, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A hacker does for love what other would not do for money. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, Manoj Srivastava wrote: On Mon, Mar 02 2009, Bill Unruh wrote: Agreed, both sides have to come to the conclusion that they are operating legally. On the plus side, Schilling would like to have his software distributed in the distros. He is also strongly of the opinion that there is no legal impediment to that happening. Debian is of the opinion that there IS an impediment. It is not that Schilling recognizes the impediment and refuses to clear it, it is that he does not believe that there is one. Thus both sides are to a large extent on the same page (wanting to distribute and to do so without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. That assumes a priori that Debian's position is wrong, and that there is no legal impediments to distributing upstream cdtools. How about countenancing the view that there could actually be a legal issue, as Debian thinks there is? Yee gads, no it does not. Yes, debian sees a legal issue ( just what its depth is neither I not Debian I suspect really knows). All I am saying is that the two sides are NOT far apart on their goals. Both would like to distribute cdrtools, both want it to be open source and to allow people to make changes. Schilling believes that these conditions are already met, Debian does not. Debian believes that with the current license situation, they cannot distribute the binary code more mkisofs due to the dual CDDL(libscg) GPL(mkisofs) licensing of components of the binary. Complicating the situation is that US copyright law contains the concept of derivative work ( a very vague term) while apparently Germal law does not. Clearing out the underbrush could well involve changes to the licensing, or clarification of the licensing. I am certainly not a sufficient expert in World copyright law to know exactly what it would take, nor I suspect are you. That there is a dispute is clear. That the dispute is unsolvable is far from clear to me. An attempt at mediation that starts from such a biased stance is unlikely to succeed. And any approach in which each side assumes that mediation will always fail, and that reads all proposals as enemy proposals will probably also fail. If you want this to be and remain like Northern Ireland or Palestine, I certainly cannot stop you. But I would suggest that the only outcome of that approach is to harm the users of Debian and of cdrtools, who should be both sides primary concern. Alternatively both sides could agree on those areas in which they do agree ( which I would suggest is a lot) and then see if the remaining issues can be solved. Note that regarding the legal issues, it would really be helpful if both sides make their correspondence with Moglen public, so that we can see what the legal issues that divide the two sides really are. Or maybe even more helpfully, what the minimum changes are required to come to agreement. manoj -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#517790: ITP: mydns -- DNS server using MySQL or PostgreSQL for data storage
William Pitcock neno...@sacredspiral.co.uk writes: What does this have over PowerDNS? AFAIUI it is a dependency of ispconfig3 (which is not packaged yet). -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517925: ITP: libio-socket-socks-perl -- IO::Socket::Socks
Package: wnpp Severity: wishlist Owner: Pierre Neyron pierre.ney...@free.fr * Package name: libio-socket-socks-perl Version : 0.1 Upstream Author : Ryan Eatmon reat...@mail.com * URL : http://search.cpan.org/~reatmon/IO-Socket-Socks-0.1/ * License : Same as Perl Programming Lang: Perl Description : IO::Socket::Socks IO::Socket::Socks connects to a SOCKS v5 proxy, tells it to open a connection to a remote host/port when the object is created. The object you receive can be used directly as a socket for sending and receiving data from the remote host. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (990, 'stable'), (200, 'testing'), (100, 'unstable'), (10, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
(Gunnar, and others, please don't send individual responses that you also send to the mailing list.) Gunnar Wolf gw...@gwolf.org writes: Hmh, this could even be promoted as a best packaging practice. Many authors do ship properly-formatted --help entries, and our hand-generated manpages can often linger behind the truth. Any strong opinions against? The information appropriate for a man page (separate “description”, “options”, “examples”, “files”, “environment variables”, “see also”, etc.) is not appropriate for cramming into a ‘--help’ output, so shouldn't be expected to be there. I don't know how many ‘--help’ outputs actually provide all that information in such a form that ‘help2man’ can extract it; I think the number would be quite few. I would expect that any which do are rather bloated as a result. -- \“I bought a dog the other day. I named him Stay. It's fun to | `\ call him. ‘Come here, Stay! Come here, Stay!’ He went insane. | _o__) Now he just ignores me and keeps typing.” —Steven Wright | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
This one time, at band camp, Bill Unruh said: All I am saying is that the two sides are NOT far apart on their goals. Both would like to distribute cdrtools, both want it to be open source and to allow people to make changes. That may have been true in 2004. I doubt it is any longer. If I was one of the maintainers of this fork, I would have zero incentive to want to work with JS any more. Now please, can we let this thread die? I'm sure there's lots more arm chair lawyering and moaning that could be done about how we don't all play nicely together, but we're just rehashing the same old nonsense. End of topic for me. -- - | ,''`.Stephen Gran | | : :' :sg...@debian.org | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
Again, let us separate out the ill feelings from the issues under dispute. I realise that it is very hard to forget history but since both sides believe that it is the user that is most important, that is whom we should keep our attention on. Schilling here says that all of cdrtools, except mkisofs are released under the CDDL. I assume that Debian does not have any particular legal issue with distributing something which is purely CDDL licensed. They may have their preferences that things be GPL licensed but are willing to live with something that is CDDL licensed. Thus, is it correct that the issue centers around mkisofs, a program which is under the GPL2 license and is linked with libscg, a CDDL licensed library? Is this where the dispute lies? If so, exactly what is the nature of the legal (as opposed to personal) disagreement? Schilling has made clear that he does not believe there to be any legal impediment to the distribution of the software. Debian has made clear that they believe that there is such an impediment. What, in as few words as possible, is the impediment? On Mon, 2 Mar 2009, Joerg Schilling wrote: Bill Unruh un...@physics.ubc.ca wrote: Agreed, both sides have to come to the conclusion that they are operating legally. On the plus side, Schilling would like to have his software distributed in the distros. He is also strongly of the opinion that there is no legal impediment to that happening. Debian is of the opinion that there IS an impediment. It is not that Schilling recognizes the impediment and refuses to clear it, it is that he does not believe that there is one. Thus both sides Well several lawyers have been asked for legal advise. The Sun legal department did a full legal review of the cdrtools source bewteen August 2008 and October 2008. No problem was found. A German lawyer who is specialized on OpenSOurce hast been asked and he also does not see a problem. Eben Moglen has been asked and he also did see no problem. Note that any laywer as a first reply confirms that the claim from the former Debian package maintainer Eduard Bloch who initiated the attacks against me and my software in May 2004 is complete nonsense. There is of course no problem to use a CDDL licensed build system to compile a GPLd project. For the rest of claims seen in the net, it is important to understand that you need to find a single interpratation of the GPL that is not in conflict with - The Copyright - The OpenSource definition http://www.opensource.org/docs/osd - and that does not make OSS distributions illegal All theories from people who claim that there is a problem with the original cdrtools I did see, are either in conflict with the Copyright law, would make the GPL a clearly nonfree license acording to http://www.opensource.org/docs/osd or would disallow to distribute e.g. Linux together with X. The GPL is a work based license (see Copyright law http://www.gesetze-im-internet.de/urhg/index.html) and with a single exception, the rules of the GPL end at the work limit. The single exception is that if you combine a GPLd work with an independent work under a different license, you need to distribute complete source in case you distribute binaries. If you did try to disallow GPLd programs to link against independent non-GPL libraries, you would make _any_ GPLd program undistributable in binary form. without legal impediment). Now the question is, is there some way of clearing out the underbrush so that both sides agree that there is no impediment. (Note that the chances of any legal action being taken by anyone with respect to cdrtools is miniscule. So it is not fear that stands in the way, but a legal quibble. There is a high risk that people, who are involved with distributing the fork, will be sued. There is no risk to distribute the original software. Will you buy the maintainer all kinds of scsi burners so they can test each? I myself and several others have used debians cdrecord with scsi just fine so the bug must be some quirk of that specific config. You can never forsee all those quirks. Look I never said that maintaining is easy. It is not. And Schilling has proven himself willing to do it, to buy all kinds of scsi burners or get ahold of them, and make it work. That is worth a HUGE amount. Let me add that Debian did verify that nobody is willing and able to fix the bugs in wodim or genisoimage. And here we have to disagree. I don't see Schilling moving one iota from his position and trying to compromise with someone so set in stone is just wasted. Well, I think there is the problem. This has come down to personal issues, not legal or technical. Everyone is so dug into their positions that they simply spend time lobbing grenades at each other, rather then trying to work through the problem. Yes, Schilling is difficult but by now, so is Debian. The amount of childish vituperation that has been seen in this discussion mostly
Re: xcdroast does no longer work with wodim: Who to blame?
On Monday 02 March 2009, Russell Coker wrote: On Mon, 2 Mar 2009, Bernd Schubert bernd.schub...@fastmail.fm wrote: Since the release of Lenny, I have installed arround 60 Workstaions, but making tararchives of the original installation and reinstalled Lenny from scratch, using the first binary DVD and the rest over Net. Nearly 80% of all Workstations do not work properly. Maybe you should start to test Debian-Testing from time to time and report bugs if something doesn't work for you? Just complaining *after* a release isn't really helpful. Bernd, I (with my DD or upstream developer hat on) understand your sentiment. But I also (with my consultant or end-user hat on) find it impossible to implement. You don't have any chroots, virtual machines and you don't run Sid at home? If I was running a large scale IT environment (say 1000+ users) then I would assign an increasing portion of the help-desk people to run testing as the release became closer and I would allow some of the user-base to run testing when the release was really close. Then after the release I would slowly increase the number of people running the new release so that bugs could be identified and fixed. If a bug hit the 1% of the user-base who were most adventurous and demanding of new versions then it wouldn't be so bad. Well, Michelle upgraded over 50 machines. At university I was admin of of group of also that number. We had chroots (for old-stable, testing and sid). Some users sometimes had to use one or another chroot to get some programs running. Since that also requires the basic libs are working, it is at least a basic test. On upgrades we always tried to migrate as few as possible workstations first (of course easy, when you have a diskless environment as we had/have). So when on the first system not everything runs smoothly we never would have upgraded the 2nd system. But however I'm not running a large IT environment and I don't have the resources for such things. Sometimes I do the upgrade after the release and just have to deal with some bugs. I don't know, maintaining a testing chroot is really simple, since you don't need to adjust a single configuration file within the chroot. Testing some software components from time there is also easy then. Cheers, Bernd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Piotrek's new preferred helper tool - (unfair) decision
Hi Dne Mon, 2 Mar 2009 22:17:52 +0100 Piotr Ożarowski pi...@debian.org napsal(a): Since nobody is interested in having the tools binary compatible[1] (and, to be honest, I cared about opinion of two guys only: Matthias voted no by not agreeing to use /usr/lib/pyshared and Joss expressed his disapproval on #debian-python) - I choose python-support to be my preferred tool (no, not the winner, I only wanted to provoke you both to make a consensus and thus not let me decide about anything). I'm not saying one of them is better than the other (although I was more a pycentral guy, Ana knows something about it[2]) - I'm saying I have more influence on how the tool looks like (f.e. via reporting bugs) and changes are more predictable in pysupport. You can now prove me how wrong decision I made but... I don't care ;-P I propose to file bugs against python-support instead (Joss will talk you to death if it's not really a bug ;-) Anyway, as promised: I will convert all my python-central based packages to python-support soon, will *not* sponsor python-central based package anymore (except packages for Lenny) - my FAQ is already updated, and will try to convince other DDs to do the same. Okay, lets make this move. Basically I've already started with this conversion on my packages some time ago, for much more important reason - dh does not need extra parameters for python-support ;-). -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: Upcoming Section changes in the archive
Hello, Joerg Jaspert, le Fri 27 Feb 2009 09:02:11 +0100, a écrit : Maybe it could be interesting to open an accessibility section? Maybe, maybe not. What packages would you put into it? Just a quick rough list (90 bin packages): accerciser at-spi at-spi-doc big-cursor brltty brltty-flite brltty-x11 cellwriter clara dasher edbrowse eflite emacspeak emacspeak-ss epos espeak-data festival festival-doc festival-freebsoft-utils festival-hi festival-mr festival-te festlex-cmu festlex-ifd festlex-oald festlex-poslex festvox-czech-ph festvox-don festvox-ellpc11k festvox-hi-nsk festvox-italp16k festvox-itapc16k festvox-kallpc16k festvox-kallpc8k festvox-kdlpc16k festvox-kdlpc8k festvox-mr-nsk festvox-rablpc16k festvox-rablpc8k festvox-suopuhe-common festvox-suopuhe-lj festvox-suopuhe-mv festvox-te-nsk flite gnome-accessibility-themes gnome-mag gnome-orca gnome-speech-swift gocr gocr-tk gok gok-doc hocr-gtk kdeaccessibility kmag kmousetool kmouth kttsd kttsd-contrib-plugins mousetweaks mozilla-mozgest recite saydate saytime screader speakup-doc speechd-el speechd-el-doc-cs speech-dispatcher speech-dispatcher-doc-cs speech-dispatcher-festival speech-tools speech-tools-doc sphinx2-bin sphinx2-hmm-6k stardict-plugin-espeak tesseract-ocr tesseract-ocr-deu tesseract-ocr-deu-f tesseract-ocr-eng tesseract-ocr-fra tesseract-ocr-ita tesseract-ocr-nld tesseract-ocr-por tesseract-ocr-spa ttf-ocr-a wayv xvkbd xzoom yasr I probably forget a lot more, it's hard to track them as there is no naming scheme at all. Plus a few packages which I intend to package sooner or later (~20 bin packages): mousetrap mbrola* cicero trf liblouis-bin liblouisxml-bin xml2brl Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “pro per manpage” for every command
On Mon, Mar 02, 2009 at 09:04:39PM +1100, Ben Finney wrote: The response from the maintainer (who is also the upstream author) so far is, essentially, “Patches welcome, but I'm not interested in maintaining manpages”. I have submitted a manpage as a patch. However, that response pretty much guarantees that the maintainer won't be taking the initiative to keep the manpage up to date. Am I right in thinking that it is nevertheless the maintainer's responsibility to do so? IMO, yes. That's part and parcel of what a package maintainer should be doing. I don't like Debian policy being used as a blunt instrument, but I must admit my mental reaction to the maintainer's response was along the lines of “Too bad; in accepting the role of package maintainer, you accepted the ongoing task of maintaining manpages for every command, utility, and function in the package”. Wording and tone aside, is that expectation reasonable? Again IMO, yes. We require manual pages, and it's the maintainer's responsibility to make sure that they are provided and up to date. It's not like it's a major chore to write a manual page, so any maintainer outright refusing to do so is a crap maintainer, as well as being bloody lazy. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
Hi, On Montag, 2. März 2009, Russell Coker wrote: There is the alien program to convert an RPM to a .deb. Is there a way of also automatically tracking the upstream (Fedora or CentOS) version of the package and downloading a new version (with signature checks) when it becomes available? apt-cache show whohas that at least will tell you what's available, add some pipes and other magic and you'll get what you want ;-) regards, Holger signature.asc Description: This is a digitally signed message part.
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, Mar 02, 2009 at 02:41:54PM -0800, Bill Unruh wrote: Thus, is it correct that the issue centers around mkisofs, a program which is under the GPL2 license and is linked with libscg, a CDDL licensed library? Is this where the dispute lies? If so, exactly what is the nature of the legal (as opposed to personal) disagreement? Schilling has made clear that he does not believe there to be any legal impediment to the distribution of the software. Debian has made clear that they believe that there is such an impediment. What, in as few words as possible, is the impediment? Read the CDDL section under the FSF's list of GPL incompatible licenses. http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega james...@debian.org signature.asc Description: Digital signature
the files in /etc/modprobe.d/
The upstream maintainers decided that in the future the files in /etc/modprobe.d/ will be processed only if they have a .conf suffix. The latest module-init-tool release complains loudly for each one and still processes them, but this will change. Please update your packages at the time of your next upload and remember that the files in this directory are opened and parsed every time modprobe is run (and it is run very often at boot time!), so try to look at the big picture and install a file there only if it is really needed. Do not install a file if it only contains comments, if it is only useful for some unusual environment or if it not needed for recent kernels (nowadays most drivers have their own aliases built in, check /lib/modules/$KVER/modules.alias). The packages affected are: etc/modprobe.d/aliases admin/module-init-tools etc/modprobe.d/alsa-base sound/alsa-base etc/modprobe.d/alsa-base-blacklist sound/alsa-base etc/modprobe.d/blacklist admin/udev etc/modprobe.d/blacklist-berry_chargeutils/barry-util etc/modprobe.d/blacklist-capiutils net/capiutils etc/modprobe.d/display_class admin/udev etc/modprobe.d/eeepc utils/eeepc-acpi-scripts etc/modprobe.d/gpib science/libgpib-bin etc/modprobe.d/hostap-utils net/hostap-utils etc/modprobe.d/i2c utils/lm-sensors etc/modprobe.d/kqemu misc/kqemu-common etc/modprobe.d/libphidgets0 libs/libphidgets0 etc/modprobe.d/libpisock9libs/libpisock9 etc/modprobe.d/libsane libs/libsane etc/modprobe.d/madwifi contrib/net/madwifi-tools etc/modprobe.d/mt-st admin/mt-st etc/modprobe.d/mwave non-free/utils/mwavem etc/modprobe.d/nbd-clientadmin/nbd-client etc/modprobe.d/nvidia-kernel-nkc contrib/x11/nvidia-kernel-common etc/modprobe.d/pnp-hotplug admin/udev etc/modprobe.d/rng-tools utils/rng-tools etc/modprobe.d/rt73 contrib/net/rt73-common etc/modprobe.d/sl-modem-daemon.modutils non-free/misc/sl-modem-daemon etc/modprobe.d/thinkpad_acpi.modprobeadmin/acpi-support etc/modprobe.d/toshset utils/toshset etc/modprobe.d/toshutils utils/toshutils etc/modprobe.d/vmxnetcontrib/admin/open-vm-tools -- ciao, Marco signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
Josselin Mouette j...@debian.org wrote: If you did try to disallow GPLd programs to link against independent non-GPL libraries, you would make _any_ GPLd program undistributable in binary form. This is absolute bullshit. Of course it is forbidden to link GPL programs against non-GPL-compatible libraries, unless the library is ???normally distributed [...] with the major components [...] of the operating system???. You verified many times that you are an extremely hostile person that prefers to spread FUD. Please stay out, we don't need you! It seems that you are unable to understand English and it is no miracle that you completely missinterpret the GPL. The so called OS exception in the GPL has been created around 1987 in order to make the GPL compatible with the license rules of the closed source Operating Systems that did forbid to distribute the complete libc while the GPL before required to distribute the complete libc when binaries from GPLd programs are distributed. The OS exception in the GPL just allows you to omit things like libc from the complete source. The The OS exception in the GPL does not allow you to treat license compatibility between GPL code and system libraries different from license compatibility between GPL code and any other library that was created as a separate work. I asked Eben Moglen: The way I read the GPLv2, the system exception in section 3 only gives you the permission to omit the system parts from the complete source. Where do you see additional differences to other code that is not part of the system? Eben Moglen replied: I don't. I agree with you. I told Mark and his colleagues that a past question raised on the debian-legal mailing list--whether an OpenSolaris distribution could combine GNU userland with Solaris kernel via OpenSolaris CDDL C-Library--was a non-issue, but that in the course of answering it Stallman realized that we would need to change the system library exception in GPLv3 to make the provision clearer. You are correct that the only question in combining CDDL system libraries with GPL'd code is what constitutes complete and corresponding source code, and nothing more. Mark's account of the conversation to you was confusing. . As you see, Moglen sees no way to treat libschily different from libc on Solaris. Both are under CDDL and the FSF clearly confirms that it is perfectly legal to distribute binaries from GPLd programs compiled for OpenSolaris. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Bill Unruh un...@physics.ubc.ca wrote: Again, let us separate out the ill feelings from the issues under dispute. I realise that it is very hard to forget history but since both sides believe that it is the user that is most important, that is whom we should keep our attention on. Schilling here says that all of cdrtools, except mkisofs are released under the CDDL. I assume that Debian does not have any particular legal issue with distributing something which is purely CDDL licensed. They may have their preferences that things be GPL licensed but are willing to live with something that is CDDL licensed. Debian even did recently package again star which is 100% CDDL too. BTW: I am happy to see that people realize that there are contradicting statements with respect to why some decisions at Debian have been made in a specific way. Maybe this helps to bring things into a first move. Thus, is it correct that the issue centers around mkisofs, a program which is under the GPL2 license and is linked with libscg, a CDDL licensed library? Is this where the dispute lies? If so, exactly what is the nature of the legal (as opposed to personal) disagreement? Schilling has made clear that he does not believe there to be any legal impediment to the distribution of the software. Debian has made clear that they believe that there is such an impediment. What, in as few words as possible, is the impediment? See my other mail where I explain why the claim on an incompatibility with regards to the CDDL GPL combination as used with mkisofs is void. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the files in /etc/modprobe.d/
On Tue, Mar 03, 2009 at 01:43:53AM +0100, Marco d'Itri wrote: The upstream maintainers decided that in the future the files in /etc/modprobe.d/ will be processed only if they have a .conf suffix. What is the point of this change, except to force an annoying transition on people? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, James Vega wrote: On Mon, Mar 02, 2009 at 02:41:54PM -0800, Bill Unruh wrote: Thus, is it correct that the issue centers around mkisofs, a program which is under the GPL2 license and is linked with libscg, a CDDL licensed library? Is this where the dispute lies? If so, exactly what is the nature of the legal (as opposed to personal) disagreement? Schilling has made clear that he does not believe there to be any legal impediment to the distribution of the software. Debian has made clear that they believe that there is such an impediment. What, in as few words as possible, is the impediment? Read the CDDL section under the FSF's list of GPL incompatible licenses. I have. It says nothing except give the opinion that the two are incompatible ( as are GPL2 and GPL3). In particular it does not address the issue of exactly why, in the case of cdrtools, the linking of mkisofs and libscg makes the result undistributable. Ie, it is not very helpful in helping to resolve this dispute. http://www.fsf.org/licensing/licenses/index_html#GPLIncompatibleLicenses -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, Mar 03, 2009 at 01:31:36AM +0100, Joerg Schilling wrote: I asked Eben Moglen: The way I read the GPLv2, the system exception in section 3 only gives you the permission to omit the system parts from the complete source. Where do you see additional differences to other code that is not part of the system? Eben Moglen replied: I don't. I agree with you. I told Mark and his colleagues that a past question raised on the debian-legal mailing list--whether an OpenSolaris distribution could combine GNU userland with Solaris kernel via OpenSolaris CDDL C-Library--was a non-issue, but that in the course of answering it Stallman realized that we would need to change the system library exception in GPLv3 to make the provision clearer. You are correct that the only question in combining CDDL system libraries with GPL'd code is what constitutes complete and corresponding source code, and nothing more. Mark's account of the conversation to you was confusing. . As you see, Moglen sees no way to treat libschily different from libc on Solaris. Both are under CDDL and the FSF clearly confirms that it is perfectly legal to distribute binaries from GPLd programs compiled for OpenSolaris. Nothing you quoted above says anything about a) whether libschily is considered a system library, or b) what the implications are for a CDDL work being considered part of the complete corresponding source code. We have had conversations with the FSF's Brett Smith to the effect that, under both GPLv2 and GPLv3, even OpenSSL can not be considered a system library, and that as a result Debian cannot ship binaries of GPL works linked against libssl. I think that you're getting the answers you're looking for from Eben because once again, you're framing the question in terms of your own biased interpretation of what the GPL says. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, 03 Mar 2009, Joerg Schilling wrote: The OS exception in the GPL just allows you to omit things like libc from the complete source. The The OS exception in the GPL does not allow you to treat license compatibility between GPL code and system libraries different from license compatibility between GPL code and any other library that was created as a separate work. Those of us who have been dealing with licensing issues for quite some time are very familiar with the major components of the operating system exception to GPL v2 §3 and the System Libraries exception of GPL v3 §1. Eben Moglen replied: I told Mark and his colleagues that a past question raised on the debian-legal mailing list--whether an OpenSolaris distribution could combine GNU userland with Solaris kernel via OpenSolaris CDDL C-Library--was a non-issue, but that in the course of answering it Stallman realized that we would need to change the system library exception in GPLv3 to make the provision clearer. You are correct that the only question in combining CDDL system libraries with GPL'd code is what constitutes complete and corresponding source code, and nothing more. Mark's account of the conversation to you was confusing. . As you see, Moglen sees no way to treat libschily different from libc on Solaris. Both are under CDDL and the FSF clearly confirms that it is perfectly legal to distribute binaries from GPLd programs compiled for OpenSolaris. You're misconstruing the very narrow statement that Eben made into an very broad statement. You asked him about GNU userland+kernel+CDDL, and Eben is said that the combination of the GNU userland with a Solaris kernel or CDDL'ed libc was a non-issue, because those *are* System Libraries. He says this because they are not part of GNU userland, but are commonly included with major components, such as the kernel, X, etc, and implement a Standard Interface. By and large, I agree with Eben in his interpretation of the GPL v2 and v3 here. If you wanted to know about the combination of CDDL+GPLv2/3 as it applies to cdrtools and libshilly as distributed by Debian, you should have *asked* Eben a specific question about that. I imagine he would have given you an answer similar to the following: libschilly as distributed by Debian is not a System Library, because it is part of the cdrtools work, does not implement a Standard Interface, nor is it included in the normal form of packaging a Major component, nor does it serve only to enable the use of the work with a Major Component. The fact that Debian does not currently distribute libschilly further indicates that it isn't a System Library. Thus, libschilly is part of the Corresponding Source for the cdrtools, and in order to distribute under GPL v3 §5, we must distribute the Corresponding Source under the GPL v3 (or terms compatible with it) which the CDDL is not. If you are actually concerned about enabling[1] Debian to distribute cdrtools, the path is clear: dual-license cdrtools and the libraries it requires that are currently CDDL-only with the CDDL and the GPLv3. If you're not willing to do this, that's definetly your choice, but Debian won't be able to distribute cdrtools if you don't. Don Armstrong 1: I should note that this doesn't mean that someone will actually do the work to package cdrtools, but it at least would make it possible for an interested maintainer to do so. -- More than any other time in history, mankind faces a crossroads. One path leads to despair and utter hopelessness. The other, to total extinction. Let us pray we have the wisdom to choose correctly. -- Woody Allen http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, Mar 02, 2009 at 09:38:20PM +0100, Joerg Schilling wrote: The current state of Eduard Bloch at Debian is suspended. No, it isn't. When will the state of Eduard Bloch be changed from suspended to thrown out? It won't. He is still a member in good standing of the Debian community, and you're still a swaggering jerk. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, Don Armstrong wrote: On Tue, 03 Mar 2009, Joerg Schilling wrote: The OS exception in the GPL just allows you to omit things like libc from the complete source. The The OS exception in the GPL does not allow you to treat license compatibility between GPL code and system libraries different from license compatibility between GPL code and any other library that was created as a separate work. Those of us who have been dealing with licensing issues for quite some time are very familiar with the major components of the operating system exception to GPL v2 §3 and the System Libraries exception of GPL v3 §1. Eben Moglen replied: I told Mark and his colleagues that a past question raised on the debian-legal mailing list--whether an OpenSolaris distribution could combine GNU userland with Solaris kernel via OpenSolaris CDDL C-Library--was a non-issue, but that in the course of answering it Stallman realized that we would need to change the system library exception in GPLv3 to make the provision clearer. You are correct that the only question in combining CDDL system libraries with GPL'd code is what constitutes complete and corresponding source code, and nothing more. Mark's account of the conversation to you was confusing. . As you see, Moglen sees no way to treat libschily different from libc on Solaris. Both are under CDDL and the FSF clearly confirms that it is perfectly legal to distribute binaries from GPLd programs compiled for OpenSolaris. You're misconstruing the very narrow statement that Eben made into an very broad statement. You asked him about GNU userland+kernel+CDDL, and Eben is said that the combination of the GNU userland with a Solaris kernel or CDDL'ed libc was a non-issue, because those *are* System Libraries. He says this because they are not part of GNU userland, but are commonly included with major components, such as the kernel, X, etc, and implement a Standard Interface. By and large, I agree with Eben in his interpretation of the GPL v2 and v3 here. If you wanted to know about the combination of CDDL+GPLv2/3 as it applies to cdrtools and libshilly as distributed by Debian, you should have *asked* Eben a specific question about that. I imagine he would have given you an answer similar to the following: libschilly as distributed by Debian is not a System Library, because it is part of the cdrtools work, does not implement a Standard Interface, nor is it included in the normal form of packaging a Major component, nor does it serve only to enable the use of the work with a Major Component. The fact that Debian does not currently distribute libschilly further indicates that it isn't a System Library. Thus, This is a bit of chicken and egg isn't it? libschilly is part of the Corresponding Source for the cdrtools, and in order to distribute under GPL v3 §5, we must distribute the Corresponding Source under the GPL v3 (or terms compatible with it) which the CDDL is not. If you are actually concerned about enabling[1] Debian to distribute cdrtools, the path is clear: dual-license cdrtools and the libraries it requires that are currently CDDL-only with the CDDL and the GPLv3. If you're not willing to do this, that's definetly your choice, but Debian won't be able to distribute cdrtools if you don't. I believe that you mean the above to apply to mkisofs, not to cdrtools, which is a bunch of different program. The programs which are purely CDDL I assume you have no problem with distributing (despite your discomfort with CDDL). Since it appears that mkisofs is the only GPL licensed program within cdrtools, the linking of mkisofs with libscg is what you find problematic. Note that since the kernel is GPL2, not GPL3, I assume you meant GPL2 in the above. I assume that you are not saying that Debian will only distribute GPL3 works. Don Armstrong 1: I should note that this doesn't mean that someone will actually do the work to package cdrtools, but it at least would make it possible for an interested maintainer to do so.
Re: Requirement for a “pro per manpage” for every command
Manoj Srivastava dijo [Mon, Mar 02, 2009 at 02:22:57PM -0600]: Hmh, this could even be promoted as a best packaging practice. Many authors do ship properly-formatted --help entries, and our hand-generated manpages can often linger behind the truth. Any strong opinions against? I would not call it best. Barely adequate, perhaps. Could do better, certainly. Best practrice would be to write up a real man page, perhaps using the help2man as a starting point. I agree - But at least its output is equivalent in quality to a couple of manpages I have hand-generated (i.e. documenting a somewhat-obscure command or one for which the --help output is just enough). For one of them I have already ditched my man page for a call to help2man in debian/rules' install - It will at least make sure I don't skip any changes introduced upstream. Greetings, -- Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the files in /etc/modprobe.d/
On Mar 03, Steve Langasek vor...@debian.org wrote: On Tue, Mar 03, 2009 at 01:43:53AM +0100, Marco d'Itri wrote: The upstream maintainers decided that in the future the files in /etc/modprobe.d/ will be processed only if they have a .conf suffix. What is the point of this change, except to force an annoying transition on people? Being sure to ignore backups, packaging systems files, etc. It's not that I like this much, but I'd rather not carry forever a patch to restore the old behaviour. -- ciao, Marco signature.asc Description: Digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, 3 Mar 2009, Bill Unruh un...@physics.ubc.ca wrote: libschilly as distributed by Debian is not a System Library, because it is part of the cdrtools work, does not implement a Standard Interface, nor is it included in the normal form of packaging a Major component, nor does it serve only to enable the use of the work with a Major Component. The fact that Debian does not currently distribute libschilly further indicates that it isn't a System Library. Thus, This is a bit of chicken and egg isn't it? If libschilly met the criteria for being a System Library then it probably have been packaged for use by other programs. If you want to make a case for including libschilly as a System Library then please provide a list of some of the other programs which depend on it. Also please note that there is nothing stopping you from building your own packages of any software you like that isn't in Debian and hosting them on your own web server. It's really not difficult to do. Bill, you could become the unofficial cdrecord maintainer for Debian if you want to do the work and host it on your own server. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Russell Coker russ...@coker.com.au writes: If libschilly met the criteria for being a System Library then it probably have been packaged for use by other programs. If you want to make a case for including libschilly as a System Library then please provide a list of some of the other programs which depend on it. It's also worth bearing in mind that, in the past, Debian has decided to not assume *any* library shipped with Debian is a System Library since the concept isn't particularly meaningful for a distribution maker that doesn't divide its software into the system and add-ons. It's a somewhat ill-defined and murky area of the GPL and I think Debian is best served by steering entirely clear of it with the exception of not worrying about the fact that the kernel is under the GPL. If Debian can't consider OpenSSL to be a System Library, and that was the decision that we were advised to make in the past, I can't imagine any circumstances that would allow libschilly to qualify. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 02 Mar 2009, Bill Unruh wrote: On Mon, 2 Mar 2009, Don Armstrong wrote: The fact that Debian does not currently distribute libschilly further indicates that it isn't a System Library. This is a bit of chicken and egg isn't it? No, because unlike the chicken and the egg,[0] if we take away libshilly, we still have Debian and vice versa. I believe that you mean the above to apply to mkisofs, not to cdrtools, which is a bunch of different program. The programs which are purely CDDL I assume you have no problem with distributing (despite your discomfort with CDDL). I actually haven't drawn a distinction between them because it's not clear to me that Joerg is actually the copyright holder of every single part of cdrtools, and thus may not actually be able to relicense the parts that are claimed to be purely CDDLed. The solution I proposed[1] would resolve even this ambiguity, which is why I didn't bother to discuss it. Note that since the kernel is GPL2, not GPL3, I assume you meant GPL2 in the above. No, I meant GPLv3, as I assume that's a more palletable license for Joerg than GPLv2. It has nothing to do with the kernel. It doesn't make any difference to me which version is chosen, though. I assume that you are not saying that Debian will only distribute GPL3 works. That would be a correct assumption, since I didn't say that. Don Armstrong 0: Clearly, if we were to take away the chicken, we'd soon have no eggs (and vice versa). 1: I should note that I proposed this solution more than two and a half years ago, so it's not like I'm saying anything new here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109#161 -- The game of science is, in principle, without end. He who decides one day that scientific statements do not call for any further test, and that they can be regarded as finally verified, retires from the game. -- Sir Karl Popper _The Logic of Scientific Discovery_ §11 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, 3 Mar 2009, Russell Coker wrote: On Tue, 3 Mar 2009, Bill Unruh un...@physics.ubc.ca wrote: libschilly as distributed by Debian is not a System Library, because it is part of the cdrtools work, does not implement a Standard Interface, nor is it included in the normal form of packaging a Major component, nor does it serve only to enable the use of the work with a Major Component. The fact that Debian does not currently distribute libschilly further indicates that it isn't a System Library. Thus, This is a bit of chicken and egg isn't it? If libschilly met the criteria for being a System Library then it probably have been packaged for use by other programs. If you want to make a case for including libschilly as a System Library then please provide a list of some of the other programs which depend on it. The only purpose of that was to point out that one could read that statement as saying that the reason libscg and mkisofs are not included in Debian was because libscg was not included in Debian. I realise that that is a gross simplification, but it does raise the issue of what a System Library is. Also please note that there is nothing stopping you from building your own packages of any software you like that isn't in Debian and hosting them on your own web server. It's really not difficult to do. Bill, you could become the unofficial cdrecord maintainer for Debian if you want to do the work and host it on your own server. I do not think we are there yet. The claim is that cdrecord cannot be distributed as any part of Debian because of legal issues. I am trying to find out what the issues are, and narrow them down to their essense. So far most of the discussion has been on personality or on overbroad, overgeneralised issues. Finding out exactly where the problem is believed to lie might help in resolving it. I just find it an unhappy situation for users that someone who has clearly put in a huge amount of time and effort in creating a working open source software project, one that everyone who uses Linux needs and could use, cannot have his product distributed. It does no-one any good, and thus I feel that trying to concentrate on the essense might help mitigate that situation. There is a problem, in which the users are caught in the middle. (Note that my coding skills are pretty primative, making my ability to act as a competent maintainer doubtful.) -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, Don Armstrong wrote: On Mon, 02 Mar 2009, Bill Unruh wrote: On Mon, 2 Mar 2009, Don Armstrong wrote: . I believe that you mean the above to apply to mkisofs, not to cdrtools, which is a bunch of different program. The programs which are purely CDDL I assume you have no problem with distributing (despite your discomfort with CDDL). I actually haven't drawn a distinction between them because it's not clear to me that Joerg is actually the copyright holder of every single part of cdrtools, and thus may not actually be able to relicense the parts that are claimed to be purely CDDLed. The solution He certainly does claim to be the copyright holder and as having the right to license them under CDDL, and I think barring solid evidence to the contrary, one should accept him at his word. Otherwise we open a huge can of worms for every single program in Linux. Given that acceptance, I assume that the concern is about mkisofs, and libscg and not the other parts. I proposed[1] would resolve even this ambiguity, which is why I didn't bother to discuss it. At present I think we should concentrate on agreeing what the problem is. Solutions are easier when the problem is clear. They may still not be possible, but they should be easier. Note that since the kernel is GPL2, not GPL3, I assume you meant GPL2 in the above. No, I meant GPLv3, as I assume that's a more palletable license for Joerg than GPLv2. It has nothing to do with the kernel. It doesn't make any difference to me which version is chosen, though. I assume that you are not saying that Debian will only distribute GPL3 works. That would be a correct assumption, since I didn't say that. Agreed, you did not say it. I just wanted to make sure it was not to be implicitly read into your statement. Don Armstrong 0: Clearly, if we were to take away the chicken, we'd soon have no eggs (and vice versa). 1: I should note that I proposed this solution more than two and a half years ago, so it's not like I'm saying anything new here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109#161 -- William G. Unruh | Canadian Institute for| Tel: +1(604)822-3273 PhysicsAstronomy | Advanced Research | Fax: +1(604)822-5324 UBC, Vancouver,BC | Program in Cosmology | un...@physics.ubc.ca Canada V6T 1Z1 | and Gravity | www.theory.physics.ubc.ca/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517943: ITP: libchemistry-formula-perl -- enumerate elements in a chemical formula
Package: wnpp Severity: wishlist Owner: Carlo Segre se...@debian.org * Package name: libchemistry-formula-perl Version : 1.0.1 Upstream Author : Bruce Ravel bra...@bnl.gov * URL : http://cars9.uchicago.edu/svn/libperlxray * License : Artistic Programming Lang: Perl Description : enumerate elements in a chemical formula This module provides a function which parses a string containing a chemical formula and returns the number of each element in the string. It can handle nested parentheses and square brackets and correctly computes stoichiometry given numbers outside the (possibly nested) parentheses. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517945: ITP: libxray-absorption-perl -- x-ray absorption data for the elements
Package: wnpp Severity: wishlist Owner: Carlo Segre se...@debian.org * Package name: libxray-absorption-perl Version : 2.0.1 Upstream Author : Bruce Ravel bra...@bnl.gov * URL : http://cars9.uchicago.edu/svn/libperlxray * License : Artistic Programming Lang: Perl Description : x-ray absorption data for the elements This module supports access to X-ray absorption data. It is designed to be a transparent interface to absorption data from a variety of sources. Currently, the only sources of data are the 1969 McMaster tables, the 1999 Elam tables, the 1993 Henke tables, and the 1995 Chantler tables. The Brennan-Cowen implementation of the Cromer-Liberman tables is available as a drop-on-top addition to this package. More resources can be added easily. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
ma, 2009-03-02 kello 14:19 -0600, Manoj Srivastava kirjoitti: Then, every few revisions, I would resync the man page. I consider this just one of the things that Debian maintainedrs ought to do -- I mean, we are not just glorified packagers. We could aid this process by having a tool to detect when a manpage and --help don't document the same options. I have one for a pet project of mine, but it's pretty specific to that. Anyone want to whip up some perl for a reasonably generic one? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the files in /etc/modprobe.d/
Thought this would be a good opportunity to remind y'all about dh_installmodules(1), which can handle modprobe.d files in addition to kernel modules. Most packages shipping files in modprobe.d seem to generate the files via echo statements in debian/rules, rather than using it. dh_installmodules will handle renaming of the modprobe.d files that it installs, in its next release. Including conffile renaming on upgrade. So using it instead of those echo statements will probably save you some pain. winge Insert the typical winge here about dpkg conffile renaming code being deployed via cut-n-paste from a wiki page instead of any of our better technologies, such as a utility, with a man page, in a single package. /winge -- see shy jo, who wishes he had his own fan newsgroup signature.asc Description: Digital signature
Bug#517946: ITP: libxray-scattering-perl -- x-ray scattering data for the elements
Package: wnpp Severity: wishlist Owner: Carlo Segre se...@debian.org * Package name: libxray-scattering-perl Version : 0.2.2 Upstream Author : Bruce Ravel bra...@bnl.gov * URL : http://cars9.uchicago.edu/svn/libperlxray * License : Artistic Programming Lang: Perl Description : x-ray scattering data for the elements This module supports access to X-ray scattering data for atoms and ions. It is designed to be a transparent interface to scattering data from a variety of sources. Currently, the only sources of data are the Cromer-Mann tables from the International Tables of Crystallography and the 1995 Waasmaier-Kirfel tables. More resources can be added easily. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517947: ITP: libxray-spacegroup-perl -- symmetry operations for the crystal space groups
Package: wnpp Severity: wishlist Owner: Carlo Segre se...@debian.org * Package name: libxray-spacegroup-perl Version : 0.1.1 Upstream Author : Bruce Ravel bra...@bnl.gov * URL : http://cars9.uchicago.edu/svn/libperlxray * License : Artistic Programming Lang: Perl Description : symmetry operations for the crystal space groups This module provides an object-oriented interface to a database of space group symmetries transcribed from volume A of the International Tables of Crystallography. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Tue, 3 Mar 2009, Bill Unruh un...@physics.ubc.ca wrote: Also please note that there is nothing stopping you from building your own packages of any software you like that isn't in Debian and hosting them on your own web server. It's really not difficult to do. Bill, you could become the unofficial cdrecord maintainer for Debian if you want to do the work and host it on your own server. I do not think we are there yet. The claim is that cdrecord cannot be distributed as any part of Debian because of legal issues. I am trying to find out what the issues are, and narrow them down to their essense. In the unlikely event that you were to resolve the legal issues, you would still have to find someone to maintain the package. If you package it yourself then anyone who believes that there is no legal problem can use your package and therefore you will provide an immediate benefit. If the legal issues are eventually resolved to the satisfaction of the Debian lawyers then your package can become the base of the new cdrecord package in Debian. I have not seen any evidence that your contribution to this discussion has done any good. I just find it an unhappy situation for users that someone who has clearly put in a huge amount of time and effort in creating a working open source software project, one that everyone who uses Linux needs and could use, cannot have his product distributed. It does no-one any good, and thus I feel that trying to concentrate on the essense might help mitigate that situation. There is a problem, in which the users are caught in the middle. (Note that my coding skills are pretty primative, making my ability to act as a competent maintainer doubtful.) Perhaps it would be best if you left discussion of this matter to the people who can do the coding. -- russ...@coker.com.au http://etbe.coker.com.au/ My Main Blog http://doc.coker.com.au/ My Documents Blog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
Bill Unruh un...@physics.ubc.ca writes: He certainly does claim to be the copyright holder and as having the right to license them under CDDL, and I think barring solid evidence to the contrary, one should accept him at his word. Given the evidence that's been presented in the past that contradicts this, I'm much more reluctant to accept him at his word. Otherwise we open a huge can of worms for every single program in Linux. Most programs are never relicensed for exactly this reason. Linus Torvalds has stated in the past that he doesn't believe the Linux kernel could *ever* be relicensed for exactly this reason. You obviously mean well, but from your posts here it's unfortunately quite clear that you're unfamiliar with some basic concepts in open source and GPL licensing, such as the issues around system libraries and the difficulty of relicensing. There's nothing wrong with that; most people never have to care about these issues, and they're annoying and complicated to understand (and often quite vague in their implications). However, without that understanding, I think it's ill-advised for you to try to insert yourself in the role of mediator. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#517948: ITP: yasnippet -- A template system for Emacs
Package: wnpp Severity: wishlist Owner: Julián Hernández Gómez julianhernan...@gmail.com * Package name: yasnippet Version : 0.5.10 Upstream Author : pluskid plus...@gmail.com * URL : http://code.google.com/p/yasnippet/ * License : GPL Programming Lang: Emacs Lisp Description : A template system for Emacs YASnippet (yet another snippet extension for Emacs) is a template system for Emacs. It allows you to type an abbrevation and automatically expand the abbreviation into function templates. . Bundled language templates includes: C, C++, C#, Perl, Python, Ruby, SQL, LaTeX, HTML, CSS and more. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 02 Mar 2009, Bill Unruh wrote: He certainly does claim to be the copyright holder and as having the right to license them under CDDL, and I think barring solid evidence to the contrary, one should accept him at his word. TPMDIR=$(mktemp -d); cd $TMPDIR; wget -O- 'ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-beta.tar.gz'|tar -zxf -; find . -type f |xargs grep Copyright|grep -iv Schilling are the parts of cdrtools which are clearly not copyrighted by Joerg Schilling. [Most of them don't matter for our discussion, but that's why it's erroneous to claim that he's the copyright holder for all parts of cdrtools, and why I don't make a distinction.] At present I think we should concentrate on agreeing what the problem is. The problem is fairly clear; the combination of GPLed and CDDLed code is not distributable. Whether Joerg will agree with that statement of the problem is unlikely, but that's not really our problem anymore. Don Armstrong -- Il semble que la perfection soit atteinte non quand il n'y a plus rien a ajouter, mais quand il n'y a plus rien a retrancher. (Perfection is apparently not achieved when nothing more can be added, but when nothing else can be removed.) -- Antoine de Saint-Exupe'ry, Terres des Hommes http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the files in /etc/modprobe.d/
On Tue, Mar 03, 2009 at 03:09:52AM +0100, Marco d'Itri wrote: On Mar 03, Steve Langasek vor...@debian.org wrote: On Tue, Mar 03, 2009 at 01:43:53AM +0100, Marco d'Itri wrote: The upstream maintainers decided that in the future the files in /etc/modprobe.d/ will be processed only if they have a .conf suffix. What is the point of this change, except to force an annoying transition on people? Being sure to ignore backups, packaging systems files, etc. It's not that I like this much, but I'd rather not carry forever a patch to restore the old behaviour. Is there a chance upstream would accept a patch to implement this as a blacklist instead of a whitelist? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: the files in /etc/modprobe.d/
On Mon, Mar 02, 2009 at 10:02:11PM -0500, Joey Hess wrote: winge Insert the typical winge here about dpkg conffile renaming code being deployed via cut-n-paste from a wiki page instead of any of our better technologies, such as a utility, with a man page, in a single package. /winge It would of course have to be in an Essential: yes package, since conffile renaming has to be handled in the package preinst and we wouldn't want conffile handling to involve lots of extra Pre-Depends. dpkg itself is the most likely package to carry this - wishlist bug on dpkg warranted? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “pro per manpage” for every command
Le Tue, Mar 03, 2009 at 12:10:09AM +, Roger Leigh a écrit : crap maintainer bloody lazy. I thought I was doing something good when writing manpages, now I realise what I am for not writing enough : « responsable de merde putain de feignant » (translated in my language). Thank you for opening my eyes. -- Charles Plessy -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Requirement for a “proper manpage” for every command
Ben Finney wrote: Wording and tone aside, is that expectation reasonable? Yes. What course of action is open to a user of the package, with a maintainer who has made it plain they're not interested in following (this part of) policy? There's nothing direct you can do as user. As a packager, you could propose adopting the package if the current maintainer is incompetent. As a user, you'd have to report a bug each time the manual becomes incorrect due to lack of care. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: xcdroast does no longer work with wodim: Who to blame?
On Mon, 2 Mar 2009, Don Armstrong wrote: On Mon, 02 Mar 2009, Bill Unruh wrote: He certainly does claim to be the copyright holder and as having the right to license them under CDDL, and I think barring solid evidence to the contrary, one should accept him at his word. TPMDIR=$(mktemp -d); cd $TMPDIR; wget -O- 'ftp://ftp.berlios.de/pub/cdrecord/alpha/cdrtools-beta.tar.gz'|tar -zxf -; find . -type f |xargs grep Copyright|grep -iv Schilling Are you claiming that he does/did not have the right to release the major portion of the code under CDDL? (ie those portions that he did release in that way?) Ie, that he did not have the permission of those other copyright holders to thus release the code? are the parts of cdrtools which are clearly not copyrighted by Joerg Schilling. [Most of them don't matter for our discussion, but that's why it's erroneous to claim that he's the copyright holder for all parts of cdrtools, and why I don't make a distinction.] At present I think we should concentrate on agreeing what the problem is. The problem is fairly clear; the combination of GPLed and CDDLed code is not distributable. Whether Joerg will agree with that statement of the problem is unlikely, but that's not really our problem anymore. This is again far too broad a statement. Debian does distribute a combination of GPL and many other code licenses which are not GPL-- if they apply to separate and different programs. I am trying to narrow down the problem. So again, is the issue the linking of mkisofs with libscg? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
conffile renaming and other sh snippets for maintainer scripts
On Mon, Mar 02, 2009 at 08:01:42PM -0800, Steve Langasek wrote:
It would of course have to be in an Essential: yes package, since conffile
renaming has to be handled in the package preinst and we wouldn't want
conffile handling to involve lots of extra Pre-Depends. dpkg itself is the
most likely package to carry this - wishlist bug on dpkg warranted?
Instead of dpkg itself, I would prefer a new, tiny teeny package,
meant to become a small lib of shell script snippets on which
maintainer scripts can rely: a sort of debhelper for maintainer
scripts. Of course it should better be maintained by the dpkg team,
but I guess having a separate source package can ease maintenance.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: conffile renaming and other sh snippets for maintainer scripts
Stefano Zacchiroli z...@debian.org writes: On Mon, Mar 02, 2009 at 08:01:42PM -0800, Steve Langasek wrote: It would of course have to be in an Essential: yes package, since conffile renaming has to be handled in the package preinst and we wouldn't want conffile handling to involve lots of extra Pre-Depends. dpkg itself is the most likely package to carry this - wishlist bug on dpkg warranted? Instead of dpkg itself, I would prefer a new, tiny teeny package, meant to become a small lib of shell script snippets on which maintainer scripts can rely: a sort of debhelper for maintainer scripts. Of course it should better be maintained by the dpkg team, but I guess having a separate source package can ease maintenance. I'm not sure anyone else thinks this is a good idea except me, but I still think there's a lot of merit in writing a custom interpreter designed specifically for Debian maintainer scripts, with built-in functionality to handle the top 20-50 things that we have to do. I suspect that we could replace 90-95% of our maintainer scripts with ones written in such a stripped down mini-language, which would then be far easier to analyze, fix, and check for consistency. We could still use shell or Perl for the really difficult cases when full generality is needed. The advantage of such an interpreter over a shell library is that, for those maintainer scripts that could use it, they *can't* do anything weird because the language has no way of expressing it. So there's no temptation to hack around the shell library and turn a simple expression into one that can't be automatically verified as correct. The interpreter can also then be responsible for the difficult work of figuring out when to call programs in all the various edge-case error-handling cases. (The obvious disadvantage is that a bunch of maintainer scripts really do need shell, and the ones that could use such an interpreter are already rather simple.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Accepted php-openid 2.1.2-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 01 Mar 2009 18:58:54 +0100 Source: php-openid Binary: php-openid Architecture: source all Version: 2.1.2-2 Distribution: unstable Urgency: low Maintainer: Jan Hauke Rahm i...@jhr-online.de Changed-By: Jan Hauke Rahm i...@jhr-online.de Description: php-openid - php openid library Changes: php-openid (2.1.2-2) unstable; urgency=low . * Upload to unstable * DM-Upload-Allowed: yes Checksums-Sha1: 80383adf13f6bfa5d84b64f0d6ce37fd748d5fea 1459 php-openid_2.1.2-2.dsc 5e73cac981fe1bbbdc207bede921e8abb1536822 1509 php-openid_2.1.2-2.diff.gz 4dc53660755bbdeb936e7d6809e33c73eb5d0e1d 276784 php-openid_2.1.2-2_all.deb Checksums-Sha256: 05db34562a3599d5beda582b86f33e1d0de1f02b704c295556c73cc35ef5a895 1459 php-openid_2.1.2-2.dsc e2fb438bfd988931c30c8cdd103a099bc7bf6121b691bae1c44104f744782fcd 1509 php-openid_2.1.2-2.diff.gz affb1a5b0325e45336c395fe30fa574890a53a9143cdbd584596263f832d8abf 276784 php-openid_2.1.2-2_all.deb Files: 5045debe59b2413c50a5db0f4f04f377 1459 web optional php-openid_2.1.2-2.dsc 298f850c5ca53abed3c79ea1b2de0ef6 1509 web optional php-openid_2.1.2-2.diff.gz 27674ae38837666fd68805ba376412c6 276784 web optional php-openid_2.1.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJq425AAoJECIIoQCMVaAcJrcIAIv9vvOFslG+Mgt4noYHOmwk XvxUQ/2Rf2h9WSScXK9LPnCmgbf+WMsoV+cuE2QmFNThWi3ki/RLrNgtSH2iN0Y3 62c9WI/bWljSnk1vGOdjmJLajVY5UD5Bh3JkYlkd81mYkWR75Jxg4iF5GBUy55j0 Ym1w1+K3iWjOjkdfgrnR0NA3nV0rEygTwHtzyeekJKnWvAX0VDEWJDpmYD3Bxul9 K6r+PhfxFW10pOYwu/NbiFgijvh3OBruyKmiYBpiwjF6L9Do9VkjR/1YPXNNeVVy nOg1Cfh8W9PCYJOUcQnYOcuJ2M9CAHDsyFJAVYoyK8QvusAF4oUHa2kRsUej8p0= =LuUC -END PGP SIGNATURE- Accepted: php-openid_2.1.2-2.diff.gz to pool/main/p/php-openid/php-openid_2.1.2-2.diff.gz php-openid_2.1.2-2.dsc to pool/main/p/php-openid/php-openid_2.1.2-2.dsc php-openid_2.1.2-2_all.deb to pool/main/p/php-openid/php-openid_2.1.2-2_all.deb -- To UNSUBSCRIBE, email to debian-devel-changes-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
