Re: [HS] gettext et perl ?
Le 24/09/07, Patrice Karatchentzeff[EMAIL PROTECTED] a écrit : Salut, [...] Une idée ? Bon, double erreur... une de ma part (il faut jouer avec LC_MESSAGES et non LANG pour gettext, ne pas se faire avoir par LC_ALL) et le paquet liblocale-gettext-perl est bogué... Le bon code est #!/usr/bin/perl use warnings; use strict; # for i18n and l10n # use POSIX; use Locale::gettext; setlocale(LC_MESSAGES, ); textdomain(essai); my $d = Locale::gettext-domain(essai); $d-dir(/home/pk/Perso/Pdico/locale/); print gettext(All you need is love), \n; print $d-get(All you need is love), \n; exit 0; la forme C (print gettext ..) n'est utilisable que si on utilise la déclaration textdomain et le couplage de la forme OO pour définir le path... or, la déclaration du path déclare déjà le domain... on a donc une double déclaration du domain par ce moyen... le bindtextdomain censé pallier ce problème se fonctionne pas. Pourquoi ne pas se contenter de la forme OO uniquement (qui fonctionne bien) ? Hors toute philosophie et le fait que cela est moins lisible, xgettext ne sait pas extraire le .po lorsque tout est écrit sous forme OO... Va falloir que je me tape le rapport de bogue maintenant... Merci à tous pour vos conseils, PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_)
glibc, bug 438179 et avenir de/dans etch
Bonjour, A travers ce mail, je souhaite évoquer les problèmes techniques qui découlent du bug 438179 de la glibc [1] et éventuellement de savoir ce qui peut-être fait pour faire avancer les choses (par debian ou par moi même). Mon soucis est de bien comprendre les tenant et les aboutissants de ce qui est, sera ou pourra être fait tant au niveau de debian qu'à un niveau plus global afin de prendre la bonne décision pour les serveurs que j'administre. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438179 Pour faire un résumer (simpliste) du bug et de la situation, une implémentation dans getaddrinfo (dans la glibc) de la RFC 3484 pose problème en cassant les mécanismes de round robin dns utilisés depuis des années (pour des applications qui utilisent getaddrinfo et qui s'appuyaient à l'origine sur gethostbyname). Ce système de répartition de charge par round robin dns n'est peut-être pas le meilleur, mais dans de nombreux cas, AMHA, il répond bien et à moindre coût (tant technique que matériel) à ce à quoi il est destiné. Pour ma part, le problème se pose dans le fonctionnement du centre serveur sur lequel je travaille, notamment au niveau de l'ensemble de l'infrastructure openldap qui fonctionne avec des heartbeat en actif/actif pour la partie haut-disponbilité et un round robin dns pour l'équilibrage de charge. Ce système fonctionnait parfaitement avec Sarge. La migration de Sarge à Etch casse donc ce fonctionnement, ce qui entraîne des problèmes de répartition de charge entre les serveurs et remet en cause les fonctionnements en actif/actif. De mon point de vue d'administrateur/utilisateur, c'est catastrophique. Un patch à la glibc a été ajouté permettant de configurer le comportement de getaddrinfo (je n'ai pas encore tester cette version de la libc). Bien qu'à mon sens cette solution ne soit pas optimale, une modification définitive de getaddrinfo et de la RFC 3484 pour garantir un fonctionnement par défaut et une compatibilité avec le comportement historique de gethostbyname me paraissant meilleur, elle a l'avantage d'exister actuellement. Pour rétablir ce fonctionnement sur mes serveurs, un backport ou une transposition du patch dans la glibc de etch sont-ils la seul solution ou une mise à disposition pour etch de cette version de la glibc est-elle envisagée ? Au pire, une mise à disposition dans volatile (ou volatile-sloppy) est-elle possible ? Faut-il faire un mail ou un rapport de bug quelque part pour cela ? Apparemment, de nombreux d'utilisateurs sont touchés par ce problème, il me semble dommage que tous essaient de vivre avec ou transposent ce patch dans leur coin. Plus généralement, est-il prévu une action au niveau des développeurs de la glibc (upstream) et/ou de l'IETF pour une modification/évolution de la RFC 3484 ? Cordialement, Julien P.S: il m'a semblé logique de poser ces questions à des développeurs debian (donc sur devel-french) plutôt que sur user-french. J'espère que cela n'offusquera personne. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc, bug 438179 et avenir de/dans etch
On Wed, Sep 26, 2007 at 03:55:56PM +, [EMAIL PROTECTED] wrote: La migration de Sarge à Etch casse donc ce fonctionnement, ce qui Non etch n'a pas ça. Seul lenny est concernée. Plus généralement, est-il prévu une action au niveau des développeurs de la glibc (upstream) et/ou de l'IETF pour une modification/évolution de la RFC 3484 ? L'upstream de la glibc a codé le changement de sémantique donc non il ne va rien changer. Personnellement je pense que sachant (et il suffit de lire le thread sur -ctte pour le savoir) que plusieurs OS font ça maintenant (Windows XP SP2, Vista, les BSDs, et toutes les autres distributions linux autres que Ubuntu) changer ça dans Debian est pointless. Dans la pratique, POSIX ne dit rien sur comment getaddrinfo trie (ou ne trie pas) les adresses qu'il renvoit. EN ce sens, si le but est de faire du RR, alors l'appli qui utilise getaddrinfo peut faire du RR en 3 lignes de code. Personnellement je ne suis pas favorable à dévier, même si le tri proposé est non optimal, parce que on va voir une nouvelle génération de software écrits avec ce comportement en vue, et qui vont se mettre à planter sur Debian. De plus, il faut bien voir que à préfixes égaux, le RR continue de fonctionner, ce qui n'est pas _si_ catastrophique. PS: ton mailer fait des lignes de 109213098 caractères et c'est un peu pénible. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJv9yTdFKBW.pgp Description: PGP signature
Re: glibc, bug 438179 et avenir de/dans etch
Le mercredi 26 septembre 2007, [EMAIL PROTECTED] a écrit : Bonjour, Bonjour, P.S: il m'a semblé logique de poser ces questions à des développeurs debian (donc sur devel-french) plutôt que sur user-french. J'espère que cela n'offusquera personne. Je fais une réponse à la debian-user-french alors ;-) PS: je ne réponds pas à la question posée... [...] Pour faire un résumer (simpliste) du bug et de la situation, une implémentation [...] dans la glibc [...] pose problème en cassant les mécanismes de round robin dns utilisés depuis des années [...]. Ce système de répartition de charge par round robin dns n'est peut-être pas le meilleur, mais dans de nombreux cas, AMHA, il répond bien et à moindre coût (tant technique que matériel) à ce à quoi il est destiné. Pour ma part, le problème se pose dans le fonctionnement du centre serveur sur lequel je travaille, notamment au niveau de l'ensemble de l'infrastructure openldap qui fonctionne avec des heartbeat en actif/actif pour la partie haut-disponbilité et un round robin dns pour l'équilibrage de charge. [..] keepalived me semble plus adapté¹ à vos besoins que heartbeat/round-robin-dns (surtout dans le cadre d'un « centre serveur ») ¹: certes au prix de deux petites machines, mais qui peuvent répartir d'autres services par la même occasion. Cordialement, Julien Cordialement, -- Eric DÉCORNOD
Re: glibc, bug 438179 et avenir de/dans etch
On Wed, Sep 26, 2007 at 03:53:12PM +, Loïc Minier wrote: On Wed, Sep 26, 2007, Pierre Habouzit wrote: L'upstream de la glibc a codé le changement de sémantique donc non il ne va rien changer. Personnellement je pense que sachant (et il suffit de lire le thread sur -ctte pour le savoir) que plusieurs OS font ça maintenant (Windows XP SP2, Vista, les BSDs, et toutes les autres distributions linux autres que Ubuntu) changer ça dans Debian est pointless. Le thread du CTTE n'est pas unilatéral ; les conclusions sur le support par les autres OS n'est pas claire (notamment sur le type de classement appliqué) et deux personnes du CTTE (vorlon et iwj) ont plutôt pris la position de refuser d'appliquer la règle 9 dans Debian pour l'IPv4. Steve a voté blanc FWIW. Aba et iwj ont voté pour changer. Le fait que Debian présente un comportement différent ne semble pas spécialement problématique pour l'interopérabilité, et le round robin est une propriété nécessaire à l'infra Debian et Ubuntu actuelle, donc je ne trouve pas ça pointless de modifier la libc de Debian. Si tu parles d'apt, fixer apt me parait trivial :) Ce qui serait nettement mieux, et qqn l'a suggéré, serait d'avoir un gethostbyname2 qui prendrait des flags qui impacteraient la méthode de tri, et faire normer ça dans POSIX. Si la glibc a ça, ça entrera dans plusieurs autres libs, et les applis qui ont vraiment besoin de RR pourront demander _explicitement_ d'avoir du RR, et non parier sur le fait que gesthostbyname en fait. Je rappelle que le comportement RR de gethostbyname n'est pas contractuel, y'a rien qui dit nulle part que ça marche comme ça. Je sais que c'est un argument qui est un peu foireux, mais au lieu de jaser sur le fait que le comportement change, ptet qu'il faudrait songer à inventer la fonction qui norme ce comportement once and for all non ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpo9io4E3szr.pgp Description: PGP signature
Re: glibc, bug 438179 et avenir de/dans etch
On mer, sep 26, 2007 at 04:06:25 +, Pierre Habouzit wrote: On Wed, Sep 26, 2007 at 03:53:12PM +, Loïc Minier wrote: On Wed, Sep 26, 2007, Pierre Habouzit wrote: L'upstream de la glibc a codé le changement de sémantique donc non il ne va rien changer. Personnellement je pense que sachant (et il suffit de lire le thread sur -ctte pour le savoir) que plusieurs OS font ça maintenant (Windows XP SP2, Vista, les BSDs, et toutes les autres distributions linux autres que Ubuntu) changer ça dans Debian est pointless. Le thread du CTTE n'est pas unilatéral ; les conclusions sur le support par les autres OS n'est pas claire (notamment sur le type de classement appliqué) et deux personnes du CTTE (vorlon et iwj) ont plutôt pris la position de refuser d'appliquer la règle 9 dans Debian pour l'IPv4. Steve a voté blanc FWIW. Aba et iwj ont voté pour changer. Le fait que Debian présente un comportement différent ne semble pas spécialement problématique pour l'interopérabilité, et le round robin est une propriété nécessaire à l'infra Debian et Ubuntu actuelle, donc je ne trouve pas ça pointless de modifier la libc de Debian. Si tu parles d'apt, fixer apt me parait trivial :) Ce qui serait nettement mieux, et qqn l'a suggéré, serait d'avoir un gethostbyname2 qui prendrait des flags qui impacteraient la méthode de tri, et faire normer ça dans POSIX. Si la glibc a ça, ça entrera dans plusieurs autres libs, et les applis qui ont vraiment besoin de RR pourront demander _explicitement_ d'avoir du RR, et non parier sur le fait que gesthostbyname en fait. Je rappelle que le comportement RR de gethostbyname n'est pas contractuel, y'a rien qui dit nulle part que ça marche comme ça. Je sais que c'est un argument qui est un peu foireux, mais au lieu de jaser sur le fait que le comportement change, ptet qu'il faudrait songer à inventer la fonction qui norme ce comportement once and for all non ? s/gethostmyname/getaddrinfo/ je fatigue. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbczsOh01JP.pgp Description: PGP signature
Salut dans le nom de Jesus Christ.
Salut dans le nom de Jesus Christ. Je sais que ce message vous apparaîtra comme une surprise puisse que nous ne nous connaissions pas mais la grâce de Dieu m'a dirigé vers vous. Lisez attentivement et soyez bénis au nom de Jésus. Je suis Mme lina cristel , une citoyene française, et je voudrais vous faire un don de la somme $8000.000,00 USD stocker dans une grande agence de securite là bas en cote d'ivoire precisemnt a abidjan la capitale economiquee de la cote d'ivoire.j'ai frequente ce pays pendant 5ans dans mes nonbresuses fonctions de directrices affectes par l'etat francais. je veux que vous fassiez de cette somme une aide par rapport aux enfants deserites , aux orphelins ou creer une entreprise pour donner du travail aux jeunes.en conclusion faites une bonne chose avec cette grosse somme d'argent qui maintenant ne peux plus me sauver. Je suis actuellement malade (paralysée) et souffre d' une terrible maladie (cancer) alors ce don vous va droit au cur faites moi signe en me répondant avec vos coordonnés afin que je puisse vous transmettre ceux de l'agencr de securite . Présentement je me retrouve dans un Hôpital ici en anglettere. Que Dieu vous bénisse. La bible dit que chaque chose a son temps et il es temps pour vous de recevoir ces fonds pour les oeuvres de l'eternel. Demandez et vous recevrez, chercher et vous trouverez, frappez et l'on vous ouvrira. Mathieu 7:7 Votre soeur . lina cristel - Stockage illimité de vos mails avec Yahoo! Mail. Changez aujourd'hui de mail !
Bug#444108: ITP: verilog-mode -- Emacs mode for editing Verilog HDL
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: verilog-mode Version : 357 Upstream Author : Michael McNamara [EMAIL PROTECTED] * URL : http://www.verilog.com * License : GPL Programming Lang: Emacs Lisp Description : Emacs mode for editing Verilog HDL The emacs major mode for editing code of Verilog HDL. Supports syntax highlighting, automatic indentation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Tue, Sep 25, 2007 at 06:25:19PM -0500, Manoj Srivastava wrote: Not good enough. What if I am using m-a with kernel.org kernel sources? I won't have a kernel-headers package installed (I don't). If you need something, depend upon it. You already built the kernel and therefor have a compiler installed. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, The Cloud Minders, stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444115: general: network interface (eth0) gets undetected after restrat checked using ifconfig -a
Package: general Severity: important When the cmos battery is removed and power unplugged and the system booted . I press f2(load defaults) in the cmos screen and the syetm boots very slowly and detects my lan card. i.e ifconfig -a lists eth0. But after this if I shut down the computer and start again or even restart it , the network card is not detected . when the network card goes undetected even if I boot into windows it remains undetected in windows also. To make the netowrk card appear again I need to rerun the procedure of removing the batters and unplugging power cable. It seems like when shutting down the system the OS is setting some flag or something like that in the bios which makes the network card go undetected. I have tried this in debian etch , lenny and sidux. The results are the same irrespective of the debian distribution. havent checked it with other distributions yet. Also about booting up , when I restart or shutdown and start the computer it boots prettu fast , but when I clear the bios and boot it takes nearly 3 - 5 minutes to boot. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22.3-rc1-slh-smp-2 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Romain Beauxis wrote: Let's say that it's the quantitative approach. Other approaches are just chatty chatty. Well, quantitative must not always be the best thing. And if it should be an argument one should create *proper* stats. (This search is not adequate, it matches non-module packages like ocaml-search) Yeah, you name it. I think we should not depend on too much half-baken stats, that might not be true. I have refined your stats by searching only with the list of m-a packages and yes the number of bz2 tarballs is actually higher then the number of gz tarballs. Stats are: Total number of packages that could be analyzed: 43 bz2 Packages: 26 gz Packages: 17 So the real percentage seems to be 60% vs. 40%. So that makes roughtly 75% of bzip2 tarballs and 25 % of gz tarballs. That number would mean to me that it is more likely to have a recommends than a depends. Yes, thats what I first said. And if that is the better way then installing it from within module-assistant (what I agree with after all), then thats the way it should be done with build-essential, too. That is for consistency reasons. For instance, should module-source package also depends on module-assistant ? That would not make much sense, but a Suggests: would make sense. This is the case for many packages but I don't think module-assistant is required to build a package, isn't it an *assistant* ? It is not required. Yes it is an assistant. A simple policy like source packages must recommend module-assistant and should provide gzip tarballs would give a common answer, given that it's not a technical issue as far as I see it... Agreed. A policy defining which tarball to choose and which recommends to setup would ease a lot. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
Bastian Blank wrote: You already built the kernel and therefor have a compiler installed. But m-a would install all the clutter anyways, wouldn't it? Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444115: general: network interface (eth0) gets undetected after restrat checked using ifconfig -a
Le mercredi 26 septembre 2007 à 12:49 +0530, Antano Solar a écrit : When the cmos battery is removed and power unplugged and the system booted . I press f2(load defaults) in the cmos screen and the syetm boots very slowly and detects my lan card. i.e ifconfig -a lists eth0. But after this if I shut down the computer and start again or even restart it , the network card is not detected . when the network card goes undetected even if I boot into windows it remains undetected in windows also. To make the netowrk card appear again I need to rerun the procedure of removing the batters and unplugging power cable. If the problem appears in other operating systems, it sounds like it is caused by the hardware or the firmware - either the BIOS or the network card's. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
dpkg-shlibdeps and private libraries
Hello, _rene_ reported me a failure with openoffice and the new dpkg-shlibdeps. Scanning debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so (for Depends field) dpkg-shlibdeps: failure: couldn't find library libsw680lp.so (note: only packages with 'shlibs' files are looked into). The problem is that libswui680lp.so has libsw680lp.so in NEEDED and thus dpkg-shlibdeps will try to find that library. I made it a failure when I'm not able to find the library as dpkg-shlibdeps is supposed to behave like ld.so and try to use the same mechanism to find out where the lib is. libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment variable apparently defined by the openoffice startup script/program. This variable is not set a build time (and the code wasn't expecting variables at that place anyway). Given this info, I would suggest _rene_ to use LD_LIBRARY_PATH to override the directories that are looked into and be done with it, however while discussing with him we wondered if ld.so didn't lookup in the directory of the object being loaded as well ? If that's the case, then I should modify dpkg-shlibdeps to also look into the directory containing the binary that's currently analyzed... Can anyone confirm or infirm this ? On the other hand, maybe I should just be less picky for shared objects without SONAME... I'm not sure about it. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
On Tue, 25 Sep 2007, Piotr Roszatycki wrote: I suppose that everyone are busy today, so do I. I'm a little tired with sponsoring his packages and I know he could to upload his packages by his own. I really don't undestand why new developers are checked so precisely. I think it is much harder to join Debian than i.e. Google or Microsoft. It is ridiculous. I understand, the developers should have a good knowledge of unix systems and our ogranization but... that's going too far! The reason why maintainers may be checked far more thoroughly is because the average employee of Google or Microsoft can't make changes to any piece of software company wide, nor do they vote on the direction of the entire company. [It's also far easier to fire someone than it is to remove a Developer.] If you feel that the checks are unreasonable or to thorough, then feel free to make specific recommendations for places where they should be relaxed, ideally by helping with the NM process. Don Armstrong -- Clothes make the man. Naked people have little or no influence on society. -- Mark Twain http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-shlibdeps and private libraries
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote: On the other hand, maybe I should just be less picky for shared objects without SONAME... I'm not sure about it. I would suggest that, there are a few programs out there which use many internal use shlibs without a soname and a more complex tree of dirs to pick up their stuff than a single directory. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: semi-virtual packages?
On Tue September 25 2007 09:22:02 am Manoj Srivastava wrote: On Tue, 25 Sep 2007 02:36:24 -0600, Bruce Sass [EMAIL PROTECTED] said: On Sun September 23 2007 03:08:59 pm Manoj Srivastava wrote: On Sun, 23 Sep 2007 14:26:29 -0600, Bruce Sass [EMAIL PROTECTED] said: [I've cut a lot of duplication. If I cut something which doesn't get addressed below, feel free to bring it back.] The scheme I described was under the written assumption there are no such situations which would not already have a virtual package. Ah. That assumption turns out to be incorrect. Haha. There is nothing wrong with the assumption. That is kinda like saying pylint is incorrect for spitting out errors when given a correct perl program. You ignored a sign which would have taken you down a different path, and now appear to be complaining because the path you ended up on took you to the wrong place---neither the sign or paths are incorrect, you just didn't pay attention and got lost. Why would you think any of that scheme was applicable to the case you were thinking of if it is a case in which there is no virtual package? I am not sure how to answer that. I assumed that the scheme under discussion was going to be universal (or else it does not seem to be much good, really -- it would still leave files around that are not associated with anything). I don't see why it would need to be universal, one size stuff often doesn't fit anyone very well and it is not like being universal is pervasive and this would stand out as a wart. I think I see where you are getting confused though. On the one hand you seem to be saying there are files that should be orphans (e.g.: /etc/kernel-img.conf), yet you criticize the scheme for not being universal. Why does not being universal not seem to be much good if you actually don't want universality because you know of files which shouldn't or can't be owned by a package? You did the same sorta thing earlier. Your initial post seemed to be *faulting* a scheme to append paths to package.list for not addressing the case of a file shared by many packages but really owned by none, yet later on you state: my use case merely says that we should be able to have a situation where we have a configuration file that does not belong to a package. Why should a scheme to add files generated by a package to its own package.list need to address the case of files without packages that don't want to be owned? The way I see it, from a logical pov, you can resolve the contradictions by giving up the premise of universality. Once you do that, the opt-in nature of the mechanism takes care of /etc/kernel-img.conf and like, trivially (nothing more trivial than doing nothing, eh). What use case _is_ knowing what package a file belongs to a part of? dpkg -S (and any programs which use it) , cruft, idle curiosity, ... Now, I suppose you are only worried about files in /etc and sch; and not files under /var (no way to associate a lot of those files with the packages that contain the entities that created them). I wasn't worried at all about where the files created by Maintainer scripts would reside, just that they were being created and there was a virtual package which could be given a real presence to claim ownership of them via info/package.list. And in case there is no virtual package? status quo I had considered that files under /etc which are owned by a semi-virtual package may need special handling, but could not think of a case for which simply not-purging the previous version before upgrading to the next wouldn't be an adequate solution. Since that is how dpkg currently behaves I saw no need to bring it up. The same would apply to files under (say) /usr/share/doc/semi-virtual package. Ah. This is not anything I was talking to. I knew that. It is just more info which may help resolve the problems. But I see the problem: if anything were to depend on a changed format of /etc/kernel-img.conf; there would be no pre-defined way to manage that. No matter what you purge, that file does not go away. [ignoring that kernel-img.conf doesn't have to opt-in, so handling that situation could be as it is now] Uhm, that is only a problem if a file is not owned by a package. This thread has been about a mechanism which could add such orphan files to a package so they can be listed, search for, removed, purged, or whatever else one (admin or program) does with that relationship. Maybe this wasn't as clear as I thought: A semi-virtual package is virtual to Debian and real on a user's system, so an admin always has the option of manually remove/purge-ing whatever they end up owning. During normal operation that sort of thing would be handled automatically as the packages Provide:-ing the semi-virtual ones get manipulated. What I would end up doing in that instance was to create a
Re: dpkg-shlibdeps and private libraries
On Wed, Sep 26, 2007 at 11:56:39AM +0200, Francesco P. Lovergine wrote: On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog wrote: On the other hand, maybe I should just be less picky for shared objects without SONAME... I'm not sure about it. I would suggest that, there are a few programs out there which use many internal use shlibs without a soname and a more complex tree of dirs to pick up their stuff than a single directory. Also all Java JNI libraries dont use SONAMEs. I guess these can be problematic for new dpkg-shlibdeps too. Cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Maintainer of package joystick may be missing
On Tue, Sep 25, 2007 at 05:24:14PM +0200, laszlo kajan wrote: Please show me the way I can have my patch included in jscal.c of the joystick package. I believe it is useful and I immediately wanted to share it with others. Please file a bug report (including the patch) against the joystick package. Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: dpkg-shlibdeps and private libraries
Raphael Hertzog [EMAIL PROTECTED] writes: libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment variable apparently defined by the openoffice startup script/program. This variable is not set a build time (and the code wasn't expecting variables at that place anyway). I don't think $ORIGIN is an environment variable. AFAIK, the sun linker is using that keyword to specify that you want to use an RPATH relative to the location of the binary, which is pretty handy for deploying/moving not packaged local software that is dynamically linked. According to http://linuxreviews.org/man/ld.so/, the linux ld.so supports the same feature. However, I did not find this piece in the debian manpage, nor in the upstream documentation. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-shlibdeps and private libraries
On Wed, Sep 26, 2007 at 11:30:27AM +0200, Raphael Hertzog [EMAIL PROTECTED] wrote: Hello, _rene_ reported me a failure with openoffice and the new dpkg-shlibdeps. Scanning debian/openoffice.org-writer/usr/lib/openoffice/program/libswui680lp.so (for Depends field) dpkg-shlibdeps: failure: couldn't find library libsw680lp.so (note: only packages with 'shlibs' files are looked into). The problem is that libswui680lp.so has libsw680lp.so in NEEDED and thus dpkg-shlibdeps will try to find that library. I made it a failure when I'm not able to find the library as dpkg-shlibdeps is supposed to behave like ld.so and try to use the same mechanism to find out where the lib is. libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment variable apparently defined by the openoffice startup script/program. This variable is not set a build time (and the code wasn't expecting variables at that place anyway). $ORIGIN in rpath is not an environment variable. It is used to have directories relative to the current file in the rpath. Typical use is something like $ORIGIN/../lib for software coming in a $DESTDIR/bin/ directory when the libraries are in $DESTDIR/lib/. It makes software work wherever they are installed to. $ORIGIN alone just tells the dynamic loader to also look in the directory where the library/binary is for other libraries. That is, if a library in /usr/lib/foo has a $ORIGIN rpath, ld.so will also look into /usr/lib/foo for whatever this library needs. Now, you may think such a thing would be useless, except that if you already get your /usr/lib/foo/libfoo.so from an rpath (i.e. a binary linked to libfoo.so having /usr/lib/foo in its rpath), this rpath is not used for libfoo.so's dependencies. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#443769: rt2500-source: Missing dependency on bzip2
On Wed, 2007-09-26 at 00:26 -0500, Manoj Srivastava wrote: On Tue, 25 Sep 2007 22:10:52 -0400, Edward Allcutt [EMAIL PROTECTED] said: Perhaps because the specific compiler needed depends on what the current kernel was compiled with? I thought that was the reason linux-headers depended on a specific compiler version. Has that ever been the case? I've had modules compiled with a different gcc that I had when I compiled the kernel, and never had an issue so far. I could well be wrong but I thought there may be some problem with compiling modules with gcc-4.1 when the kernel was compiled with gcc-3.3. -- Edward Allcutt [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: Building packages with exact binary matches
On Wed, Sep 26, 2007 at 12:25:02AM -0500, Manoj Srivastava wrote: On Wed, 26 Sep 2007 02:45:09 +0200, Martin Uecker [EMAIL PROTECTED] said: [...] No. I would trust the binaries if there are *no mails* from other Ah, security through blissful ignorance :) You do not actually trust the archive, or the developers, you trust the silence. I trust special relativity, because nobody has disproven it yet. Do you think this is blissfull ignorance, too? Actually, partly. I am a quantum mechanic by training (I just went sideways into computer because there was so little money in devoce modeling). I like the special relativity because the math is sound; it has predicted things we were not aware of before; and all kinds of experimental data matches the theory -- except when you get to very very small dimensions, but people are still working on that. I am a mathematical phycicist by training: There are no known problems with the SRT at the small scale. But you are right with your other point: The math of a scientific theory has to be sound. But it has to be related to reality, too. It is the last part we are talking about. Just because you have _heard_ anyone diss special relativity being the sole reason to believe in it is in the same ball park as blissful, you know, ignorance. It is not about hearsay. It is about finding an error in a predictation. And I do not care *who* finds the error. Of course the predications have actually be checked. So you are right with your argument, if nobody actually does this, it would be ignorant to believe in a scientifc theory for the sole reason that nobody complains. Similar, if nobody recompiles the packages and checks for mismatches, then silence would in fact not imply that things are ok. But I question your premise: I have no doubt that some people would actually recompile packages and compare the hash. Even if it is not done normally, somebody would do this if doubts come up for some reason (e.g. some debian hosts are compromised again.). This alone would actually be worth a lot. [...] So, one someone lets the cat out of the bag, and we are not so blissful ,how can we check? Simple, you say, compile the source!! But, dear folks, the person who can compromise the archive, fake out the buildd's, add the archive signature -- can also hack the source. Is actually quite likely that somebody would notice if Debian distributes trojaned source packages. Really? What was the last time anyone looked through libsepol library code, eh? Or libselinux code? You do know dpkg and coreutils are linked to that? I would assume that there are people hacking on this code or at least somebody fixes a bug in it occasionally. I know I looked at the source code of libselinux once (but not closely). If in fact some code is never looked at, then it is propably a really bad idea to include it in critical packages. All security work in the free software community works like this: Somebody finds a flaw, he reports it, it gets fixed. So you say this can be DOSed by reporting a lot of false bug reports with a botnet? No, the bug reporter goes and presents _evidence_ that can be checked, and a patch, or a source of the problem. No one jumps up and down and issue CVE's just become someone says things are not ok. And no one makes a security ssue go away if bunches of people rise up and say the code is juuust fiiine. I never claimed that I believe random people just saying things are ok or not ok. A binary mismatch is *evidence*. So if some random people come up with such evidence, then I can check it myself. The difference is evidence. If there is some merit to the notion that a buildd is compromised, the solution is not bunches of people building from potentially tainted sources and comparing checksums. If know that the source code wich has hash 4457575757575 compiled in the build environment with hash 4837373737 gives a package with hash 366336363, then it is actually *evidence* that something is seriously wrong if you end up with a package with a different hash. Ironically, I think the current scheme where the binaries are signed by some public key provides a false illusion of security. Have you actually thought about the meaning of this signature? It just means that the signee (and I do not even know who this actually is) believes that this binary was not tampered with. Nothing more. And nobody else has the possibilty to verify this. If you do not know who the signatories of the archive key are, I suggest you leanr, and see how the web of trust thing works for you, and whether or not you can trust the guy doing the builds. Nothing is bullet proof. And no one can make anyone trust anyone, including themselves. Like all security ractices, it is a tradeoff. I have decided to trust my fellow DD's, and to trust the
Re: dpkg-shlibdeps and private libraries
On Wed, Sep 26, 2007 at 10:36:18AM +, Reinhard Tartler wrote: Raphael Hertzog [EMAIL PROTECTED] writes: libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment variable apparently defined by the openoffice startup script/program. This variable is not set a build time (and the code wasn't expecting variables at that place anyway). I don't think $ORIGIN is an environment variable. AFAIK, the sun linker is using that keyword to specify that you want to use an RPATH relative to the location of the binary, which is pretty handy for deploying/moving not packaged local software that is dynamically linked. According to http://linuxreviews.org/man/ld.so/, the linux ld.so supports the same feature. However, I did not find this piece in the debian manpage, nor in the upstream documentation. Yeah, as discussed on IRC, it's not documented, but the glibc ld.so supports $ORIGIN and $PLATFORM at least since glibc 2.1. It also supports $LIB which use is somehow unclear to me. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcyBXN29vD0.pgp Description: PGP signature
Re: AM status for Krystian Wlosek?
Don Armstrong wrote: The reason why maintainers may be checked far more thoroughly is because the average employee of Google or Microsoft can't make changes to any piece of software company wide, nor do they vote on the direction of the entire company. [It's also far easier to fire someone than it is to remove a Developer.] Nor can they write emails with the branding of Debian as a project (and eventually throw a bad light on it), nor can they use (and possibly abuse) the infrastructure a dozen volunteers provide. If you feel that the checks are unreasonable or to thorough, then feel free to make specific recommendations for places where they should be relaxed, ideally by helping with the NM process. There has been the decision on Developers light. Wouldn't that be something for contributors like him? How far has this gotten in technical sense? Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-shlibdeps and private libraries
libswui680lp.so has an RPATH set to $ORIGIN ... which is an environment variable apparently defined by the openoffice startup script/program No. $ORIGIN is dynamic linker feature, it is expanded to the directory where executable resides. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
On Wed, Sep 26, 2007 at 02:57:52AM -0700, Don Armstrong wrote: On Tue, 25 Sep 2007, Piotr Roszatycki wrote: I suppose that everyone are busy today, so do I. I'm a little tired with sponsoring his packages and I know he could to upload his packages by his own. I really don't undestand why new developers are checked so precisely. I think it is much harder to join Debian than i.e. Google or Microsoft. It is ridiculous. I understand, the developers should have a good knowledge of unix systems and our ogranization but... that's going too far! The reason why maintainers may be checked far more thoroughly is because the average employee of Google or Microsoft can't make changes to any piece of software company wide, nor do they vote on the direction of the entire company. [It's also far easier to fire someone than it is to remove a Developer.] If you feel that the checks are unreasonable or to thorough, then feel free to make specific recommendations for places where they should be relaxed, ideally by helping with the NM process. There is also the DM (Debian maintainer) vote that indicates that DD seem not to mind allowing certain folks to upload certain packages. But this has not been implemented yet. If that were implemented, the OP would have want he wanted, at least that is what I would expect. =K -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal |mysite.verizon.net/kevin.mark/| | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keyserver: subkeys.pgp.net | my NPO: cfsg.org | |join the new debian-community.org to help Debian! | |___ Unless I ask to be CCd, assume I am subscribed ___| -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
/usr/share/man/man8/ld.so.8.gz does not document the $ORIGIN, $PLATFORM and $LIB feature
Package: libc6 Version: 2.6.1-1+b1 Severity: wishlist Tags: patch File: /usr/share/man/man8/ld.so.8.gz Raphael Hertzog noticed in [1] that the openoffice.org package is using the undocumented $ORIGIN feature of the linux ld.so. See [2] for a documentation of that feature. [1] http://thread.gmane.org/gmane.linux.debian.devel.general/119923 [2] http://linuxreviews.org/man/ld.so/ See the following irc query in #debian-devel: 12:42:05 MadCoder according to http://linuxreviews.org/man/ld.so/ it does 12:42:20 MadCoder (understands $ORIGIN) 12:43:04 MadCoder siretart: linux seems to support it 12:43:12 MadCoder it's just not in the man page 12:43:21 MadCoder let me look at ld code 12:43:21 siretart MadCoder: oh. then we should have that documented :) 12:43:31 buxy siretart: anyway, thanks for the info! 12:43:53 MadCoder siretart: yeah, stupid glibc maintainers 12:44:27 _rene_ siretart: their goal is to get rid of LD_LIBRARY_PATH (which they currently use, too because some internally shipped libs like libxml, python, .. (sic!) don't have the RPATH) 12:44:53 _rene_ siretart: and they indeed used $ORIGIN since ever. 12:45:08 MadCoder siretart: the code shows that $ORIGIN and $PLATFORM are supported 12:45:27 MadCoder and $LIB 12:45:31 MadCoder not sure what they do 12:45:40 _rene_ MadCoder: ah, so it's an ld feature? good to know... 12:45:58 MadCoder yeah I'm looking at glibc-2.6/elf/dl-load.c right now :) 12:46:02 * _rene_ didn't really look that deep into what $ORIGIN is for at OOo 12:46:23 MadCoder and it seems that you can put $ORIGIN $PLATFORM and $LIB in your rpath 12:46:38 MadCoder $ORIGIN is the absolute path the binary in question live 12:46:44 MadCoder $PLATFORM is your elf platform 12:46:58 siretart MadCoder: cool! 12:47:10 MadCoder I'm not sure to understand what $LIB is yet 12:49:39 MadCoder siretart: and it seems linux supports it at least since glibc 2.1 12:49:43 MadCoder so it's hardly new 12:50:15 _rene_ .oO ( that also explains why OOos configure script explicitely checks for glibc being = 2.1 ) 12:51:02 MadCoder probably 12:51:29 MadCoder $LIB is defined it seems to a safe path where to find libraries when building the glibc 12:51:32 MadCoder it's odd 12:52:16 MadCoder though $ORIGIN and $PLATFORM are definitely nice features 12:52:33 MadCoder buxy: so you shouldn't have such a hard time to deal with it 12:53:00 MadCoder for a library path/to/libfoo.so $ORIGIN has to be replaced with path/to 12:54:25 buxy MadCoder: yeah, that's easy, however I think I'll ignore $PLATFORM and $LIB for now 12:54:31 * siretart goes to file a bug about documenting the $ORIGIN feature 12:55:14 MadCoder $LIB is likely to be never used -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (50, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 2.6.20.4-gernoth-64bit (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.2.1-4 GCC support library libc6 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
2007/9/26, Patrick Schoenfeld [EMAIL PROTECTED]: Don Armstrong wrote: The reason why maintainers may be checked far more thoroughly is because the average employee of Google or Microsoft can't make changes to any piece of software company wide, nor do they vote on the direction of the entire company. [It's also far easier to fire someone than it is to remove a Developer.] Nor can they write emails with the branding of Debian as a project (and eventually throw a bad light on it), nor can they use (and possibly abuse) the infrastructure a dozen volunteers provide. Why just new maintainers are checked so precisely? The old Debian developers also can make a threat for Debian Project. It's logical, that everybody should be checked, especially the old developers which didn't be check so paranoid in the past. I hope you see the absurdity in this procedure... -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
Piotr Roszatycki wrote: Why just new maintainers are checked so precisely? The old Debian Because the old Debian developers should have been checked already. developers also can make a threat for Debian Project. It's logical, Yeah, off course *can* they do this. But it is impossible to check everyone who ever passed a NM-test on a regular basis. You see that it is already a *big* job to check new applicants which shouldn't be more then eventual 100 per month, how should that be if you wanted to check 1000 developers on a regular basis? So all you *can* do is check it when they apply to become a developer. that everybody should be checked, especially the old developers which didn't be check so paranoid in the past. I got the point, but you cannot argue against a good practice in the current by mistakes made in the past. I agree that it might be good to checkout who were checked more loosely and check if this maintainer is still active, if his contributions are of a good quality, etc. But I think that this will not make things better, so it is eventually pointless, while you can avoid a lot by checking new applicants proper. I hope you see the absurdity in this procedure... Nope. Not that clear. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444115: general: network interface (eth0) gets undetected after restrat checked using ifconfig -a
On Wednesday 26 September 2007 13:33:09 Josselin Mouette wrote: Le mercredi 26 septembre 2007 à 12:49 +0530, Antano Solar a écrit : When the cmos battery is removed and power unplugged and the system booted . I press f2(load defaults) in the cmos screen and the syetm boots very slowly and detects my lan card. i.e ifconfig -a lists eth0. But after this if I shut down the computer and start again or even restart it , the network card is not detected . when the network card goes undetected even if I boot into windows it remains undetected in windows also. To make the netowrk card appear again I need to rerun the procedure of removing the batters and unplugging power cable. If the problem appears in other operating systems, it sounds like it is caused by the hardware or the firmware - either the BIOS or the network card's. The problem occurs in windows only if I do a shutdown in linux. When i boot in windows and restart again or shutdown and start it is fine. But the card disappears only after I boot into linux and shutdown
Re: volatile.debian.org: Does Debian still support it?
Hi, On Wed Sep 26, 2007 at 00:20:10 +0200, Piotr Roszatycki wrote: You made a subtle mistake. You checked the source package for tzdata and the changes are really small. Then you checked the differences for libdatetime-timezone-perl package, but this source package is already compiled. You should check the difference between binary packages for tzdata. The real source data for DateTime::TimeZone is the same as for tzdata source package. Then, the data is precompiled into Perl source. It makes a Debian source package. Accepted now. For the future: i would have been much easier, if you would have said: be warned, the patch is huge, but if you don't look at the compiled version of it, it is these number of lines... Both of us would have had much less trouble. Greetings Martin PS: It might take me a day or so to prepare a VUA, unless someone drafts one for me. -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
On Wed, 26 Sep 2007, Piotr Roszatycki wrote: Why just new maintainers are checked so precisely? The old Debian developers also can make a threat for Debian Project. It's logical, that everybody should be checked, especially the old developers which didn't be check so paranoid in the past. Those Developers who haven't gone through the NM process for the most part have been checked by a far more rigorous procedure: they've actually contributed and done the work. [Indeed, all developers are continually being rechecked by this metric.] Don Armstrong -- Every gun that is made, every warship launched, every rocket fired signifies in the final sense, a theft from those who hunger and are not fed, those who are cold and are not clothed. This world in arms is not spending money alone. It is spending the sweat of its laborers, the genius of its scientists, the hopes of its children. This is not a way of life at all in any true sense. Under the clouds of war, it is humanity hanging on a cross of iron. -- Dwight Eisenhower, April 16, 1953 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]: Accepted now. Thank you very much. For the future: i would have been much easier, if you would have said: be warned, the patch is huge, but if you don't look at the compiled version of it, it is these number of lines... Both of us would have had much less trouble. I think we could communicate better if you read the patch, not just statistics about it. By the way, the patch itself does not contain the real source data - the Olson database. I understand that it might be not clear for someone who didn't use this library and know nothing about complexity of timezones support in computing systems. It is really hard piece of technology. Thanks a lot and greetings. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
Don Armstrong wrote: Those Developers who haven't gone through the NM process for the most part have been checked by a far more rigorous procedure: they've actually contributed and done the work. [Indeed, all developers are continually being rechecked by this metric.] Eh.. i agree with most of you in this thread. But this argumentation meets for almost everybody that really intends to become a DD. That does say nothing about quality of their work, *if* they *will* do there duties and if they *will* do it in a regular manner. You cannot argue with something that cannot be evaluated, whereas you ask for evaluation of other peoples contribution to Debian. Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
Piotr Roszatycki wrote: 2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]: Accepted now. Thank you very much. For the future: i would have been much easier, if you would have said: be warned, the patch is huge, but if you don't look at the compiled version of it, it is these number of lines... Both of us would have had much less trouble. I think we could communicate better if you read the patch, not just statistics about it. By the way, the patch itself does not contain the real source data - the Olson database. I understand that it might be not clear for someone who didn't use this library and know nothing about complexity of timezones support in computing systems. It is really hard piece of technology. It's only logical to NOT start reading a patch of more than 38K lines, so it's far easier if one would explain beforehand why it's that huge... Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
On Wed, 26 Sep 2007, Patrick Schoenfeld wrote: Don Armstrong wrote: Those Developers who haven't gone through the NM process for the most part have been checked by a far more rigorous procedure: they've actually contributed and done the work. [Indeed, all developers are continually being rechecked by this metric.] Eh.. i agree with most of you in this thread. But this argumentation meets for almost everybody that really intends to become a DD. That does say nothing about quality of their work, *if* they *will* do there duties and if they *will* do it in a regular manner. You cannot argue with something that cannot be evaluated, whereas you ask for evaluation of other peoples contribution to Debian. Unfortunatly, I'm not quite sure I understand what you're saying. The point of NM is to evaluate whether people are capable of positively contributing to Debian and are going to do so. How this is done exactly depends on the AM, but that's what the NM procedure does. If you're arguing that we can't evaluate it with 100% certainty, I agree. My goal as an AM is to do the best job I can. If you're saying that it can't be evaluated at all, I disagree. People's technical skill and previous contributions to Debian all point to the likelihood of their future contribution. Don Armstrong -- My spelling ability, or rather the lack thereof, is one of the wonders of the modern world. http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
Hi, On Wed Sep 26, 2007 at 14:46:16 +0200, Piotr Roszatycki wrote: 2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]: Accepted now. Thank you very much. For the future: i would have been much easier, if you would have said: be warned, the patch is huge, but if you don't look at the compiled version of it, it is these number of lines... Both of us would have had much less trouble. I think we could communicate better if you read the patch, not just statistics about it. By the way, the patch itself does not contain the real source data - the Olson database. I understand that it might be will that cause dfsg problems? not clear for someone who didn't use this library and know nothing about complexity of timezones support in computing systems. It is really hard piece of technology. -- [EMAIL PROTECTED] /root]# man real-life No manual entry for real-life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: modified email address in debian/copyright file
On Tue, Sep 25, 2007 at 03:20:09PM -0500, Steve Greenland wrote: I'd bet at least a small sum of money that not beyond human recognition and impede machine parsing are, at this point, non-intersecting sets. It's not even like they have to get it right on the first try -- just generate a bunch of differnt unmunges, and try them. Or, more accurately, sell them to losers. I personally agree. I don't bother munging my email address at all anymore, as I don't think it helps a great deal in the mid to long term, and it certainly detracts from the usefulness of an address. However if an upstream author of a package wishes to conceal their address, I think we should honour that. -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
Don Armstrong schrieb: If you're saying that it can't be evaluated at all, I disagree. No. Don't get me wrong, because that is /absolutely/ not what I wanted to say. But you said (as far as I have understood) that those Debian Developers that have /not/ gone through the NM process has proven that they are good enough to be a DD, by actually (and /just/)contributing and doing the work. I just wanted to point out, that this argumentation is weak, because you say: Hey, we need to check if a /new/ prospective developer really has the intension that conform with the project, is technically skilled, has actually done something for the project, etc. Yeah, we *really* need to check it, because he did eventually do some work, but we have not checked it for quality, for the kind of it has to be for Debian etc. But OTOH you say: Hey, those Debian Developers that have /not/ been checked have proven their qualification on their own, without anyone ever checking this like you do with a NM-application. Again: I really really think that the NM-Process is a good thing and i really think it has to be done well, but then you cannot argue /this/ way for people who didn't need to go through this procedure. Hopefully, I now found a way to tell you, what I meant. Greets Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
On Wed, 26 Sep 2007 16:17:52 +0200 Patrick Schoenfeld [EMAIL PROTECTED] wrote: But OTOH you say: Hey, those Debian Developers that have /not/ been checked have proven their qualification on their own, without anyone ever checking this like you do with a NM-application. The work of those DD's is constantly reviewed and checked by other DD's - during mass bug filing, NMU's, bug triage etc.etc. Again: I really really think that the NM-Process is a good thing and i really think it has to be done well, but then you cannot argue /this/ way for people who didn't need to go through this procedure. Hopefully, I now found a way to tell you, what I meant. The procedure is constantly evolving - it was different 5 years ago to how it was 2 years ago and how it is today. The only way to proceed is to ensure that DD's who were accepted long ago are as up to date as new DD's via mailing lists, standards versions and policy etc. Ongoing work within Debian is a continuing re-evaluation of each active DD by other DD's (and users). The process of learning does not stop upon acceptance, it is an ongoing process of keeping up to date with changes across Debian. From what little I've seen on debian-private, it is this ongoing workload of staying up to date that makes the difference when an inactive DD is thinking about leaving the project due to a lack of time. DD's who were accepted many years ago are just as conscientious as new DD's. Staying up to date after acceptance is a trickle process - it is completely impractical to try to require ongoing examination of such a process. Old or new, if a DD makes a wrong call on a mailing list or in a bug report, there's usually someone who will point it out. :-) That's how peer review works - not by continual external examination but by ongoing review by those who are in the same situation. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpFDGzPntHFM.pgp Description: PGP signature
Re: How to detect if inside a buildd chroot
hi It is all explained in /usr/share/doc/sysv-rc/README.policy-rc.d It seems that all you need to do is to create inside your chroot a simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101' for example with these two simple commands $ echo -e '#!/bin/sh\nexit 101' /usr/sbin/policy-rc.d $ chmod +x /usr/sbin/policy-rc.d then invoke-rc.d becomes a no-op, it will not start or stop anything. Unfortunately the docs are a bit incomprehensible to me .. it seems you can do much complex stuff than that, but I cant help. You may want to look into the package policyrcd-script-zg2 : they know their act. a. Sebastian Dröge ha scritto: Am Dienstag, den 25.09.2007, 11:49 +0200 schrieb Jonas Meurer: On 25/09/2007 Sebastian Dröge wrote: does somebody know about a solution to check whether one runs in a buildd chroot or not? I need this to prevent hal from starting in buildd chroots (via invoke-rc.d from postinst) as it breaks there because of several reasons, including no /sys mounted. I tought that this should be handled by invoke-rc.d itself. The manpage states that: invoke-rc.d introduces the concept of a policy layer which is used to verify if an init script should be run or not, or if something else should be done instead. This layer has various uses, the most immediate ones being avoiding that package upgrades start daemons out-of-runlevel, and that a package starts or stops daemons while inside a chroot jail. So my assumption was that invoke-rc.d detects if it's invoked inside a chroot, and doesn't start the service in that case. AFAIK this only happens if specified in some config file that daemons shouldn't be started. Whatever, although hal is invoked by invoke-rc.d it is started in the buildd chroots. :/
Re: AM status for Krystian Wlosek?
Neil Williams wrote: The work of those DD's is constantly reviewed and checked by other DD's - during mass bug filing, NMU's, bug triage etc.etc. And the work of non-DD contributors isn't? Come on, you know that I don't speak against how it is currently, but against the /argumentation/. It is as it is: We need to trust in that the people, who ever got DD, are trust worth. If we do not, then a community and the good work like it is can't be kept up. as new DD's. Staying up to date after acceptance is a trickle process - it is completely impractical to try to require ongoing examination of such a process. Full ACK. And *this* is a true argument, IMHO. It is just not realizable to ongoing examine if DD stayed actual with current policies or their interest. Old or new, if a DD makes a wrong call on a mailing list or in a bug report, there's usually someone who will point it out. :-) Right. :-)) -Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New adzapper package with Konqueror AdBlocK support
Hi ! I've uploaded a new adzapper package (20070317-2), which generates a file compatible with Konqueror's adblock feature. Just import the file /var/lib/adzapper/konqueror.txt in the adblock panel. Feel free to send me any suggestion. Cheers, -- Ludovic Drolez. http://www.palmopensource.com - The Palm Open Source Portal http://www.drolez.com - Personal site - Linux, Zaurus and PalmOS stuff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New adzapper package with Konqueror AdBlocK support
[Ludovic Drolez] Just import the file /var/lib/adzapper/konqueror.txt in the adblock panel. Feel free to send me any suggestion. Uh, wouldn't that belong in /usr/share? -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Bug#444189: ITP: libtap-parser-perl -- Perl module for parsing TAP output
Package: wnpp Severity: wishlist Owner: gregor herrmann [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: libtap-parser-perl Version : 0.54 Upstream Author : Curtis Ovid Poe * URL : http://search.cpan.org/dist/TAP-Parser/ * License : Perl (GPL/Artistic) Programming Lang: Perl Description : Perl module for parsing TAP output TAP::Parser is designed to produce a proper parse of TAP output. . TAP, the Test Anything Protocol, is Perl's simple text-based interface between testing modules such as Test::More and the test harness Test::Harness. libtap-parser-perl is needed by the new release of libmail-box-perl (cf. #442912). - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22.200709061812 Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+oyAOzKYnQDzz+QRAqHcAKCdi/rYOL7YROIRsbM+O2Ts+7LqnwCgv5ai vsY5+VB7aN6t4P9+ijY6SNs= =F+R4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: volatile.debian.org: Does Debian still support it?
2007/9/26, Martin Zobel-Helas [EMAIL PROTECTED]: I think we could communicate better if you read the patch, not just statistics about it. By the way, the patch itself does not contain the real source data - the Olson database. I understand that it might be will that cause dfsg problems? Not at all. The packages was built with pbuilder. It still is not fully understandable, so I'll try explain: olson db = tzdata source package upstream olson db + time zone compiler (zic) = tzdata binary package olson db + parse_olsen translator = DateTime::TimeZone official CPAN source package = Debian source package Debian source package + pbuilder = Debian binary package The Debian source package is based on official CPAN package and contains already parsed database which is provided by original author. I did the same work as upstream author, so I called parse_olsen translator and I've got the path for new Debian source package. Of course it builds our Debian binary package correctly. -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
On Wed, 26 Sep 2007, Patrick Schoenfeld wrote: Neil Williams wrote: The work of those DD's is constantly reviewed and checked by other DD's - during mass bug filing, NMU's, bug triage etc.etc. And the work of non-DD contributors isn't? Not in the same way, no. Most non-DD contributions that actually affect the archive always go through a DD gatekeeper. At the end of the day, that DD is the person who is actually responsible. We need to trust in that the people, who ever got DD, are trust worth. If we do not, then a community and the good work like it is can't be kept up. That's actually backwards from what I've said. My argument is not that DDs should be trusted, but that DDs are in a position where they can abuse that trust. The longer they've been a DD (and the more work they do) the less and less likely they are to do so (at least intentionally). It is just not realizable to ongoing examine if DD stayed actual with current policies or their interest. It's easier to tell[1] which developers are current with what is happening in Debian (assuming they're active) than it is to tell whether an NM applicant is. Don Armstrong 1: by looking at the packages they upload, the bugs that they have open, and the bugs which have been filed -- Grimble left his mother in the food store and went to the launderette and watched the clothes go round. It was a bit like colour television only with less plot. -- Clement Freud _Grimble_ http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AM status for Krystian Wlosek?
Don Armstrong wrote: That's actually backwards from what I've said. My argument is not that DDs should be trusted, but that DDs are in a position where they can Well, but actually it does not work without a level of trust. And as a community that tries to build up a good, reliable and universal operating system, there cannot be trust in anyone. abuse that trust. The longer they've been a DD (and the more work they do) the less and less likely they are to do so (at least intentionally). If you intended to say that by the first mail, then I agree and there is no need to argue anymore. :) It's easier to tell[1] which developers are current with what is happening in Debian (assuming they're active) than it is to tell whether an NM applicant is. Hm. Considered that all tools (including BTS, PTS and QA pages) track the work of non-DD contributors.. hmm.. probably, probably not. Greets, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444199: ITP: freecol -- freecol: an open version of Colonization
Package: wnpp Severity: wishlist Owner: Vincent Fourmond [EMAIL PROTECTED] * Package name: freecol Version : 0.7.2 Upstream Author : [EMAIL PROTECTED] * URL : http://www.freecol.org/ * License : GPL Programming Lang: java Description : freecol: an open version of Colonization freecol is a game in the spirit of Civilization but taking place in a colonial background. Colonize a new world, build towns, trade or fight with natives and other European civilizations, trade with your homeland until you're ready to fight for your independance ! Java game, so probably will end up in contrib. License is GPL, I'm not sure though whether all art work is free. Great game (though buggy sometimes...) ! Vincent Fourmond -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
A Mennucc [EMAIL PROTECTED] writes: It is all explained in /usr/share/doc/sysv-rc/README.policy-rc.d It seems that all you need to do is to create inside your chroot a simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101' I would very much prefer that all packages worked correctly inside a chroot without any admin intervention. If it's not appropriate to run inside a chroot, then the init script should IMHO detect that and not start/restart/stop the service. 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. pgptLwotFfjzL.pgp Description: PGP signature
Re: How to detect if inside a buildd chroot
On Wed, Sep 26, 2007 at 09:31:36PM +0100, Roger Leigh wrote: A Mennucc [EMAIL PROTECTED] writes: It is all explained in /usr/share/doc/sysv-rc/README.policy-rc.d It seems that all you need to do is to create inside your chroot a simple shell script /usr/sbin/policy-rc.d that just does an 'exit 101' I would very much prefer that all packages worked correctly inside a chroot without any admin intervention. If it's not appropriate to run inside a chroot, then the init script should IMHO detect that and not start/restart/stop the service. The fact is, not all chroot are buildd chroots, and many chroots actually do run services... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
Mike Hommey [EMAIL PROTECTED] wrote: chroot without any admin intervention. If it's not appropriate to run inside a chroot, then the init script should IMHO detect that and not start/restart/stop the service. The fact is, not all chroot are buildd chroots, and many chroots actually do run services... Yep... but I still find it a bit annoying that I have to override binaries like start-stop-daemon or invoke-rc.d when building a chroot. I wish there was a way to just set a flag that means dpkg, don't start/stop any services!... instead I end up doing stuff like: invoke=/usr/sbin/invoke-rc.d cdebootstrap -f standard $SUITE $TARGET $MIRROR mount -t proc proc $TARGET/proc $chroot $TARGET $aptitude update || throw $chroot $TARGET /usr/sbin/dpkg-divert \ --add --rename --divert $invoke.orig $invoke || throw ln -sf /bin/true $TARGET/$invoke [bootstrap code...] /bin/rm -f $TARGET/$invoke $chroot $TARGET /usr/sbin/dpkg-divert \ --remove --rename --divert $invoke.orig $invoke || throw umount $TARGET/proc - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect if inside a buildd chroot
ke, 2007-09-26 kello 13:49 -0700, Tyler MacDonald kirjoitti: Yep... but I still find it a bit annoying that I have to override binaries like start-stop-daemon or invoke-rc.d when building a chroot. I wish there was a way to just set a flag that means dpkg, don't start/stop any services!... instead I end up doing stuff like: That shouldn't be necessary anymore. The policy-rc.d trick that has been mentioned in this thread a couple of times should work fine. Here's the code in piuparts which does it: full_name = os.path.join(self.name, usr/sbin/policy-rc.d) create_file(full_name, #!/bin/sh\nexit 101\n) os.chmod(full_name, 0777) -- Copyrights, patents, trademarks: not property, not rights, but priviledges! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444221: ITP: python-pysizer -- memory profiiler for Python
Package: wnpp Severity: wishlist X-Debbugs-Cc: debian-devel@lists.debian.org Owner: Thomas Viehmann [EMAIL PROTECTED] * Package name: python-pysizer Version : 0.1.1 Upstream Authors: Nick Smallbone * URL : http://pysizer.8325.org/ * License : BSD-like Programming Lang: Python, basically Description : memory profiler for Python PySizer lets you analyse the memory usage of your Python programs and makes data such as memory usage by objects of a certain type readily available. This package contains the parts of PySizer written in Python. There is an optional patch to python itself to collect more information, but that has not been compiled into the stock Debian python binaries. As always, suggestions (better description, etc.) are very welcome. There might be room for improvement. python-pysizer will likely be comaintained by the python-modules team. I'm not yet sure what to do about the patch to the python interpreter, PySizer is very useful even without it, though. PySizer has an advantage over Heapy (cp. ITP #409740) in that the pure python parts are useful by themselves. (Heapy presently segfaults on amd64 and I have not found a fix yet). Kind regards T. -- Thomas Viehmann, http://thomas.viehmann.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
ITH: libxmlrpc-c
hey folks, this package is getting waaay out of date. as the current maintainer has stated in the BR (which has been open for over 2 years), he doesn't really have the time/interest in continuing to maintain it and has offerred to give it up to those in the BR, but nothing has happened. also, gutsy has moved on ahead and packaged the latest version. personally, i have a small amount of interest in seeing this package updated, as i would like the xmlrpc support in rtorrent which is blocked by this. so, unless there are any serious objections i will just grab the version from gutsy if that seems to work, and follow their lead. i don't believe that the updating will cause too much problems wrt transitions, since there's only one reverse depends (openser) for the package currently in unstable afaict. if there's anyone who's more interested in permanently maintaining this package feel free to step up. sean signature.asc Description: This is a digitally signed message part.
Re: New adzapper package with Konqueror AdBlocK support
Peter Samuelson schrieb: [Ludovic Drolez] Just import the file /var/lib/adzapper/konqueror.txt in the adblock panel. Feel free to send me any suggestion. Uh, wouldn't that belong in /usr/share? If it's downloaded from the internet or autogenerated in some way then I'd say /var/lib/ is correct. For static data I agree, /usr/share/ would be more appropriate (*) Cheers, Michael (*) I think adzapper does the former (without checking the package more deeply). -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: modified email address in debian/copyright file
Jon Dowland [EMAIL PROTECTED] writes: However if an upstream author of a package wishes to conceal their address, I think we should honour that. This is at odds with always have correct contact information for the copyright holder at the time of packaging, which I think Debian should strive to achieve for the sake of its users. The only way to honour conceal their address at the same time as the above is to not distribute the package at all. I don't think that's a good solution. -- \Computers are useless. They can only give you answers. -- | `\ Pablo Picasso | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packaging a library that requires cross-compiled code
[I've only just subscribed, please forgive me if I got something horribly wrong] Hello, I was redirected here for advice from #debian-mentors, following a packaging question I have. The short summary: I'd like to package a library which requires a tiny blob of cross-compiled code to run, and don't know how to achieve this in a debian-friendly way. Context: the code I'd like to package is a Python package and associated Python scripts, that enable low-level communication with a Lego Mindstorms NXT brick over USB. This is the newer Lego Mindstorms brick, which to the best of my knowledge currently has no supporting libraries available in Debian (support is available for the older, but completely different RCX model). My module enables low-level communication at two levels: a wrapper around python-pyusb to facilitate scanning for a brick and accessing it, and an implementation of the simple command protocol used by the onboard bootloader. This is a library aimed squarely at developers who want to replace Lego's firmware with something else (in my case, an open source high kernel I'm working on). One of the tools provided is called `fwflash`, which takes a binary firmware image and writes it to the brick's flash chip via the bootloader. One of the steps in the flashing procedure is to upload a tiny (136 bytes) driver for the flash controller into the brick's ram, to oversee the actual flashing process. The brick cannot be flashed without the help of this driver. (for those who care, the flash memory is single-plane, which cannot be simultaneously read and written, which requires the use of an in-ram driver for the few instructions that actually perform the write. Attempting to drive the entire process through the bootloader crashes the brick.) And, of course, as the brick is based on an arm7 architecture, this flash driver needs to be cross-compiled. From an architectural POV, the flash driver is an internal implementation detail, the end user of the library doesn't care about the technicalities that forced it into existence. Problem: the flashing tool is unusable without this tiny piece of firmware, but that code can only be compiled with a properly built arm7tdmi cross-compiling gcc, which is not available in Debian. I built my own from gnuarm.com. Therefore, question: how should I get from this situation to having a working .deb (including the cross-compiled driver), while at the same time playing nicely with Debian packaging policies? Possible solutions that we came up with on #debian-mentors: 1) Ship a built copy of the code in the package's .diff.gz, and DTRT at package creation time to move the .bin from debian/ to the right place in the staging tree. The source code for the .bin is in .orig.tar.gz, under a free license. Anyone is free to modify or rebuild the .bin, provided they obtain an arm7 cross-compiler by non-debian means (instructions provided). People who just want to rebuild the package can do so, without caring that there is cross-compiled code involved. Pro: dead simple, the packaging problem goes away. Con: means shipping a binary blob in the source distribution, which appears to be frowned upon, regardless of whether the source is also freely available in the source distribution. 2) Package an arm7 cross-compiling gcc with just the right set of options, integrate that with the packaging tools, and then package with a Build-Depends on the cross-compiler. Pro: feels like the Right Way, in a perfect world. Cons: opens the floodgates of packaging cross-compilers, likely requires additions/modifications to packaging tools, and takes way more time than I'm personally ready to put into packaging my code. 3) Somehow make the packaging tools properly cross-compile the .bin without having a cross-compiler package around. This was briefly suggested on #debian-mentors, but I have no idea how this would be implemented. Pros: less time involved than 2), would make the package self-contained. Cons: building a cross-compiler in the packaging process just to build a 136 byte binary blob feels like killing a flea with a bazooka, and makes building the package much, much longer than it should be, given the amount of code and logic it actually carries. 4) Give up and stay away from the Debian main repositories, just put the package up on a private package repository. Pro: trivial solution. Cons: I'd like to do things right rather than cobbling something together. There you have it. Ideas, thoughts? - Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
On 9/27/07, David Anderson [EMAIL PROTECTED] wrote: Possible solutions that we came up with on #debian-mentors: The other possibility that was mentioned was to split the firmware out into a separate source package that produces an Arch: all package and then ensure that it is built on arm. People in the channel had no idea if this would work though :) -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
4) Give up and stay away from the Debian main repositories, just put the package up on a private package repository. Please don't choose this way to solve the problem. Lego Mindstorms are used a lot for education, including universities, as it is just very easy to build objects with Lego bricks, so you have more time to think about the code then about how to handle metal or other raw material. Unfortunately I still have no clue about cross-compiling, but please let me know if you need any help with the python parts. Feel free to join #debian-python on OFTC, all questions regarding python apps/modules are welcome there Imho one very fast way to solve the problem would be to package all the python tools, including fwflash - but without the actual firmware blob. Instead you ask the people to download the file or let the tool handle this automatically - at least this would make sure people are able to use your tools with mindstorms while you have enough time to figure out how to ship the precompiled firmware in a debian package. For example you could build the firmware package on arm only and let your tools download and extract the package. Hope I could give you some useful hints, Bernd -- Bernd Zeimetz [EMAIL PROTECTED] http://bzed.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
On Thu, Sep 27, 2007 at 11:11:40AM +1000, Paul Wise wrote: On 9/27/07, David Anderson [EMAIL PROTECTED] wrote: Possible solutions that we came up with on #debian-mentors: The other possibility that was mentioned was to split the firmware out into a separate source package that produces an Arch: all package and then ensure that it is built on arm. People in the channel had no idea if this would work though :) The only (good) way to ensure the arch: all package is built on arm is to always do the sourceful upload of the package from arm. (Otherwise, you'd be building the arch: all package from the binary-arch rule on arm only; this would work, but cause brain-twistiness wrt the separation between arch: all and arch: any.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
On Wed, Sep 26, 2007 at 06:38:02PM -0700, Steve Langasek wrote: On Thu, Sep 27, 2007 at 11:11:40AM +1000, Paul Wise wrote: On 9/27/07, David Anderson [EMAIL PROTECTED] wrote: Possible solutions that we came up with on #debian-mentors: The other possibility that was mentioned was to split the firmware out into a separate source package that produces an Arch: all package and then ensure that it is built on arm. People in the channel had no idea if this would work though :) The only (good) way to ensure the arch: all package is built on arm is to always do the sourceful upload of the package from arm. (Otherwise, you'd be building the arch: all package from the binary-arch rule on arm only; this would work, but cause brain-twistiness wrt the separation between arch: all and arch: any.) I think that perhaps Paul meant to say an arch any package. If the code must always be compiled for a particular flavor of ARM processor, regardless of the host architecture of the machine which will be controlling the Lego, then it should be possible to build it is arch any, which would not get autobuilt anyways. Then, as long as the uploader (maintainer or NMU) buils on ARM, everything should be OK. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Packaging a library that requires cross-compiled code
On Wed, Sep 26, 2007 at 09:43:17PM -0400, Roberto C. Sánchez wrote: I think that perhaps Paul meant to say an arch any package. If the code must always be compiled for a particular flavor of ARM processor, regardless of the host architecture of the machine which will be controlling the Lego, then it should be possible to build it is arch any, which would not get autobuilt anyways. Then, as long as the uploader (maintainer or NMU) buils on ARM, everything should be OK. Please completely disregard what I said. I have got it completely confused. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com signature.asc Description: Digital signature
Re: Packaging a library that requires cross-compiled code
On 9/27/07, Steve Langasek [EMAIL PROTECTED] wrote: The other possibility that was mentioned was to split the firmware out into a separate source package that produces an Arch: all package and then ensure that it is built on arm. People in the channel had no idea if this would work though :) The only (good) way to ensure the arch: all package is built on arm is to always do the sourceful upload of the package from arm. Right. The issue would be whether or not the arm/armel gcc binaries support the right target characteristics: danderson the target system is an arm7, with no MMU, so no linux for starters danderson I suspect that if debian supports an arm architecture, it'd be arm9 or higher helmut -mcpu=arm7? danderson arm7tdmi * danderson digs out the arm-elf-gcc configuration danderson arm-elf, arm7 cpu, thumb interworking support, software floating point emulation. That's the combination I need. Any emdebian/other folks know if this is an option? -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Changing name of source package
On Tue, Sep 25, 2007 at 05:04:47PM +0200, Uwe Steinmann wrote: I just want to double check that changing the name of a source package can be done as I anticipate it. I would like to change the name of the source package php4-ps into php-ps. php4-ps creates two binary packages php4-ps and php5-ps. The new source package php-ps will only create php5-ps because php4 will be dropped anyway in the near future. From what I have read so far, it should be sufficient to upload the new source package which takes over the binary package php5-ps. Is it required to wait for a new upstream version or can I simply push up the debian version from 1.3.5-1 to 1.3.5-2? The only other thing you need to worry about is filing a bug report against ftp.debian.org to get the old php4-ps source package removed, since this won't happen automatically. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Packaging a library that requires cross-compiled code
On Thu, Sep 27, 2007 at 02:59:16AM +0200, David Anderson wrote: [how best to package a stub for which the cross-compiler isn't in Debian] [possible solution 1] 1) Ship a built copy of the code in the package's .diff.gz, and DTRT at package creation time to move the .bin from debian/ to the right place in the staging tree. The source code for the .bin is in .orig.tar.gz, under a free license. Anyone is free to modify or rebuild the .bin, provided they obtain an arm7 cross-compiler by non-debian means (instructions provided). People who just want to rebuild the package can do so, without caring that there is cross-compiled code involved. Pro: dead simple, the packaging problem goes away. Con: means shipping a binary blob in the source distribution, which appears to be frowned upon, regardless of whether the source is also freely available in the source distribution. A slight variant on this would be to ship assembly source (the output of gcc -S) instead of a binary blob, and cross-assemble that. If the stub is 136 bytes long, assembly isn't too bad, and it's a step away from a binary blob. This presumes that the cross-tools in Debian can correctly assemble arm7, which I haven't verified. But the binary-blob variant is probably simplest, and I'd recommend going with that to get packaging done and the package in Debian. Alternately, check for the compiler, and use it if it's installed. (And fall back to the binary blob if it's not there.) Jon Leonard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Teaching assembly (Re: Bug#443370: ITP: asmutils -- coreutils replacement written in i386 assembler)
23-09-2007, Bernd Zeimetz: Some more context for compilers: http://article.gmane.org/gmane.comp.gcc.devel/92499 I can confirm that it is not faster since I tested it once, I think 'wc' it was. And it is definitely not portable to other platforms either :-) Nevertheless the package brings with it some spirit that is good to have: love to assembly as a language. Maybe there are applications of this package in the embedded world or for some UNIX on a floppy disk-kind of distributions. I do not care for the moment. The educational aspect of this package is what makes me want it for our distribution. For the educational aspect it would now nice to have this package at least in mips assembly, too, which is at least at my university used to teach assembly. It would also allow to compare the same implementation for different architectures. What problems are with `gcc -S --verbose-asm` `objdump -S`? Even more interesting would be (i guess), to see actual output of various optimizations stages in gcc. And this is more interesting work for students. Analyzing, what is done -- is part of any scientific publication and academic work. Education (for me) is developed skill of analyzing with comprehensive knowledge of history of the subject. That's how one can deal with data coming right now. So, why waste time with obsolete plain asm programming??? The term asm programming means teaching asm in *vacuum*. And this is wrong. Problem is (from what i've seen), that GCC developers don't like to waste much time looking in asm. Asm is a text output of GCC for them[0]. Kernel developers like only C, and not many of them like to spend time looking in actual asm, because they think, that -O2 good, -Os is better for Embedded hype[1][2]. [0] http://article.gmane.org/gmane.comp.gcc.devel/91370 [1] http://mid.gmane.org/[EMAIL PROTECTED] [2] http://mid.gmane.org/[EMAIL PROTECTED] (care to look a little more in threads) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: autobuilder pseudo-package
Holger Levsen [EMAIL PROTECTED] writes: Hi, On Tuesday 25 September 2007 12:25, Simon Richter wrote: inspired by the how to detect if inside a buildd chroot thread: would it make sense to have an (empty) package autobuilder that all packages that are not supposed to be installed on autobuilders (daemons, packages requiring interactive configuration, ...) can conflict against? Interactive configuration must be done via debconf by now. And not wanting to start daemon can have other reasons than autobuilders, eg. eg. chroots, fai's nfsroot, piuparts... so autobuilder is not a good name. regards, Holger I also would not make it empty but have it come with a policy-rc.d script that returns 101. That way it nicely disables all daemons for you. Also you could have some debconf configuration to set the hostname and prompts to reflect it is a chroot. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mecab-ipadic 2.7.0+20070801-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 15 Sep 2007 18:32:35 +0900 Source: mecab-ipadic Binary: mecab-ipadic Architecture: source all Version: 2.7.0+20070801-1 Distribution: unstable Urgency: low Maintainer: TSUCHIYA Masatoshi [EMAIL PROTECTED] Changed-By: TSUCHIYA Masatoshi [EMAIL PROTECTED] Description: mecab-ipadic - IPA dictionary compiled for Mecab Changes: mecab-ipadic (2.7.0+20070801-1) unstable; urgency=low . * New upstream. Files: b57130b2731fd1084b3981559f2242e2 617 non-free/misc optional mecab-ipadic_2.7.0+20070801-1.dsc 379500dc9277f1f5fa776a718e8c530b 11028849 non-free/misc optional mecab-ipadic_2.7.0+20070801.orig.tar.gz 09293042a96dfa98d32798bd4cedbee3 3647 non-free/misc optional mecab-ipadic_2.7.0+20070801-1.diff.gz 48025f074cec82049f4454300c689f5e 12117780 non-free/misc optional mecab-ipadic_2.7.0+20070801-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+fTyK6gmAsLOgJkRAksuAJ9gDfe4F42vR0/lYxUh140RIU7k2wCfbP7/ PEaoZzLLnOHnGOP2Qwd9Da8= =pinB -END PGP SIGNATURE- Accepted: mecab-ipadic_2.7.0+20070801-1.diff.gz to pool/non-free/m/mecab-ipadic/mecab-ipadic_2.7.0+20070801-1.diff.gz mecab-ipadic_2.7.0+20070801-1.dsc to pool/non-free/m/mecab-ipadic/mecab-ipadic_2.7.0+20070801-1.dsc mecab-ipadic_2.7.0+20070801-1_all.deb to pool/non-free/m/mecab-ipadic/mecab-ipadic_2.7.0+20070801-1_all.deb mecab-ipadic_2.7.0+20070801.orig.tar.gz to pool/non-free/m/mecab-ipadic/mecab-ipadic_2.7.0+20070801.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mecab 0.96-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 15 Sep 2007 18:32:35 +0900 Source: mecab Binary: mecab-utils libmecab-dev libmecab1 mecab Architecture: source i386 Version: 0.96-1 Distribution: unstable Urgency: low Maintainer: TSUCHIYA Masatoshi [EMAIL PROTECTED] Changed-By: TSUCHIYA Masatoshi [EMAIL PROTECTED] Description: libmecab-dev - Header files of Mecab libmecab1 - Libraries of Mecab mecab - Japanese morphological analysis system mecab-utils - Support programs of Mecab Changes: mecab (0.96-1) unstable; urgency=low . * New upstream. Files: 10e92e90d0ad94f0dde519391d1daadf 633 misc optional mecab_0.96-1.dsc 6a629ecba9e1249a98de434e38d03913 952078 misc optional mecab_0.96.orig.tar.gz 24ba1ad5f339e2d050cb5b08b711d460 4252 misc optional mecab_0.96-1.diff.gz 736f5cd750f704c110ca30229cfa51eb 111492 misc optional mecab_0.96-1_i386.deb d92318aaaf8b9cc6a936c3f010139732 4828 misc optional mecab-utils_0.96-1_i386.deb fc8eedf32ceaf7f4a6883a86c328d9a7 315938 libs optional libmecab1_0.96-1_i386.deb c5a765a5814da05586daba8970933809 438544 libdevel optional libmecab-dev_0.96-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+fP/K6gmAsLOgJkRAkZAAJ9DOMJhAJhZS77DDUy9OoY382tDGACeIsF9 hCOmfS54qMZFnLHIQldQ57w= =eXEy -END PGP SIGNATURE- Accepted: libmecab-dev_0.96-1_i386.deb to pool/main/m/mecab/libmecab-dev_0.96-1_i386.deb libmecab1_0.96-1_i386.deb to pool/main/m/mecab/libmecab1_0.96-1_i386.deb mecab-utils_0.96-1_i386.deb to pool/main/m/mecab/mecab-utils_0.96-1_i386.deb mecab_0.96-1.diff.gz to pool/main/m/mecab/mecab_0.96-1.diff.gz mecab_0.96-1.dsc to pool/main/m/mecab/mecab_0.96-1.dsc mecab_0.96-1_i386.deb to pool/main/m/mecab/mecab_0.96-1_i386.deb mecab_0.96.orig.tar.gz to pool/main/m/mecab/mecab_0.96.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sigscheme 0.8.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 15:03:08 +0900 Source: sigscheme Binary: libgcroots0 libsscm-dev sigscheme libgcroots-dev libsscm3 Architecture: source i386 Version: 0.8.0-3 Distribution: unstable Urgency: low Maintainer: NIIBE Yutaka [EMAIL PROTECTED] Changed-By: NIIBE Yutaka [EMAIL PROTECTED] Description: libgcroots-dev - Development GC library for a Scheme interpreter named 'sigscheme' libgcroots0 - GC shared library for a Scheme interpreter named 'sigscheme' libsscm-dev - Development library for a Scheme interpreter named 'sigscheme' libsscm3 - A shared library for a Scheme interpreter named 'sigscheme' sigscheme - A Scheme Interpreter Changes: sigscheme (0.8.0-3) unstable; urgency=low . * libgcroots/mach_dep.c: Fix FTBFS of ia64. Files: cbf3557d59be4e3c93ea4099bcf1ddec 617 interpreters optional sigscheme_0.8.0-3.dsc be08d54d88336ded1f459de82232ed3d 7557 interpreters optional sigscheme_0.8.0-3.diff.gz 2ffa66e792718a970e28e691dd45be11 52814 interpreters optional sigscheme_0.8.0-3_i386.deb 88c87297cc79b04ef417294a306b1eaf 67570 libs optional libsscm3_0.8.0-3_i386.deb 8b1a4a86d129b80518ac8dded724d81d 117710 libdevel optional libsscm-dev_0.8.0-3_i386.deb 18a75fa73c40dd4b9aeb43b81b385099 8196 libs optional libgcroots0_0.8.0-3_i386.deb 9424b9f5522fd0f1d9a4b04ab249eae4 8648 libdevel optional libgcroots-dev_0.8.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+feUBB45r3HV9DoRAq4uAKCpIt4nH6A6aU7vzPtpqV5xAz7JgQCg2yCX ywq3Z4o+vPpFoh1j/srsJTI= =CLt0 -END PGP SIGNATURE- Accepted: libgcroots-dev_0.8.0-3_i386.deb to pool/main/s/sigscheme/libgcroots-dev_0.8.0-3_i386.deb libgcroots0_0.8.0-3_i386.deb to pool/main/s/sigscheme/libgcroots0_0.8.0-3_i386.deb libsscm-dev_0.8.0-3_i386.deb to pool/main/s/sigscheme/libsscm-dev_0.8.0-3_i386.deb libsscm3_0.8.0-3_i386.deb to pool/main/s/sigscheme/libsscm3_0.8.0-3_i386.deb sigscheme_0.8.0-3.diff.gz to pool/main/s/sigscheme/sigscheme_0.8.0-3.diff.gz sigscheme_0.8.0-3.dsc to pool/main/s/sigscheme/sigscheme_0.8.0-3.dsc sigscheme_0.8.0-3_i386.deb to pool/main/s/sigscheme/sigscheme_0.8.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted sigscheme 0.8.0-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 16:01:19 +0900 Source: sigscheme Binary: libgcroots0 libsscm-dev sigscheme libgcroots-dev libsscm3 Architecture: source i386 Version: 0.8.0-4 Distribution: unstable Urgency: low Maintainer: NIIBE Yutaka [EMAIL PROTECTED] Changed-By: NIIBE Yutaka [EMAIL PROTECTED] Description: libgcroots-dev - Development GC library for a Scheme interpreter named 'sigscheme' libgcroots0 - GC shared library for a Scheme interpreter named 'sigscheme' libsscm-dev - Development library for a Scheme interpreter named 'sigscheme' libsscm3 - A shared library for a Scheme interpreter named 'sigscheme' sigscheme - A Scheme Interpreter Changes: sigscheme (0.8.0-4) unstable; urgency=low . * libgcroots/mach_dep.c: Fix FTBFS of sparc. Files: e3692bbf4156a555968f636ea26c1cf8 617 interpreters optional sigscheme_0.8.0-4.dsc 673c04ea97672674179b0938fcb2436f 7568 interpreters optional sigscheme_0.8.0-4.diff.gz e9e203917a443c761d536d4c0f5a25b0 52840 interpreters optional sigscheme_0.8.0-4_i386.deb c7b2015bc6db6148b7ecb693fdc6254f 67598 libs optional libsscm3_0.8.0-4_i386.deb 1c466dc23ea88d7635649ba1e09685d1 117756 libdevel optional libsscm-dev_0.8.0-4_i386.deb 4f758cbf031e6be45852bbc9745e61ef 8228 libs optional libgcroots0_0.8.0-4_i386.deb 01afded1fdb1d3cdfbc47093f52030a6 8692 libdevel optional libgcroots-dev_0.8.0-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+gYUBB45r3HV9DoRAq0pAKDFCH1rDb2uAZhBic8z5WoZVCv2NACfd9lN JwrioBRQAlnKqVorwQj52Tk= =xOuo -END PGP SIGNATURE- Accepted: libgcroots-dev_0.8.0-4_i386.deb to pool/main/s/sigscheme/libgcroots-dev_0.8.0-4_i386.deb libgcroots0_0.8.0-4_i386.deb to pool/main/s/sigscheme/libgcroots0_0.8.0-4_i386.deb libsscm-dev_0.8.0-4_i386.deb to pool/main/s/sigscheme/libsscm-dev_0.8.0-4_i386.deb libsscm3_0.8.0-4_i386.deb to pool/main/s/sigscheme/libsscm3_0.8.0-4_i386.deb sigscheme_0.8.0-4.diff.gz to pool/main/s/sigscheme/sigscheme_0.8.0-4.diff.gz sigscheme_0.8.0-4.dsc to pool/main/s/sigscheme/sigscheme_0.8.0-4.dsc sigscheme_0.8.0-4_i386.deb to pool/main/s/sigscheme/sigscheme_0.8.0-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kid3 0.9-4 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 09:22:56 +0200 Source: kid3 Binary: kid3 kid3-qt Architecture: source amd64 Version: 0.9-4 Distribution: unstable Urgency: low Maintainer: Debian KDE Extras Team [EMAIL PROTECTED] Changed-By: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Description: kid3 - KDE MP3 ID3 tag editor kid3-qt- Audio tag editor Closes: 442615 Changes: kid3 (0.9-4) unstable; urgency=low . * Fix clean rule to allow package be built twice in a row. (Closes: #442615) Files: e4396bdd5deb691e4e500953159b4a17 883 kde optional kid3_0.9-4.dsc 377a37aa235ae26a33260c2384aafae5 8329 kde optional kid3_0.9-4.diff.gz c4c2ac9d3f3dfc1147c0cb100425545f 355338 kde optional kid3_0.9-4_amd64.deb f9db5b4eaad3fbbaf89146eaaa661712 415002 kde optional kid3-qt_0.9-4_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Signed by Ana Guerrero iD8DBQFG+gsdn3j4POjENGERAhVEAJ4kMnr7Z6W9a/lyNZp0O555x+ysIACePe4x QqQnpGpWiGx25jzRdUZNXo8= =QR1L -END PGP SIGNATURE- Accepted: kid3-qt_0.9-4_amd64.deb to pool/main/k/kid3/kid3-qt_0.9-4_amd64.deb kid3_0.9-4.diff.gz to pool/main/k/kid3/kid3_0.9-4.diff.gz kid3_0.9-4.dsc to pool/main/k/kid3/kid3_0.9-4.dsc kid3_0.9-4_amd64.deb to pool/main/k/kid3/kid3_0.9-4_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libvorbis-perl 0.05-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 10:26:30 +0300 Source: libvorbis-perl Binary: libogg-vorbis-perl Architecture: source i386 Version: 0.05-5 Distribution: unstable Urgency: high Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Damyan Ivanov [EMAIL PROTECTED] Description: libogg-vorbis-perl - Perl extension for Ogg Vorbis streams Changes: libvorbis-perl (0.05-5) unstable; urgency=high . * Urgency is high, due to the folloing changes * Fix a typo in Provides * Add Replaces: libvorbis-perl to avoid conflicts with the old package name . * Added myself to Uploaders * Corrected upstream URL in debian/copyright Files: d1921ddc6784ae19af6f90b20d48c843 973 perl optional libvorbis-perl_0.05-5.dsc 46c556698219ae92202bb5135fc9ec66 3391 perl optional libvorbis-perl_0.05-5.diff.gz 848cb37331ea2a859747ca824dc3eb39 23234 perl optional libogg-vorbis-perl_0.05-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+goMHqjlqpcl9jsRAvoOAJ93u3uliIvXO7WgNEOOQiZRa54z8wCfV98r Ltf+beu+5ejiCiMoh61NSKE= =/2Io -END PGP SIGNATURE- Accepted: libogg-vorbis-perl_0.05-5_i386.deb to pool/main/libv/libvorbis-perl/libogg-vorbis-perl_0.05-5_i386.deb libvorbis-perl_0.05-5.diff.gz to pool/main/libv/libvorbis-perl/libvorbis-perl_0.05-5.diff.gz libvorbis-perl_0.05-5.dsc to pool/main/libv/libvorbis-perl/libvorbis-perl_0.05-5.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted octplot 0.4.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 21 Sep 2007 17:07:49 +0200 Source: octplot Binary: octplot Architecture: source i386 Version: 0.4.0-3 Distribution: unstable Urgency: low Maintainer: Debian Octave Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: octplot- graphical interface for Octave Closes: 435206 Changes: octplot (0.4.0-3) unstable; urgency=low . [ Thomas Weber ] * Be more specific about OctPlot's license (closes: #435206). . [ Rafael Laboissiere ] * debian/control: Added Homepage field Files: 08a36972e8ecf4ac6e7f756469aa6c60 1016 math optional octplot_0.4.0-3.dsc 63a05ef7e202368a20d21f9886989136 71010 math optional octplot_0.4.0-3.diff.gz a9363121b630c98faf7d27be7ec9680b 1031082 math optional octplot_0.4.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+hBAk3oga0pdcv4RAsyeAJ9Z7DMndRltxZXN8b0yl/mYpAMobgCfQl3r uwTRKZT0SoQWaF9rIqXnN0g= =xMc0 -END PGP SIGNATURE- Accepted: octplot_0.4.0-3.diff.gz to pool/main/o/octplot/octplot_0.4.0-3.diff.gz octplot_0.4.0-3.dsc to pool/main/o/octplot/octplot_0.4.0-3.dsc octplot_0.4.0-3_i386.deb to pool/main/o/octplot/octplot_0.4.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted joystick 20051019-1.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 17:23:40 +1000 Source: joystick Binary: joystick Architecture: source i386 Version: 20051019-1.1 Distribution: unstable Urgency: low Maintainer: Edward Betts [EMAIL PROTECTED] Changed-By: Anibal Monsalve Salazar [EMAIL PROTECTED] Description: joystick - Testing and calibration tools Closes: 336882 Changes: joystick (20051019-1.1) unstable; urgency=low . * Non-maintainer upload * Fixed wrong setting of mouse type. Closes: #336882 * debian/control: added Homepage record * Fixed the following lintian messages: - W: joystick source: out-of-date-standards-version 3.6.2 (current is 3.7.2) - E: joystick source: build-depends-on-build-essential build-depends Files: 4a53b2e8e79434c1dc9d3d4a49bfdf90 645 utils optional joystick_20051019-1.1.dsc 4b65182301ed02cb278c057672398e0b 4351 utils optional joystick_20051019-1.1.diff.gz 6361a7351c877057fff01f11862d6386 18290 utils optional joystick_20051019-1.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFG+hE5gY5NIXPNpFURAshRAJd5Qhq5hDNVCxGGZKKkaALnCub/AJ400Yxb PXzmCHcbYyZUI/5AsGNFvQ== =gf+Q -END PGP SIGNATURE- Accepted: joystick_20051019-1.1.diff.gz to pool/main/j/joystick/joystick_20051019-1.1.diff.gz joystick_20051019-1.1.dsc to pool/main/j/joystick/joystick_20051019-1.1.dsc joystick_20051019-1.1_i386.deb to pool/main/j/joystick/joystick_20051019-1.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xawtv 3.95.dfsg.1-6 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 00:12:47 +0200 Source: xawtv Binary: xawtv-plugins fbtv radio ttv webcam xawtv-plugin-qt pia xawtv xawtv-tools scantv streamer alevtd v4l-conf Architecture: source i386 Version: 3.95.dfsg.1-6 Distribution: unstable Urgency: low Maintainer: Krzysztof Burghardt [EMAIL PROTECTED] Changed-By: Krzysztof Burghardt [EMAIL PROTECTED] Description: alevtd - http daemon for videotext pages fbtv - linux console (fbcon) TV application pia- movie player radio - ncurses-based radio application scantv - scan TV channels for stations streamer - capture tool (images / movies) ttv- tty TV application v4l-conf - tool to configure video4linux drivers webcam - capture and upload images xawtv - X11 TV application xawtv-plugin-qt - quicktime plugin for xawtv and motv xawtv-plugins - plugins for xawtv and motv xawtv-tools - Miscellaneous tools distributed with xawtv Closes: 438135 439694 440706 Changes: xawtv (3.95.dfsg.1-6) unstable; urgency=low . * Applied Martin Denn's patch for 11_plugins_memory_leaks.dpatch fixes free()ing invalid pointer (Closes: #438135, #440706) * Moved xawtv binary to xawtv.bin and add wrapper to detect and work around graphic cards / drivers without DGA support (idea by Jorge S. de Lis) * Updated Portuguese translation for debconf messages (Closes: #439694) * File xawtv.desktop modified to adhere to freedesktop standards (incorporated changes from Ubuntu patch by Luca Falavigna) Files: 5d180b244bf5500e1becb26b2ddd5d12 1147 graphics extra xawtv_3.95.dfsg.1-6.dsc 2c5c79cd28c87e0d4cbb8eeec3c06c1f 33621 graphics extra xawtv_3.95.dfsg.1-6.diff.gz c1d31b5b5527f4e7e3ea86f1e904924a 245592 x11 extra xawtv_3.95.dfsg.1-6_i386.deb 96e96128af545301c46aa57b61e09fec 37458 x11 extra pia_3.95.dfsg.1-6_i386.deb fac4cd28aacc3fcf938e65461ff1a173 66856 graphics extra fbtv_3.95.dfsg.1-6_i386.deb da1c75b4c17d102e094297681a09d6c2 50140 graphics extra ttv_3.95.dfsg.1-6_i386.deb 8a08e62ddb3aea38d4811c89d08b45ab 54808 graphics extra scantv_3.95.dfsg.1-6_i386.deb 0f1ae79e1e846e1f3f6397f50b048b2e 52334 graphics extra streamer_3.95.dfsg.1-6_i386.deb 835a50cb9fa818fbe9cbad45380d6613 17976 sound extra radio_3.95.dfsg.1-6_i386.deb a7722886fc2b70310d1fa9192793af6a 26316 graphics extra v4l-conf_3.95.dfsg.1-6_i386.deb 92182fc122af425e22d4bae4a95fcea7 31530 graphics extra xawtv-tools_3.95.dfsg.1-6_i386.deb 56d24faa01cb31ba5609fc98cd76f519 16360 graphics extra xawtv-plugin-qt_3.95.dfsg.1-6_i386.deb cad6f8d102df3229e5e2aaa9dfdfc524 84764 graphics extra xawtv-plugins_3.95.dfsg.1-6_i386.deb c7e862584132595d19aafe82479dd1f8 36234 net extra webcam_3.95.dfsg.1-6_i386.deb e9cb3fecfe003380c5d357c748fbfd38 32374 net extra alevtd_3.95.dfsg.1-6_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+hfrs3U+TVFLPnwRApIOAKCDq561jrmpGzTowKvAQQxDtczEoQCffCUN XQFScv6BqYjgB0o6xmCu4gw= =TP5F -END PGP SIGNATURE- Accepted: alevtd_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/alevtd_3.95.dfsg.1-6_i386.deb fbtv_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/fbtv_3.95.dfsg.1-6_i386.deb pia_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/pia_3.95.dfsg.1-6_i386.deb radio_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/radio_3.95.dfsg.1-6_i386.deb scantv_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/scantv_3.95.dfsg.1-6_i386.deb streamer_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/streamer_3.95.dfsg.1-6_i386.deb ttv_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/ttv_3.95.dfsg.1-6_i386.deb v4l-conf_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/v4l-conf_3.95.dfsg.1-6_i386.deb webcam_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/webcam_3.95.dfsg.1-6_i386.deb xawtv-plugin-qt_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/xawtv-plugin-qt_3.95.dfsg.1-6_i386.deb xawtv-plugins_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/xawtv-plugins_3.95.dfsg.1-6_i386.deb xawtv-tools_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/xawtv-tools_3.95.dfsg.1-6_i386.deb xawtv_3.95.dfsg.1-6.diff.gz to pool/main/x/xawtv/xawtv_3.95.dfsg.1-6.diff.gz xawtv_3.95.dfsg.1-6.dsc to pool/main/x/xawtv/xawtv_3.95.dfsg.1-6.dsc xawtv_3.95.dfsg.1-6_i386.deb to pool/main/x/xawtv/xawtv_3.95.dfsg.1-6_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted nc6 1.0-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 07:44:07 + Source: nc6 Binary: netcat6 Architecture: source amd64 Version: 1.0-3 Distribution: unstable Urgency: low Maintainer: Peter Makholm [EMAIL PROTECTED] Changed-By: Peter Makholm [EMAIL PROTECTED] Description: netcat6- TCP/IP swiss army knife with IPv6 support Changes: nc6 (1.0-3) unstable; urgency=low . * Remember to add the build-dependency on cdbs. Ooops... Files: 29a07d574d1e2016e53316af8b7f1482 573 net optional nc6_1.0-3.dsc 58de1174a102f203df60468766d70f0c 24927 net optional nc6_1.0-3.diff.gz aaefc6ebbb60bea9a74e7c4f4ef12b5d 41438 net optional netcat6_1.0-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+g6oobE/LCyLGVoRApdrAJ9JMq7EX+dCvpvAN2+SvATOtN/T/QCeIeGX U/ZS/ZBO08BpELMPJA1V6UQ= =NVX9 -END PGP SIGNATURE- Accepted: nc6_1.0-3.diff.gz to pool/main/n/nc6/nc6_1.0-3.diff.gz nc6_1.0-3.dsc to pool/main/n/nc6/nc6_1.0-3.dsc netcat6_1.0-3_amd64.deb to pool/main/n/nc6/netcat6_1.0-3_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tinyerp-server 4.2.0~rc3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 11:10:00 +0200 Source: tinyerp-server Binary: tinyerp-server Architecture: source all Version: 4.2.0~rc3-1 Distribution: experimental Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: tinyerp-server - Enterprise Resource Management software (server) Changes: tinyerp-server (4.2.0~rc3-1) experimental; urgency=low . * New upstream release. Files: 60cf3edc7ea12160fd568496e0cc8065 704 net optional tinyerp-server_4.2.0~rc3-1.dsc 2713b2a94917604b986494adbdda011c 1812403 net optional tinyerp-server_4.2.0~rc3.orig.tar.gz a41ecbbac53ffc4cfcf9924443db9abf 5920 net optional tinyerp-server_4.2.0~rc3-1.diff.gz 8df46bbfdc79df92cd3bc1202d08da00 1823996 net optional tinyerp-server_4.2.0~rc3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+iIw+C5cwEsrK54RArxVAJ9cU4F4n8noM6P1F0ne17SZWFJLwQCfUY77 F350G09Hy1tLCWqAl3ZBvWU= =zimQ -END PGP SIGNATURE- Accepted: tinyerp-server_4.2.0~rc3-1.diff.gz to pool/main/t/tinyerp-server/tinyerp-server_4.2.0~rc3-1.diff.gz tinyerp-server_4.2.0~rc3-1.dsc to pool/main/t/tinyerp-server/tinyerp-server_4.2.0~rc3-1.dsc tinyerp-server_4.2.0~rc3-1_all.deb to pool/main/t/tinyerp-server/tinyerp-server_4.2.0~rc3-1_all.deb tinyerp-server_4.2.0~rc3.orig.tar.gz to pool/main/t/tinyerp-server/tinyerp-server_4.2.0~rc3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cakephp1.2 1.2.0.5427alpha-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Sep 2007 17:52:25 +0100 Source: cakephp1.2 Binary: cakephp1.2-scripts cakephp1.2 Architecture: source all Version: 1.2.0.5427alpha-2 Distribution: unstable Urgency: low Maintainer: Chris Lamb [EMAIL PROTECTED] Changed-By: Chris Lamb [EMAIL PROTECTED] Description: cakephp1.2 - MVC rapid application development framework for PHP (1.2 version) cakephp1.2-scripts - MVC rapid application development framework for PHP (scripts) Changes: cakephp1.2 (1.2.0.5427alpha-2) unstable; urgency=low . * Add cakephp-instaweb to Suggests:. Files: a57e2ce8ba92df521433fe2babe4acfd 752 web optional cakephp1.2_1.2.0.5427alpha-2.dsc 9f3a2561416b8fcdbc6bddef9a4c9ea5 5577 web optional cakephp1.2_1.2.0.5427alpha-2.diff.gz ba248d18062382f0bfbda98205270a84 317592 web optional cakephp1.2_1.2.0.5427alpha-2_all.deb e84acd5d10c1f99121421bffc74408bf 81988 web optional cakephp1.2-scripts_1.2.0.5427alpha-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+iAc+C5cwEsrK54RAlJkAKCkINrndizhTWX1t+F7CRMOtDQWhQCgpSs8 SeFn/lamQ4POZAudA+B1toc= =qRNI -END PGP SIGNATURE- Accepted: cakephp1.2-scripts_1.2.0.5427alpha-2_all.deb to pool/main/c/cakephp1.2/cakephp1.2-scripts_1.2.0.5427alpha-2_all.deb cakephp1.2_1.2.0.5427alpha-2.diff.gz to pool/main/c/cakephp1.2/cakephp1.2_1.2.0.5427alpha-2.diff.gz cakephp1.2_1.2.0.5427alpha-2.dsc to pool/main/c/cakephp1.2/cakephp1.2_1.2.0.5427alpha-2.dsc cakephp1.2_1.2.0.5427alpha-2_all.deb to pool/main/c/cakephp1.2/cakephp1.2_1.2.0.5427alpha-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cakephp 1.1.17.5612-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Sep 2007 17:53:34 +0100 Source: cakephp Binary: cakephp-scripts cakephp Architecture: source all Version: 1.1.17.5612-2 Distribution: unstable Urgency: low Maintainer: Chris Lamb [EMAIL PROTECTED] Changed-By: Chris Lamb [EMAIL PROTECTED] Description: cakephp- MVC rapid application development framework for PHP cakephp-scripts - MVC rapid application development framework for PHP (scripts) Changes: cakephp (1.1.17.5612-2) unstable; urgency=low . * Add cakephp-instaweb to Suggests:. Files: 40d3e77a10a59c8d15b8c5f7948e35b9 719 web optional cakephp_1.1.17.5612-2.dsc cae9d8197366fd9341074194fd8ca336 5298 web optional cakephp_1.1.17.5612-2.diff.gz 21cb96fc7b0d0ad21f8060aaa671a195 162166 web optional cakephp_1.1.17.5612-2_all.deb 6e5742a43b3aa6400bd8070dcabf2071 59094 web optional cakephp-scripts_1.1.17.5612-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+iBU+C5cwEsrK54RAqmCAKCbP/vGlwDsqfslUGAWOpG6QFakkgCg16+V 0AO9xsyarmUw+Qjz2YbLJco= =sTP1 -END PGP SIGNATURE- Accepted: cakephp-scripts_1.1.17.5612-2_all.deb to pool/main/c/cakephp/cakephp-scripts_1.1.17.5612-2_all.deb cakephp_1.1.17.5612-2.diff.gz to pool/main/c/cakephp/cakephp_1.1.17.5612-2.diff.gz cakephp_1.1.17.5612-2.dsc to pool/main/c/cakephp/cakephp_1.1.17.5612-2.dsc cakephp_1.1.17.5612-2_all.deb to pool/main/c/cakephp/cakephp_1.1.17.5612-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cakephp-instaweb 0.2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Sep 2007 17:54:47 +0100 Source: cakephp-instaweb Binary: cakephp-instaweb Architecture: source all Version: 0.2 Distribution: unstable Urgency: low Maintainer: Chris Lamb [EMAIL PROTECTED] Changed-By: Chris Lamb [EMAIL PROTECTED] Description: cakephp-instaweb - Development webserver for CakePHP applications Changes: cakephp-instaweb (0.2) unstable; urgency=low . * Add cakephp1.2 to Recommends:. Files: ed5723bd10eae726262a94a435ef5b5f 637 web optional cakephp-instaweb_0.2.dsc e3a56b1922854df19b05599c31e56be5 3774 web optional cakephp-instaweb_0.2.tar.gz 34f16ef4416eef8deda182a663122848 4616 web optional cakephp-instaweb_0.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+h/g+C5cwEsrK54RAliNAJ91n4+IqbDgAMzAhPxSNZrmwvjoswCfX91k swnjJng33D+KxjOUnKrU9yc= =jZRP -END PGP SIGNATURE- Accepted: cakephp-instaweb_0.2.dsc to pool/main/c/cakephp-instaweb/cakephp-instaweb_0.2.dsc cakephp-instaweb_0.2.tar.gz to pool/main/c/cakephp-instaweb/cakephp-instaweb_0.2.tar.gz cakephp-instaweb_0.2_all.deb to pool/main/c/cakephp-instaweb/cakephp-instaweb_0.2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tinyerp-client 4.2.0~rc3-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 11:12:00 +0200 Source: tinyerp-client Binary: tinyerp-client Architecture: source all Version: 4.2.0~rc3-1 Distribution: experimental Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: tinyerp-client - Enterprise Resource Management software (client) Changes: tinyerp-client (4.2.0~rc3-1) experimental; urgency=low . * New upstream release. Files: 4a81340be2bc328ae069f611ecbaa033 683 x11 optional tinyerp-client_4.2.0~rc3-1.dsc a198a7e48b17f23bc4d46ec3074a2234 1274864 x11 optional tinyerp-client_4.2.0~rc3.orig.tar.gz c10e61374d429d9fce0a223afb4b2c19 6735 x11 optional tinyerp-client_4.2.0~rc3-1.diff.gz 3c2b9553c0ebaf034ce198d073e3c2a5 1120890 x11 optional tinyerp-client_4.2.0~rc3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+iLL+C5cwEsrK54RAtoFAJ0edCZCCbYVtDHjO0aeEg5EA1zfWACeLJDK /xCpdXYrrJ5iuhMC0OwJE0w= =kesd -END PGP SIGNATURE- Accepted: tinyerp-client_4.2.0~rc3-1.diff.gz to pool/main/t/tinyerp-client/tinyerp-client_4.2.0~rc3-1.diff.gz tinyerp-client_4.2.0~rc3-1.dsc to pool/main/t/tinyerp-client/tinyerp-client_4.2.0~rc3-1.dsc tinyerp-client_4.2.0~rc3-1_all.deb to pool/main/t/tinyerp-client/tinyerp-client_4.2.0~rc3-1_all.deb tinyerp-client_4.2.0~rc3.orig.tar.gz to pool/main/t/tinyerp-client/tinyerp-client_4.2.0~rc3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted syslinux 1:3.60~pre2-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Aug 2007 11:16:00 +0200 Source: syslinux Binary: syslinux Architecture: source i386 Version: 1:3.60~pre2-1 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: syslinux - Bootloader for Linux/i386 using MS-DOS floppies Changes: syslinux (1:3.60~pre2-1) unstable; urgency=low . * New upstream release. Files: 7b8f1cd67b31c0f5cedcaf0f5e84c156 733 utils optional syslinux_3.60~pre2-1.dsc 21c9cf6614b244e4bb9e6bba663336eb 1996957 utils optional syslinux_3.60~pre2.orig.tar.gz b7fb9bf6bd3f0a1e13a91b4e3249ece4 17180 utils optional syslinux_3.60~pre2-1.diff.gz 4fcd3d534071cda67fd968e31ec13988 356342 utils optional syslinux_3.60~pre2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+iOw+C5cwEsrK54RAp94AJ446hnNox/3dpdaCWWH1MOYCqXbHACggIXc 9jZToEaEzxkLvI4VlG2WefY= =muEH -END PGP SIGNATURE- Accepted: syslinux_3.60~pre2-1.diff.gz to pool/main/s/syslinux/syslinux_3.60~pre2-1.diff.gz syslinux_3.60~pre2-1.dsc to pool/main/s/syslinux/syslinux_3.60~pre2-1.dsc syslinux_3.60~pre2-1_i386.deb to pool/main/s/syslinux/syslinux_3.60~pre2-1_i386.deb syslinux_3.60~pre2.orig.tar.gz to pool/main/s/syslinux/syslinux_3.60~pre2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lwat 0.16-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 12:52:16 +0200 Source: lwat Binary: lwat Architecture: source all Version: 0.16-1 Distribution: unstable Urgency: low Maintainer: Patrick Winnertz [EMAIL PROTECTED] Changed-By: Patrick Winnertz [EMAIL PROTECTED] Description: lwat - LDAP Web-based Administration Tool Closes: 426690 430666 435997 440441 Changes: lwat (0.16-1) unstable; urgency=low . [ Finn-Arne Johansen ] * Updated spanish and norwegian translations * new upstream release * test if createhomedir script exists before it's called from cron.d (Closes: #435997) * Updated german translations (Closes: #440441) . [ Patrick Winnertz ] * Removes /etc/lwat on purge. (Closes: #426690) * set useLisgroups in config.php correctly (Closes: #430666) Files: 2d3d7796513943305900d942530adb97 630 misc optional lwat_0.16-1.dsc 85e19a7e1305b8d509723ebb6ef24bd8 67237 misc optional lwat_0.16.orig.tar.gz 97aa215b5106d6f49f652260ee1d32f9 16833 misc optional lwat_0.16-1.diff.gz f40331404bbfeea6302430e3f8c3a2b3 74134 misc optional lwat_0.16-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+ioq62zWxYk/rQcRAq9HAJ9i+O2AOF8SLnO8VXeSwgg7N5ZOlwCgz997 ZbTjpTZgBzZF6JbUjX1oUYM= =ZsZq -END PGP SIGNATURE- Accepted: lwat_0.16-1.diff.gz to pool/main/l/lwat/lwat_0.16-1.diff.gz lwat_0.16-1.dsc to pool/main/l/lwat/lwat_0.16-1.dsc lwat_0.16-1_all.deb to pool/main/l/lwat/lwat_0.16-1_all.deb lwat_0.16.orig.tar.gz to pool/main/l/lwat/lwat_0.16.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dh-make-php 0.2.8 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 11:42:25 +0200 Source: dh-make-php Binary: dh-make-php Architecture: source all Version: 0.2.8 Distribution: unstable Urgency: low Maintainer: Uwe Steinmann [EMAIL PROTECTED] Changed-By: Uwe Steinmann [EMAIL PROTECTED] Description: dh-make-php - Creates Debian source packages for PHP PEAR and PECL extensions Closes: 443523 Changes: dh-make-php (0.2.8) unstable; urgency=low . * Do not install pear packages by postinst, prerm scripts anymore, but keep the .reg file instead and install it into /usr/share/php/.registry/. (Closes: #443523) Files: e9e29c4468f54ce6453effc8a38258cd 594 web optional dh-make-php_0.2.8.dsc 0d6b28bbe273adbe7c5924b8d84cbd72 31479 web optional dh-make-php_0.2.8.tar.gz 84aff3660b4b7c2cc868be1cbb9859f3 30866 web optional dh-make-php_0.2.8_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+jDbih2Zvw18pwERAijzAJ9moJUmDyitC4tBY05oHa8Tv+5Q2ACeNLVB RUGPxLdwRfe+TbPTUNcA1kQ= =aHfk -END PGP SIGNATURE- Accepted: dh-make-php_0.2.8.dsc to pool/main/d/dh-make-php/dh-make-php_0.2.8.dsc dh-make-php_0.2.8.tar.gz to pool/main/d/dh-make-php/dh-make-php_0.2.8.tar.gz dh-make-php_0.2.8_all.deb to pool/main/d/dh-make-php/dh-make-php_0.2.8_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-modules-extra-2.6 2.6.22-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 8 Sep 2007 22:47:00 +0200 Source: linux-modules-extra-2.6 Binary: squashfs-modules-2.6.22-2-sb1a-bcm91480b gspca-modules-2.6.22-2-k7 squashfs-modules-2.6.22-2-versatile squashfs-modules-2.6-amd64 squashfs-modules-2.6-itanium squashfs-modules-2.6-vserver-powerpc squashfs-modules-2.6.22-2-atari aufs-modules-2.6.22-2-4kc-malta gspca-modules-2.6-powerpc-smp squashfs-modules-2.6-alpha-legacy squashfs-modules-2.6-vserver-sparc64 mol-modules-2.6-vserver-powerpc squashfs-modules-2.6-686 gspca-modules-2.6-k7 squashfs-modules-2.6-sb1-bcm91250a aufs-modules-2.6.22-2-powerpc64 squashfs-modules-2.6.22-2-sb1-bcm91250a squashfs-modules-2.6-mckinley squashfs-modules-2.6.22-2-powerpc-miboot gspca-modules-2.6-vserver-686 aufs-modules-2.6-686-bigmem aufs-modules-2.6-powerpc gspca-modules-2.6-powerpc-miboot aufs-modules-2.6-mckinley aufs-modules-2.6-alpha-generic aufs-modules-2.6.22-2-r5k-cobalt aufs-modules-2.6-powerpc64 squashfs-modules-2.6.22-2-vserver-itanium aufs-modules-2.6-parisc aufs-modules-2.6.22-2-alpha-generic gspca-modules-2.6.22-2-powerpc-smp aufs-modules-2.6.22-2-powerpc squashfs-modules-2.6-alpha-smp aufs-modules-2.6.22-2-r4k-ip22 gspca-modules-2.6.22-2-686-bigmem gspca-modules-2.6-vserver-powerpc gspca-modules-2.6.22-2-powerpc aufs-modules-2.6.22-2-ixp4xx aufs-modules-2.6-s390x squashfs-modules-2.6-vserver-686 squashfs-modules-2.6.22-2-686 aufs-modules-2.6-mac squashfs-modules-2.6.22-2-qemu squashfs-modules-2.6-amiga squashfs-modules-2.6.22-2-alpha-smp aufs-modules-2.6-4kc-malta squashfs-modules-2.6-powerpc-miboot squashfs-modules-2.6.22-2-amd64 aufs-modules-2.6.22-2-atari squashfs-modules-2.6-s390 mol-modules-2.6.22-2-powerpc squashfs-modules-2.6-powerpc squashfs-modules-2.6-alpha-generic squashfs-modules-2.6-486 squashfs-modules-2.6.22-2-r5k-cobalt aufs-modules-2.6-s390 squashfs-modules-2.6-powerpc-smp squashfs-modules-2.6-686-bigmem aufs-modules-2.6.22-2-alpha-legacy aufs-modules-2.6-ixp4xx squashfs-modules-2.6.22-2-s390x aufs-modules-2.6-qemu gspca-modules-2.6-powerpc aufs-modules-2.6.22-2-mac gspca-modules-2.6.22-2-vserver-686 aufs-modules-2.6.22-2-mckinley squashfs-modules-2.6.22-2-powerpc squashfs-modules-2.6.22-2-sparc64 squashfs-modules-2.6-mac squashfs-modules-2.6.22-2-amiga squashfs-modules-2.6.22-2-vserver-k7 aufs-modules-2.6-powerpc-miboot squashfs-modules-2.6.22-2-486 aufs-modules-2.6.22-2-sparc64-smp mol-modules-2.6.22-2-powerpc-miboot aufs-modules-2.6.22-2-s390 squashfs-modules-2.6-r5k-ip32 squashfs-modules-2.6.22-2-r4k-ip22 squashfs-modules-2.6.22-2-alpha-legacy squashfs-modules-2.6-r5k-cobalt squashfs-modules-2.6-k7 squashfs-modules-2.6.22-2-s390 aufs-modules-2.6-itanium squashfs-modules-2.6.22-2-vserver-alpha aufs-modules-2.6.22-2-iop32x aufs-modules-2.6.22-2-amd64 aufs-modules-2.6-parisc-smp aufs-modules-2.6-686 aufs-modules-2.6.22-2-sparc64 mol-modules-2.6-powerpc mol-modules-2.6-powerpc-smp squashfs-modules-2.6.22-2-powerpc64 squashfs-modules-2.6.22-2-r5k-ip32 gspca-modules-2.6-vserver-k7 aufs-modules-2.6-parisc64 gspca-modules-2.6.22-2-amd64 gspca-modules-2.6-vserver-amd64 aufs-modules-2.6.22-2-footbridge aufs-modules-2.6-parisc64-smp squashfs-modules-2.6-sparc64-smp gspca-modules-2.6.22-2-486 squashfs-modules-2.6.22-2-vserver-686 squashfs-modules-2.6-vserver-amd64 squashfs-modules-2.6-versatile squashfs-modules-2.6.22-2-k7 mol-modules-2.6.22-2-powerpc-smp squashfs-modules-2.6-sparc64 gspca-modules-2.6-686 aufs-modules-2.6.22-2-sb1-bcm91250a aufs-modules-2.6.22-2-parisc64-smp aufs-modules-2.6-486 gspca-modules-2.6.22-2-powerpc64 aufs-modules-2.6-versatile squashfs-modules-2.6-vserver-itanium gspca-modules-2.6-amd64 squashfs-modules-2.6-4kc-malta squashfs-modules-2.6-iop32x aufs-modules-2.6-sb1-bcm91250a aufs-modules-2.6.22-2-alpha-smp aufs-modules-2.6.22-2-s390x aufs-modules-2.6-sb1a-bcm91480b aufs-modules-2.6.22-2-r5k-ip32 mol-modules-2.6.22-2-vserver-powerpc aufs-modules-2.6-atari aufs-modules-2.6-alpha-legacy aufs-modules-2.6-r5k-cobalt aufs-modules-2.6-alpha-smp squashfs-modules-2.6.22-2-iop32x aufs-modules-2.6.22-2-k7 squashfs-modules-2.6-vserver-s390x squashfs-modules-2.6.22-2-vserver-mckinley squashfs-modules-2.6-s390x aufs-modules-2.6.22-2-versatile aufs-modules-2.6.22-2-686-bigmem aufs-modules-2.6.22-2-486 squashfs-modules-2.6.22-2-vserver-powerpc squashfs-modules-2.6-powerpc64 aufs-modules-2.6-powerpc-smp aufs-modules-2.6.22-2-parisc-smp squashfs-modules-2.6.22-2-4kc-malta aufs-modules-2.6-iop32x gspca-modules-2.6.22-2-vserver-k7 gspca-modules-2.6.22-2-vserver-powerpc64 mol-modules-2.6-powerpc-miboot gspca-modules-2.6-486 gspca-modules-2.6-686-bigmem aufs-modules-2.6-amiga gspca-modules-2.6.22-2-powerpc-miboot aufs-modules-2.6.22-2-powerpc-miboot aufs-modules-2.6.22-2-parisc squashfs-modules-2.6.22-2-686-bigmem aufs-modules-2.6-r4k-ip22 squashfs-modules-2.6.22-2-itanium aufs-modules-2.6.22-2-686 aufs-modules-2.6-r5k-ip32
Accepted gmrun 0.9.1-2.2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 25 Sep 2007 00:53:39 +0200 Source: gmrun Binary: gmrun Architecture: source i386 Version: 0.9.1-2.2 Distribution: unstable Urgency: low Maintainer: David B. Harris [EMAIL PROTECTED] Changed-By: Luca Bedogni [EMAIL PROTECTED] Description: gmrun - Featureful CLI-like GTK+ application launcher Closes: 417203 Changes: gmrun (0.9.1-2.2) unstable; urgency=low . * Non-maintainer upload. * Added patch (20-includes.dpatch) to fix missing includes for building with gcc 4.3 (Closes: #417203). Files: ca3284cd4a8d730da9946cc1cadfac79 586 x11 optional gmrun_0.9.1-2.2.dsc ef2642142d183c8037226ce5f7c83590 28352 x11 optional gmrun_0.9.1-2.2.diff.gz 323086107a0907ac77eaf6a335dc3abe 45060 x11 optional gmrun_0.9.1-2.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+jrcgY5NIXPNpFURAruxAKC6FsgTN8+1xLSy/AJDJQ2NQsYCoQCeIJw1 KgmmHTkPlNyLuEadiHdJJhI= =jfvP -END PGP SIGNATURE- Accepted: gmrun_0.9.1-2.2.diff.gz to pool/main/g/gmrun/gmrun_0.9.1-2.2.diff.gz gmrun_0.9.1-2.2.dsc to pool/main/g/gmrun/gmrun_0.9.1-2.2.dsc gmrun_0.9.1-2.2_i386.deb to pool/main/g/gmrun/gmrun_0.9.1-2.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zomg 0.2.8-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 07:51:15 -0400 Source: zomg Binary: zomg Architecture: source i386 Version: 0.2.8-1 Distribution: unstable Urgency: low Maintainer: Clint Adams [EMAIL PROTECTED] Changed-By: Clint Adams [EMAIL PROTECTED] Description: zomg - console-based last.fm submission and radio client Changes: zomg (0.2.8-1) unstable; urgency=low . * New upstream release. Files: 95410f1bb36c63c59ffbc02633744f62 569 sound optional zomg_0.2.8-1.dsc 878c606f7790d1107c5188ddbe60e413 74552 sound optional zomg_0.2.8.orig.tar.gz d06fff02d1bc484ae028b2e62b75f702 8879 sound optional zomg_0.2.8-1.diff.gz ef1ff9ca9ec5d8c78b7f9cb90a7013f0 14784 sound optional zomg_0.2.8-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Debian! iD8DBQFG+kiN5m0u66uWM3ARAg4wAJ0cdKQQMRtv7BmpBt0OyHYwxKznNwCeIT5M xFTyPwJ2ve9NdYg7Jk9BtpI= =wgqB -END PGP SIGNATURE- Accepted: zomg_0.2.8-1.diff.gz to pool/main/z/zomg/zomg_0.2.8-1.diff.gz zomg_0.2.8-1.dsc to pool/main/z/zomg/zomg_0.2.8-1.dsc zomg_0.2.8-1_i386.deb to pool/main/z/zomg/zomg_0.2.8-1_i386.deb zomg_0.2.8.orig.tar.gz to pool/main/z/zomg/zomg_0.2.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted br.ispell 3.0~beta4-10 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 13:56:34 +0200 Source: br.ispell Binary: wbrazilian ibrazilian brazilian-conjugate Architecture: source all i386 Version: 3.0~beta4-10 Distribution: unstable Urgency: low Maintainer: Rafael Laboissiere [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: brazilian-conjugate - Brazilian Portuguese verb conjugator ibrazilian - Brazilian Portuguese dictionary for ispell wbrazilian - Brazilian Portuguese wordlist Changes: br.ispell (3.0~beta4-10) unstable; urgency=low . * debian/ibrazilian.info-ispell: Reverted the changes for adding UTF-8 support, which were done in 3.0~beta4-8. This is not really needed. Files: b1ecb2056caf29dfa8a932674508d99f 878 text optional br.ispell_3.0~beta4-10.dsc 094af55d3722a1b218a530fa3e9af875 9396 text optional br.ispell_3.0~beta4-10.diff.gz 55ae6b20ca1d71971941179e525ca54c 104570 text extra brazilian-conjugate_3.0~beta4-10_all.deb 8df51fc1d71d1993587a7b51cd0b83f2 670666 text optional wbrazilian_3.0~beta4-10_all.deb 15ae3b3ee9b0c47edf354ff1815b8f45 364228 text optional ibrazilian_3.0~beta4-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+krbk3oga0pdcv4RAhy2AJ96Jym7UiyL4Qw9F2GVtIgk9OayJwCfcqdj SCmzfIi9ZCzGvrIqCdEio9Q= =GiE1 -END PGP SIGNATURE- Accepted: br.ispell_3.0~beta4-10.diff.gz to pool/main/b/br.ispell/br.ispell_3.0~beta4-10.diff.gz br.ispell_3.0~beta4-10.dsc to pool/main/b/br.ispell/br.ispell_3.0~beta4-10.dsc brazilian-conjugate_3.0~beta4-10_all.deb to pool/main/b/br.ispell/brazilian-conjugate_3.0~beta4-10_all.deb ibrazilian_3.0~beta4-10_i386.deb to pool/main/b/br.ispell/ibrazilian_3.0~beta4-10_i386.deb wbrazilian_3.0~beta4-10_all.deb to pool/main/b/br.ispell/wbrazilian_3.0~beta4-10_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted aspell6.pt 20070823.0-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 14:00:44 +0200 Source: aspell6.pt Binary: aspell-pt-pt Architecture: source all Version: 20070823.0-2 Distribution: unstable Urgency: low Maintainer: Rafael Laboissiere [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: aspell-pt-pt - European Portuguese dictionary for GNU Aspell Changes: aspell6.pt (20070823.0-2) unstable; urgency=low . * debian/control: Added Homepage field * debian/info-aspell: + Changed Emacsen-Name to portugues + Added Otherchars and Additionalchars fields Files: e7d25191d801cf16784766739acbcd09 855 text optional aspell6.pt_20070823.0-2.dsc d96204d9caab0cb375e9add796a66d69 2973 text optional aspell6.pt_20070823.0-2.diff.gz a45c27cd949df47a325a6c11f6d915b9 104088 text optional aspell-pt-pt_20070823.0-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+kzhk3oga0pdcv4RAgkPAJsFxas7SHkdROUGk/5XtG74t0bGbACeMan9 IeqTZ8g1sAcdFKtJ7YPgBgg= =eZ1b -END PGP SIGNATURE- Accepted: aspell-pt-pt_20070823.0-2_all.deb to pool/main/a/aspell6.pt/aspell-pt-pt_20070823.0-2_all.deb aspell6.pt_20070823.0-2.diff.gz to pool/main/a/aspell6.pt/aspell6.pt_20070823.0-2.diff.gz aspell6.pt_20070823.0-2.dsc to pool/main/a/aspell6.pt/aspell6.pt_20070823.0-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted aspell6-pt-br 20070206-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 12:16:00 +0200 Source: aspell6-pt-br Binary: aspell-pt-br Architecture: source all Version: 20070206-2 Distribution: unstable Urgency: low Maintainer: Rafael Laboissiere [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: aspell-pt-br - Brazilian Portuguese dictionary for GNU Aspell Changes: aspell6-pt-br (20070206-2) unstable; urgency=low . * debian/control: Added Homepage, XS-Vcs-Svn, and XS-Vcs-Browser fields * debian/info-aspell: + Renamed Emacsen-Name to brasileiro + Added Otherchars and Additionalchars fields Files: 617b04a98965e78ceb947524ea7cbcdd 852 text optional aspell6-pt-br_20070206-2.dsc 90956ad724ab2563e8cf6596889a1d13 2250 text optional aspell6-pt-br_20070206-2.diff.gz 803b456416cbce931e405330ff44e120 1015498 text optional aspell-pt-br_20070206-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+kw4k3oga0pdcv4RAka8AJ9Frh8GbnQjnJ/wlfw8ntGxmyQKWwCfYttD PdLAugSxL4bMlTUHjhOfGqg= =mONB -END PGP SIGNATURE- Accepted: aspell-pt-br_20070206-2_all.deb to pool/main/a/aspell6-pt-br/aspell-pt-br_20070206-2_all.deb aspell6-pt-br_20070206-2.diff.gz to pool/main/a/aspell6-pt-br/aspell6-pt-br_20070206-2.diff.gz aspell6-pt-br_20070206-2.dsc to pool/main/a/aspell6-pt-br/aspell6-pt-br_20070206-2.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xmedcon 0.9.10-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 10:57:23 +0200 Source: xmedcon Binary: xmedcon libmdc2 medcon libmdc2-dev Architecture: source i386 Version: 0.9.10-1 Distribution: unstable Urgency: low Maintainer: Roland Marcus Rutschmann [EMAIL PROTECTED] Changed-By: Roland Marcus Rutschmann [EMAIL PROTECTED] Description: libmdc2- Medical Image (DICOM, ECAT, ...) conversion tool libmdc2-dev - Medical Image (DICOM, ECAT, ...) conversion tool medcon - Medical Image (DICOM, ECAT, ...) conversion tool xmedcon- Medical Image (DICOM, ECAT, ...) conversion tool Changes: xmedcon (0.9.10-1) unstable; urgency=low . * New upstream release * removed nifti libs from source as they are packaged in debian allready * patched ./configure and libs/Makefile.in to not fail after removal of libs/nifti Files: 184bbb8e4553612539e0e85a3b71f565 698 graphics optional xmedcon_0.9.10-1.dsc 596574ff683d389cf27dae28cac66105 822146 graphics optional xmedcon_0.9.10.orig.tar.gz 51a69da03bd474f7cffd3f592d1ade12 22587 graphics optional xmedcon_0.9.10-1.diff.gz 4ef17f39020224a5d1110b89d2a380c9 265212 libs optional libmdc2_0.9.10-1_i386.deb c73cae303c0908d572f2a99b7014aae6 354002 libdevel optional libmdc2-dev_0.9.10-1_i386.deb b764cc3d915c08b459a78ae09f5dc37c 24992 graphics optional medcon_0.9.10-1_i386.deb e89dffd7f87a20935e6e9c4186eaa715 80626 graphics optional xmedcon_0.9.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFG+krBqE9wmu3T13kRAtTdAKC5/zYlYWp5796I8s8cjvsVsw1djgCdHghq d3NRRNbfJ7TrKSIH3DdsA+E= =XkUh -END PGP SIGNATURE- Accepted: libmdc2-dev_0.9.10-1_i386.deb to pool/main/x/xmedcon/libmdc2-dev_0.9.10-1_i386.deb libmdc2_0.9.10-1_i386.deb to pool/main/x/xmedcon/libmdc2_0.9.10-1_i386.deb medcon_0.9.10-1_i386.deb to pool/main/x/xmedcon/medcon_0.9.10-1_i386.deb xmedcon_0.9.10-1.diff.gz to pool/main/x/xmedcon/xmedcon_0.9.10-1.diff.gz xmedcon_0.9.10-1.dsc to pool/main/x/xmedcon/xmedcon_0.9.10-1.dsc xmedcon_0.9.10-1_i386.deb to pool/main/x/xmedcon/xmedcon_0.9.10-1_i386.deb xmedcon_0.9.10.orig.tar.gz to pool/main/x/xmedcon/xmedcon_0.9.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cryptsetup 2:1.0.5-2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 24 Sep 2007 15:42:06 +0200 Source: cryptsetup Binary: cryptsetup cryptsetup-udeb Architecture: source amd64 Version: 2:1.0.5-2 Distribution: unstable Urgency: low Maintainer: Jonas Meurer [EMAIL PROTECTED] Changed-By: Jonas Meurer [EMAIL PROTECTED] Description: cryptsetup - configures encrypted block devices cryptsetup-udeb - configures encrypted block devices (udeb) Closes: 401766 409775 411784 418450 421693 436434 438169 438198 438450 438473 441428 Changes: cryptsetup (2:1.0.5-2) unstable; urgency=low . [ Jonas Meurer ] * Add libselinux1-dev and libsepol1-dev to build-depends. Detected by the build daemon from hell by Steinar H. Gunderson. Thanks to Manoj Srivastava for advice. * Fix the watchfile * Fix cryptopensc-hook to honor key=none. Thanks to Daniel Baumann (closes: #436434) * Remove outdated README.html and example usbcrypto.* scripts from documentation. Add example usbcrypto.udev script. Thanks to Volker Sauer for the update. (closes: #409775) * Document that stdin is read different with '--key-file=-' than without. Thanks to Marc Haber. (closes: #418450) * Document that --timeout is useless in conjunction with --key-file. Thanks Alexander Zangerl. (closes: #421693) * [03_check_for_root.dpatch] Check for UID == 0 before actually doing something. Thanks to Benjamin Seidenberg. (closes: #401766) * [04_fix_unused_or_unitialized_variables.dpatch] Fix some gcc warnings about unused or unitialized variables. Thanks to Ludwig Nussel for the patch. * [05_segfault_at_nonexisting_device.dpatch] Fix segfault when trying to open a non existing device. Thanks to Ludwig Nussel for the patch. (closes: #438198) * Add CFLAGS=$(CFLAGS) before ./configure invocation in debian/rules. This way CFLAGS are passed to the configure script. Thanks to Gordon Farquharson for the patch. (closes: #438450) * Add a warning about missing hash option in crypttab to initramfs cryptoroot hook. Thanks to Sebastian Leske for the patch. (closes: #438169) * Add support for openct using data objects on a smartcard as key. Thanks to Daniel Baumann [EMAIL PROTECTED] for patch and documentation. (closes: #438473) * Polish opensc_decrypt and openct_decrypt. * Add initramfs patch by maximilian attems. Bump depends on initramfs-tools to (= 0.91). (closes: #441428) * several cleanups to make lintian happy: - remove #!/bin/sh from cryptsetup.functions as it is not executable. - remove unused-override configure-generated-file-in-source config.log. - add some hyphen fixes to patches/02_manpage.dpatch * Filter out the detection of filesystem type 'minix' in checks vol_id and un_vol_id if checking for any valid filesystem. The minix fs signature seems short enough to be detected erroneously by /lib/udev/vol_id. Thanks to Fredrik Olofsson and arno for the bugreport. (closes: #411784) * Add Homepage field to debian/control. Files: 5ad206a8625c2ce420f31b84003769bf 882 admin optional cryptsetup_1.0.5-2.dsc 5f5e0c8d4b7c3f761e993b290ee0a8ae 6 admin optional cryptsetup_1.0.5-2.diff.gz 33121c13828ca7200e28aa0f43a81a0a 260504 admin optional cryptsetup_1.0.5-2_amd64.deb 7f100565ef3ffac0c55bfcd9e10dc953 184474 debian-installer optional cryptsetup-udeb_1.0.5-2_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+jGvd6lUs+JfIQIRAj24AJ4xEXFom9SxdB1+5UHpp6IiC+d7BwCdGa3W Wv0wXBV0cAO4vNN9aLb7jJM= =dXey -END PGP SIGNATURE- Accepted: cryptsetup-udeb_1.0.5-2_amd64.udeb to pool/main/c/cryptsetup/cryptsetup-udeb_1.0.5-2_amd64.udeb cryptsetup_1.0.5-2.diff.gz to pool/main/c/cryptsetup/cryptsetup_1.0.5-2.diff.gz cryptsetup_1.0.5-2.dsc to pool/main/c/cryptsetup/cryptsetup_1.0.5-2.dsc cryptsetup_1.0.5-2_amd64.deb to pool/main/c/cryptsetup/cryptsetup_1.0.5-2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted asterisk 1:1.4.11~dfsg-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 13:32:01 +0300 Source: asterisk Binary: asterisk-sounds-main asterisk-h323 asterisk asterisk-config asterisk-dbg asterisk-dev asterisk-doc Architecture: source all i386 Version: 1:1.4.11~dfsg-2 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Faidon Liambotis [EMAIL PROTECTED] Description: asterisk - Open Source Private Branch Exchange (PBX) asterisk-config - Configuration files for Asterisk asterisk-dbg - Debugging symbols for Asterisk asterisk-dev - Development files for Asterisk asterisk-doc - Source code documentation for Asterisk asterisk-h323 - H.323 protocol support for Asterisk asterisk-sounds-main - Core Sound files for Asterisk (English) Closes: 376514 439197 440187 Changes: asterisk (1:1.4.11~dfsg-2) unstable; urgency=low . [ Faidon Liambotis ] * Depend on libpri-dev = 1.4.1-1 for the bristuffed header. (Closes: #439197) * Added a 1.4 backport of the DEVSTATE() dialplan function which allows retrieving any device state in the dialplan, as well as creating custom device states that are controllable from the dialplan. * Replace Build-Depends libc-client-dev (which wasn't used) with libc-client2006j2-dev and enable Voicemail IMAP storage (configure-libc-client). * Build depend on libcurl4-openssl-dev instead of libcurl4-dev which is a virtual package. This also means using the more complete OpenSSL libcurl backend instead of the GnuTLS one. * Add a versioned = 1.4 dependency of asterisk in asterisk-h323. * Don't use MAKEFLAGS as a variable in debian/rules since it has a special meaning for make. Reported by Simon Richter. * Add Homepage field, as supported by dpkg 1.14.6. * Fix init.d stop when using safe_asterisk. (Closes: #376514) * Drop asterisk-web-vmail package and place the script in /usr/share/doc/asterisk. * Move static-http and sample.call to asterisk's examples. . [ Kilian Krause ] * Update backports scripts for libcurl4*-dev * Fix IMAP crash with upstream source snipplet. (Closes: #440187) . [ Tzafrir Cohen ] * Support increasing open files limit from init.d script. Files: 94574cad237fcc94fc5fcd548087c752 1650 comm optional asterisk_1.4.11~dfsg-2.dsc cdde357d7d3a1645a5f24818b80b5328 161180 comm optional asterisk_1.4.11~dfsg-2.diff.gz 6eb6d96c08f1d1204e7c045ca023d347 31336360 doc extra asterisk-doc_1.4.11~dfsg-2_all.deb 208446776a2b6cf26f555aaad3b2a180 307996 devel extra asterisk-dev_1.4.11~dfsg-2_all.deb eca2f68f26aecdd1f6aa39bf227c27b6 1647302 comm optional asterisk-sounds-main_1.4.11~dfsg-2_all.deb 0e16a14778034fd0beb1fec267a961eb 369462 comm optional asterisk-config_1.4.11~dfsg-2_all.deb 38a5f2891d35de7f78a3125dec4af155 2063024 comm optional asterisk_1.4.11~dfsg-2_i386.deb 23bdd75502a9c72df97745bf8da72b99 276192 comm optional asterisk-h323_1.4.11~dfsg-2_i386.deb dc7fc99a3c44c399c3afa74e95d5aa86 12120606 devel extra asterisk-dbg_1.4.11~dfsg-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+mGiVty5d8XpUzMRApzyAJ93kh1/LOtxpyG2ed/cq3dXQnwvVQCbBvCt AMPYim3IhRMIwX6p0oDqJ2g= =bQFo -END PGP SIGNATURE- Accepted: asterisk-config_1.4.11~dfsg-2_all.deb to pool/main/a/asterisk/asterisk-config_1.4.11~dfsg-2_all.deb asterisk-dbg_1.4.11~dfsg-2_i386.deb to pool/main/a/asterisk/asterisk-dbg_1.4.11~dfsg-2_i386.deb asterisk-dev_1.4.11~dfsg-2_all.deb to pool/main/a/asterisk/asterisk-dev_1.4.11~dfsg-2_all.deb asterisk-doc_1.4.11~dfsg-2_all.deb to pool/main/a/asterisk/asterisk-doc_1.4.11~dfsg-2_all.deb asterisk-h323_1.4.11~dfsg-2_i386.deb to pool/main/a/asterisk/asterisk-h323_1.4.11~dfsg-2_i386.deb asterisk-sounds-main_1.4.11~dfsg-2_all.deb to pool/main/a/asterisk/asterisk-sounds-main_1.4.11~dfsg-2_all.deb asterisk_1.4.11~dfsg-2.diff.gz to pool/main/a/asterisk/asterisk_1.4.11~dfsg-2.diff.gz asterisk_1.4.11~dfsg-2.dsc to pool/main/a/asterisk/asterisk_1.4.11~dfsg-2.dsc asterisk_1.4.11~dfsg-2_i386.deb to pool/main/a/asterisk/asterisk_1.4.11~dfsg-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gforge 4.6.99+svn6094-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 15:44:35 +0200 Source: gforge Binary: gforge-plugin-scmsvn gforge-plugin-scmcvs gforge-lists-mailman gforge-db-postgresql gforge-web-apache2 gforge-plugins-extra gforge-mta-postfix gforge gforge-common gforge-web-apache gforge-mta-courier gforge-ftp-proftpd gforge-shell-postgresql gforge-mta-exim4 gforge-dns-bind9 Architecture: source all Version: 4.6.99+svn6094-2 Distribution: unstable Urgency: low Maintainer: Roland Mas [EMAIL PROTECTED] Changed-By: Roland Mas [EMAIL PROTECTED] Description: gforge - collaborative development tool - meta-package gforge-common - collaborative development tool - shared files gforge-db-postgresql - collaborative development tool - database (using PostgreSQL) gforge-dns-bind9 - collaborative development tool - DNS management (using Bind9) gforge-ftp-proftpd - collaborative development tool - FTP management (using ProFTPd) gforge-lists-mailman - collaborative development tool - mailing-lists (using Mailman) gforge-mta-courier - collaborative development tool - mail tools (using Courier) gforge-mta-exim4 - collaborative development tool - mail tools (using Exim 4) gforge-mta-postfix - collaborative development tool - mail tools (using Postfix) gforge-plugin-scmcvs - CVS plugin for Gforge gforge-plugin-scmsvn - Subversion plugin for Gforge gforge-plugins-extra - collaborative development tool - extra plugins gforge-shell-postgresql - collaborative development tool - shell accounts (using PostgreSQL gforge-web-apache - transition package to gforge-web-apache2 gforge-web-apache2 - collaborative development tool - web part (using Apache) Closes: 433826 441250 443951 Changes: gforge (4.6.99+svn6094-2) unstable; urgency=low . * Added Homepage: field to debian/control. * debian/patches/use-snoopy-from-distro.dpatch: Use the Snoopy class as provided by libphp-snoopy rather than shipping our own copy of it (closes: #443951). * Removed local copies from the binary packages, to be extra sure. * Updated debian/po/de.po, from Helge Kreutzmann [EMAIL PROTECTED] (closes: #441250). * Make sure there's at least a dummy SSL certificate set up, even if it's the Snake Oil cert; the admin is expected to replace it with a real cert if possible, but this should ensure the initial SSL setup is at least working (closes: #433826). Files: 92b242af30fd8f11efc38a2afd71496d 1027 devel optional gforge_4.6.99+svn6094-2.dsc 7517f80738ef12b4a825df525cc57942 13144 devel optional gforge_4.6.99+svn6094-2.diff.gz 9ee7a8502ac3f8d86959224996d2b836 85416 devel optional gforge_4.6.99+svn6094-2_all.deb 4851a3c1ad08b5d7c2305cf68b6d6bfe 1743132 devel optional gforge-common_4.6.99+svn6094-2_all.deb 7d179c0a1e85a40acfdf8d51caa90f3d 2347296 devel optional gforge-plugins-extra_4.6.99+svn6094-2_all.deb ba8693f97f5648ff7516099d3fc1a222 1383348 devel optional gforge-web-apache2_4.6.99+svn6094-2_all.deb 6577092a9071b5b2502280c26495003d 81002 devel optional gforge-web-apache_4.6.99+svn6094-2_all.deb 13de67ba60d25f414916997ef1762ec6 212760 devel optional gforge-db-postgresql_4.6.99+svn6094-2_all.deb fc3c9f189f61d8f7b2963d4445c619c9 92148 devel optional gforge-mta-exim4_4.6.99+svn6094-2_all.deb 921df54672f7776115cb9ee6a3c8c993 91832 devel optional gforge-mta-postfix_4.6.99+svn6094-2_all.deb b1b14b9cf451c92bdfe269148d97 81282 devel optional gforge-mta-courier_4.6.99+svn6094-2_all.deb bb75e78674fbadce308dad4eb746282a 90212 devel optional gforge-shell-postgresql_4.6.99+svn6094-2_all.deb 11a6fc1ccead9fa2465eae08bdec9deb 91252 devel optional gforge-ftp-proftpd_4.6.99+svn6094-2_all.deb b61fa9f9d537809575d9f4a04b062866 99412 devel optional gforge-dns-bind9_4.6.99+svn6094-2_all.deb ab78ffc8609f3ec86b25e1eaf5b3e39d 87286 devel optional gforge-lists-mailman_4.6.99+svn6094-2_all.deb 45e901d730057805955cb7b78f9e0b2d 127950 devel optional gforge-plugin-scmcvs_4.6.99+svn6094-2_all.deb 6c55e51eb20c71fbee988be182ab82fa 114326 devel optional gforge-plugin-scmsvn_4.6.99+svn6094-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+mO6DqdWtRRIQ/URAr9oAJ4s/nEWIFWvsVWHZ9TfRHmy7butvQCfb7Yu qdGIYKYJd+MsYRDL+aQ2vQ4= =duH8 -END PGP SIGNATURE- Accepted: gforge-common_4.6.99+svn6094-2_all.deb to pool/main/g/gforge/gforge-common_4.6.99+svn6094-2_all.deb gforge-db-postgresql_4.6.99+svn6094-2_all.deb to pool/main/g/gforge/gforge-db-postgresql_4.6.99+svn6094-2_all.deb gforge-dns-bind9_4.6.99+svn6094-2_all.deb to pool/main/g/gforge/gforge-dns-bind9_4.6.99+svn6094-2_all.deb gforge-ftp-proftpd_4.6.99+svn6094-2_all.deb to pool/main/g/gforge/gforge-ftp-proftpd_4.6.99+svn6094-2_all.deb gforge-lists-mailman_4.6.99+svn6094-2_all.deb to pool/main/g/gforge/gforge-lists-mailman_4.6.99+svn6094-2_all.deb gforge-mta-courier_4.6.99+svn6094-2_all.deb to pool/main/g/gforge/gforge-mta-courier_4.6.99+svn6094-2_all.deb
Accepted aterm 1.0.1-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 15:07:37 +0200 Source: aterm Binary: aterm-ml aterm Architecture: source i386 Version: 1.0.1-2 Distribution: unstable Urgency: medium Maintainer: Nico Golde [EMAIL PROTECTED] Changed-By: Nico Golde [EMAIL PROTECTED] Description: aterm - Afterstep XVT - a VT102 emulator for the X window system aterm-ml - Afterstep XVT - a VT102 emulator for the X window system Closes: 443811 Changes: aterm (1.0.1-2) unstable; urgency=medium . * Included 29_fix_deadkeys.dpatch to fix broken deadkeys input (Closes: #443811) * Bumped urgency since the deadkeys bug breaks a lot of languages. Files: 3ae0ae63e9e9b43e2a1c655bb3124e24 630 x11 optional aterm_1.0.1-2.dsc ecfbfe53f4da459ca8823342d47d39f1 13877 x11 optional aterm_1.0.1-2.diff.gz f7032c5ad39fa4117625219476e13d9c 84396 x11 optional aterm_1.0.1-2_i386.deb 9b7d2da17dcf31951e702bca69273974 265224 x11 optional aterm-ml_1.0.1-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+mTyHYflSXNkfP8RAsV6AJ0UQxP+3y9kaV73sLlshf8UHWLKlACfeGo3 0CjG71myAM6vsqI9FjpGYBs= =XyPF -END PGP SIGNATURE- Accepted: aterm-ml_1.0.1-2_i386.deb to pool/main/a/aterm/aterm-ml_1.0.1-2_i386.deb aterm_1.0.1-2.diff.gz to pool/main/a/aterm/aterm_1.0.1-2.diff.gz aterm_1.0.1-2.dsc to pool/main/a/aterm/aterm_1.0.1-2.dsc aterm_1.0.1-2_i386.deb to pool/main/a/aterm/aterm_1.0.1-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted genromfs 0.5.2-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Sep 2007 15:52:04 +0200 Source: genromfs Binary: genromfs Architecture: source i386 Version: 0.5.2-2 Distribution: unstable Urgency: low Maintainer: Juan Cespedes [EMAIL PROTECTED] Changed-By: Juan Cespedes [EMAIL PROTECTED] Description: genromfs - This is the mkfs equivalent for romfs filesystem Closes: 240522 Changes: genromfs (0.5.2-2) unstable; urgency=low . * Check for errors when writing image (closes: Bug#240522) * Switched to debhelper Files: 3c47040f3287b50966df2897cd0a941e 562 admin extra genromfs_0.5.2-2.dsc 315c1f81a833ca5fcb3dcf97633cad71 3008 admin extra genromfs_0.5.2-2.diff.gz ef7916f032e50f0f0cd127a0d8d527ce 17750 admin extra genromfs_0.5.2-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+mTZepWluYh4RwMRAqzRAJ99Juh635IRHiRuuYfH0QGBQ9M8xwCgu36F OQQU1wpfpP9IvXHdPV1Ibrg= =LIdD -END PGP SIGNATURE- Accepted: genromfs_0.5.2-2.diff.gz to pool/main/g/genromfs/genromfs_0.5.2-2.diff.gz genromfs_0.5.2-2.dsc to pool/main/g/genromfs/genromfs_0.5.2-2.dsc genromfs_0.5.2-2_i386.deb to pool/main/g/genromfs/genromfs_0.5.2-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tclodbc 2.5-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 7 Aug 2007 16:30:00 +0200 Source: tclodbc Binary: tclodbc Architecture: source i386 Version: 2.5-2 Distribution: unstable Urgency: low Maintainer: Francesco Paolo Lovergine [EMAIL PROTECTED] Changed-By: Daniel Rus Morales [EMAIL PROTECTED] Description: tclodbc- The ODBC extension to Tcl Closes: 435291 Changes: tclodbc (2.5-2) unstable; urgency=low . * Closes: #435291 (FTFBS in AMD64) and fix some warnings. * debian/patches/03-tclconfig_tcl.m4.dpatch: new dpatch file to fix warnings. * debian/patches/04-tclodbc.hxx.dpatch: new dpatch file to fix bug #435291. * debian/patches/05-statemnt.cxx.dpatch: new dpatch file to fix bug #435291. * debian/patches/06-database.cxx.dpatch: new dpatch file to fix some warnings. Files: 40d58ace400b18f88391c87a111efdaf 724 devel optional tclodbc_2.5-2.dsc d4e8ca2883bd0269a898f894a3cb598f 8215 devel optional tclodbc_2.5-2.diff.gz 18adf9c5fb6bf28026f96610a4a2528a 56734 libs optional tclodbc_2.5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG+mhNpFNRmenyx0cRAlGTAKDYU+UNUIn2pSatbspO084RsRsl9ACePa2L eIM3MlCJYptY0ck24HytAHs= =II2E -END PGP SIGNATURE- Accepted: tclodbc_2.5-2.diff.gz to pool/main/t/tclodbc/tclodbc_2.5-2.diff.gz tclodbc_2.5-2.dsc to pool/main/t/tclodbc/tclodbc_2.5-2.dsc tclodbc_2.5-2_i386.deb to pool/main/t/tclodbc/tclodbc_2.5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
