APT ne sait pas résoudre les dépendances
Bonjour, J'ai un petit soucis avec APT. Je cherchais à installer le package ardour, disponible dans sid. J'ai eu droit à plusieurs échecs que je ne comprenais pas dans un premier temps : ardour ne s'installait pas par ce qu'il dépend de python-twisted qui refusait de s'installer. En effet, le python-twisted de sid (8.2.0) est en attente d'un python-twisted-runner 8.1.0, et seul le 8.0.0 est disponible pour l'instant. Pourtant, il est possible d'installer ardour. Il suffit d'installer le python-twisted de squeeze à la main, puis ardour depuis sid. Sachant qu'il y a dans ma configuration apt ceci : APT::Default-Release squeeze;, apt n'aurait-il pas pu/du essayer lui même d'installer les versions squeeze des librairies plutôt que les versions sid, limitant ainsi l'ajout de packages sid dans une machine squeeze par défaut, dans la mesure où les dépendances étaient satisfaites ? Merci par avance pour vos éclaircissements, Cordialement, Laurent Vromman -- Laurent Vromman Key ID : B57DA503 Fingerprint : 2214 8446 F5A7 F310 EB67 25F2 A683 42D3 B57D A503 signature.asc Description: OpenPGP digital signature
Re: =?UTF-8?Q?AP T ne sait pas r=c3=a9soudre les d=c3=a9pendances?=
On Fri, 27 Feb 2009, laur...@vromman.org wrote: Sachant qu'il y a dans ma configuration apt ceci : APT::Default-Release squeeze;, apt n'aurait-il pas pu/du essayer lui même d'installer les versions squeeze des librairies plutôt que les versions sid, limitant ainsi l'ajout de packages sid dans une machine squeeze par défaut, dans la mesure où les dépendances étaient satisfaites ? On ne peut mettre que stable/testing/unstable dans APT::Default-Release. Si vous essayez avec testing ca devrait marcher. A+ -- 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: APT ne sait pas résoudre les dépendances
Effectivement, c'est mieux, merci. APT ne devrait pas me taper dessus si je lui donne une conf fausse ? apt-config dump me sortait bien APT::Default-Release squeeze; sans se plaindre. Laurent 2009/2/27 Raphael Hertzog hert...@debian.org: On Fri, 27 Feb 2009, laur...@vromman.org wrote: Sachant qu'il y a dans ma configuration apt ceci : APT::Default-Release squeeze;, apt n'aurait-il pas pu/du essayer lui même d'installer les versions squeeze des librairies plutôt que les versions sid, limitant ainsi l'ajout de packages sid dans une machine squeeze par défaut, dans la mesure où les dépendances étaient satisfaites ? On ne peut mettre que stable/testing/unstable dans APT::Default-Release. Si vous essayez avec testing ca devrait marcher. A+ -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- Laurent Vromman Key ID : B57DA503 Fingerprint : 2214 8446 F5A7 F310 EB67 25F2 A683 42D3 B57D A503 signature.asc Description: OpenPGP digital signature
Re: =?UTF-8?Q?AP T ne sait pas r=c3=a9soudre les d=c3=a9pendances?=
On Fri, 27 Feb 2009, Laurent wrote: Effectivement, c'est mieux, merci. APT ne devrait pas me taper dessus si je lui donne une conf fausse ? Elle n'est pas invalide… c'est juste elle ne correspond à aucun des noms qu'il connait pour identifier les release. apt-config dump me sortait bien APT::Default-Release squeeze; sans se plaindre. Il y a surement moyen de mieux faire mais pour le moment ca ne marche qu'avec le champ Suite des fichiers Release et pas le Codename (cf /var/lib/apt/lists/*_Release). Vous pouvez soumettre un rapport wishlist sur apt s'il n'y est pas déjà. Vous pouvez par exemple suggérer d'émettre un avertissement si APT::Default-Release ne correspond à aucun des dépôts listés. 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: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Hi Sam, On Thu, Feb 26, 2009 at 11:40:45PM -0500, Sam Hartman wrote: Sam 3) Make libkrb53 depend on all the libraries it now contains Sam and libkadm55 depend on the libraries it contains. Sam 4) Set up symbols and shlibs files to point everyone at Sam libkrb53 and libkadm55 as appropriate. It turns out this fails impressively. The problem is that the library packages depend on each other. So, for example, libk5crypto3 is needed by libkrb5-3. If I make the shlibs file for libk5crypto3 point to libkrb53 instead of libk5crypto3, then libkrb5-3 depends on libkrb53. But libkrb53 depends on libkrb5-3 because that is the point of libkrb53 in the new layout. I probably could hack something that would work: use symbols files that point at the split library packages internally and just before the debs are constructed run a sed script on symbols and shlibs. However as you'll recall the only reason we didn't point the shlibs at the new packages initially is to make things easy for unstable packages that get rebuilt while the new krb5 is waiting to migrate to testing. Actually, I was meaning to comment on this. Why would you not simply point the shlibs at the component library packages at this stage? The only side effect is that the version of krb5 that includes the split library packages has to migrate to testing before anything else depending on these packages can reach testing, but that's not terribly onerous given that krb5's own migration to testing won't be tangled up with other packages - this is already a very soft transition, and I don't see the need for extra work on the shlibs handling. and In addition, either versioned replaces don't work as well for downgrades as unversioned replaces, or replaces on unpacked but not configured packages don't work as well as replaces on installed packages. Possible... downgrades are almost never tested in Debian, so there could be a variety of dpkg bugs at work here. :) Cheers, -- 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: Upcoming Section changes in the archive
Maybe it could be interesting to open an accessibility section? Maybe, maybe not. What packages would you put into it? -- bye, Joerg Getty LOL die Telefonnummer vom Arbeitsamt Mönchengladbach ist echt 404-0? Getty Soll das nen schlechter Scherz sein? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
ruby Everything about ruby, an interpreted object oriented language. java Everything about Java How about a cli section about everything related to Mono and the Common Language Infrastructure (aka .NET) ? That makes quite a number of packages now. Like the other poster, cli is very confusing. If we have enough packages (get me a list/matches :) ), im not against a section for it, but cli wouldnt be my favorite name for it. -- bye, Joerg [...]that almost anything related to intellectual property is idiotic by it's nature, [...] -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Joerg Jaspert wrote: gnustep gnustep* libgnustep* *.app *.framework I maintain a page.app package. It is right it is a gnustep application (ie it uses the gnustep framwork). However, I never use the gnustep environment. Upstream sometimes talked about rewriting Page into another language (such as C or C++) to get more contributor but did not do it yet (not enough free time). This is just to say that some *.app application are not tied to the gnustep environment (for example, I find correct that gnumeric is in the 'math' section and not in the 'gnome' section). Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- 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
Hi Marc, hi Andreas, On Freitag, 27. Februar 2009, Steve Langasek wrote: Also, I haven't seen the exim4 maintainers comment on this proposal until now. Obviously we would want to get that package to Provide: default-mta before filing bugs on other packages. Could you please take a look at 508644 and comment. Thanks. regards, Holger 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 Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote: But as this would hardcode exim4 as the default MTA for Debian in a number of packages, some better solutions have been proposed in http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best choice appearantly being 87ve1faria@frosties.localdomain which proposes that exim4 should provide default-mta, packages needing an MTA should depend on default-mta | mail-transfer-agent and the other MTAs should provide mail-transfer-agent. Then, if we want to change the default, we just need to touch two packages. I agree that this is the best solution. As per policy I'd like to gather consensus on this before mass filing bugs. Given that m-t-a is mentioned explicitly in policy, and that default-mta will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. Also, I haven't seen the exim4 maintainers comment on this proposal until now. Obviously we would want to get that package to Provide: default-mta before filing bugs on other packages. 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]. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. ciao cate [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. Probably we should be stricter. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Joerg Jaspert wrote: The new sections are: ruby Everything about ruby, an interpreted object oriented language. java Everything about Java videoVideo viewers, editors, recording, streaming fontsFont packages gnustep The Gnustep environment xfce The XFCE Desktop, fast and lightweight Desktop Environment. httpdWebservers and their modules localisationsLanguage packs debugDebug packages lisp Everything about Lisp vcs Version control systems haskell Everything about haskell zope Zope/Plone Framework database Databases kernel Kernel and Kernel modules What about creating a 'libs' section for different languages? Something like libs-ruby, libs-perl, libs-python, libs-java, libs-r, ... This would allow to split the big 'libs' section and this avoid to put libs (ie mostly automatic pulled packages) in sections where the user search for applications (for example 'java' for programs that help to write java development, ...) It is also easier for tools such as deborphan to find libraries that are not needed anymore. I know that the 'auto' flag should solve this problem but it often happens for me to switch from auto to noauto when trying to upgrade a package with 'apt-get install package' and no new version of 'package' is available (in this case, the effect of 'apt-get install package' is to mark 'package' as 'noauto') Regards, Vincent -- Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87 Unofficial pacakges: http://www-id.imag.fr/~danjean/deb.html#package APT repo: deb http://perso.debian.org/~vdanjean/debian unstable main -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Vincent Danjean wrote: What about creating a 'libs' section for different languages? Something like libs-ruby, libs-perl, libs-python, libs-java, libs-r, ... This would allow to split the big 'libs' section and this avoid to put libs (ie mostly automatic pulled packages) in sections where the user search for applications (for example 'java' for programs that help to write java development, ...) I don't think 'java' would be the right place for applications. For example, Eclipse is in devel rather than java. Same for Python, end users don't care if the application is written in Python or C, they just want to play music or edit a document or whatever. So single java, python, perl... sections looks like the right choice to me. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Fri, Feb 27, 2009 at 12:18:07AM +0100, Joerg Schilling wrote: As you don't know what grants and what duties you have when dealing with free software, please try to inform yourself. You may get into trouble if you change things that are forbidden by law. Let me quote the license person from the board of directors from the OpenSource initiave: No OpenSource license gives you all grants you need to change anything in the source. If the authors or Copyright holders of a software like, they may always sue you. If you like to avoid being sued, play nicely with the Copyright holders. Uh, citation needed. Giving you all grants you need to change anything in the source is practically the definition of an open-source licence, with the exception of removing the original copyright and licence notices. What changes have been made that are supposedly illegal? (Note that introducing new bugs is, sadly, not illegal anywhere that I know of. If it were, Microsoft would've been out of business years ago, along with probably everybody else. ;) ) -- Benjamin M. A'Lee || mail: b...@subvert.org.uk web: http://subvert.org.uk/~bma/ || gpg: 0xBB6D2FA0 -- 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?
Hi, On Fri, 2009-02-27 at 00:18 +0100, Joerg Schilling wrote: John Goerzen jgoer...@complete.org wrote: Joerg Schilling wrote: The fork distributed by Debian may however be called dubious: - The fork is in conflict with the Copyright law and thus may not be legally distributed. If your code was Free Software, then it is perfectly legal for Debian to do what it does. It seems that you first need to learn what Free Software means and what constraints the License and the Copyright law enforce. A Free software license allows you to do many things, it does definitely not allow you what Debian did. While I personally do not use wodim, simply because wodim does not inspire much confidence with me being based on cdrecord, I have a few observations: 1. If your code was licensed correctly, and there wasn't concerns about it's quality, then nobody inside Debian would have forked it. 2. I am not convinced that there is any legal issue with the fork of cdrecord as wodim; it is clearly identified that it is a fork, and anything published describing problems with cdrecord would be the opinions of wodim's authors, not the Debian project itself, or the wodim project itself. As a result, no personal harm to your reputation has been done in the context of the Urheberrechtsgesetz[1] by the fork of cdrecord itself. As a result, it appears that your argument that the fork of cdrecord being illegal is actually invalid. 3. You might be taken more seriously at this point if you didn't act like a toddler. I'm just saying... every time this subject comes up, you show up and whine and whine and whine. It's doing you no good. Try something else, like improving cdrecord with your time instead of wasting it whining here. Please note that I haven't even tried wodim. I suspect it is not any better than cdrecord, and further I don't care. All of the burning apps I use are based around libburn, which seems to have a drama-free maintainer. I consider that to be a good thing, the fact that it supports more than just CD burning without any bogus license key-based closed-source cdrecord-pro software is a plus. [1] Everyone here should read the Urheberrechtsgesetz here http://www.iuscomp.org/gla/statutes/UrhG.htm and stop listening to Joerg's bollocks. He appears to be very misinformed. If your code wasn't Free Software, then we wouldn't be using it in the first place. ISTR that your code WAS free, but now isn't. The code that was taken by Debian for the fork WAS free but now it is no longer because Debian did apply changes that are forbidden by law. What changes are those? Can you identify them? All of them is not a valid response here, just FYI. As you don't know what grants and what duties you have when dealing with free software, please try to inform yourself. You may get into trouble if you change things that are forbidden by law. I am pretty sure Eduard knows what he is doing. Let me quote the license person from the board of directors from the OpenSource initiave: No OpenSource license gives you all grants you need to change anything in the source. If the authors or Copyright holders of a software like, they may always sue you. If you like to avoid being sued, play nicely with the Copyright holders. Just because you can sue someone does not make their actions illegal. I can sue somebody for skipping a rock across a puddle in their own property, mind I would be laughed out of court for doing this, but I hope you see my point here. Eduard Bloch made a big mistake, he started a deffamation campaign against cdrtools and Debian made the mistake to support Eduard Bloch. I don't know whether you are able to change the named mistake, but please note that I am the copyright holder for the vast majority of the cdrtools code. I am licensing the code and I am able to sue people for Copyright violations on the code, Debian is not. If Debian claims they might be sued because of so called license problems in the original software, this is just FUD. I am not interested to sue people as long as there is a chance to have a solution that does not need a court. If Debian however continues to attack me, Debian should be aware that at some point I am forced to sue people for violating GPL and Copyright law with the fork. People who make threats should be fully prepared to deal with backlash from those threats. How will Fraunhofer handle such a public relations disaster? You may want to keep this in consideration before continuing with legal threats, as I am pretty sure that it will be all over slashdot, and Fraunhofer will likely be asked for a comment. So let me ask: Is Debian willing to play nicely with me in the future or is Debian interested in continuing the attacks? In case you don't know: My main interest is to make sure that the software I write remains free and I am doing whaterver I need to
Re: Upcoming Section changes in the archive
On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: We plan on changing the current sections in the archive. With the rapid growth of archive, many of them have become too big to be useful anymore. According to my knowledge of dak, the sections are global. Which means that we don't have to worry about a possible kernel update for lenny+1/2. Am I correct with that? kernel Kernel and Kernel modules Does this only include the user usable parts or also internal development packages? linux-support-* linux-tree-* As you explicitely list this, I assume the later. Bastian -- Captain's Log, star date 21:34.5... signature.asc Description: Digital signature
Re: Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Thu, Feb 26, 2009 at 11:51:39PM -0800, Steve Langasek wrote: On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote: But as this would hardcode exim4 as the default MTA for Debian in a number of packages, some better solutions have been proposed in http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best choice appearantly being 87ve1faria@frosties.localdomain which proposes that exim4 should provide default-mta, packages needing an MTA should depend on default-mta | mail-transfer-agent and the other MTAs should provide mail-transfer-agent. Then, if we want to change the default, we just need to touch two packages. The referred post mentions an actual package rather than just a provides: field. It makes a difference. Given that m-t-a is mentioned explicitly in policy, and that default-mta will be a virtual package, 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. Rawr?!? -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- 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
Giacomo A. Catenazzi wrote: Steve Langasek wrote: On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote: But as this would hardcode exim4 as the default MTA for Debian in a number of packages, some better solutions have been proposed in http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best choice appearantly being 87ve1faria@frosties.localdomain which proposes that exim4 should provide default-mta, packages needing an MTA should depend on default-mta | mail-transfer-agent and the other MTAs should provide mail-transfer-agent. Then, if we want to change the default, we just need to touch two packages. I agree that this is the best solution. As per policy I'd like to gather consensus on this before mass filing bugs. Given that m-t-a is mentioned explicitly in policy, and that default-mta will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. Also, I haven't seen the exim4 maintainers comment on this proposal until now. Obviously we would want to get that package to Provide: default-mta before filing bugs on other packages. 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]. I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. BTW mta is IMHO wrong. In most of the cases (IIRC) programs needs only a sendmail program. Should we split the dependencies on real-mta and only on a sendmail provider. BTW we should also rule a minimal set of sendmail interface (which option should be implemented). Actually every MTA has different sets of sendmail options, but I don't yet know about problems. ciao cate -- 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?
John Goerzen jgoer...@complete.org wrote: The code that was taken by Debian for the fork WAS free but now it is no longer because Debian did apply changes that are forbidden by law. When will you enumerate these? Until you do, I can't see your arguments being taken seriously by anyone. As long as Debian hides related Bug reports and as long as Debian continues to publish slander against me and my software, I cannot see any will to change the current situation that is 100% a result of activities from some people that called themself Debian maintainers. Explaining the situation in more details, than I did in the open during the past years already, takes time. Please understand that I am not going to waste my time with trolls. Debian as whole did lose any credibility because of the cdrtools attacks that have been initated by Eduard Bloch and that have been supported by other Debian people. If you are seriously interested to change this situation, give me a strong sign that there is a will at Debian to get rid of the situation that has been created by Eduard Bloch by attacking me and my projects in 2004 . As I mentioned already: the license change in cdrtools was a _reaction_ on the attacks run by Eduard Bloch and others. The attacks from this person started in May 2004 as personal attacks and increased over time. I understand that in bigger associations there is a higher probability to also have bad people but any assicoation needs to find ways to deal with problems that result from bad people's actions. Are aou interested to change this situation? 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: Upcoming Section changes in the archive
On Fri, Feb 27, 2009 at 07:19:11AM +, Matthew Johnson wrote: Should Java libs be in lib or libdevel (they are both). This is one of the reasons we've wanted a Java section. I wouldn't mind a proper discussion on the pros and cons of both. That'd help me for debtags as well, where java libs, but also perl, python and ruby modules for example, fit both as development libraries and as shared libraries. My general idea is asking: would you like it to be hidden in a package manager as dependency-only stuff? If a library can be used as a development library, then maybe not, therefore 'libdevel'. But this is a nontrivial argument that is worth of more discussion than just my gut feelings. Ciao, Enrico -- 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?
I am the psychotherapist. Please, describe your problems. Each time you are finished talking, type RET twice. Le vendredi 27 février 2009 11:03:55 Joerg Schilling, vous avez écrit : John Goerzen jgoer...@complete.org wrote: The code that was taken by Debian for the fork WAS free but now it is no longer because Debian did apply changes that are forbidden by law. When will you enumerate these? Until you do, I can't see your arguments being taken seriously by anyone. As long as Debian hides related Bug reports and as long as Debian continues to publish slander against me and my software, I cannot see any will to change the current situation that is 100% a result of activities from some people that called themself Debian maintainers. Is it because is 100% a result of activities from some people that called themself debian maintainers that you came to me? Explaining the situation in more details, than I did in the open during the past years already, takes time. Please understand that I am not going to waste my time with trolls. Does it bother you that you are not going to waste your time with trolls? Debian as whole did lose any credibility because of the cdrtools attacks that have been initated by Eduard Bloch and that have been supported by other Debian people. Are you sure that is the real reason? If you are seriously interested to change this situation, give me a strong sign that there is a will at Debian to get rid of the situation that has been created by Eduard Bloch by attacking me and my projects in 2004 . When did you first know that there is a will at debian to get rid of the situation that has been created by eduard bloch by attacking you and your projects in 2004? As I mentioned already: the license change in cdrtools was a _reaction_ on the attacks run by Eduard Bloch and others. Why do you say that? The attacks from this person started in May 2004 as personal attacks and increased over time. Earlier you said is 100% a result of activities from some people that called themself debian maintainers? I understand that in bigger associations there is a higher probability to also have bad people but any assicoation needs to find ways to deal with problems that result from bad people's actions. Is the fact that in bigger associations there is a higher probability to also have bad people but any assicoation needs to find ways to deal with problems that result from bad people's actions the real reason? Are aou interested to change this situation? Maybe the cdrtools attacks that have been initated by eduard bloch and that have been supported by other debian people have something to do with this. Jörg Can you elaborate on that? -- 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 -- Jean Parpaillon - Kerlabs Engineer Bâtiment Germanium 80 avenue des buttes de Coësmes 35700 Rennes - France Tel.: +33 6 80 332 73 85 http://www.kerlabs.com/ signature.asc Description: This is a digitally signed message part.
Re: xcdroast does no longer work with wodim: Who to blame?
On Thu, 2009-02-26 at 15:47 +0100, Joerg Schilling wrote: Before Eduard Bloch made insane modifications, the code was GPLv2 and legal. Now the cude is undistributable because of modifications in the fork that are incompatible with the Copyright law. See my bug report from December 2006. Please provide a URL for this supposed bug report. I have spent the last 30 minutes datamining bugs.debian.org for it, and have found nothing other than replies to other bug reports from you which mostly have to do with whining. William signature.asc Description: This is a digitally signed message part
Re: Upcoming Section changes in the archive
Hi, On Freitag, 27. Februar 2009, Bastian Blank wrote: According to my knowledge of dak, the sections are global. Which means that we don't have to worry about a possible kernel update for lenny+1/2. Am I correct with that? Can you/anybody please explain how this is related to the sections? regards, Holger signature.asc Description: This is a digitally signed message part.
Re: xcdroast does no longer work with wodim: Who to blame?
Benjamin M. A'Lee bma-li...@subvert.org.uk wrote: On Fri, Feb 27, 2009 at 12:18:07AM +0100, Joerg Schilling wrote: As you don't know what grants and what duties you have when dealing with free software, please try to inform yourself. You may get into trouble if you change things that are forbidden by law. Let me quote the license person from the board of directors from the OpenSource initiave: No OpenSource license gives you all grants you need to change anything in the source. If the authors or Copyright holders of a software like, they may always sue you. If you like to avoid being sued, play nicely with the Copyright holders. Uh, citation needed. Giving you all grants you need to change anything in the source is practically the definition of an open-source licence, with the exception of removing the original copyright and licence notices. I recommend you to read the Copyright law: http://www.gesetze-im-internet.de/urhg/index.html There are rights that _cannot_ be given away. 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?
On Fri, Feb 27, 2009 at 11:40:45AM +0100, Joerg Schilling wrote: Benjamin M. A'Lee bma-li...@subvert.org.uk wrote: On Fri, Feb 27, 2009 at 12:18:07AM +0100, Joerg Schilling wrote: As you don't know what grants and what duties you have when dealing with free software, please try to inform yourself. You may get into trouble if you change things that are forbidden by law. Let me quote the license person from the board of directors from the OpenSource initiave: No OpenSource license gives you all grants you need to change anything in the source. If the authors or Copyright holders of a software like, they may always sue you. If you like to avoid being sued, play nicely with the Copyright holders. Uh, citation needed. Giving you all grants you need to change anything in the source is practically the definition of an open-source licence, with the exception of removing the original copyright and licence notices. I recommend you to read the Copyright law: http://www.gesetze-im-internet.de/urhg/index.html There are rights that _cannot_ be given away. Which of these rights do you consider is being infringed? -- Benjamin M. A'Lee || mail: b...@subvert.org.uk web: http://subvert.org.uk/~bma/ || gpg: 0xBB6D2FA0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: We plan on changing the current sections in the archive. With the rapid growth of archive, many of them have become too big to be useful anymore. I propose 'oldlibs' to be renamed to 'deprecated'. That would also fit, for example, packages abandoned upstream, or packages that have a better alternative, but that still have users. It will also provide a path for planning removals of packages from the archive, when the maintainer is still ok with maintaining a package and fixing its bugs, but in his/her long term plan the package should eventually go away. Ciao, Enrico -- 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?
Josselin Mouette j...@debian.org writes: Le jeudi 26 février 2009 à 12:58 +0100, Alexander Reichle-Schmehl a écrit : Please, not again. The arguments have been exchanged ad invinitum a couple of times already. So if there is nothing new to bring up, please don't restart the discussion. Why? It’s quite funny to discuss with Joerg Schilling. No, it's not. It is juvenile, and if it doesn't constructively advance the discussion, needlessly inflames hostile sentiment. I prefer to do it in private, but it is good to have some of the discussions in public: I believe it strengthens the project by giving developers a common target, instead of hurting each other in internal fights. I disagree completely. It weakens the project, by encouraging puerile behaviour no better than poking an anthill. To remain strong, a community needs to deprecate such behaviour, not encourage it. Far better to keep those discussions outside the context of a Debian discussion forum, if they need to happen at all, instead of playing games that require attacks upon others. Please stop making the situation worse. If you want a way for people to let off steam, find a way to do it that doesn't involve treating anyone as a “target”. -- \ “Two possibilities exist: Either we are alone in the Universe | `\ or we are not. Both are equally terrifying.” —Arthur C. Clarke, | _o__) 1999 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
On Fri, Feb 27, 2009 at 07:13:07AM +, Matthew Johnson wrote: localization is the spelling given by the OED, so it is correct in all locales. It doesn't even list localisation as an alternative spelling. The OED lists plenty of examples of localisation and localise; whether you consider the usage right or wrong, it's certainly widespread. Cue the argument over a dictionary's role as describing or prescribing use of language... I couldn't care less, but language-packs would indeed avoid the whole argument. Dave (en_GB) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Le vendredi 27 février 2009 à 01:19 +, Sam Morris a écrit : I don’t like the name either, but can you think of a better one? We could use “mono”, but it’s the implementation name. 'clr' (common language runtime)? It's the acronym that MS uses quite a bit. CLR is the acronym for the interpreter, while CLI covers the whole thing. Or 'msclr'? 'dotnetclr'? I don’t like the idea of naming the section after another implementation. We could use 'cli-mono', or 'ecma-cli'. -- .''`. 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: Upcoming Section changes in the archive
Hi there! Cc:ing the Debian Common Lisp mailing list. On Fri, 27 Feb 2009 02:02:03 +0100, Aaron M. Ucko wrote: Joerg Jaspert jo...@debian.org writes: Its lisp. Not one special part of it, just lisp. So other dialects as well, if someone gets me a list of packages (or matches) for it. [...] cl-* FYI, as Aaron already showed with his list, ome packages (especially the non-library ones) do not have the cl-* suffix. StumpWM is missing, for example. *-el There are some packages which have something after the -el suffix: iiimf-client-el-bin - Utility of IIIMF frontend for Emacs speechd-el-doc-cs - speechd-el documentation in Czech w3-el-e21 - Web browser for GNU Emacs 21 w3m-el-snapshot - simple Emacs interface of w3m (development version) However, we cannot add the *-el-* filter because this will also match false positives, at least: libcommons-el-java - Implementation of the JSP2.0 Expression Language interpreter myspell-el-gr - Greek (el_GR) dictionary for myspell And there is at least one package which is still missing: w3-url-e21 - URL library for use by w3-el-e21 BTW, while compiling that list, I also ran across a couple more httpds: araneida and hunchentoot. With my Common Lisp maintainer hat on, I am not sure I would like araneida and hunchentoot to be placed in the httpd section. As Joerg already said in the thread, I think we need to define if the language the program is written in is more important than the function of the program itself. Thx, bye, Gismo / Luca pgpt7ExIWGNDo.pgp Description: PGP signature
Re: xcdroast does no longer work with wodim: Who to blame?
On Fr, 27 Feb 2009, Ben Finney wrote: that doesn't involve treating anyone as a “target”. It's not anyone, it is simply one, and that one is making himself anyway prime target with openly declaring all Linux developers as completely incompetent programmers, and he (who has never written an operating system, although contributing to Solaris) is the only one with ideas on how everything should be. Come on, that *is* a good target, even of higher interest. This guy should be brought either down to reality, or to a (uups I don't utter it here or I will get sooo many flames). Best wishes Norbert --- Dr. Norbert Preining prein...@logic.atVienna University of Technology Debian Developer prein...@debian.org Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- Out of memory. We wish to hold the whole sky, But we never will. --- Windows Error Haiku -- 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?
William Pitcock neno...@sacredspiral.co.uk wrote: The fork distributed by Debian may however be called dubious: - The fork is in conflict with the Copyright law and thus may not be legally distributed. If your code was Free Software, then it is perfectly legal for Debian to do what it does. It seems that you first need to learn what Free Software means and what constraints the License and the Copyright law enforce. A Free software license allows you to do many things, it does definitely not allow you what Debian did. While I personally do not use wodim, simply because wodim does not inspire much confidence with me being based on cdrecord, I have a few observations: 1. If your code was licensed correctly, and there wasn't concerns about it's quality, then nobody inside Debian would have forked it. This is an asumption that is only true in a nice world. Unfortunately, there are some Debian maintainers that rather attack software authors instead of colaborating. wodim has been created by Eduard Bloch because he is a person who is interested in actively preventing collaboration. The attacks run by him started in May 2004 and at that time he did already create broken (buy him) versions of cdrecord and shipped them as Debian package. 2. I am not convinced that there is any legal issue with the fork of cdrecord as wodim; it is clearly identified that it is a fork, and There definitely _is_ a major legal problem with the fork. 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?
On Fri, 2009-02-27 at 11:56 +0100, Joerg Schilling wrote: William Pitcock neno...@sacredspiral.co.uk wrote: The fork distributed by Debian may however be called dubious: - The fork is in conflict with the Copyright law and thus may not be legally distributed. If your code was Free Software, then it is perfectly legal for Debian to do what it does. It seems that you first need to learn what Free Software means and what constraints the License and the Copyright law enforce. A Free software license allows you to do many things, it does definitely not allow you what Debian did. While I personally do not use wodim, simply because wodim does not inspire much confidence with me being based on cdrecord, I have a few observations: 1. If your code was licensed correctly, and there wasn't concerns about it's quality, then nobody inside Debian would have forked it. This is an asumption that is only true in a nice world. Unfortunately, there are some Debian maintainers that rather attack software authors instead of colaborating. It is impossible to collaborate when you add invariant sections to the code. Well done. Generally it is considered to be bad taste when you change the licensing rules abruptly. wodim has been created by Eduard Bloch because he is a person who is interested in actively preventing collaboration. I am sorry that you are hurt about that, but get over it. The attacks run by him started in May 2004 and at that time he did already create broken (buy him) versions of cdrecord and shipped them as Debian package. 2. I am not convinced that there is any legal issue with the fork of cdrecord as wodim; it is clearly identified that it is a fork, and There definitely _is_ a major legal problem with the fork. I have a solution that I think will make us all happy. Why not just get rid of cdrkit and write some nice wrappers for cdrecord and other components of cdrtools using libburn/libisofs. That way we get a CD/DVD/BD burning engine that isn't originated from *you*, so *you* can't complain about it anymore. If cdrkit is as buggy as you claim, and you are so busy trolling, then I feel that we cannot hold confidence in your product either. Good job on that. After all, if we aren't using your code or any derivative of your code, then you have no reason to complain at us. William signature.asc Description: This is a digitally signed message part
Re: Upcoming Section changes in the archive
Le vendredi 27 février 2009 à 09:03 +0100, Joerg Jaspert a écrit : Like the other poster, cli is very confusing. If we have enough packages (get me a list/matches :) ), im not against a section for it, but cli wouldnt be my favorite name for it. I’m not sure for the section name, but here is a list of matches: monodoc* monodevelop* mono-* libmono* *-mono *-cil (except cl-cil which goes to lisp) *-cil-* cli-* *-sharp2* -- .''`. 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?
On Fri, 2009-02-27 at 12:26 +0100, Joerg Schilling wrote: William Pitcock neno...@sacredspiral.co.uk wrote: are some Debian maintainers that rather attack software authors instead of colaborating. It is impossible to collaborate when you add invariant sections to the code. Well done. This is a text that has been created in collaboration a former Debian maintainer. So what? Generally it is considered to be bad taste when you change the licensing rules abruptly. It is generally considered bad taste to offend and to try to blackmail the Copyright holder. As this has been done by the Debian package maintainer, Debian should not complain. Note that the license change was caused by attacks from a Debian maintainer and that the license change that was done in an agreement with the other authors. What does Eduard being a Debian maintainer have to do with it? Also, ISTR Eduard no longer being involved in Debian at all, or cdrkit. William signature.asc Description: This is a digitally signed message part
Re: xcdroast does no longer work with wodim: Who to blame?
On Fri, Feb 27, 2009 at 11:56:38AM +0100, Joerg Schilling wrote: William Pitcock neno...@sacredspiral.co.uk wrote: 2. I am not convinced that there is any legal issue with the fork of cdrecord as wodim; it is clearly identified that it is a fork, and There definitely _is_ a major legal problem with the fork. Please provide specific details, rather than vaguely defined major problems. Are we talking about copyright infringement, licence infringement, or what? Which lines in which files? Your current SCO approach is not productive. Thanks, 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. -- 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 vendredi 27 février 2009 à 10:57 +, Benjamin M. A'Lee a écrit : http://www.gesetze-im-internet.de/urhg/index.html There are rights that _cannot_ be given away. Which of these rights do you consider is being infringed? He’s talking about moral rights, which exist in several Europe countries. They include: * the right to get the work back and ask everyone using it to stop doing so, with the condition to indemnify them for the losses (in France, this right does not apply to software, and IIRC this is the same in Germany); * the right to oppose a modification of the work - for Software, this does only apply to modifications affecting the honor or reputation of the author. This is the latter right that Jörg Schilling is trying to apply. But for that he needs to show how the modifications affect his honor or reputation. So far, the only things affecting JS’s honor and reputation are the emails he sent, so I think we’re pretty safe on this topic. -- .''`. 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: Upcoming Section changes in the archive
On Fri, Feb 27, 2009 at 02:53:04AM -0300, Felipe Augusto van de Wiel (faw) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26-02-2009 23:10, Darren Salt wrote: I demand that Frans Pop may or may not have written... Joerg Jaspert wrote: [...] The new sections are: localisationsLanguage packs I'd prefer localization. Whereas I'd prefer localisation... What about using 'l10n'? It tends to be well know these days, and would avoid the s|z problem. :-) The terms i18n and l10n might be well known amongst developers, but I contend that most users won't know (or should need to know) arcane abbreviations when we could use the full word. 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. -- 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?
William Pitcock neno...@sacredspiral.co.uk wrote: are some Debian maintainers that rather attack software authors instead of colaborating. It is impossible to collaborate when you add invariant sections to the code. Well done. This is a text that has been created in collaboration a former Debian maintainer. Generally it is considered to be bad taste when you change the licensing rules abruptly. It is generally considered bad taste to offend and to try to blackmail the Copyright holder. As this has been done by the Debian package maintainer, Debian should not complain. Note that the license change was caused by attacks from a Debian maintainer and that the license change that was done in an agreement with the other authors. 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
Making some tags mandatory
[if help is needed with following the proposal below: a list of tags and
their description can be found at:
* http://debtags.alioth.debian.org/tags/vocabulary.gz
* /var/lib/debtags/vocabulary (if you have debtags installed)
* http://packages.debian.org/about/debtags (formatted on the web)
and can be searched with 'debtags tagsearch' or using the tag editor
at http://debtags.alioth.debian.org/edit.html in the 'all' and
'search' views]
Hello,
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 :)
While I see a list of well defined sections that could still make a lot
of sense and carry a very practical meaning (namely, libs, libdevel,
deprecated (former oldlibs), debug, locale, kernel and data (for
foo-data packages)), other sections are clearly minor and belong
elsewhere (like the programming language for a library).
You said that debtags cannot yet replace sections because it is not
assured that all packages have tags: you have a point. Let's take care
of it.
I say that with the number of tags in the vocabulary approacing 600, we
just can't ask maintainer, ftp-masters, or anyone really, to know all of
them; but I can certainly come up with a 'core' list of tags that are
well defined enough, and that we can safely expect maintainers to know
about.
This is what I have to offer:
* The proposal
At the end of this mail is the list that I propose: it's 138 of them,
but grouped as they are, they should be quite clear to grasp. I
consider these groups of tags (debtags calls them facets) to be mature
and uncontroversial enough to be made official and to ask maintaners to
take care of them.
Besides proposing the tags, I offer to implement these three features
within a month from when we agree on a way for maintainers to add them
to the control file:
- For packages with no tags in the control file, take the tags from the
review tag set as we have now
- For packages with tags in the control file, take tags in facets
{role, implemented-in, devel, interface, uitoolkit, accessibility,
admin} from the control file, and all the other facets from the
reviewed tag set.
- Provide a way for maintainers to show differences between the tags in
their control file and the submissions on the debtags web interface,
to be used as a sort of hint
I also offer to write lintian tests to ensure some consistency (role::*
must be there, implemented-in::* must be there if role::program is
there, and so on).
Note that this proposal can be implemented right now, as it introduces
new functionality without interfering with the existing one.
* Future developments
In the future more groups of tags can become 'core', after a round of
discussion, polishing, and testing. This discussion and polishing can
be done in the debtags side, without bothering/boring ftp-masters.
Tags first in the line to become core could be, for example, game::*,
hardware::*, mail::*, web::*, x11::*.
Some other groups of tags (biology::*, field::*, junior::*, made-of::*,
protocol::*, scope::*, suite::* and more) are probably better left to be
managed by groups of field experts. The gnome/kde team is probably
better than any single maintainer in deciding what should have the
suite::gnome/kde tag. Similarly, debian-med or debian-science people
can be called to have a say on tags of their interest.
Also, some tags like those in use::* or work-with::* are better assigned
the other way round, with people picking one tag and working to make
sure that the list of packages with that tag makes sense.
I am happy to come up with a workflow that allows such groups to have
the final say on their tags, and get the result integrated with the
rest: there are already several items in my todo-list that go in this
direction. Maybe, even if game maintainers will easily be able to pick
a game::* tag, we will even decide that it will make more sense, for
consistency, that game::* tags will be managed by the Debian Games team.
But this is for the future. For now, let's stick to the short term
proposal.
* The list
Role of the package in the archive (mandatory for all packages):
role::app-data - Application Data
role::data - Standalone Data
role::debug-symbols - Debugging symbols
role::devel-lib - Development Library
role::documentation - Documentation
role::dummy - Dummy Package
role::kernel - Kernel and Modules
role::metapackage - Metapackage
role::plugin - Plugin
role::program - Program
role::shared-lib - Shared Library
role::source - Source Code
Language that the package is implemented in (mandatory for all packages
mostly consisting of software):
implemented-in::ada - Ada
implemented-in::c - C
implemented-in::c++ - C++
implemented-in::c-sharp - C#
Re: Upcoming Section changes in the archive
Bastian Blank wrote: On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: According to my knowledge of dak, the sections are global. Which means that we don't have to worry about a possible kernel update for lenny+1/2. Am I correct with that? The sections are defined in the override files [1], which are per codename. Special case is current testing (i.e. squueze), for which the overrides are always kept the same as sid. I assume the proposed changes would only affect sid + squeeze, not sarge and lenny. So you probably do have to worry about lennynhalf as that will introduce new packages which should go in the current sections. So either they will need to have the correct old sections in the control file, or the FTP masters will have to correct them in the overrides file for lenny during NEW processing. For existing packages that are uploaded to stable (p-u) with a wrong section by accident there is no problem as the existing overrides for lenny would correct that automatically. Cheers, FJP /me hopes he's got all that right :-) [1] See: merkel:/org/ftp.debian.org/scripts/override signature.asc Description: This is a digitally signed message part.
Re: xcdroast does no longer work with wodim: Who to blame?
William Pitcock neno...@sacredspiral.co.uk wrote: Generally it is considered to be bad taste when you change the licensing rules abruptly. It is generally considered bad taste to offend and to try to blackmail the Copyright holder. As this has been done by the Debian package maintainer, Debian should not complain. Note that the license change was caused by attacks from a Debian maintainer and that the license change that was done in an agreement with the other authors. What does Eduard being a Debian maintainer have to do with it? Also, ISTR Eduard no longer being involved in Debian at all, or cdrkit. Then it seems the right time for Debian to excuse for what Mr. Bloch did under the name of Debian and to start to collaborate again as usual before he appeared at Debian. 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?
Roger Leigh rle...@codelibre.net wrote: On Fri, Feb 27, 2009 at 11:56:38AM +0100, Joerg Schilling wrote: William Pitcock neno...@sacredspiral.co.uk wrote: 2. I am not convinced that there is any legal issue with the fork of cdrecord as wodim; it is clearly identified that it is a fork, and There definitely _is_ a major legal problem with the fork. Please provide specific details, rather than vaguely defined major problems. Read the related entry in the Debian bugtracking system before asking me for details. 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
who killed bambi?
flaming, trolling and shitting on -devel is not useful for the general audience, even is some people think it is. /me fully agrees with 874oygdu1r@benfinney.id.au signature.asc Description: This is a digitally signed message part.
Re: Upcoming Section changes in the archive
On Fri, Feb 27, 2009 at 11:04:36AM +0100, Luca Capello wrote:
FYI, as Aaron already showed with his list, ome packages (especially the
non-library ones) do not have the cl-* suffix. StumpWM is missing,
for example.
Note that the current language-oriented sections (python, perl, and
the just proposed ocaml and ruby) are meant to contain stuff related
to develop in that language. They are not meant to contain
everything implemented in a given language.
While it is quite clear that we are rapidly approaching the inherent
problem of sections (i.e., they cannot be orthogonal), I believe that
the above rule is quite agreed upon.
Hence, IMHO, StumpWM should be in a section related to X11 or window
managers, not in lisp.
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: xcdroast does no longer work with wodim: Who to blame?
Le vendredi 27 février 2009 à 12:37 +0100, Joerg Schilling a écrit : Then it seems the right time for Debian to excuse for what Mr. Bloch did under the name of Debian and to start to collaborate again as usual before he appeared at Debian. Change your license, and maybe we’ll be able to think of collaborating. As for excuses, I guess we could be fine with excuses from you for all the shit you said about Debian for the last years. -- .''`. 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: Making some tags mandatory
On Fri, Feb 27, 2009 at 11:48:30AM +, Enrico Zini wrote: - For packages with no tags in the control file, take the tags from the review tag set as we have now Are packages supposed to do this? If they are it'd probably be worth announcing more generally to let people know it's OK to do this. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Bastian Blank wrote: On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: According to my knowledge of dak, the sections are global. Which means that we don't have to worry about a possible kernel update for lenny+1/2. Am I correct with that? The sections are defined in the override files [1], which are per codename. Special case is current testing (i.e. squueze), for which the overrides are always kept the same as sid. I assume the proposed changes would only affect sid + squeeze, not sarge and lenny. So you probably do have to worry about lennynhalf as that will introduce new packages which should go in the current sections. So either they will need to have the correct old sections in the control file, or the FTP masters will have to correct them in the overrides file for lenny during NEW processing. [...] Seeing that the change of sections could pose some technical problems (not only challenges implementing them) as well, let me ask one (possibly stupid) question: Why do we need sections at all? All that policy states is that it simplifies some handling of packages. If it's about partitioning the archive into manageable components (some algorithm traversing each component linearly or whatever), why not just group them by source package names, as already done in other situations? Thanks a lot, Michael pgpA8snxadbgM.pgp Description: PGP signature
Re: xcdroast does no longer work with wodim: Who to blame?
Note: you still haven’t fixed your email client. Le vendredi 27 février 2009 à 13:34 +0100, Joerg Schilling a écrit : Josselin Mouette j...@debian.org wrote: Le vendredi 27 février 2009 à 12:37 +0100, Joerg Schilling a écrit : Then it seems the right time for Debian to excuse for what Mr. Bloch did under the name of Debian and to start to collaborate again as usual before he appeared at Debian. Change your license, and maybe we???ll be able to think of collaborating. You seem to be unable for collaboration as you try to blackmail me. Maybe you should buy yourself an English dictionary. Since you don’t seem to understand this word, the German word for it is “Erpressung”. This is a serious accusation, and it has nothing to do with imposing conditions (Vorbedingung) or negotiation (Verhandlung). For example, if you go to a butcher’s, you can have a steak, but you won’t have it until you pay. That’s not blackmailing. The butcher is not forcing you to pay: you can just go away without a steak and that’s all. The same goes for Debian. You can collaborate with us, but only about software that’s released under a free licensing scheme. If you don’t want that, you can go piss away some other people, and we won’t care. That’s all. -- .''`. 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?
On Fri, 2009-02-27 at 12:38 +0100, Joerg Schilling wrote: Roger Leigh rle...@codelibre.net wrote: On Fri, Feb 27, 2009 at 11:56:38AM +0100, Joerg Schilling wrote: William Pitcock neno...@sacredspiral.co.uk wrote: 2. I am not convinced that there is any legal issue with the fork of cdrecord as wodim; it is clearly identified that it is a fork, and There definitely _is_ a major legal problem with the fork. Please provide specific details, rather than vaguely defined major problems. Read the related entry in the Debian bugtracking system before asking me for details. Can you provide a URL to this entry? I have still yet to find it. William signature.asc Description: This is a digitally signed message part
Re: xcdroast does no longer work with wodim: Who to blame?
Josselin Mouette j...@debian.org wrote: Le vendredi 27 février 2009 à 12:37 +0100, Joerg Schilling a écrit : Then it seems the right time for Debian to excuse for what Mr. Bloch did under the name of Debian and to start to collaborate again as usual before he appeared at Debian. Change your license, and maybe we???ll be able to think of collaborating. You seem to be unable for collaboration as you try to blackmail me. Have a nice day and try to steal other people's time. 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: Proposal to improve package configuration upgrades
Stefano Zacchiroli z...@debian.org writes: I can agree, at least in theory. But as we all known, due to how source code tends to work, in 90% of the cases automatic merges do the right thing. Well, of course I cannot prove that number, but my personal feelings is that with a high confidence automatic merges do the right thing. I think your numbers are right. The main problem I see is that the automatic merge will not be able to inform the user whether the merge is correct or not. In case of merge failure, the application will exit on error and leave the average user in the dark. Even 10% of this kinf of failure will be badly perceived. You know, in the general case it is an undecidable problem, so I seriously doubt Config::Model can be the silver bullet. It's not as I already know that Config::Model cannot address *all* config files. Possibly you can get a good coverage of most of the files we have under /etc which have a trivial structure (hence the questions raised by other people: how many of those files in a typical installation you can cover?). Potentially, I'd say 90% of the files (very ballpark figure). But the configuration files need to be created. Config::Model is designed to reduce the work (and maintenance) work as the model are specifed in a data structure. This data structure can be created and maintained with a GUI (Config::Model::Itself). But then we are back at the issue of a 80-20 problem, and I see the VCS solution as more flexible and more readily available. Agreed. But VCS solution is a 80% success/20% silent failure. Config::Model is a 80% success/20% abort. The latter should be easier to deal with for average user. But again, it looks to me that the two approaches can coexist. Absolutely: Something like try Config::Model, if it fails (missing or incomplete model) may be VCS merge with mandatory user interaction or usual ucf question. ... now it is only the two of us which needs to stop talking and start proposing patches as needed :-) :-) For this I need a candidate package with a package maintainer willing to experiment the patch I might send... All the best -- Dominique Dumont Delivering successful solutions requires giving people what they need, not what they want. Kurt Bittner irc: domidumont at irc.freenode.net ddumont at irc.debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Hi Stefano! Cc:ing again the Debian Common Lisp mailing list, please keep it! On Fri, 27 Feb 2009 13:02:59 +0100, Stefano Zacchiroli wrote: On Fri, Feb 27, 2009 at 11:04:36AM +0100, Luca Capello wrote: FYI, as Aaron already showed with his list, ome packages (especially the non-library ones) do not have the cl-* suffix. StumpWM is missing, for example. Note that the current language-oriented sections (python, perl, and the just proposed ocaml and ruby) are meant to contain stuff related to develop in that language. They are not meant to contain everything implemented in a given language. While I agree, this could pose a major problem for e.g. compilers: CLISP (or any other CL compiler) is used to develop CL applications *and* to start them. NB, you can create a CL executable, but this will be a snapshot of the compiler, i.e. you start the compiler, then load your application and finally save the status as an image, which can then be loaded as a stand-alone executable. However, some CL compilers (e.g. GCL and ECL) can produce real executables. While it is quite clear that we are rapidly approaching the inherent problem of sections (i.e., they cannot be orthogonal), I believe that the above rule is quite agreed upon. Hence, IMHO, StumpWM should be in a section related to X11 or window managers, not in lisp. As far as this is the general case, I am fine as well. It is just that I would like to avoid some applications in one section and some in the other. Thx, bye, Gismo / Luca pgpfEpTAatqQ2.pgp Description: PGP signature
RFH: cheese
Hi, the GNOME team is currently maintaining cheese, a program to take shots from a webcam. However, while we have no particular trouble to maintain it (it’s a small package), none of the maintainers currently owns a webcam. Therefore, it would be nice if someone with a webcam could give us a hand with the bug reports and the interaction with the GStreamer video input. Thanks, -- .''`. 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: Upcoming Section changes in the archive
On Fri, 27 Feb 2009, Joerg Jaspert wrote: Like the other poster, cli is very confusing. If we have enough packages (get me a list/matches :) ), im not against a section for it, but cli wouldnt be my favorite name for it. I would suggest c-sharp for the section. 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: RFH: cheese
I have a laptop with a webcam and would be willing to assist. What version would i need to run. I am currently using lenny. I am willing to upgrade to a newer version. What documents would I need to familiarize myself with to be able to assist. I am not a Debian Developer. But I am a UNIX admin. So, I have some knowledge. On Feb 27, 2009 7:19am, Josselin Mouette j...@debian.org wrote: Hi, the GNOME team is currently maintaining cheese, a program to take shots from a webcam. However, while we have no particular trouble to maintain it (it’sa small package), none of the maintainers currently owns a webcam. Therefore, it would be nice if someone with a webcam could give us a hand with the bug reports and the interaction with the GStreamer video input. Thanks, -- .''`. 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.
Re: RFH: cheese
On Fri, Feb 27, 2009 at 6:49 PM, Josselin Mouette j...@debian.org wrote: the GNOME team is currently maintaining cheese, a program to take shots from a webcam. However, while we have no particular trouble to maintain it (it’s a small package), none of the maintainers currently owns a webcam. I will be happy to help in any debugging, testing etc team wants. I love this program cheese - it saves me to boot into Mac OS, only for taking photos. -- Cheers, Kartik Mistry | 0xD1028C8D | IRC: kart_ Debian GNU/Linux Developer Blog.en: ftbfs.wordpress.com Blog.gu: kartikm.wordpress.com -- 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
Norbert Preining prein...@logic.at (27/02/2009): it is quite hard to get definitive answer on the above license. Interestingly the Debian wiki says that In contrast to the CC-SA 2.0 license, version 3.0 is considered to be compatible to the DFSG. and there are many discussions about the CC-BY-SA but no definitive answer. ISTR (some of) -legal@ saying not DFSG-compliant, ftpmasters saying yes, but that's only my (bad) memory. Does anyone know anything about that license? Looking at the pool: | k...@gluck:/org/lintian.debian.org/laboratory/source$ grep -i cc-by-sa */debfiles/copyright | botan/debfiles/copyright:License: CC-BY-SA-2.5 | botan-devel/debfiles/copyright:License: CC-BY-SA-2.5 | freedink-data/debfiles/copyright:License: CC-BY-SA 3.0 Unported | freedink-data/debfiles/copyright:License: GPLv3+ | Art Libre | CC-BY-SA | freedink-data/debfiles/copyright:License: GPLv3+ | Art Libre | CC-BY-SA | freedink-data/debfiles/copyright:License: GPLv3+ | Art Libre | CC-BY-SA | freedink-data/debfiles/copyright:License: CC-BY-SA | gnuit/debfiles/copyright: CC-BY-SA means the Creative Commons Attribution-Share Alike 3.0 | gnuit/debfiles/copyright: under CC-BY-SA on the same site at any time before August 1, 2009, | grub2-splashimages/debfiles/copyright:Aesculus_hippocastanum_fruit.tga Andrew Dunn [[:en:User:Solipsist]]CC-BY-SA-2.0 | grub2-splashimages/debfiles/copyright:Flower_jtca001.tga Sam Oth [[:c:User:World Trekker]] CC-BY-SA-2.5 | grub2-splashimages/debfiles/copyright:Plasma-lamp.tga Luc Viatour [[:c:User:Lviatour]] GNU FDL = 1.2 or CC-BY-SA 2.5, 2.0, and 1.0 | grub2-splashimages/debfiles/copyright:Sparkler.tga Gabriel Pollard gabriel.poll...@wikinewsie.org CC-BY-SA 2.5 | grub2-splashimages/debfiles/copyright:License (CC-BY-SA 2.5): | grub2-splashimages/debfiles/copyright:License (CC-BY-SA 2.0): | libtasn1-3/debfiles/copyright:“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license | libtasn1-3/debfiles/copyright:under CC-BY-SA on the same site at any time before August 1, 2009, provided | oxine/debfiles/copyright:License: CC-BY-SA-2 | splint/debfiles/copyright: (under which the splint software itself is licensed) or CC-BY-SA 3.0 | splint/debfiles/copyright:I hereby release that code under CC-BY-SA 3.0. | splint/debfiles/copyright:post using CC-BY-SA 3.0. He on behalf of Duolog is okay with this, as am | splint/debfiles/copyright:Please use the CC-BY-SA 3.0 license to license this post. | splint/debfiles/copyright:which the splint software itself is licensed) or CC-BY-SA 3.0 (under | terminator/debfiles/copyright:Cory Kontros - Produced our current icon under the CC-by-SA licence | warzone2100/debfiles/copyright:License: CC-BY-SA-3.0 | warzone2100/debfiles/copyright:License: CC-BY-SA-3.0 | wound-up/debfiles/copyright: music licenced under the CC-by v2.0 (the game itself is CC-by-sa v3.0). freedink-data having seen a single upload, there's no doubts its current license has been approved by ftpmasters, and that it hasn't been altered afterwards. Mraw, KiBi. signature.asc Description: Digital signature
Re: Upcoming Section changes in the archive
Le vendredi 27 février 2009 à 14:33 +0100, Raphael Hertzog a écrit : On Fri, 27 Feb 2009, Joerg Jaspert wrote: Like the other poster, cli is very confusing. If we have enough packages (get me a list/matches :) ), im not against a section for it, but cli wouldnt be my favorite name for it. I would suggest c-sharp for the section. The CLI is not restricted to a single language support. How are you going to classify IronPython or boo ? -- .''`. 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
Bug#517404: ITP: polyorb -- The PolyORB schizophrenic middleware for Ada
Package: wnpp Severity: wishlist Owner: Reto Buerki r...@codelabs.ch * Package name: polyorb Version : 2.4.0 Upstream Author : li...@adacore.com * URL : https://libre.adacore.com/polyorb/ * License : GMGPL Programming Lang: Ada Description : The PolyORB schizophrenic middleware for Ada PolyORB is a general middleware technology for CORBA and other distributed systems technologies. More specifically, PolyORB provides a uniform solution to build distributed applications relying either on middleware standards such as CORBA, the Ada 95 Distributed System Annex, SOAP, Web Services, or to implement application- specific middleware. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') 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: Transition: krb5 to drop Kerberos IV (libkrb53 restructuring)
Steve == Steve Langasek vor...@debian.org writes: Steve Actually, I was meaning to comment on this. Why would you Steve not simply point the shlibs at the component library Steve packages at this stage? The only side effect is that the Steve version of krb5 that includes the split library packages Steve has to migrate to testing before anything else depending on Steve these packages can reach testing, but that's not terribly Steve onerous given that krb5's own migration to testing won't be Steve tangled up with other packages - this is already a very Steve soft transition, and I don't see the need for extra work Steve on the shlibs handling. That was the only reason. If it had worked easily it would have been worth it. At this point I'll just keep on top of the package and do everything I can to let it migrate to testing quickly. --Sam -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Josselin Mouette j...@debian.org writes: Le vendredi 27 février 2009 à 14:33 +0100, Raphael Hertzog a écrit : On Fri, 27 Feb 2009, Joerg Jaspert wrote: Like the other poster, cli is very confusing. If we have enough packages (get me a list/matches :) ), im not against a section for it, but cli wouldnt be my favorite name for it. I would suggest c-sharp for the section. The CLI is not restricted to a single language support. How are you going to classify IronPython or boo ? How about those knowing what Common Language Infrastructure is about, trying to describe it in a somewhat less ambigious way than cli? Take a look at http://en.wikipedia.org/wiki/CLI Can't speak for anyone else, but I would certainly think command-line interface if I encountered a section named cli. Bjørn -- 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: Note: you still haven???t fixed your email client. Le vendredi 27 février 2009 à 13:34 +0100, Joerg Schilling a écrit : Josselin Mouette j...@debian.org wrote: Le vendredi 27 février 2009 à 12:37 +0100, Joerg Schilling a écrit : Then it seems the right time for Debian to excuse for what Mr. Bloch did under the name of Debian and to start to collaborate again as usual before he appeared at Debian. Change your license, and maybe we???ll be able to think of collaborating. You seem to be unable for collaboration as you try to blackmail me. Maybe you should buy yourself an English dictionary. Since you don???t seem to understand this word, the German word for it is ???Erpressung???. This is a serious accusation, and it has nothing to do with imposing conditions (Vorbedingung) or negotiation (Verhandlung). It seems that you do not understant what freedom means - try to inform yourself before popping up again. 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: CC Attribution ShareALike (CC-by-sa) 3.0
Hi, 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... ftpmasters saying yes, and ftpmaster, obviously :) Looking at the pool: wow, I'm surprised to see 2.0 and 2.5 licences there. AFAIU (and I've read those licences...) and AFAIK, cc-by-sa 3.0 is fine for main, previous versions not. So I guess some bugs are in order to be filed... regards, Holger signature.asc Description: This is a digitally signed message part.
Re: CC Attribution ShareALike (CC-by-sa) 3.0
Le vendredi 27 février 2009 à 15:46 +0100, Holger Levsen a écrit : wow, I'm surprised to see 2.0 and 2.5 licences there. AFAIU (and I've read those licences...) and AFAIK, cc-by-sa 3.0 is fine for main, previous versions not. So I guess some bugs are in order to be filed... Anyway, versions 2.0 and 2.5 allow relicensing to 3.0, so if we accept 3.0, the older versions are a non-issue. -- .''`. 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: CC Attribution ShareALike (CC-by-sa) 3.0
On Freitag, 27. Februar 2009, Josselin Mouette wrote: Anyway, versions 2.0 and 2.5 allow relicensing to 3.0 By anyone? signature.asc Description: This is a digitally signed message part.
Re: CC Attribution ShareALike (CC-by-sa) 3.0
Le vendredi 27 février 2009 à 16:02 +0100, Holger Levsen a écrit : On Freitag, 27. Februar 2009, Josselin Mouette wrote: Anyway, versions 2.0 and 2.5 allow relicensing to 3.0 By anyone? §4b : You may distribute, publicly display, publicly perform, or publicly digitally perform a Derivative Work only under the terms of this License, a later version of this License with the same License Elements as this License, or a Creative Commons iCommons license that contains the same License Elements as this License (e.g. Attribution-ShareAlike 2.0 Japan). Since a Debian package is clearly a derivative work, we can distribute Debian packages of CC-BY-SA 2.0 software under CC-BY-SA 3.0. -- .''`. 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: Upcoming Section changes in the archive
We plan on changing the current sections in the archive. With the rapid growth of archive, many of them have become too big to be useful anymore. According to my knowledge of dak, the sections are global. Which means that we don't have to worry about a possible kernel update for lenny+1/2. Am I correct with that? Sections are. The overrides not, which means stable/oldstable wont change and keep whatever they have now. Otherwise it wouldnt be possible to do a change, ever, when it would always affect stable. -- bye, Joerg Some AM after a mistake: Sigh. One shouldn't AM in the early AM, as it were. grin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: handling group membership in and outside d-i
On Thu, 2009-02-26 at 13:01 +, Ben Hutchings wrote: On Thu, 2009-02-26 at 08:31 +0100, Peter Palfrader wrote: This is of course broken. It breaks granting console users access to the netdev or powerdev groups through pam_groups, which is really really annoying when you get your users from say ldap. But that's broken to start with, since you can't revoke group membership when the user logs out. The group membership is only assigned to the process, not in the group database. I generally have something like: gdm; :*; *; Al-2400; audio,floppy,video,cdrom,scanner,plugdev,voice in /etc/security/group.conf to ensure that any user that is logged in on the console can do most things you can expect console users to do. So for a gdm session: % groups users voice cdrom floppy audio src video plugdev scanner But the NSS databases contain the following: % groups arthur arthur : users src I've found that with lenny for some things (dbus?) you need consolekit (I install policykit-gnome which has all the dependencies I need) to accomplish (part of?) what you did with secondary groups before. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Re: Proposal to improve package configuration upgrades
On Fri, Feb 27, 2009 at 01:35:56PM +0100, Dominique Dumont wrote:
I think your numbers are right. The main problem I see is that the
automatic merge will not be able to inform the user whether the
merge is correct or not. In case of merge failure, the application
will exit on error and leave the average user in the dark. Even 10%
of this kinf of failure will be badly perceived.
I agree with this argument, but I contend that it would be no
regression: currently, would the user know that after having chosen to
preserve the installed version of a conffile (instead of the
maintainer version) that configuration can be wrong wrt the new
version of the package being installed?
She wouldn't know, where is the difference?
(Yes, I know you are proposing an improvement over that situation, but
it is not for free, since it requires a per-conffile-kind
development. Mine is conffile-kind-independent and I believe it wont
introduce any regression.)
But then we are back at the issue of a 80-20 problem, and I see
the VCS solution as more flexible and more readily available.
Agreed. But VCS solution is a 80% success/20% silent
failure. Config::Model is a 80% success/20% abort. The latter should
be easier to deal with for average user.
With my former argument, that 20% of silent failures is possibly very
comparable with the silent failures enabled by the current status. I
stop before the temptation of repeating:
But again, it looks to me that the two approaches can coexist.
Absolutely: Something like try Config::Model, if it fails (missing
or incomplete model) may be VCS merge with mandatory user
interaction or usual ucf question.
:-)
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: xcdroast does no longer work with wodim: Who to blame?
joerg.schill...@fokus.fraunhofer.de (Joerg Schilling) writes: Josselin Mouette j...@debian.org wrote: Change your license, and maybe we???ll be able to think of collaborating. You seem to be unable for collaboration as you try to blackmail me. Stating a fact is not blackmail. As SFLC has determined that CDDL and GPL are incompatible [1], Debian is unable to distribute any software which contains code with those two licenses mixed in. If you wish for the cdrtools to be included in Debian (or in any major Linux distribution), you should fix that problem. This is nonnegotiable, as we would be breaking the copyright law by distributing software for which we have no license to do so. If you feel that the SFLC's opinion is wrong, you are of course free to provide us with competent legal advice countering SFLC's opinion. [1] https://lists.ubuntu.com/archives/ubuntu-news-team/2009-February/000413.html -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- 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 Fri, Feb 27, 2009 at 06:48:01AM -0600, William Pitcock wrote: There definitely _is_ a major legal problem with the fork. Please provide specific details, rather than vaguely defined major problems. Read the related entry in the Debian bugtracking system before asking me for details. Can you provide a URL to this entry? I have still yet to find it. I have to say that for a person who doesn't know the exact details of the fork, this thread is quite vague (especially for its size). So I googled a bit. There's a bit of background here: http://lwn.net/Articles/195167/ And the bug report is probably this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109 Berto -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
[BTW, the only proper spelling is GNUstep -- not Gnustep or GNUStep.] Vincent Danjean wrote: I maintain a page.app package. You mean paje.app, I assume (innocent typo)? It is right it is a gnustep application (ie it uses the gnustep framwork). However, I never use the gnustep environment. Well, GNUstep is not a desktop environment (unlike GNOME, KDE, Xfce, etc.), so it is more or less correct that the proposed section title says GNUstep environment and not GNUstep desktop environment. GNUstep is more than libraries (like GLib/GTK+), so it is basically right to say environment. Whether gnumail.app (for example) belongs in the gnustep section instead of the mail section is another question. I think that programs that have already specialized sections should remain there (i.e. science for adun.app or news for lusernet.app). OTOH, having the GNUstep apps/bundles/tools in one section is a convenience for the average user (I guess). Current GNUstep upstream labels it as development environment, and it's very unlikely that GNUstep would become a desktop anytime soon (contrary to the hopes of many GNUsteppers, unfo). There is a desktop based on it, however, Étoilé (http://etoileos.com). The Debian package is about to be updated after the current post-release dust/morass settles down. This is just to say that some *.app application are not tied to the gnustep environment (for example, I find correct that gnumeric is in the 'math' section and not in the 'gnome' section). Right, you can run GNUstep apps under any window manager (well, in theory, at least -- there are lots of WM-specific bugs and limitations). The same holds (to a much greater extent) for GNOME or pure GTK+ apps or pretty much everything else. I would consider it a bug if I install (say) kmail on my GNUstep workstation and it doesn't pull all the required dependencies and doesn't work correctly. -- 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 Fri, Feb 27, 2009 at 10:32:51AM +0100, Giacomo A. Catenazzi wrote: Giacomo A. Catenazzi wrote: BTW mta is IMHO wrong. In most of the cases (IIRC) programs needs only a sendmail program. Should we split the dependencies on real-mta and only on a sendmail provider. BTW we should also rule a minimal set of sendmail interface (which option should be implemented). Actually every MTA has different sets of sendmail options, but I don't yet know about problems. Well there were some problems with popularity-contest, see bug #326593 IIRC for sending to both f...@example.com and b...@example.com: ssmtp allows sendmail -oi f...@example.com,b...@example.com but not courrier-mta which want sendmail -oi f...@example.com b...@example.com Another issue for popularity-contest is that MTA that do not retry on error do not provide much avantage over HTTP submission. However popularity-contest does not need that the MTA listen on port 25. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Fri, Feb 27, 2009 at 10:37:19AM +0100, Adam Borowski wrote: On Thu, Feb 26, 2009 at 11:51:39PM -0800, Steve Langasek wrote: On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote: But as this would hardcode exim4 as the default MTA for Debian in a number of packages, some better solutions have been proposed in http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best choice appearantly being 87ve1faria@frosties.localdomain which proposes that exim4 should provide default-mta, packages needing an MTA should depend on default-mta | mail-transfer-agent and the other MTAs should provide mail-transfer-agent. Then, if we want to change the default, we just need to touch two packages. The referred post mentions an actual package rather than just a provides: field. No, not the Message-Id that Holger referenced. http://lists.debian.org/msgid-search/87ve1faria@frosties.localdomain It makes a difference. Yes, it does; and that thread identified what the differences are that should cause us to prefer a virtual package instead of a real one. http://lists.debian.org/debian-devel/2008/05/msg00390.html 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? -- 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: Proposal to improve package configuration upgrades
On Fri, 27 Feb 2009 13:35:56 +0100 Dominique Dumont dominique.dum...@hp.com wrote: Stefano Zacchiroli z...@debian.org writes: But then we are back at the issue of a 80-20 problem, and I see the VCS solution as more flexible and more readily available. Agreed. But VCS solution is a 80% success/20% silent failure. Config::Model is a 80% success/20% abort. The latter should be easier to deal with for average user. But you don't need to silently merge (and thus silently fail in some cases). You can still ask the user about confirmation. harry signature.asc Description: PGP signature
Re: xcdroast does no longer work with wodim: Who to blame?
Alberto Garcia wrote: So I googled a bit. There's a bit of background here: http://lwn.net/Articles/195167/ And the bug report is probably this one: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=377109 Which doesn't say anything more specific. It plays on the same level as this thread here. And the only thing that will happen is that I run out of popcorn and become fat. -- 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?
Kalle Kivimaa kil...@debian.org writes: If you feel that the SFLC's opinion is wrong, you are of course free to provide us with competent legal advice countering SFLC's opinion. opinions can only be proven right or wrong in court. It seems that Sun's opinion is that the combination doesn't impose redistribution problems, whereas SFLC's opinion differs. Debian's arguments pretty much match SFLC's. The main problem here is that Joerg seems to be more interested in having proved that opinion wrong than in actually getting his software packaged and distributed in Linux distributions. -- 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
Re: xcdroast does no longer work with wodim: Who to blame?
On Friday 27 February 2009 21:29:01 Reinhard Tartler wrote: Kalle Kivimaa kil...@debian.org writes: If you feel that the SFLC's opinion is wrong, you are of course free to provide us with competent legal advice countering SFLC's opinion. opinions can only be proven right or wrong in court. It seems that Sun's opinion is that the combination doesn't impose redistribution problems, whereas SFLC's opinion differs. Debian's arguments pretty much match SFLC's. OTOH, no court is able to prevent people to express their own opinion unless one lives in a regime jurisdiction. The main problem here is that Joerg seems to be more interested in having proved that opinion wrong than in actually getting his software packaged and distributed in Linux distributions. This is not very interesting, since we can live without Joerg's software. I for one have been using cdrskin for more than 3 years now quite happily. By the way, any help in maintaining libburn/libisofs/libisoburn/cdrskin packages would be appreciated. P.S. Btw, not that I care about JS, but what I'm *very* interested in is to hear the opinion of Fraunhofer when they read all the mailing list traffic genereated by their employee (OpenBSD's mailing lists included, since they have also been badly bombarded in the past by similar topics around star licensing discussions). -- 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
Re: Upcoming Section changes in the archive
On 11674 March 1977, Edward Betts wrote: webfeed - RSS/Atom feed readers, aggregator and utilities Not enough packages, can stay in web, especially as that gets rid of httpds. -- bye, Joerg ftpbot cron.daily time, unlocking: slave_NEW mhy ftpbot: oh bugger off, slave_NEW isn't affected by dinstall :-) tomv_w bugger off, sonst gibt es zoff! tomv_w for the bilinguists pgp1Vq8FTatk7.pgp Description: PGP signature
Re: Upcoming Section changes in the archive
Have sense to inaugurate a section with all the R modules? Nowadays many of them are in math. $ apt-cache search r- | grep ^r- | wc - l 133 Thats ok, get me a good name and short description for it please. r is not a good name, i think. -- bye, Joerg * wiggy just looking at gforge-inject output wiggy last year I could not run it for months and still not see any new users wiggy it just added 19 new users Mithrandir it's this bloody active new DAM we've managed to get. pgp689gurUJ0V.pgp Description: PGP signature
Re: Upcoming Section changes in the archive
video mplayer* That is already in. vswitch* No hit for this match?! -- bye, Joerg GyrosGeier I've annoyed Ganneff enough with that package already, no reason to top it off by a build-depend on emacs for writing control files pgpLuKXMhKlrs.pgp Description: PGP signature
Re: Upcoming Section changes in the archive
You also want totem* and kaffeine*. Done. *-dbg packages could go in their own section(s) (debug, or libdebug appdebug?); otherwise, I think that they should remain with (the bulk of) the packages for which they provide debug data. All debug packages will go in the debug section. -- bye, Joerg liw I like shooting people liw er, wait liw that could be quoted out of context pgpqZ0rWgkczJ.pgp Description: PGP signature
Re: Upcoming Section changes in the archive
Get me a short description for it. Compiler, libraries, and tools for OCaml: a static typed ML language implementation supporting functional, imperative, and object-oriented programming styles. You have an interesting definition of short, i stopped after : for now. :) (Its a different thing what packages.d.o will show later, for example, but for me the part before the : is more than enough) The regex over binary package names would be lib.*-ocaml.*, currently matching 160 binary packages in the APT database on my laptop (unstable + experimental). ocaml ocaml-* lib*ocaml* Yup, of course I forgot the first pattern in the former post. Actually, you can add also *-ocaml which would match also dh-ocaml, our debhelper-like tools for OCaml-related packages. K. -- bye, Joerg AM: Whats the best way to find out if your debian/copyright is correct? NM: Upload package into the NEW queue. pgp7Cr78WgYnn.pgp Description: PGP signature
Re: Upcoming Section changes in the archive
On 11674 March 1977, Aaron M. Ucko wrote: As I mentioned directly to override-change before encountering this message, I'd argue that my goo package is a (somewhat exotic) candidate. In general, here's a first cut at a full list, including it and your initial proposals: Thanks. -- bye, Joerg HE Joerg knuddeln ist wie mit Skorpionen schlafen. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
Like the other poster, cli is very confusing. If we have enough packages (get me a list/matches :) ), im not against a section for it, but cli wouldnt be my favorite name for it. I’m not sure for the section name, but here is a list of matches: Select one of cli-mono or ecma-cli and please also get me a short description :) monodoc* monodevelop* mono-* libmono* *-mono *-cil (except cl-cil which goes to lisp) *-cil-* cli-* *-sharp2* Taken. -- bye, Joerg lamont is there a tag for won't be fixed until sarge+1? sam depends whether the BTS is year 2037 compliant pgpEhT8JhCSZo.pgp Description: PGP signature
Re: Upcoming Section changes in the archive
El Vie 27 Feb 2009, Joerg Jaspert escribió: Thats ok, get me a good name and short description for it please. r is not a good name, i think. gnu-r ? Everything about GNU R, an statistical computation and graphics system luciano -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 27-02-2009 08:41, Roger Leigh wrote: On Fri, Feb 27, 2009 at 02:53:04AM -0300, Felipe Augusto van de Wiel (faw) wrote: On 26-02-2009 23:10, Darren Salt wrote: I demand that Frans Pop may or may not have written... Joerg Jaspert wrote: [...] The new sections are: localisationsLanguage packs I'd prefer localization. Whereas I'd prefer localisation... What about using 'l10n'? It tends to be well know these days, and would avoid the s|z problem. :-) The terms i18n and l10n might be well known amongst developers, but I contend that most users won't know (or should need to know) arcane abbreviations when we could use the full word. Well, Debian has a lot of users that don't know English, in this sense, some sections do not mean anything to them. I'm not saying that we should translate it, but knowing the meaning is quite relative under this point of view. I do believe that users are getting used to see the terms i18n/l10n, and if our users are able to find out what httpd and vcs mean, I'm pretty sure they will survive l10n. :-) Kind regards, - -- Felipe Augusto van de Wiel (faw) Debian. Freedom to code. Code to freedom! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmoYYsACgkQCjAO0JDlykatQgCgnNVy2XKpQAuwtJyB5+Wb087Y aK0An0+OfjDL027McuD/ZWfDrpZ0aLbH =fHox -END PGP SIGNATURE- -- 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, Feb 27, 2009 at 12:12:48PM +, Mark Brown wrote: On Fri, Feb 27, 2009 at 11:48:30AM +, Enrico Zini wrote: - For packages with no tags in the control file, take the tags from the review tag set as we have now Are packages supposed to do this? If they are it'd probably be worth announcing more generally to let people know it's OK to do this. Please note that it is a proposal. At the moment, the main and the suggested way to tag package is to go to http://debtags.alioth.debian.org/todo.html or http://debtags.alioth.debian.org/edit.html and follow the instructions. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature
Re: Upcoming Section changes in the archive
Michael Tautschnig m...@debian.org writes: Seeing that the change of sections could pose some technical problems (not only challenges implementing them) as well, let me ask one (possibly stupid) question: Why do we need sections at all? All that policy states is that it simplifies some handling of packages. Off the top of my head: They section the display of packages in utilities like aptitude, which I for one find extremely useful. They let you easily perform bulk operations on related packages, like marking all libraries as autoinstalled or removing all debug packages. They let you find the set of available add-ons for a given programming language easily in both searches and browsing when you're looking for something in particular. -- 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#517467: ITP: libstring-bufferstack-perl -- framework for storing nested buffers
Package: wnpp Severity: wishlist Owner: Antonio Radici anto...@dyne.org * Package name: libstring-bufferstack-perl Version : 1.12 Upstream Author : Alex Vandiver ale...@bestpractical.com * URL : http://search.cpan.org/dist/String-BufferStack/ * License : Artistic Programming Lang: Perl Description : framework for storing nested buffers String::BufferStack provides some functions to store data into nested buffers . By default, all of the buffers flow directly to the output method, but individual levels of the stack can apply filters, or store their output in a scalar reference . The main consumers of this module are templating systems, like Template::Declare, which needs to manipulate nested buffes. -- System Information: Debian Release: 5.0 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: Upcoming Section changes in the archive
I demand that Felipe Augusto van de Wiel (faw) may or may not have written... [snip] I do believe that users are getting used to see the terms i18n/l10n, and if our users are able to find out what httpd and vcs mean, I'm pretty sure they will survive l10n. :-) Where's the t1g3r section? -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Lobby friends, family, business, government.WE'RE KILLING THE PLANET. Windows 98. Eats RAM and HD space for breakfast. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Desktop standards, MIME info cache, and Lintian
Michael Biebl wrote: [...] It's also a matter for what case we optimize: For users running unstable, who constantly update, it might/will happen that the update-desktop-database trigger is activated although unnecessary. For stable users, who only do distro upgrades, it might be quite some benefit, as instead of dozens of update-desktop-database calls during the upgrade, you'd only get one. Why not implement a system that maintainer scripts could use to tell dpkg that a given script or 'not automagic trigger' is needed, that would only be enabled when a package really needs it; but the operation would be done just once. Cheers, Raphael Geissert -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: Hello world, We also plan on adding a number of new sections. wanna-build will need to be change for this too, and will probably break if you give it an unknown section. Please wait until the list is added to wanna-build. Kurt -- 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 Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote: Given that m-t-a is mentioned explicitly in policy, and that default-mta will be a virtual package, I think this should be recorded in policy as well - though if a clear consensus emerges on debian-devel, there's no need to go through the policy process before filing bugs. 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. The problems caused by having more than one provider of default-mta are the same as those caused by depending on mail-transport-agent alone. This is not an argument against defining a default-mta virtual package, this is an argument against having stupid bugs in the implementation. 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. This was already discussed in the thread referenced by Holger. [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. Probably we should be stricter. Stricter about what? There are lots of cases where it's useful to have only one package at a time provide a virtual package, and to have other packages reference that virtual package on its own (think build-dependencies). -- 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: Upcoming Section changes in the archive
On Fri, 2009-02-27 at 21:24 +0100, Joerg Jaspert wrote: video mplayer* That is already in. vswitch* No hit for this match?! Holger probably meant dvswitch. Which is in NEW, anyway. Ben. signature.asc Description: This is a digitally signed message part
Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
On Fri, Feb 27, 2009 at 10:32:51AM +0100, Giacomo A. Catenazzi wrote: I would prefer to create a real empty package: default-mta (maybe in a source package debian-defaults), which depends on exim. BTW mta is IMHO wrong. In most of the cases (IIRC) programs needs only a sendmail program. Should we split the dependencies on real-mta and only on a sendmail provider. I think that's well out of scope for the current discussion. This is the definition of the 'mail-transport-agent' virtual package that's been used in Debian for many years; I don't think it makes sense to change the virtual package name because of a quibble over the proper definition of an MTA. BTW we should also rule a minimal set of sendmail interface (which option should be implemented). Actually every MTA has different sets of sendmail options, but I don't yet know about problems. In practice, we have the LSB definition of the interfaces that /usr/sbin/sendmail have to support; all but one of the MTA packages in Debian implement this interface (the odd duck is nullmailer, which Conflicts: lsb for this reason...) But perhaps that definition needs some help if popcon can't use it to reliably send mail to multiple recipients? -- 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: Making some tags mandatory
Enrico Zini enr...@enricozini.org writes: At the end of this mail is the list that I propose: it's 138 of them, but grouped as they are, they should be quite clear to grasp. I consider these groups of tags (debtags calls them facets) to be mature and uncontroversial enough to be made official and to ask maintaners to take care of them. I like this proposal, thank you for presenting it. * The list Role of the package in the archive (mandatory for all packages): role::app-data - Application Data role::data - Standalone Data role::debug-symbols - Debugging symbols role::devel-lib - Development Library role::documentation - Documentation role::dummy - Dummy Package role::kernel - Kernel and Modules role::metapackage - Metapackage role::plugin - Plugin role::program - Program role::shared-lib - Shared Library role::source - Source Code Language that the package is implemented in (mandatory for all packages mostly consisting of software): Arguably, *all* digital information is software (as contrasted with the hardware that contains it), so every Debian package consists entirely of software. Whether or not you agree with that, it would be best for this proposal if the set of packages for which “foo is mandatory” were clearly deliniated: Language(s) that the package is implemented in. Mandatory for all packages mostly consisting of programs or program components (role::debug-symbols, role::devel-lib, role::kernel, role::plugin, role::program, role::shared-lib, role::source). That is, the determination of whether an ‘implemented-in’ facet is mandatory is whether the package has one of the enumerated tags from the ‘role’ facet. (If that set of tags is wrong, feel free to correct it of course.) User interface (mandatory for all packages mostly consisting of software): Likewise: User interface(s) for the programs in the package. Mandatory for all packages mostly consisting of executable programs (role::plugin, role::program). -- \ “I do not believe in immortality of the individual, and I | `\consider ethics to be an exclusively human concern with no | _o__) superhuman authority behind it.” —Albert Einstein, letter, 1953 | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sjors Gielen wrote: [...] I'm working on a project porting the Debian tools to Cygwin. Yes, yes, I know I'm replying to a post over a month old. Nevertheless, I recently found something that's relevant: http://debian-interix.net/ This is a Debian port on top of Interix, a.k.a. Microsoft Services for Unix, the unix-alike that runs on the NT kernel. Unlike Cygwin it doesn't go through the win32 layer and so doesn't need all the emulation layers, which gives it (allegedly) much better I/O throughput, proper case sensitive filenames, inode semantics, etc. While installation is still a bit tortuous, they have a buildd and claim to support a decent number of packages... Is this of interest to anyone? - -- David Given d...@cowlark.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJqIBzf9E0noFvlzgRAs3KAJ4le9J35bJcN7agQVK0RfU+7I6Y2ACeLxFZ Wtyi1QBbD79to3bcE/XXxg0= =JXPo -END PGP SIGNATURE- -- 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
Steve Langasek vor...@debian.org writes: In practice, we have the LSB definition of the interfaces that /usr/sbin/sendmail have to support; all but one of the MTA packages in Debian implement this interface (the odd duck is nullmailer, which Conflicts: lsb for this reason...) But perhaps that definition needs some help if popcon can't use it to reliably send mail to multiple recipients? Listing multiple addresses separated by commas feels like a sendmailism to me. I'm surprised that doesn't break with lots of other MTAs. The general interface is addresses separated by spaces, which is also the documented sendmail command-line interface. (The sendmail man page represents the syntax as [ address ... ].) I think this was just a bug in popularity-contest that happened to go unnoticed since sendmail runs command-line arguments through the same parser that it applies to To: headers. -- 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: DebConf10 to take place in New York City, USA
Jimmy Kaplowitz dijo [Wed, Feb 25, 2009 at 02:31:24PM -0500]: Martin may have left the wrong impression. We don't have the issues fully solved, and of course can no more make guarantees that there won't be visa or border hassles than the Mexico local team was able to for DebConf6 (the first year where visas became an issue). Not only, might I add, DC6 was the first time the visas were an issue, it was the first time also (at least as far as the organizers could know) that people were left out because of the visa situation. Recall that, i.e., DC4 (@Brazil) posed a problematic visa issuing situation -precisely- for USAmericans, as Brazil has this polemic (but IMHO great) reciprocity system, whereas Mexico appears to have decided to become a screening door for the USA - We didn't expect the visa requirements to be an issue at all, and even having all the needed connections (my wife was at the time speaking on an almost-daily basis with the Foreign Relations Secretary's personal assistant, and not even that did the trick) we ended up... With a mess that left some people in the cold. But still, that experience showed us quite a bit. And yes, we are now (I was not involved in DC8, but at least for DC7) receiving some applications from people clearly looking only for a way to get entry to a more developed country. And as an organization, DebConf (which means, Debian) must be careful to check that all visa tramits we process are _really_ for people interested in working for Debian. (And going legally back home!) Further, we're definitely going to be giving people invitation letters and other advice to make sure they present themselves in the best (accurate) light they can to the visa or border officials, as well as separate exaggeration from fact with regard to border search and other privacy concerns so that people can make rational decisions based on reality instead of sensationalism. More details will be provided at the DebConf10 presentation in Caceres at DebConf9, if not sooner. One source of confusion in Mexico was that people said at the Mexican embassy they were travelling for a conference. Stupid as it might sound, that meant they were coming on business, and it was a PITA to convince the Foreign Relations people that we were _NOT_ for profit, and neither were any of you. Jimmy, I advise you to triple-check if that it is the best way to help the visa process, or whether we should all apply as tourists-and-nothing-else. After all, quite a bit of people go as tourists to NY, so nothing fishy there. -- 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
