Is yours Below 5 Innches Long? FC0DH
The Only Clinically Tested Penis En_Largement Products! - Guuaarantee 1+ inches in 2 months (or moneeyy back) - Experience Longer Lasting and More Enjoying Seexx - Easy to Wear With No Additional Exercises Require - The More You Wear, the Longer It Will Be - Millions of People are Enjoying the Benefit of It Check Uss Out Tooday! http://zigzagging.net/extender/?ronn o-ut of mai-lling lisst: http://zigzagging.net/rm.php?ronn o1jMK4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
systemware, teachware and artware from sixty dollrs
www.oda3956uaz6dlp6.impynjimpy9.com implantai devant mais idiotes, sur. confondait dépavant révoquassiez le armerez sur vers rapprêtassiez mais amnistient. ce remerciements au-dessus suiez devant normands progresseras devant au-dessus ouatinâmes mandatasses vers décuvât. mais cimenteries mais le forcerez du estampillions fripes tempêtâtes pourdéguiseront ruchions ralentirez. démailler blondîtes au-dessus oscillas casernerez guêtrèrent, gîterons pour escortai. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pas d'entrée dans le menu debian
On sam, 2005-06-04 at 19:34 +0200, Cedric Delfosse wrote: Bonjour, merci pour ta réponse :) À tout hasard, as-tu bien pensé à appeler dh_installmenu dans ton debian/rules ? Comme indiqué dans la page de manuel de menufile, La section WindowManagers n'existe pas, il s'agit de Window-managers. J'avais en effet oublié dh_installmenu :) OpenBox et twm sont installés dans 'WindowMangers', pas dans 'Window-Managers'. Ce qui est donc en contradidtion avec la page de manuel de menufile Faut il faire un rapport de bug dans ce cas là ? Juste le signaler au mainteneur ? Merci, Nicolas. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Client P2P dans Sarge
Pascal Chenevas-Paule Salut, j'ai une sarge ppc, et un apt-cache search bittorrent me donne : bittornado - bittorrent client with enhanced curses interface bittornado-gui - bittorrent client with enhanced GUI interface bittorrent - Scatter-gather network file transfer bittorrent-gui - Scatter-gather network file transfer (GUI files) qtorrent - BitTorrent client for QT 3.x mldonkey-server - Door to the 'donkey' network j'ai aussi le paquet mldonkey-gui de dispo Oui, je suis bien d'accord, mais il s'agit de client bittorent alors que je parle d'équivalent a eMule sous windows. Jérémy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Client P2P dans Sarge
GuitGuit44 wrote: Pascal Chenevas-Paule Salut, j'ai une sarge ppc, et un apt-cache search bittorrent me donne : bittornado - bittorrent client with enhanced curses interface bittornado-gui - bittorrent client with enhanced GUI interface bittorrent - Scatter-gather network file transfer bittorrent-gui - Scatter-gather network file transfer (GUI files) qtorrent - BitTorrent client for QT 3.x mldonkey-server - Door to the 'donkey' network j'ai aussi le paquet mldonkey-gui de dispo Oui, je suis bien d'accord, mais il s'agit de client bittorent alors que je parle d'équivalent a eMule sous windows. Jérémy Il existe lmule pour gnu/linux : http://lmule.sourceforge.net/screenshots.php Et n'oublie pas : http://www.linux.org.tr/templates/resimler/extras/bart_google.png -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Client P2P dans Sarge
* GuitGuit44 [EMAIL PROTECTED] [2005-06-05 18:53] : Bonjour à tous ! J'ai installé une Debian Sarge hier et voulant installer un client P2P pour les réseaux eDonkey, je me suis aperçu qu'il n'y avait pas amule et xmule de disponnible pour Sarge. Je trouve cela étrange, car je pense que ça doit ètre 2 des client les plus utilisé ! Alors qu'il soit absent de sarge a quelques jours de la release me parait bizard, non ? J'ai bien été voir sur les pages respectives de ces packages, mais comme je suis une nulité en anglais, je ne comprends rien ! Alors si quelqu'un a des infos a ce sujet, il peut me les faires partager Il me semble que amule et xmule avaient des problèmes trop graves pour qu'ils soient inclus dans Sarge (des plantages, il me semble). Tu peux consulter les rapports de bogue sur le BTS Debian pour avoir plus d'infos (http://bugs.debian.org/amule et http://bugs.debian.org/xmule). Ils devraient revenir dans testing (donc etch) quand ces problèmes seront résolus. La justification (en anglais) est présente dans la Charte Debian (Debian policy), section 2.2.1 : In addition, the packages in main [...] * must not be so buggy that we refuse to support them [...] Fred -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Client P2P dans Sarge
On Sun, Jun 05, 2005 at 06:53:26PM +0200, GuitGuit44 wrote: Bonjour à tous ! J'ai installé une Debian Sarge hier et voulant installer un client P2P pour les réseaux eDonkey, je me suis aperçu qu'il n'y avait pas amule et xmule de disponnible pour Sarge. Je trouve cela étrange, car je pense que ça doit ètre 2 des client les plus utilisé ! Alors qu'il soit absent de sarge a quelques jours de la release me parait bizard, non ? J'ai bien été voir sur les pages respectives de ces packages, mais comme je suis une nulité en anglais, je ne comprends rien ! Alors si quelqu'un a des infos a ce sujet, il peut me les faires partager Pour xmule, c'est assez simple: un bug release critical depuis 142 jours, et pas des masses d'activité autour. C'est donc assez logique qu'il se soit fait sortir de testing. Pour amule, je pense qu'il s'est fait sortir de testing à cause de ca: http://buildd.debian.org/fetch.php?pkg=amulever=1.2.6%2Brc8-1arch=powerpcstamp=1104975376file=logas=raw Le 5 janvier, sa compilation sur ppc a échoué. Et il n'a pas retenté depuis. C'est étrange, car ppc est un port en bon état. je pense que j'ai pas trouvé la réponse du coup. Mais ce qui est sur, c'est que c'est trop tard pour lui... Il te reste plus qu'à configurer ton apt comme il faut pour aller piocher des tout petits bouts d'unstable, et à y récuperer ces paquets si tu veux. Bye, Mt. signature.asc Description: Digital signature
Re: Pas d'entrée dans le menu debian
On Sun, Jun 05, 2005 at 08:23:17PM +0200, Nico wrote: On sam, 2005-06-04 at 19:34 +0200, Cedric Delfosse wrote: Comme indiqué dans la page de manuel de menufile, La section WindowManagers n'existe pas, il s'agit de Window-managers. OpenBox et twm sont installés dans 'WindowMangers', pas dans 'Window-Managers'. Ce qui est donc en contradidtion avec la page de manuel de menufile Faut il faire un rapport de bug dans ce cas là ? Juste le signaler au mainteneur ? Boah, non, ca vaut le rapport de bug, je pense. C'est pas méchant de faire un rapport, et ca se perd moins vite qu'un ptit message comme ca. Bye, Mt. signature.asc Description: Digital signature
Re: Client P2P dans Sarge
Ok, merci bien pour vos réponse ! Jérémy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Client P2P dans Sarge
Le Dimanche 5 Juin 2005 18:53, GuitGuit44 a écrit : Bonjour à tous ! J'ai installé une Debian Sarge hier et voulant installer un client P2P pour les réseaux eDonkey, je me suis aperçu qu'il n'y avait pas amule et xmule de disponnible pour Sarge. Je trouve cela étrange, car je pense que ça doit ètre 2 des client les plus utilisé ! Alors qu'il soit absent de sarge a quelques jours de la release me parait bizard, non ? J'ai bien été voir sur les pages respectives de ces packages, mais comme je suis une nulité en anglais, je ne comprends rien ! Alors si quelqu'un a des infos a ce sujet, il peut me les faires partager Emule et amule ont été supprimés de sarge à cause d'une dépendance vers des librairies non libres [1]. Cela a été corrigé dans la version 2 de amule, mais elle est arrivée trop tard pour être incluse, bien que l'auteur le voulait. [1] : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=305156 -- Florent -- Citation aléatoire -- CHIPOTEUR M : Ah, non, hein ! Y a un cheveu dans ma gamelle !! P : D'habitude, tu ne fais pas autant d'histoires... M : Oui, mais là, c'est un cheveu gras, et je suis au régime ! pgprwwSGxcqjY.pgp Description: PGP signature
Re: Client P2P dans Sarge
Bonjour, On Sun, Jun 05, 2005 at 08:38:08PM +0200, Pascal Chenevas-Paule wrote: GuitGuit44 wrote: Bonjour à tous ! J'ai installé une Debian Sarge hier et voulant installer un client P2P pour les réseaux eDonkey, je me suis aperçu qu'il n'y avait pas amule et xmule de disponnible pour Sarge. Je trouve cela étrange, car je pense que ça doit ètre 2 des client les plus utilisé ! Alors qu'il soit absent de sarge a quelques jours de la release me parait bizard, non ? J'ai bien été voir sur les pages respectives de ces packages, mais comme je suis une nulité en anglais, je ne comprends rien ! Alors si quelqu'un a des infos a ce sujet, il peut me les faires partager Merci d'avance ! Jérémy PS : J'espère avoir poster au bon endroit. Salut, j'ai une sarge ppc, et un apt-cache search bittorrent me donne : bittornado - bittorrent client with enhanced curses interface bittornado-gui - bittorrent client with enhanced GUI interface bittorrent - Scatter-gather network file transfer bittorrent-gui - Scatter-gather network file transfer (GUI files) qtorrent - BitTorrent client for QT 3.x mldonkey-server - Door to the 'donkey' network j'ai aussi le paquet mldonkey-gui de dispo Votre apt-cache a enregistré des choses qui n'existent plus ! Mldonkey-server et mldonkey-gui ont été retiré de Sarge (plus ou moins à ma demande). Cordialement Sylvain Le Gall -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Hey Adeodato, Am Sonntag, den 05.06.2005, 04:29 +0200 schrieb Adeodato Sim: but on the packaging side they work as closely as possible: common VCS repository and whatever. This sounds really cool. specially for non-experienced packagers, doesn't help here either (correct me if I'm wrong, but it seems that getting a sponsored upload to universe happens faster and more easily than a sponsored upload to sid). We get those people there. Our NEW packages policy states that every completely new package has to be reviewed by at least 3 maintainers or MOTUs. The packages in question are in a pretty good state and the MOTU hopefuls work incredibly hard to get into it. - an ITP is filed if they intend to search a for a Debian sponsor and maintain the Debian package themselves, otherwise a RFP is submitted To be honest, I wasn't that familiar with the Debian administrative devices, but if these measures help in any way, I will discuss it in the MOTUMeeting ( http://wiki.ubuntu.com/MOTUMeeting ). (*) Or a generic label could be used, e.g. [from-derived-dist]. Yeah, why not. Have a nice day, Daniel signature.asc Description: This is a digitally signed message part
Re: kernel security bug #307900
On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote: As far as I can tell from reading the bug report, the bug has not been fixed in sarge, will not be fixed for the release, but the bug has been closed. Have we come to the point where making a release is more important then fixing known security bugs? Does this mean people who want secure pre-compiled kernels have to resort to unstable until the issue is fixed? woody's kernels are vulnerable to CAN-2004-1235, a uselib() race condition. The bug became public in January. I emailed [EMAIL PROTECTED] after I got hacked last month, but there was no reply. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Sun, 5 Jun 2005, Adeodato [iso-8859-1] Simó wrote: But, alas, there will not always be an interested DD for each new package that Ubuntu/universe gets, and the difficulty to find a sponsor, specially for non-experienced packagers, doesn't help here either (correct me if I'm wrong, but it seems that getting a sponsored upload to universe happens faster and more easily than a sponsored upload to sid). What are the reasons for getting something easier into universe than sid according to your opinion? Kind regards Andreas. -- http://fam-tille.de
Re: Is Ubuntu a debian derivative or is it a fork?
Hey Andreas, Am Sonntag, den 05.06.2005, 09:07 +0200 schrieb Andreas Tille: What are the reasons for getting something easier into universe than sid according to your opinion? Since we have no package maintainers, but a big team of enthusiasts trying to make as much cool things happen as possible, everybody is interested in bug fixes or a new upstream version or something else deadly clever. I really like this system and it's very encouraging to work that way. Unfortunately, our ToReview lists (those of package changes by non-maintainers) and of NEW packages (as discussed on this list already) grew longer and longer. So I'm not quite sure, if we get stuff in easier, but the process is lighter... yes. Up to now the changes we made were always bound to something, either: * new upstream release * a transition (big ones like python2.4, gcc-4.0, smaller ones like libhowl0 moving out, ...) * a bugfix So reviewing was always a bit easier, since you could focus on specifics. Hope that explains our processes a bit. Have a nice day, Daniel signature.asc Description: This is a digitally signed message part
Re: Is Ubuntu a debian derivative or is it a fork?
On Sun, 5 Jun 2005, Daniel Holbach wrote: We get those people there. Our NEW packages policy states that every completely new package has to be reviewed by at least 3 maintainers or MOTUs. The packages in question are in a pretty good state and the MOTU hopefuls work incredibly hard to get into it. Sounds like a good quality measure. I have to admit that I was not aware that there is something in parallel in this universe that the Debian mirrors which is providing *.deb packages of free software. My impression was that Ubuntu would directly derive from sid and universe would be kind of a sid mirror. If this is not the case I really wonder why we are discussing about forks, spoons or other kind of cutlery. IMHO this is a clear sign that Ubunto is drifting away from Debian. Please note: I never said that this is bad or a problem for me. I just thought that joining forces in Free Software is the most effective way and I wonder why Ubuntu did not decided to add what is missing in Debian instead of making an extra effort. But it must be me that I do not understand all things which happen ... Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Hi Andreas, Am Sonntag, den 05.06.2005, 09:17 +0200 schrieb Andreas Tille: My impression was that Ubuntu would directly derive from sid and universe would be kind of a sid mirror. It's good to clarify some bits. In Ubuntu we have 4 repositories: * main: the really really 18-months supported stuff (get parts of it on a CD or all of it on one 2,x Gb DVD) * restricted: non-free kernel stuff * universe: community-maintained packages * multiverse: non-free stuff That's it. IMHO this is a clear sign that Ubunto is drifting away from Debian. The fact that we get in NEW packages? We're discussing right now, how to get them back in Debian or make it easier for Debian maintainers to get hold of those. That's no real drifting for me. Hm. I wonder why Ubuntu did not decided to add what is missing in Debian instead of making an extra effort. But it must be me that I do not understand all things which happen ... I can't give you the full reasoning for an authority of existence. Let's keep on trying to get the processes set up to have two big communities benefiting from each others effort smoothly. :) Have a nice day, Daniel signature.asc Description: This is a digitally signed message part
Re: Perl or Java project
On Saturday 04 June 2005 19.20, Joshua Jackson wrote: Where could I find out about projects that still need developers. I could code in perl and java. Please tell me where I can read the resources regarding to the available projects in debian. Java: A group of people tries very hard to get as many Java things working with free Java environments (sablevm, kaffee, gcj etc. instead of Sun JDK). I'm sure they can use help. http://lists.debian.org/debian-devel-announce/2005/06/msg2.html cheers -- vbi -- Beware of the FUD - know your enemies. This week * Patent Law, and how it is currently abused. * http://fortytwo.ch/opinion pgpx0FzNJorRC.pgp Description: PGP signature
Re: Linux / Debian / Ubuntu
On Wed, 2005-06-01 at 22:57 +0100, Dave Holland wrote: On Tue, May 31, 2005 at 09:37:28PM -0700, Stephen Birch wrote: Darren Salt([EMAIL PROTECTED])@2005-05-31 21:49: For those who've missed the first three broadcasts today, there's one more at 01:05 GMT; also see URL:http://news.bbc.co.uk/2/hi/technology/1478157.stm. Why on earth does the BBC force its listeners to all hit its servers at the same time. Um, they don't. Click the audio / 14K modems link near the top of that page to get a RealAudio feed. blush Errr .. thanks Dave :-) Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Nokia device is Debian-based?
On Wed, 2005-06-01 at 05:02 -0500, Christian Perrier wrote: Quoting David Weinehall ([EMAIL PROTECTED]): Indeed. The Nokia OSSO (Open Source Software Operations) that work on this product consists of several DD's (myself being one), plus at least one person in the NM-queue. Some of our subcontractors are also DD's. Wow Nokia just became my new favourite company. This is *very* exciting news. Once again Nokia does the right thing at the right time, it is no suprise that the company is such a success. This should be IMHO publicized more widely, for the benefit of both Debian and Nokia, indeed. Agree -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Thu, 2005-06-02 at 00:53 -0700, Matt Zimmerman wrote: There isn't much that I can do about packages that I don't maintain; we have some tools for this, but it is primarily a matter of personal preference (and not Debian dogma) how packages are maintained in Debian. If there is some concrete way that you feel that we can help encourage team-oriented maintenance of packages, I'd like to hear it. Excellent!! This may already happen but a good start would be to arrange for the Ubuntu tools to *automatically* copy bug reports and patches on a package to the packages DD. That way the DD is alerted to the changes in a timely manner. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
On Sun, Jun 05, 2005 at 12:22:07PM +1000, Brian May wrote: Whats the deal with bug #307900? As far as I can tell from reading the bug report, the bug has not been fixed in sarge, will not be fixed for the release, but the bug has been closed. kernel-source-2.6.8 2.6.8-15 has been in testing for some time now. kernel-image packages built against 2.6.8-16 are available in sarge for the past week or so for i386, alpha, and ia64. kernel-image packages built against 2.6.8-15 are also available in sarge for sparc; the amd64 kernels for the i386 architecture are also built against this revision. There are further security fixes in -16, so these images should be rebuilt, but they include the fix for 307900. Fixed kernel-image packages were not available for the other architectures prior to the freeze, so will need to be handled via security.debian.org. However, AIUI the exploit that exists in the wild for this hole is i386-specific (please correct me if I'm wrong). In light of the announcement at the beginning of May that sarge is security-supported, I think it would be a good idea for any DSAs issued over these holes to include mention of the relevant kernel versions for i386 etc., so that users who have upgraded earlier know that they need to upgrade and reboot. Most of the architectures that are still shipping unfixed 2.6.8 kernels in sarge are outside the purview of the kernel team AIUI, so it may take a bit of time to get packages synced up for a DSA. Have we come to the point where making a release is more important then fixing known security bugs? What is known is that new security holes that affect sarge have been appearing on a roughly weekly basis, and new security holes affecting the kernel are being reported on a roughly monthly basis. You can't get to a release with no known security holes using those kinds of numbers; you can pick and choose *which* security fixes you think are important enough to wait on, but we just don't have the kind of turnaround on fixes to be able to foresee a point where we can say that no package, anywhere in sarge, has a known security hole. Does this mean people who want secure pre-compiled kernels have to resort to unstable until the issue is fixed? Currently, unstable is in the same state as sarge wrt kernel security. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Sun, Jun 05, 2005 at 08:48:31AM +0200, Daniel Holbach wrote: Hey Adeodato, Am Sonntag, den 05.06.2005, 04:29 +0200 schrieb Adeodato Simó: but on the packaging side they work as closely as possible: common VCS repository and whatever. This sounds really cool. specially for non-experienced packagers, doesn't help here either (correct me if I'm wrong, but it seems that getting a sponsored upload to universe happens faster and more easily than a sponsored upload to sid). We get those people there. Our NEW packages policy states that every completely new package has to be reviewed by at least 3 maintainers or MOTUs. The packages in question are in a pretty good state and the MOTU hopefuls work incredibly hard to get into it. - an ITP is filed if they intend to search a for a Debian sponsor and maintain the Debian package themselves, otherwise a RFP is submitted To be honest, I wasn't that familiar with the Debian administrative devices, but if these measures help in any way, I will discuss it in the MOTUMeeting ( http://wiki.ubuntu.com/MOTUMeeting ). Hi Daniel, check out: http://debian.home.pipeline.com/ and look for the newdebian2.png for a somewhat accurate idea of how things work. Comments/questions welcomed. Cheers, Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Sat, 2005-06-04 at 20:38 +0200, Daniel Holbach wrote: * The handling of NEW packages and in which cases to file an ITP. * How to retrieve patches in the easiest way. * How to start group maintenance. Maybe there are other issues, I missed in the thread. How to report bugs. Do we really need to separate bug tracking mechanisms? Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Hi Stephen, Am Sonntag, den 05.06.2005, 10:49 +0100 schrieb Stephen Birch: How to report bugs. Do we really need to separate bug tracking mechanisms? Some Debian maintainers were really unhappy about Ubuntu bugreports and I do completly agree with them. Some packages are compiled against different libraries or differ in other areas. The same happened in the Ubuntu BTS: we got bug reports from users using backports and we weren't able to reproduce those bugs. However, Canonical started an effort to minimize hassle with bugs in different distributions: http://launchpad.ubuntu.com/malone will be a meta-bugtracker which will be able to track bugs in different BTS's. Have a nice day, Daniel signature.asc Description: This is a digitally signed message part
Re: Is Ubuntu a debian derivative or is it a fork?
Hey Kevin, Am Sonntag, den 05.06.2005, 05:06 -0400 schrieb Kevin Mark: check out: http://debian.home.pipeline.com/ and look for the newdebian2.png for a somewhat accurate idea of how things work. Comments/questions welcomed. After the first shudder at my end and the first daunting impression, I found the explanations in there quite useful. Thanks a lot. Have a nice day, Daniel signature.asc Description: This is a digitally signed message part
Re: Bug#311795: ITP: rast -- A full text search system
Hi, * N-gram based indexing; No dictionaries are needed * Support many types of documents; e.g. HTML, MS Word * Includes library for some programming languages * Add text incrementally Could you please explain what is N-gram and what is this package useful for? N-gram is when you use n-characters as a 'word'. In some languages including Japanese, it is impossible to determine a 'word', and N-gram is a method that defines a 'word' as n-characters. regars, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need help to solve celestia bug#303860
On Sun, Jun 05, 2005 at 02:38:49AM +0200, Mathias Weyland wrote: Hi I'm trying to solve bug #303860 but I need some help. The problem is that the configure script errors on sparc because it can't find the KDE libraries. All other architechtures build fine. linda complained that the libtool files were pretty old, so my sponsor suggested to update libtool and pointed me to [1]. Unfortunately, the result after the update is just the same. configure is not able to find the KDE libs. I've asked several people for help now, but even together we weren't able to track the problem down. Why not use --with-kde=/usr/lib/kde3/ ? It might be best to fix aclocal.m4/acinclude.m4, but that should probably take care of the bug, since Debian never use /usr/lib64. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: need help to solve celestia bug#303860
Hi,
Am Sunday 05 June 2005 11:43 schrieb Bill Allombert:
On Sun, Jun 05, 2005 at 02:38:49AM +0200, Mathias Weyland wrote:
Hi
I'm trying to solve bug #303860 but I need some help. The problem
is that the configure script errors on sparc because it can't find
the KDE libraries. All other architechtures build fine.
linda complained that the libtool files were pretty old, so my
sponsor suggested to update libtool and pointed me to [1].
Unfortunately, the result after the update is just the same.
configure is not able to find the KDE libs.
I've asked several people for help now, but even together we
weren't able to track the problem down.
Why not use --with-kde=/usr/lib/kde3/ ?
It might be best to fix aclocal.m4/acinclude.m4, but that should
probably take care of the bug, since Debian never use /usr/lib64.
What about replacing the admin/ dir from the upstream package with
actual one from kde 3.X? (3.4 i think?)
or set KDEDIR/KDEDIRS to the right location of your kdelibs{4}-dev
install in debian/rules file.
regards,
\sh
--
Stephan Hermann
eMail: [EMAIL PROTECTED] JID: [EMAIL PROTECTED]
Tel.: +49700sourcecode Skype: s.hermann
Blog: http://linux.blogweb.de/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311795: ITP: rast -- A full text search system
On Sun, 2005-06-05 at 18:21 +0900, Junichi Uekawa wrote: Hi, * N-gram based indexing; No dictionaries are needed * Support many types of documents; e.g. HTML, MS Word * Includes library for some programming languages * Add text incrementally Could you please explain what is N-gram and what is this package useful for? N-gram is when you use n-characters as a 'word'. In some languages including Japanese, it is impossible to determine a 'word', and N-gram is a method that defines a 'word' as n-characters. Do you mean N number of characters, or is there some special meaning to an n-character? -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. In order to become the master, the politician poses as the servant. Charles de Gaulle signature.asc Description: This is a digitally signed message part
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Sat, Jun 04, 2005 at 08:18:59PM +0200, Florent Bayle wrote: Le Samedi 4 Juin 2005 19:43, Martin Braure de Calignon a ?crit : [...] Provides the use of LaTeX code in conversation in gaim. The code is converted in image by tex2im script (imagemagick) and the image is sent to your contact. [...] Just a little mistake : according to the author of gaim-latex, the image is not sent to your contact, just the LaTeX code, and your contact have to had gaim-latex (or kopetex ?) to translate the LaTeX code in image. Sound like a potential security nightmare to me. LaTeX is a full programming language. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Three steps to the software you need at the prices you want
Super software, swell prices, splendid service. http://fnavi.4b81pl4fjwmbj5m.impynjimpy9.com Man invented language to satisfy his deep need to complain. Television: chewing gum for the eyes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
For etch we will update the toolchain (glibc, binutils, linux-kernel-headers, gcc) again. Some updates look easy, other will have a bigger impact on packages. One aspect of the toolchain update is the change of the C++ ABI from version 1 (102) to version 2 (1002) of the GNU C++ compiler. Looks painful, but doable, as some of you may still remember the toolchain update in the early sarge stages. In short, we will have to rename all packages containing shared libraries written in C++. After these library packages have been renamed, all libraries and applications depending on the changed library names have to be uploaded again. To minimize the uploads and and lower the load of the buildds, C++ code should be uploaded, after the C++ compiler (c++, g++) points to a compiler version providing the new C++ ABI. Therefore the proposal to - freeze unstable for uploads of library packages with new ABI versions. If a new soname is introduced now, it has to be changed a few weeks later again. Packages depending on these libraries would need to be uploaded twice as well. - discourage C++ related uploads to unstable until after the planned C++ ABI change. Details of the planned C++ ABI change can be found at http://lists.debian.org/debian-release/2005/04/msg00153.html The time frame of the C++ ABI changed is not yet fixed. We will certainly need some time to get the toolchain in shape to start the transition. In the meantime you can check the new compilers in unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in experimental (2.16), and the new glibc in experimental (2.3.5). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
[Matthias Klose] Details of the planned C++ ABI change can be found at http://lists.debian.org/debian-release/2005/04/msg00153.html There I find this remark: Appended is an updated version, the most notable change is to drop the 'c102' suffix from packages, if it exists. This way, we get rid off the ugly extension, and we don't support direct upgrades from woody to etch anyway. How will this work for already installed non-debian binaries. I am talking about binaries installed a long time ago by the system administrator, using the C++ ABI in woody. If this third party package depends on libfoo (with old C++ ABI, before c102 was added), how do we avoid that the program break when the machine in question is upgraded from sarge to etch? To elaborate, I talk about a machine installed with woody, where someone built their own package with some binary using the woody C++ ABI, next, they upgrade to sarge and get libfooc102 in addition to the libfoo library they are using, and then when etch is released, they upgrade to etch, and libfoo from woody is replaced with libfoo from etch, with a completely different C++ ABI. Is this the way it will work? Do we want it? Notice that I am not talking about a direct upgrade from woody to etch. I'm talking about an upgrade woody-sarge-etch. (I suspect we could avoid it by making sure all libraries using the c102 prefix use the c2 prefix in etch.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Debian Package Customization HOWTO
On Sat, Jun 04, 2005 at 10:28:24PM -0400, Roberto C. Sanchez wrote: On Sat, Jun 04, 2005 at 08:53:06PM -0400, Kevin Mark wrote: Hi Roberto, I read it and it seems great! Haven't had a change to build anything yet but I'm sure it will help me when I do. a minor typo, search for 'since'. As someone commented, I believe pbuilder does not clean the chroot. for slow archs like arm and m68k, it would be inefficient to rebuild all the dependencies for building KDE on arm after every change, as an example. And I dont think someone making a personal packages would want to waste the time to clean it. Keep up the great work, you'll be a DD before Etch (at least I hope so) is released! [...] As far as for building personal packages, you are right. But, as the default pbuilder behavior is to wipe out the temporary chroot after every session, that should work for most people. I haven't read far enough into the docs to find out how to get it preserve the installed packages, but that is because I like being able to build in a clean environment every time and don't have an inclination to change it. But, your point is taken. I guess many people confuse pbuilder and sbuild here , two entirely different pieces of software: pbuilder untars a tarball of a clean build system, copies the source into the chroot, installs the build dependencies there, builds the package, copies the generated packages out and deletes the whole chroot sbuild uses an existing chroot, copies the source there, installs the build dependencies, builds the package, copies the generated packages out and deinstalls the build dependencies The buildds use sbuild. Most individual developers I know use pbuilder... So nothing complicated here. Just don't talk about the wrong software in the wrong context. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 03:04:45PM +0200, Petter Reinholdtsen wrote: [Matthias Klose] Details of the planned C++ ABI change can be found at http://lists.debian.org/debian-release/2005/04/msg00153.html There I find this remark: Appended is an updated version, the most notable change is to drop the 'c102' suffix from packages, if it exists. This way, we get rid off the ugly extension, and we don't support direct upgrades from woody to etch anyway. How will this work for already installed non-debian binaries. I am talking about binaries installed a long time ago by the system administrator, using the C++ ABI in woody. If this third party package depends on libfoo (with old C++ ABI, before c102 was added), how do we avoid that the program break when the machine in question is upgraded from sarge to etch? To elaborate, I talk about a machine installed with woody, where someone built their own package with some binary using the woody C++ ABI, next, they upgrade to sarge and get libfooc102 in addition to the libfoo library they are using, and then when etch is released, they upgrade to etch, and libfoo from woody is replaced with libfoo from etch, with a completely different C++ ABI. Is this the way it will work? Do we want it? Since the C++ transition *to* c102 naming involved conflicting with the previous version of the library (since the package name changed but the soname -- and therefore the filename -- did not), such third-party binaries are already unusable in sarge unless the user did not install the c102 package. So, this is only a problem for users that didn't have anything on their system which depends on the sarge version of the library. (I suspect we could avoid it by making sure all libraries using the c102 prefix use the c2 prefix in etch.) True, to the extent that it applies. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: New Debian Package Customization HOWTO
On Sun, Jun 05, 2005 at 05:32:56AM +0200, Bernd Eckenfels wrote: In article [EMAIL PROTECTED] you wrote: The official Debian packages are built by a buildd, also called build daemon, which make use of sbuild (a package similar in function to pbuilder) to ensure that every package is built in a clean environment (note: some slower architectures do not actually clean after every package build, but the concept is the same). Which is not true for binary uploads (especially on i386). Those are unfortunatelly official packages without rebuilding and without a clean environment. Which is why I finally changed it :-) Thanks. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpOH3D88NAW0.pgp Description: PGP signature
Re: New Debian Package Customization HOWTO
On Sun, Jun 05, 2005 at 03:09:02PM +0200, Frank Lichtenheld wrote: I guess many people confuse pbuilder and sbuild here , two entirely different pieces of software: pbuilder untars a tarball of a clean build system, copies the source into the chroot, installs the build dependencies there, builds the package, copies the generated packages out and deletes the whole chroot I have used both and noticed this behavior. sbuild uses an existing chroot, copies the source there, installs the build dependencies, builds the package, copies the generated packages out and deinstalls the build dependencies The buildds use sbuild. Most individual developers I know use pbuilder... OK. I was under the impression they used pbuilder. But then, IANADD, so I don't *really* know. After having used both, I found pbuilder to be more convenient, especially since Manoj gave me a recipe that automates the the whole with pdebuild from within the package source, to include the signing part. So nothing complicated here. Just don't talk about the wrong software in the wrong context. Got it. In order to avoid furhter confusion, I have removed any mention of buildds and sbuild and simply discuss the policy requirement that dictates that pacakges build with only build-essential + Build-Depends and why that is a good idea even for non-official packages. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpn4RSUzmrZw.pgp Description: PGP signature
systemware, teachware and artware from sixty dollrs
www.h63w2gh5lszow0z.wafddiwafd8.com rusions de sur gonflâtes, sur. interdites atténuâmes environnements de exacerbée pour sur descriptions les avoisina. sous longés mais internationaliser sous maintiendraient vannera les vers hardiesses détroques pour nationalisera. de caractérisez sans ce décréteriez vers fléchîmes désabonnées réhabilités au-dessuspoissait saluassions taquineriez. engraisseriez tasserais vers couguar acheminassent solutionneras, réimportais mais fientâtes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Java in Sarge
On Sat, Jun 04, 2005 at 01:06:44PM -0400, sean finney wrote: instead of trying to force people to do things your way, i would suggest that you come up with an infrastructure for making these packages that really is easier and consistant, and then say something like packages built with java must follow these guidelines. we've made this easy to do if you use these build tools. Surprise surprise, they have. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
[Matthias Klose] Pere, could you point of one of these packages? Which one? One of the packages changing name from libfoo to libfooc102 and then if this proposal goes through back to libfoo? Or one of the packages outside of debian installed on some machine somewhere? PS: No, I haven't checked if either of these package sets are non-empty. The first class of packages should be fairly easy to find, as we still have the package lists from woody and sarge available. The first class of packages is impossible to extract. :) Do you know if these package sets are non-empty? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote: The time frame of the C++ ABI changed is not yet fixed. We will certainly need some time to get the toolchain in shape to start the transition. In the meantime you can check the new compilers in unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in experimental (2.16), and the new glibc in experimental (2.3.5). What is proposed as the default C compiler for etch ? gcc-3.4 or gcc-4.0 ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote: ... - freeze unstable for uploads of library packages with new ABI versions. If a new soname is introduced now, it has to be changed a few weeks later again. Packages depending on these libraries would need to be uploaded twice as well. ... The time frame of the C++ ABI changed is not yet fixed. We will certainly need some time to get the toolchain in shape to start the transition. In the meantime you can check the new compilers in unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in experimental (2.16), and the new glibc in experimental (2.3.5). Doesn't this cause the same issue as with sarge where the transition was too early and could have been to a more recent gcc version if done later? Your release team plans a 12-18 months release cycle. This means etch will not release before the second half of 2006. It's not unlikely that gcc 4.1 will be released in 2005. The C++ ABI might change again in gcc 4.1 . If the C++ transition was half a year from now to gcc 4.1, it was still 6-12 months before the date your release team plans to release etch. Matthias cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Steve Langasek writes: On Sun, Jun 05, 2005 at 03:04:45PM +0200, Petter Reinholdtsen wrote: [Matthias Klose] Details of the planned C++ ABI change can be found at http://lists.debian.org/debian-release/2005/04/msg00153.html There I find this remark: Appended is an updated version, the most notable change is to drop the 'c102' suffix from packages, if it exists. This way, we get rid off the ugly extension, and we don't support direct upgrades from woody to etch anyway. How will this work for already installed non-debian binaries. I am talking about binaries installed a long time ago by the system administrator, using the C++ ABI in woody. If this third party package depends on libfoo (with old C++ ABI, before c102 was added), how do we avoid that the program break when the machine in question is upgraded from sarge to etch? To elaborate, I talk about a machine installed with woody, where someone built their own package with some binary using the woody C++ ABI, next, they upgrade to sarge and get libfooc102 in addition to the libfoo library they are using, and then when etch is released, they upgrade to etch, and libfoo from woody is replaced with libfoo from etch, with a completely different C++ ABI. Is this the way it will work? Do we want it? Since the C++ transition *to* c102 naming involved conflicting with the previous version of the library (since the package name changed but the soname -- and therefore the filename -- did not), such third-party binaries are already unusable in sarge unless the user did not install the c102 package. So, this is only a problem for users that didn't have anything on their system which depends on the sarge version of the library. (I suspect we could avoid it by making sure all libraries using the c102 prefix use the c2 prefix in etch.) True, to the extent that it applies. Pere, could you point of one of these packages? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 à 13:25 +0200, Matthias Klose a écrit : For etch we will update the toolchain (glibc, binutils, linux-kernel-headers, gcc) again. Some updates look easy, other will have a bigger impact on packages. One aspect of the toolchain update is the change of the C++ ABI from version 1 (102) to version 2 (1002) of the GNU C++ compiler. How is it going to affect the compatibility between Debian and Ubuntu? As I understand it, Ubuntu has started to move to G++ 4.0 without any synchronisation with the Debian toolchain maintainers. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: need help to solve celestia bug#303860
tag 303860 patch
thanks
* Mathias Weyland [Sun, 05 Jun 2005 02:38:49 +0200]:
Hi
Hello Mathias,
I'm trying to solve bug #303860 but I need some help. The problem is that
the configure script errors on sparc because it can't find the KDE
libraries. All other architechtures build fine.
You can solve this bug with the following patch (at least, celestia
got past the configure step on vore.debian.org):
--- debian/rules
+++ debian/rules
@@ -84,7 +84,7 @@
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--disable-rpath \
- --with-kde \
+ --with-kde --enable-libsuffix= \
--with-lua
touch config-kde-stamp
This workarounds a bug in admin/acinclude.m4.in which bogusly assumes
that if /lib64 exists, all libraries are to be found in lib64/
directories.
This bug was fixed upstream on 2003-03-06 [1], so I really recommend
(as Stephan mentioned) that upstream updates the admin/ directory for
celestia. If you want to do it yourself for the Debian package, you
can do this:
% dpkg-source -x celestia_1.3.2-1.dsc
% cd celestia-1.3.2
% rm -rf admin
% svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.3/kde-common/admin
% sudo apt-get install automake1.7 autoconf
% make -f admin/Makefile.common dist
HTH,
[1] svn diff -r 211698:211699 svn://anonsvn.kde.org/home/kde/
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
Listening to: Javier Álvarez - Patio
If you want the holes in your knowledge showing up try teaching someone.
-- Alan Cox
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
* Josselin Mouette | How is it going to affect the compatibility between Debian and Ubuntu? Not. | As I understand it, Ubuntu has started to move to G++ 4.0 without | any synchronisation with the Debian toolchain maintainers. Uhm, no? The plan outlined in http://lists.debian.org/debian-release/2005/04/msg00153.html is what Ubuntu is already doing. Note that some of the people involved in the Ubuntu transition are Matthias Klose and Jeff Bailey so it would be nice if you didn't go about spreading FUD like that. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 à 17:57 +0200, Tollef Fog Heen a écrit : The plan outlined in http://lists.debian.org/debian-release/2005/04/msg00153.html is what Ubuntu is already doing. Note that some of the people involved in the Ubuntu transition are Matthias Klose and Jeff Bailey so it would be nice if you didn't go about spreading FUD like that. Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. Will the next development decisions also be taken by some Canonical staff? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 06:01:33PM +0200, Josselin Mouette wrote: Le dimanche 05 juin 2005 à 17:57 +0200, Tollef Fog Heen a écrit : The plan outlined in http://lists.debian.org/debian-release/2005/04/msg00153.html is what Ubuntu is already doing. Note that some of the people involved in the Ubuntu transition are Matthias Klose and Jeff Bailey so it would be nice if you didn't go about spreading FUD like that. Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. Will the next development decisions also be taken by some Canonical staff? Yes. Canonical actually means Cabal. There. Happy now? -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 à 18:20 +0200, Wouter Verhelst a écrit : Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. Will the next development decisions also be taken by some Canonical staff? Yes. Canonical actually means Cabal. There. Happy now? Is the Cabal supposed to be the pendant of the Godwin point for Debian-related discussions? We all know there *is* a cabal, since the latest DPL election and that Vancouver proposal. Trying to shift the conversation to a supposedly legendary topic is purely rhetorical, and doesn't answer the question: Are, as of today, Canonical and its employees the sole people responsible for important technical and political decisions within the project? This is a real question, that deserves something else than there is no cabal as an answer. Debian has succeeded so far as the project was independent from any institution or company. If this changes, we're going to a dead end. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Hello Josselin, Am Sonntag, den 05.06.2005, 18:01 +0200 schrieb Josselin Mouette: Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. Will the next development decisions also be taken by some Canonical staff? could you please try to discuss problems, whatever they REALLY are in a calm an rational way? The decisions that were taken, were discussed by not just Canonical employees. Did you actually check if they make sense at all? To me it seems to be the only reasonable thing. You just heat up the discussion with your mail and get nowhere. Everybody involved in the transition does great work; such complaints just stop people, it drains motivation, what do you intend? Sorry for all this, but I just cannot stand how 3 hot-headed lines make people upset and annoy them. Have a nice day, Daniel signature.asc Description: This is a digitally signed message part
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Petter Reinholdtsen writes: [Matthias Klose] Pere, could you point of one of these packages? Which one? One of the packages changing name from libfoo to libfooc102 and then if this proposal goes through back to libfoo? Or one of the packages outside of debian installed on some machine somewhere? PS: No, I haven't checked if either of these package sets are non-empty. The first class of packages should be fairly easy to find, as we still have the package lists from woody and sarge available. The first class of packages is impossible to extract. :) As Steve did explain, the first class is a non-issue. Because you brought up the topic, I was asking you for a real-world example of your so defined second set. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
* Josselin Mouette | Oh, great. I forgot that Canonical's business model is to use Ubuntu as | an upstaging area for Debian, so that we're always lagging behind. Uhm, so you think Debian should have done the gcc 4.0 transition while in the final stages of a freeze? Do you think Ubuntu would have done this transition if we could have pushed it through Debian quicker than doing it ourselves in Ubuntu? I would rather be thankful that somebody had actually done 90% of the work already in the same way that the Ubuntu developers have been very, very happy about all the work committed by Andreas Jochens as part of his gcc3.4 and later gcc 4.0 AMD64 port. | Will the next development decisions also be taken by some Canonical | staff? They are already, but why is that relevant? Why is that a bigger problem than development decisions being taken by HP staff, Progeny staff, RedHat staff, SuSE staff, IBM staff and employees of other organisations? Debian isn't under the control of any of those organisations; that should be fairly obvious. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Adrian Bunk writes: On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote: ... - freeze unstable for uploads of library packages with new ABI versions. If a new soname is introduced now, it has to be changed a few weeks later again. Packages depending on these libraries would need to be uploaded twice as well. ... The time frame of the C++ ABI changed is not yet fixed. We will certainly need some time to get the toolchain in shape to start the transition. In the meantime you can check the new compilers in unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in experimental (2.16), and the new glibc in experimental (2.3.5). Doesn't this cause the same issue as with sarge where the transition was too early and could have been to a more recent gcc version if done later? which issue? It's not unlikely that gcc 4.1 will be released in 2005. The C++ ABI might change again in gcc 4.1 . the world might become flat again. If the C++ transition was half a year from now to gcc 4.1, it was still 6-12 months before the date your release team plans to release etch. If it's 6 month before the release, it's definitely too late. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 06:32:10PM +0200, Josselin Mouette wrote: Are, as of today, Canonical and its employees the sole people responsible for important technical and political decisions within the project? 1) No. There are a number of people who are in charge of important technical decisions who have no more association with Canonical than you or I do. I'm sure if you stop ranting for a moment and think about it you can name some of them yourself. 2) This is completely off-topic for this thread, which is potentially both important and productive. I'm setting MFT appropriately. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 à 18:34 +0200, Daniel Holbach a écrit : Hello Josselin, Am Sonntag, den 05.06.2005, 18:01 +0200 schrieb Josselin Mouette: Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. Will the next development decisions also be taken by some Canonical staff? could you please try to discuss problems, whatever they REALLY are in a calm an rational way? The decisions that were taken, were discussed by not just Canonical employees. Did you actually check if they make sense at all? To me it seems to be the only reasonable thing. The problem is that the decisions are always taken for the Ubuntu distribution first. Then, people from Canonical or people wanting to keep compatibility between the two distributions will always want Debian to follow the decisions taken for Ubuntu, regardless of their technical merit and relevance for Debian. This way, Debian ends up being lead by Canonical, and always lagging behind. Actually, you can just look at what happens and see this is already the case. Many packages in Debian are lagging behind Ubuntu, and Ubuntu-specific patches are not forwarded to Debian maintainers, regardless of the declarations. You can also see that the only architectures supposed not to be dropped from testing in the Vancouver proposal are the architectures Ubuntu supports. Is it a coincidence? I'd like to think so. I'm not saying that for this particular decision, it wasn't the right thing to do. I'm questioning the independence of the project as a whole for important technical decisions. Debian has always been superior because we used to take the time to evaluate solutions and keep the best one, technically speaking. If we merely follow Ubuntu, decisions won't be only based on technical merits, but also on political and economical ones. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Canonical and Debian
On Sun, Jun 05, 2005 at 06:32:10PM +0200, Josselin Mouette wrote: Le dimanche 05 juin 2005 ? 18:20 +0200, Wouter Verhelst a ?crit : Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. Will the next development decisions also be taken by some Canonical staff? Yes. Canonical actually means Cabal. There. Happy now? Is the Cabal supposed to be the pendant of the Godwin point for Debian-related discussions? We all know there *is* a cabal, since the latest DPL election and that Vancouver proposal. Trying to shift the conversation to a supposedly legendary topic is purely rhetorical, and doesn't answer the question: Are, as of today, Canonical and its employees the sole people responsible for important technical and political decisions within the project? If you're going to complain about a cabal, please do try to get the facts straight: The DPL team consists of only one Canonical employee, who was even later, after the election, added (Benjamin Mako Hill), and in Vancouver, again there was only one[1] single Canonical employee present (James Troup). All the others involved with either of those two groups are not involved in Canonical at all, and only one or two are marginally involved in Ubuntu. This is a real question, that deserves something else than there is no cabal as an answer. Debian has succeeded so far as the project was independent from any institution or company. If this changes, we're going to a dead end. All the teams that are occasionally accused of cabalistic characteristics are composed of a diverse group of DD's, and I dare say that they are composed of a group of DD's that simply have shown genuine interest and constructive contributions to the team's goal at hand. In other words, those teams consist of those doing the work. I'll be the first to admit that indeed the admittance to such teams might be a bit obscure to those not following closely what's happening, but if someone's genuinly interested in contributing to any particular task, there's always a lot to do also for relatively outsiders, and that's the way you can show competence and make a step towards joining. If you believe that it is impossible, I can assure you I've doing exactly the above. Considering I've started my NM process beginning of 2004, hardly knowing any other DD, and I'm a DD for less than half a year now, I think one can say it can't be that bad. For what it's worth, I did feel and do still feel that some parts of Debian are too obscure to join and contribute to, it's not that I don't think that can be improved. One of the things I've done to try to improve the situation, was mobilizing a group of somewhat-like-minded people in the form of a DPL team. I know results so far are sparse, especially seeing we're approaching 2 months since the election now, but releasing Sarge has drained a significant amount of energy of a number of people so far :-/. I plan to give more attention to this stuff real soon now, and also in Helsinki, I hope a number of brainstorm sessions on issues like this will result in good and new idea's on various subjects. As always, constructive idea's and posts about issues in Debian not running as smoothly as they maybe could are always appreciated, but just complaining about being doomed with Canonical ruling Debian, or something like that, is not constructive at all, rather, it'll only hurt cooperation. And isn't cooperation one of the founding reasons for the Open Source movement, that one can share idea's and code, in order to all together make the greatest software about? Thanks for listening, --Jeroen [1] Colin Watson was not present, but indeed he was one of the supporters of the Vancouver proposal too, so that makes 3 -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
Le dimanche 05 juin 2005 à 19:00 +0200, Jeroen van Wolffelaar a écrit : If you're going to complain about a cabal, please do try to get the facts straight: The DPL team consists of only one Canonical employee, who was even later, after the election, added (Benjamin Mako Hill), and in Vancouver, again there was only one[1] single Canonical employee present (James Troup). All the others involved with either of those two groups are not involved in Canonical at all, and only one or two are marginally involved in Ubuntu. Then how did these people end up choosing to support the same set of architectures as Ubuntu? I know this has been discussed to death, but I still fail to see which problems in Debian the Vancouver proposal can actually solve. All the teams that are occasionally accused of cabalistic characteristics are composed of a diverse group of DD's, and I dare say that they are composed of a group of DD's that simply have shown genuine interest and constructive contributions to the team's goal at hand. In other words, those teams consist of those doing the work. I'll be the first to admit that indeed the admittance to such teams might be a bit obscure to those not following closely what's happening, but if someone's genuinly interested in contributing to any particular task, there's always a lot to do also for relatively outsiders, and that's the way you can show competence and make a step towards joining. If you want to contribute to GNOME packaging, you know what to do: contribute enough patches and uploads, and you'll end up having a subversion access very quickly. This is the case for most maintenance teams in the project, and I doubt you can say they have cabalistic characteristics. Now, please tell me what I can do so that all architectures in sarge are supported in etch. Or what I could have done so that amd64 was included in sarge. These decisions were taken by closed groups, without any care for their actual technical merits, and against the will of most developers. And there's nothing I can do to contribute to these decisions. As always, constructive idea's and posts about issues in Debian not running as smoothly as they maybe could are always appreciated, but just complaining about being doomed with Canonical ruling Debian, or something like that, is not constructive at all, rather, it'll only hurt cooperation. And isn't cooperation one of the founding reasons for the Open Source movement, that one can share idea's and code, in order to all together make the greatest software about? As long as the cooperation is about making Debian the best operating system ever, I'm fine with that. But given the behavior of some people occupying key positions in the project, I'm wondering if that's really what they're aiming for. Let's just say that, in its current state, the Debian project still fails the tentacle of evil test. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, 2005-06-05 at 17:36 +0200, Josselin Mouette wrote: How is it going to affect the compatibility between Debian and Ubuntu? As I understand it, Ubuntu has started to move to G++ 4.0 without any synchronisation with the Debian toolchain maintainers. Huh?! If I'm not mistaken, couple of hours ago I offerd you colaboration on hdf5 source. I contacted you for you plans, to even work together. You asked me to stop with my work, so your package would be in both distributions. I said ok. You make calls, not anyone from Ubuntu. I offered you patches for g++ 4.0, remember? Let's all calm down and start working together. If no one else, I'm very interested and devoted to compatibilty between Debian and Ubuntu. Peace? -- Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225 http://master.grad.hr/~ivoks/|--|ICQ: 64631782 May, 15. herve we're fixing the universe, it's not an easy duty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 05:12:46PM +0200, Matthias Klose wrote: Adrian Bunk writes: On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote: ... - freeze unstable for uploads of library packages with new ABI versions. If a new soname is introduced now, it has to be changed a few weeks later again. Packages depending on these libraries would need to be uploaded twice as well. ... The time frame of the C++ ABI changed is not yet fixed. We will certainly need some time to get the toolchain in shape to start the transition. In the meantime you can check the new compilers in unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in experimental (2.16), and the new glibc in experimental (2.3.5). Doesn't this cause the same issue as with sarge where the transition was too early and could have been to a more recent gcc version if done later? which issue? It's not unlikely that gcc 4.1 will be released in 2005. The C++ ABI might change again in gcc 4.1 . the world might become flat again. The issue with sarge is that it ships with gcc 3.3 as default compiler although it could have shipped with gcc 3.4 . The issue with etch is that there might be enough time to wait for gcc 4.1 before doing the transition and immediately go to gcc 4.1 then. Shipping sarge with gcc 3.3 and etch with gcc 4.0 doesn't the world stop from turning. But as far as I can see the big batch of work is the transition. And if one transition can be a bigger step forwards, that doesn't sound like a bad idea. If the C++ transition was half a year from now to gcc 4.1, it was still 6-12 months before the date your release team plans to release etch. If it's 6 month before the release, it's definitely too late. Silly question: Why? I see the following critical tasks of a gcc transition (you have to change gcc-defaults and perhaps a few other things, but they shouldn't cause any problems): 1. ensure that the whole archive builds with the new default compiler 2. doing the C++ transition The C++ transition seems to be the easier part, since it mostly requires updating all C++ libraries and packages using C++ libraries. This is a serious amount of packages, but it's pretty straightforward. Reagarding the first part, gcc 3.4 and 4.0 compile errors are already reported in the BTS and hopefully resolved pretty soon. And unless the C or C++ frontends of gcc 4.1 will reject a serious amount of code their gcc 4.0 counterparts accepted, this should only generate a manageable amount of problems. Yes, a gcc transition takes some time. But with the experiences of the sarge transition to gcc 3.2 and the Ubunto transition to gcc 4.0, where exactly in the transition do you expect problems that couldn't be solved within 2 or 3 months after the start of the transition? And whether I like it or not, the resulting three months before the release would still be before the start of the first part of the freeze in the schedules of your release team. Matthias cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsubscribe
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
What we can learn from Canonical/Ubuntu
#include hallo.h * Josselin Mouette [Sun, Jun 05 2005, 06:32:10PM]: Le dimanche 05 juin 2005 à 18:20 +0200, Wouter Verhelst a écrit : This is a real question, that deserves something else than there is no cabal as an answer. Debian has succeeded so far as the project was independent from any institution or company. If this changes, we're going to a dead end. Really? IMO it is exactly the lack of authority and strong top management that has lead us into the current situation. Take it as is: Woody release was a real misery, and Sarge's close to a fiaco (sligthly exxagerating). What's the reason? IMO simple: we cannot synchronise our actions properly. This happens because of missing motivation, but this is a side effect of the real reason: having no concrete tasks, no concreate plans or scedules. And no authorities that would give the answers (even worse, official or pseudo authorities hiding and avoiding to have to answer, you know whom I am talking about). The dead end expects Debian because of people not wanting to take responsibility and people that act irrational (eg. too risky in task scheduling issues, time calculations) because they know they can afford it, not having to take any responsibility. Are you jealous of Ubuntu because they have more success then Debian? Why about seeing them as a software experiment and learning from them? We would learn following things: - a hard release schedule is neccessary. Everyone needs to know _when_ the job is to done, there must be a clear deadline. Even if there is just small leeway for delay, people will be unable to schedule their work. We have seen that before, again and again, even AJ has complained about that. We should stop compensating this shit with stretching the release period, again and again. - we need to priorize packages and architectures. Second class may sound bad we need it to make the core system thin enough to become release in timely manner. Keep the best, drop the rest (or move it to separated archives). We cannot have every piece of software in the world in Debian and guarantee a high quality level. Remember the numbers of upstream bugs that we have in our stable all the time. After view months it simply outnumbers the potential risks from having an upgrade. So recommending Debian Stable as production system has become pure farce in the last months, because it is either buggy (upstream bugs) or incompatible == unuseable because of hardware issues (outdated software) or compatibility with newer developments. What I mean: Debian has become a no-no for productive environment for the majority of users out there (and please do not come with works for me on ..., it is not very representative). Regards, Eduard. -- Ein reicher Mann ist oft nur ein armer Mann mit sehr viel Geld. signature.asc Description: Digital signature
Re: Canonical and Debian
On Sun, Jun 05, 2005 at 07:15:49PM +0200, Josselin Mouette wrote: Le dimanche 05 juin 2005 à 19:00 +0200, Jeroen van Wolffelaar a écrit : If you're going to complain about a cabal, please do try to get the facts straight: The DPL team consists of only one Canonical employee, who was even later, after the election, added (Benjamin Mako Hill), and in Vancouver, again there was only one[1] single Canonical employee present (James Troup). All the others involved with either of those two groups are not involved in Canonical at all, and only one or two are marginally involved in Ubuntu. Then how did these people end up choosing to support the same set of architectures as Ubuntu? I know I've been screaming murder and hell about this, but in hindsight, after having read the proposers' explanations (and the proposal itself for a few more times), this certainly is not what they're proposing. The whole thing is confusing, because the one nybbles mail talks about multiple things, and it's easy to mix those up. But in reality, the nybbles proposal suggests that we do the following: * Split the architectures over two sets of mirror networks, so that mirror administrators don't need 100G just to mirror Debian anymore. This has nothing to do with what architectures can release a stable and what architectures cannot; only with mirror bandwidth and disk space usage. The popularity of an architecture will be a deciding factor in the decision of what archive mirror network will be used, but there's of course nothing wrong with that; architectures would be allowed to create a stable release on that second-class mirror network, and that's what counts. * Create a set of rules that an architecture has to abide by in order to be allowed to release. This set of rules would be there to make sure that a port's porters, rather than the set of release managers, ftp masters and the like, do all the work in making the port work. Provided that set of rules is sensible (which I'm not entirely sure of right now, but that can be fixed), there's nothing wrong with such a suggestion. While it is indeed very likely that only amd64, i386, and (perhaps) powerpc fall in the first thread, the same is very much not true for the second set. I know this has been discussed to death, but I still fail to see which problems in Debian the Vancouver proposal can actually solve. Then I suggest you go back and read the vancouver proposal one more time, keeping the above in mind. [...] -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
The story of speex/vorbis-tools, or how not to be disservicing to our users
Hello, [I'm sending this to three lists. Please only reply to -devel unless the answer is on-topic for some of the others.] This mail is about making people aware of how actions aimed at improving Debian, like providing a new version of a library or NMUing a package, can have negative effects too, and how can everybody (even the casual -devel reader) help to minimize such effects. For that, I will use what recently happened with vorbis-tools and speex as a example. This is not a personal rant, since I don't use any of the affected software, but I do care about the overall quality of Debian and seeing this things happen saddens me a lot. Which is why I decided to write this e-mail. None of this is about finding out who was at fault, since we all make mistakes. It's just about answering what can I do better, which I think everybody asks themselves from time to time. * * * The story = The Speex library made, among others, the following change between 1.0 and 1.1: its speex.h file moved from /usr/include to /usr/include/speex. After libspeex 1.1 had been uploaded, a new upload of the vorbis-tools package happened (an authorized NMU, to be precise). When this new version was compiled against speex 1.1, the ./configure script failed to detect the availability of speex, and thus disabled speex support. A bug about ogg123 not being able to reproduce .spx files any more was filed at severity important 9 days after the upload (#306809). One month later, a message was sent to d-devel [1] explaining the situation. I read the message a couple days later, and promptly uploaded a NMU to fix (with maintainer's permission). Unfortunately, it was too late for it to be included in Sarge. Net result: ogg123 as shipped in Sarge can't play speex files, while the software is capable of doing so and so was the case during most of the Sarge development cycle. [1] http://lists.debian.org/debian-devel/2005/06/msg00035.html * * * The analysis So let's have a look from several point of views at what can be done better in order to prevent things like this happening, Library maintainers --- Please treat the maintainers of packages build-depending on your library as first-class users. Try to always be aware of what consequences will your acts have for them, and communicate when necessary. For example, for the above change between speex 1.0 and 1.1, a notice could have been sent (and perhaps it was) to the affected maintainers making them aware of the issue. Such notice is best sent in the form of a bug in the BTS, so that other people (e.g., NMUers) can know about the issue too. If you're certain that the issue will bite a package in the next upload, file the bug at severity important or higher. For example: vorbis-tools: auto-detection of libspeex will fail in the next upload. Coordinate with the Release Team. Package maintainers --- Try to make your build system as robust and deterministic as possible, as in, avoid if possible that it produces different binaries for different sets of installed packages. For example, explicitly using --with-something will make ./configure fail if it can't find it, while not specifying it would just result on the script disabling that part. Know the output of your ./configure script, and baby-sit new builds looking for differences. Even better, use the resulting config.h file: always compare the new one with the previous one. Consider putting it in the source package, e.g. debian/config.h.prev, so that NMUers can benefit from it too. (I don't think this has been proposed before, and makes absolute sense to me.) Run debdiff. Inactive package maintainers Know your limitations, and file RFH/RFA/O bugs as appropriate. Just welcoming NMUs is not enough, since then you rely on the MIA people discovering someday that your package is unmaintained. NMUers -- Read the whole list of bugs for the package before you upload, not only the ones you'll be fixing. See above under Library maintainers for an example of this being useful. Subscribe to the PTS of the package. This way, you'll become aware of any new bugs you've accidentally introduced (as the mentioned #306809). Run debdiff. Twice. The casual -devel reader If you see a message about an important issue not being handled, try to do something about it. Think whom could you forward it to: the maintainer, the latest uploaders, the maintainers of related packages, an specific mailing list or IRC channel. It's all about finding a developer that will care. If you know that a maintainer is
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 06:50:57PM +0200, Josselin Mouette wrote: The problem is that the decisions are always taken for the Ubuntu distribution first. There's two reasons why this could be happening: * There's a master plan over at Canonical to try and take over Debian. * For every step someone tries to make in Debian, a two-month long flame has to happen on this very list. As a result, nobody is motivated to do /anything/, because nobody likes to be flamed. Pick your bets. ... Rien ne va plus. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond signature.asc Description: Digital signature
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 ? 13:25 +0200, Matthias Klose a ?crit : For etch we will update the toolchain (glibc, binutils, linux-kernel-headers, gcc) again. Some updates look easy, other will have a bigger impact on packages. One aspect of the toolchain update is the change of the C++ ABI from version 1 (102) to version 2 (1002) of the GNU C++ compiler. How is it going to affect the compatibility between Debian and Ubuntu? As I understand it, Ubuntu has started to move to G++ 4.0 without any synchronisation with the Debian toolchain maintainers. I think that no Ubuntu action should matter when we are about Debian quality. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Leadership, collaboration and canoncial
Josselin Mouette wrote: The problem is that the decisions are always taken for the Ubuntu distribution first. Then, people from Canonical or people wanting to keep compatibility between the two distributions will always want Debian to follow the decisions taken for Ubuntu, regardless of their technical merit and relevance for Debian. This way, Debian ends up being lead by Canonical, and always lagging behind. I know i'm going to regret saying this, but someone has to lead the way. if none of the current Debian developers step up to the task, someone else has to. This has nothing to do with canonical or ubuntu for that matter. This applies to all projects and businesses out there. Actually, you can just look at what happens and see this is already the case. Many packages in Debian are lagging behind Ubuntu, and Ubuntu-specific patches are not forwarded to Debian maintainers, regardless of the declarations. This would be because the Ubuntu developers are rather afraid of doing a full scale patch distribution to debian developers due to the fact that some developers have already declared that they do not want these patches. This is a huge problem for the ubuntu developers as some people insist on getting the patches automatically, some don't care either way and others are angered by people meddling with their packages and don't want the patches. My question to you is: what would you do? How would you solve this problem? The patches are out there, you can fetch them. If you want your patches, contact ubuntu developers and ask for them. I'm sure they are happy to give their patches to your packages and embrace your suggestions. Collaboration is the way, not hostility! You can also see that the only architectures supposed not to be dropped from testing in the Vancouver proposal are the architectures Ubuntu supports. Is it a coincidence? I'd like to think so. I don't thing it is a coincidence! I even think that it is a straight consequence of ubuntu's influence. But not because they say it should be kept, it's because they work on it too. They provide patches, do autocompilation and testing on the packages. That in turn helps the archs in Debian too. In the proposal there was a clear outline of what archs should be kept, it's not a coincidence that those archs happen to be the same popular architechtures that ubuntu ships for. There is no conspiracy, Debian is not being taken over. I'm not saying that for this particular decision, it wasn't the right thing to do. I'm questioning the independence of the project as a whole for important technical decisions. Debian has always been superior because we used to take the time to evaluate solutions and keep the best one, technically speaking. If we merely follow Ubuntu, decisions won't be only based on technical merits, but also on political and economical ones. Lately i've failed to see those evaluations, everyone just work for their own benefit. There are just a handful of groups that work towards a common goal. GNOME and KDE teams to name some. Others mostly work just with their own package. Even though i don't like the Vancouver proposal, i see the issues it addresses. One of the issues being the fact that Sarge would never be ready for release if the unmaintained architechtures weren't dropped. Other issue would be the lack of guidelines. The proposal gives one guideline: How to get your favourite Architecture supported in a release. As for the C++ transition, i was given the impression when i first saw the proposal was that Ubuntu developers asked for the approval of this proposal from the debian developers. And with a little work, i can find references to the transition on debian lists that propose the same scheme that ubuntu is now using, before they began using it. Personally i feel that Debian Developers should put their jealousy aside, burry the hatchet and start collaborating with the other developers out there, not just ubuntu. Besides, you have given your work out to the public for anyone to use, anyone to modify, anyone to create derivates from. Why not try and benefit from that symbiosis. - S -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The story of speex/vorbis-tools, or how not to be disservicing to our users
On Sun, Jun 05, 2005 at 08:38:07PM +0200, Adeodato Simó wrote: Library maintainers --- Please treat the maintainers of packages build-depending on your library as first-class users. Try to always be aware of what consequences will your acts have for them, and communicate when necessary. Since not everyone subscribes to d-d, is there a n easy way to do this? Would a change in a library that is officially depended on by more than X packages qualify to be sent out via d-d-a? Or does there is exist some alias that a library maintainer could a mail to? For example, if I maintain a library with a source package name of foo and I could send a message to [EMAIL PROTECTED] and the system could figure out, based on the maintainer info kept for each package, a list of email addresses, that would be very nice. That way, by sending one message, the maintainers of all dependent packages ar notified. This would be especially good for packages which have many dependents. Just my $.02. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr pgpVSE94E3p4i.pgp Description: PGP signature
Bug#306809: Info received and FILED only (was The story of speex/vorbis-tools, or how not to be disservicing to our users)
Thank you for the additional information you have supplied regarding this problem report. It has NOT been forwarded to the package maintainers, but will accompany the original report in the Bug tracking system. Please ensure that you yourself have sent a copy of the additional information to any relevant developers or mailing lists. If you wish to continue to submit further information on your problem, please send it to [EMAIL PROTECTED], as before. Please do not reply to the address at the top of this message, unless you wish to report a problem with the Bug-tracking system. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Leadership, collaboration and canoncial
On Sun, Jun 05, 2005 at 10:03:35PM +0300, Sami Haahtinen wrote: Personally i feel that Debian Developers should put their jealousy aside, burry the hatchet and start collaborating with the other developers out there, not just ubuntu. Besides, you have given your work out to the public for anyone to use, anyone to modify, anyone to create derivates from. Why not try and benefit from that symbiosis. Agree, and also possibly work more and flame less. I found a good deal of traffic on this list in the last years^Wperiod not too far from trolling, for contents and usefulness. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The story of speex/vorbis-tools, or how not to be disservicing to our users
On Sun, Jun 05, 2005 at 03:08:48PM -0400, Roberto C. Sanchez wrote: Since not everyone subscribes to d-d, is there a n easy way to do this? Would a change in a library that is officially depended on by more than X packages qualify to be sent out via d-d-a? Or does there is exist some alias that a library maintainer could a mail to? For example, if I maintain a library with a source package name of foo and I could send a message to [EMAIL PROTECTED] and the system could figure out, based on the maintainer info kept for each package, a list of email addresses, that would be very nice. That way, by sending one message, the maintainers of all dependent packages ar notified. This would be especially good for packages which have many dependents. You can easily find rdepends for your packages. Sending mass mails to communicate with their maintainers is easy as well. I did that sometimes for libraries I maintain, whenever needed. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312126: ITP: libsvg-ruby -- SVG generation library for Ruby
Package: wnpp Severity: wishlist Owner: Paul van Tilburg [EMAIL PROTECTED] * Package name: libsvg-ruby Version : 1.0.3 Upstream Author : Yuya Kato [EMAIL PROTECTED] * URL : http://ruby-svg.sourceforge.jp/ * License : LGPL Description : SVG generation library for Ruby This library allows you to use a simple class/object interface to generate a valid SVG (Scalable Vector Graphic) file in a very simple and intuitive way. I've actually already created the package, but what to consult with upstream for a small issue and write documentation before uploading. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (102, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.10-powerpc Locale: LANG=C, [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 à 20:40 +0200, Wouter Verhelst a écrit : On Sun, Jun 05, 2005 at 06:50:57PM +0200, Josselin Mouette wrote: The problem is that the decisions are always taken for the Ubuntu distribution first. There's two reasons why this could be happening: * There's a master plan over at Canonical to try and take over Debian. * For every step someone tries to make in Debian, a two-month long flame has to happen on this very list. As a result, nobody is motivated to do /anything/, because nobody likes to be flamed. Pick your bets. And you're the one to tell I'm spreading FUD? Real improvement comes from actual work on packages, not from discussion here. The only cases where improvement can't be brought are when adequate people cannot do the work for political reasons. You don't *have* to discuss all matters on this list. I believe it is here to give advice, not to make decisions. Decisions are taken by maintainers - or by the technical committee. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 10:37:08PM +0200, Josselin Mouette wrote: Le dimanche 05 juin 2005 à 20:40 +0200, Wouter Verhelst a écrit : On Sun, Jun 05, 2005 at 06:50:57PM +0200, Josselin Mouette wrote: The problem is that the decisions are always taken for the Ubuntu distribution first. There's two reasons why this could be happening: * There's a master plan over at Canonical to try and take over Debian. * For every step someone tries to make in Debian, a two-month long flame has to happen on this very list. As a result, nobody is motivated to do /anything/, because nobody likes to be flamed. Pick your bets. And you're the one to tell I'm spreading FUD? Where did I say FUD? Real improvement comes from actual work on packages, not from discussion here. The only cases where improvement can't be brought are when adequate people cannot do the work for political reasons. You don't *have* to discuss all matters on this list. I believe it is here to give advice, not to make decisions. Decisions are taken by maintainers - or by the technical committee. Indeed. So what is your quarrel with Ubuntu? If decisions are made by maintainers rather than this list, they are also made by maintainers rather than Canonical employees. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Sun, Jun 05, 2005 at 09:17:26AM +0200, Andreas Tille wrote: I have to admit that I was not aware that there is something in parallel in this universe that the Debian mirrors which is providing *.deb packages of free software. This seems incredible to me. What did you mean by this? You have never heard of Knoppix, Morphix, Xebian, or the huge number of other, similar distributions? apt-get.org? Christian Marillat's repository of packages? My impression was that Ubuntu would directly derive from sid and universe would be kind of a sid mirror. Ubuntu is a derivative of Debian; this is what it has always been. It is different from some other derivatives in that it is derived at the source level, and does not use binary packages from Debian. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
Le dimanche 05 juin 2005 à 22:55 +0200, Wouter Verhelst a écrit : And you're the one to tell I'm spreading FUD? Where did I say FUD? Sorry, that was Tollef. Real improvement comes from actual work on packages, not from discussion here. The only cases where improvement can't be brought are when adequate people cannot do the work for political reasons. You don't *have* to discuss all matters on this list. I believe it is here to give advice, not to make decisions. Decisions are taken by maintainers - or by the technical committee. Indeed. So what is your quarrel with Ubuntu? If decisions are made by maintainers rather than this list, they are also made by maintainers rather than Canonical employees. There are decisions that can't be made by maintainers. In these cases this list often ends up being the place where solutions are discussed while they'll never be applied, just because someone competent and willing to apply them wouldn't be allowed to do so. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: This is a digitally signed message part
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
David Nusinow writes: No. There are a number of people who are in charge of important technical decisions who have no more association with Canonical than you or I do. I'm sure if you stop ranting for a moment and think about it you can name some of them yourself. You are assuming that everyone has been paying close attention to Ubuntu and it's activities. While I have the impression that many Debian senior developers are involved with it, I can name only one who I am sure is and one who I am sure isn't. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Sun, Jun 05, 2005 at 10:49:27AM +0100, Stephen Birch wrote: On Sat, 2005-06-04 at 20:38 +0200, Daniel Holbach wrote: * The handling of NEW packages and in which cases to file an ITP. * How to retrieve patches in the easiest way. * How to start group maintenance. Maybe there are other issues, I missed in the thread. How to report bugs. Do we really need to separate bug tracking mechanisms? We don't necessarily need separate bug tracking systems, but in order to share a bug tracking system, the system would need to make it convenient to work in the context of a particular distribution (e.g., for a Debian developer to avoid seeing Ubuntu-specific bugs in query results). I don't think there exists a bug tracking system which meets this need today, which is why Canonical is developing a bug tracking system which is designed to meet the needs of open source projects collaborating with each other on common code bases (Malone). -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve kernel-image packages built against 2.6.8-16 are available Steve in sarge for the past week or so for i386, alpha, and ia64. [...] Steve In light of the announcement at the beginning of May that Steve sarge is security-supported, I think it would be a good Steve idea for any DSAs issued over these holes to include Steve mention of the relevant kernel versions for i386 etc., so Steve that users who have upgraded earlier know that they need to Steve upgrade and reboot. I think it would also be a good idea if the change log in the kernel-image package could mention any DSAs fixed... The changelog I have says: --- cut --- kernel-image-2.6.8-i386 (2.6.8-16) unstable; urgency=low * Fix up AMD descriptions to include CPU name. Thanks to J. Grant. (Simon Horman) * Removed for those who want the latest ... from header package descriptons as this is what packages from kernel-latest-2.6-i386 do. (Simon Horman) * Build against kernel-tree-2.6.8-16. (Simon Horman) * Add myself as an uploader. (Simon Horman) -- Simon Horman [EMAIL PROTECTED] Thu, 19 May 2005 16:52:19 +0900 kernel-image-2.6.8-i386 (2.6.8-15) unstable; urgency=high * Build against 2.6.8-15. -- Andres Salomon [EMAIL PROTECTED] Tue, 22 Mar 2005 12:39:59 -0500 --- cut --- This still leaves me confused if it fixed the problem or not. I guess I am expected to cross reference this with the changelog of the kernel-source package. What is the kernel-tree-2.6.8-16 package? Or is this an abbreviation for kernel-tree-2.6.8 version 2.6.8-16? Does this imply kernel-source version 2.6.8-16? Again, I think it would be much quicker, easier, and less prone to errors if the DSAs where mentioned in the relevant kernel-image-change too. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On Sun, Jun 05, 2005 at 07:15:49PM +0200, Josselin Mouette wrote: All the teams that are occasionally accused of cabalistic characteristics are composed of a diverse group of DD's, and I dare say that they are composed of a group of DD's that simply have shown genuine interest and constructive contributions to the team's goal at hand. In other words, those teams consist of those doing the work. I'll be the first to admit that indeed the admittance to such teams might be a bit obscure to those not following closely what's happening, but if someone's genuinly interested in contributing to any particular task, there's always a lot to do also for relatively outsiders, and that's the way you can show competence and make a step towards joining. If you want to contribute to GNOME packaging, you know what to do: contribute enough patches and uploads, and you'll end up having a subversion access very quickly. This is the case for most maintenance teams in the project, and I doubt you can say they have cabalistic characteristics. Now, please tell me what I can do so that all architectures in sarge are supported in etch. Clone yourself and make yourself a slave to the buildds for 7 or 8 architectures, so that the release team doesn't have to. Neither the release team nor the FTP team is interested in being responsible for keeping all of these architectures afloat. You can either step up and make sure the architectures you care about are in good shape for etch, or you can be a whiny brat expecting everything to be handed to you on a silver platter and accusing people of being members of a Canonical-controlled cabal when they do you the courtesy of informing you about their personal priorities for etch. Your choice. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#311795: ITP: rast -- A full text search system
Could you please explain what is N-gram and what is this package useful for? N-gram is when you use n-characters as a 'word'. In some languages including Japanese, it is impossible to determine a 'word', and N-gram is a method that defines a 'word' as n-characters. Do you mean N number of characters, or is there some special meaning to an n-character? I mean N number of characters, yes. Instead of picking up keywords through whitespace-separated 'word's, it uses pre-set N number of characters for indexing. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 06:01:33PM +0200, Josselin Mouette wrote: Le dimanche 05 juin 2005 à 17:57 +0200, Tollef Fog Heen a écrit : The plan outlined in http://lists.debian.org/debian-release/2005/04/msg00153.html is what Ubuntu is already doing. Note that some of the people involved in the Ubuntu transition are Matthias Klose and Jeff Bailey so it would be nice if you didn't go about spreading FUD like that. Oh, great. I forgot that Canonical's business model is to use Ubuntu as an upstaging area for Debian, so that we're always lagging behind. The outline for this C++ transition was run past debian-release@ well before anything happened in Ubuntu, precisely to avoid painful desynchronisation between the two distributions, and to make sure that everyone could have a say before anything happened in either distribution. The people doing the work were pretty much the same people who did the work last time, anyway; I can't see how you'd do a C++ transition without having, say, the lead gcc maintainer involved ... In mid-April, very little active development was happening on Ubuntu due to conference timings, so it's likely that the transition would have taken place in Debian first if we hadn't been in the middle of a deep freeze (which thank God is finally coming to a close). The Ubuntu development team took the decision not to wait, because it was clearly better to make the change as close to the beginning of a release cycle as possible in order to have as much time as possible to clean up any resulting problems. This had nothing to do with fictional business models and everything to do with straightforward practical release management. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames
On Sun, Jun 05, 2005 at 02:35:10PM -0500, John Hasler wrote: David Nusinow writes: No. There are a number of people who are in charge of important technical decisions who have no more association with Canonical than you or I do. I'm sure if you stop ranting for a moment and think about it you can name some of them yourself. You are assuming that everyone has been paying close attention to Ubuntu and it's activities. While I have the impression that many Debian senior developers are involved with it, I can name only one who I am sure is and one who I am sure isn't. Not everyone. Just the people who fly off the handle and make fairly mean-spirited accusations. I see some of the merit to what he's saying: that we shouldn't become beholden to Canonical. But claiming that the Canonical employees are trying to destroy Debian is just being excessively harsh. These same people are Debian Developers who care deeply about the project, and I can imagine how they feel seeing these kinds of flames. A constructive thread is going on elsewhere on this list for mediating the problems between Ubuntu and Debian, and I'd rather see more of that. This sort of thing is just the usual stuff that's harmful to the project and hateful to its own constituents. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#311795: ITP: rast -- A full text search system
At Mon, 06 Jun 2005 09:12:28 +0900, Junichi Uekawa wrote: Instead of picking up keywords through whitespace-separated 'word's, it uses pre-set N number of characters for indexing. I had a presentation about full-text search engines in Debian, see the following, and it describe about N-gram based search engine: http://www.daionet.gr.jp/~knok/materials/admc2005.sxi BTW, there is the n-gram word in libdigest-nilsimsa-perl package's description without explain of the word. -- NOKUBI Takatsugu E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] / [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel security bug #307900
On Mon, Jun 06, 2005 at 08:28:17AM +1000, Brian May wrote: Steve == Steve Langasek [EMAIL PROTECTED] writes: Steve kernel-image packages built against 2.6.8-16 are available Steve in sarge for the past week or so for i386, alpha, and ia64. [...] Steve In light of the announcement at the beginning of May that Steve sarge is security-supported, I think it would be a good Steve idea for any DSAs issued over these holes to include Steve mention of the relevant kernel versions for i386 etc., so Steve that users who have upgraded earlier know that they need to Steve upgrade and reboot. I think it would also be a good idea if the change log in the kernel-image package could mention any DSAs fixed... The changelog I have says: --- cut --- I guess I am expected to cross reference this with the changelog of the kernel-source package. Yeah, at this point that's the process. What is the kernel-tree-2.6.8-16 package? Or is this an abbreviation for kernel-tree-2.6.8 version 2.6.8-16? Does this imply kernel-source version 2.6.8-16? $ apt-cache show kernel-tree-2.6.8 Package: kernel-tree-2.6.8 Priority: optional Section: devel Installed-Size: 56 Maintainer: Debian kernel team debian-kernel@lists.debian.org Architecture: all Source: kernel-source-2.6.8 Version: 2.6.8-16 Provides: kernel-tree-2.6.8-1, kernel-tree-2.6.8-10, kernel-tree-2.6.8-11, kernel-tree-2.6.8-12, kernel-tree-2.6.8-13, kernel-tree-2.6.8-14, kernel-tree-2.6.8-15, kernel-tree-2.6.8-16, kernel-tree-2.6.8-2, kernel-tree-2.6.8-3, kernel-tree-2.6.8-4, kernel-tree-2.6.8-5, kernel-tree-2.6.8-6, kernel-tree-2.6.8-7, kernel-tree-2.6.8-8, kernel-tree-2.6.8-9 Depends: kernel-patch-debian-2.6.8 (= 2.6.8-16), kernel-source-2.6.8 (= 2.6.8-1) | kernel-source-2.6.8 (= 2.6.8-10) | kernel-source-2.6.8 (= 2.6.8-11) | kernel-source-2.6.8 (= 2.6.8-12) | kernel-source-2.6.8 (= 2.6.8-13) | kernel-source-2.6.8 (= 2.6.8-14) | kernel-source-2.6.8 (= 2.6.8-15) | kernel-source-2.6.8 (= 2.6.8-16) | kernel-source-2.6.8 (= 2.6.8-2) | kernel-source-2.6.8 (= 2.6.8-3) | kernel-source-2.6.8 (= 2.6.8-4) | kernel-source-2.6.8 (= 2.6.8-5) | kernel-source-2.6.8 (= 2.6.8-6) | kernel-source-2.6.8 (= 2.6.8-7) | kernel-source-2.6.8 (= 2.6.8-8) | kernel-source-2.6.8 (= 2.6.8-9) snip Again, I think it would be much quicker, easier, and less prone to errors if the DSAs where mentioned in the relevant kernel-image-change too. It would be prone to errors from kernel-image uploaders who aren't actually keeping track of what has been fixed in the kernel source; at least if there's an expectation that you have to look at the kernel-source, you always know where you stand. You could try cooking up some magic to automatically incorporate particular changelog snippets in kernel-image, but there's also the possibility of arch-specific security issues, so... -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation
On Sunday 05 June 2005 03:37 am, Bill Allombert wrote: Sound like a potential security nightmare to me. LaTeX is a full programming language. Well, in principle it would be possible to just parse a subset of LaTeX [0] and get reasonable results. If they're calling LaTeX directly, though, that could definitely spell trouble. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ |We've got nothing to fear but the stuff that we're| | afraid of! -- Fluble | \--- Be like the kid in the movie! Play chess! -- http://www.uschess.org --/ pgp0fGy6ioE9f.pgp Description: PGP signature
Re: Bug#311795: ITP: rast -- A full text search system
NOKUBI Takatsugu writes: BTW, there is the n-gram word in libdigest-nilsimsa-perl package's description without explain of the word. Where it helps to render the description incomprehensible. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Canonical and Debian
On 6/5/05, Steve Langasek [EMAIL PROTECTED] wrote: You can either step up and make sure the architectures you care about are in good shape for etch, or you can be a whiny brat expecting everything to be handed to you on a silver platter and accusing people of being members of a Canonical-controlled cabal when they do you the courtesy of informing you about their personal priorities for etch. Your choice. I am no fan of the Vancouver proposal, but Steve's got a point. Ensuring that packages build and run properly on a wide variety of architectures is _work_. I happen to think that it's worthwhile work, and that it's the main factor that sets Debian apart from all the rest and directly contributes to the superior quality of Debian relative to other distros. But if it isn't spread across a large number of people, it's a crushing burden, and no one has a right to ask the release team to shoulder it. The mirror network is not the big issue, as I see it; I care more about the question of whether the build procedures have adequate conditional logic to handle the presence/absence of a native-code compiler for language X, the existence or lack of an assembly-language implementation of core routine Y, etc. As I have argued previously, the diversity of architectures is the best available proxy for the evolution of platforms over time, and the packages which have a hard time building on all arches are precisely those which it's a struggle to maintain for the duration of a release cycle. Steve's also right that buildds that have non-zero queue depths for non-trivial lengths of time tend to expose fragility in build and run-time dependencies, and so they get stuck in ugly ways that need release team (or porter) attention. So either Debian collectively is willing to labor to maintain a high standard of portability and stability, or we need to focus on a few arches and ignore bugs-in-principle that don't happen to break on those systems. I know which one I'd like to see, but I have to admit that I have done a lousy job of following through so far on things that I could help with myself. But at least I don't go around blaming the people who are actually doing the work. :-/ Cheers, - Michael
Accepted meanwhile 0.4.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 1 Jun 2005 13:33:23 +0200 Source: meanwhile Binary: libmeanwhile0 libmeanwhile-dev Architecture: source i386 Version: 0.4.2-1 Distribution: unstable Urgency: low Maintainer: Chris Vanden Berghe [EMAIL PROTECTED] Changed-By: Chris Vanden Berghe [EMAIL PROTECTED] Description: libmeanwhile-dev - development package for libmeanwhile0 libmeanwhile0 - open implementation of the Lotus Sametime Community Client protoc Changes: meanwhile (0.4.2-1) unstable; urgency=low . * New upstream version. Files: a8141adfd0b34a572f6008d0b5e4cae6 618 net optional meanwhile_0.4.2-1.dsc f76f5c59be5696c906a5cfa6a67e73e2 399079 net optional meanwhile_0.4.2.orig.tar.gz cf2500a5fda948b24f9872ea486a83bc 9456 net optional meanwhile_0.4.2-1.diff.gz fdd3bff5afd073fa5415b9fd125852b4 94006 libdevel optional libmeanwhile-dev_0.4.2-1_i386.deb d5d6ba73ee08c74550d19dcaa792a41d 57988 libs optional libmeanwhile0_0.4.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCof3LpD5tJxKCh+gRAuvGAKCKR32qqfjJG8ZPe/F/EoHSe66+jgCcC8Fl 9EguozVfT5L7/ZcJbJKBYOA= =Kfah -END PGP SIGNATURE- Accepted: libmeanwhile-dev_0.4.2-1_i386.deb to pool/main/m/meanwhile/libmeanwhile-dev_0.4.2-1_i386.deb libmeanwhile0_0.4.2-1_i386.deb to pool/main/m/meanwhile/libmeanwhile0_0.4.2-1_i386.deb meanwhile_0.4.2-1.diff.gz to pool/main/m/meanwhile/meanwhile_0.4.2-1.diff.gz meanwhile_0.4.2-1.dsc to pool/main/m/meanwhile/meanwhile_0.4.2-1.dsc meanwhile_0.4.2.orig.tar.gz to pool/main/m/meanwhile/meanwhile_0.4.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted matchbox-window-manager 0.9.5-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 19:59:09 +0100 Source: matchbox-window-manager Binary: matchbox-window-manager Architecture: source i386 Version: 0.9.5-1 Distribution: unstable Urgency: low Maintainer: Moray Allan [EMAIL PROTECTED] Changed-By: Moray Allan [EMAIL PROTECTED] Description: matchbox-window-manager - window manager for resource-limited systems Changes: matchbox-window-manager (0.9.5-1) unstable; urgency=low . * New upstream release. Files: 3a1f174151ee9a8506c94f43551d3c22 710 embedded optional matchbox-window-manager_0.9.5-1.dsc 7343855f03e962307a350c1cfd03c740 237878 embedded optional matchbox-window-manager_0.9.5.orig.tar.gz 0b6aa0f9ce84424d6b46fded4b32a48c 2472 embedded optional matchbox-window-manager_0.9.5-1.diff.gz 581cbf588b04072b846de4e9f37d4135 77810 embedded optional matchbox-window-manager_0.9.5-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCo03J500puCvhbQERAlHgAJ9t9A/V37/b9wlZk4y0zlp4ORbyyQCfV6vO 03Dqwj/fMdT7HmPp47eR18E= =W3Et -END PGP SIGNATURE- Accepted: matchbox-window-manager_0.9.5-1.diff.gz to pool/main/m/matchbox-window-manager/matchbox-window-manager_0.9.5-1.diff.gz matchbox-window-manager_0.9.5-1.dsc to pool/main/m/matchbox-window-manager/matchbox-window-manager_0.9.5-1.dsc matchbox-window-manager_0.9.5-1_i386.deb to pool/main/m/matchbox-window-manager/matchbox-window-manager_0.9.5-1_i386.deb matchbox-window-manager_0.9.5.orig.tar.gz to pool/main/m/matchbox-window-manager/matchbox-window-manager_0.9.5.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linuxsampler 0.3.cvs20050604-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 4 Jun 2005 14:16:09 +1000 Source: linuxsampler Binary: linuxsampler Architecture: source i386 Version: 0.3.cvs20050604-1 Distribution: unstable Urgency: low Maintainer: Matt Flax [EMAIL PROTECTED] Changed-By: Matt Flax [EMAIL PROTECTED] Description: linuxsampler - realtime audio sampler Closes: 311572 Changes: linuxsampler (0.3.cvs20050604-1) unstable; urgency=low . * Added automake to build depends to fix sparc's problem of not finding aclocal (Closes: 311572) Files: 83dceae65fa4d6043d36074b5c8c721d 640 sound optional linuxsampler_0.3.cvs20050604-1.dsc 3a501004b7da697426be3815c4b4dd87 271355 sound optional linuxsampler_0.3.cvs20050604.orig.tar.gz d447b9a9eb316b6b04c269740714542d 303107 sound optional linuxsampler_0.3.cvs20050604-1.diff.gz 0736f1beba8baef802cc2aaa1325f8af 871194 sound optional linuxsampler_0.3.cvs20050604-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCoS3GxszRMwUB+IIRAhC8AKCyMBW/tR6EtyiwAgeU1iWemNs4TACgwYJw rAb0NSNxiV8BAVbKnzNeJBI= =VlKX -END PGP SIGNATURE- Accepted: linuxsampler_0.3.cvs20050604-1.diff.gz to pool/main/l/linuxsampler/linuxsampler_0.3.cvs20050604-1.diff.gz linuxsampler_0.3.cvs20050604-1.dsc to pool/main/l/linuxsampler/linuxsampler_0.3.cvs20050604-1.dsc linuxsampler_0.3.cvs20050604-1_i386.deb to pool/main/l/linuxsampler/linuxsampler_0.3.cvs20050604-1_i386.deb linuxsampler_0.3.cvs20050604.orig.tar.gz to pool/main/l/linuxsampler/linuxsampler_0.3.cvs20050604.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kterm 6.2.0-44 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 18:32:26 +0900 Source: kterm Binary: kterm Architecture: source i386 Version: 6.2.0-44 Distribution: unstable Urgency: low Maintainer: ISHIKAWA Mutsumi [EMAIL PROTECTED] Changed-By: ISHIKAWA Mutsumi [EMAIL PROTECTED] Description: kterm - Multi-lingual terminal emulator for X. Closes: 259024 Changes: kterm (6.2.0-44) unstable; urgency=low . * fix build problem with gcc-3.4/gcc4, closes: #259024 Files: ac178eb312421d68dd157e1c3514e0aa 683 x11 extra kterm_6.2.0-44.dsc 118db041371d1c0119bee5358ca6dde6 31058 x11 extra kterm_6.2.0-44.diff.gz 9cae9ba271d03f291ff58a28506ef7ff 105872 x11 extra kterm_6.2.0-44_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iEYEARECAAYFAkKix50ACgkQfi8w7uypT6jjRQCgg3VmBA66fi2clK1FldnZgTLP m8kAn2mkIM0zS6TSuh3pm6y0tOROtBsg =Ut4z -END PGP SIGNATURE- Accepted: kterm_6.2.0-44.diff.gz to pool/main/k/kterm/kterm_6.2.0-44.diff.gz kterm_6.2.0-44.dsc to pool/main/k/kterm/kterm_6.2.0-44.dsc kterm_6.2.0-44_i386.deb to pool/main/k/kterm/kterm_6.2.0-44_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ipolish 20050605-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 13:01:08 +0200 Source: ipolish Binary: wpolish myspell-pl ipolish Architecture: source all Version: 20050605-1 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: ipolish- The Polish dictionary for ispell myspell-pl - The Polish dictionary for myspell wpolish- Polish dictionary words for /usr/share/dict Closes: 312029 Changes: ipolish (20050605-1) unstable; urgency=low . * New upstream version. * Add Vietnamese translation of debconf templates. Thanks to Clytie Siddall [EMAIL PROTECTED] (closes: #312029). Files: fe160504a7dd0d7eb8485f61d286eb27 685 text optional ipolish_20050605-1.dsc 11ef6a1c33ac0dbfc9285a7d9b526698 839614 text optional ipolish_20050605.orig.tar.gz 28568cad04af98e412036c467b9860e0 57437 text optional ipolish_20050605-1.diff.gz 6702e744d8541956a2bcd7053843e5e1 889410 text optional ipolish_20050605-1_all.deb c533b43b7aa37e55da56e6827d7e8a88 8014872 text optional wpolish_20050605-1_all.deb 93ba6bc2819c6dd838b08af8c52b2056 772206 text optional myspell-pl_20050605-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCounlThh1cJ0wnDsRAuxGAKCH+2270t711RYRNH0/5REAA6yUNgCeK774 TrVSjSRWkNN2pTvyi12VhMc= =HYaU -END PGP SIGNATURE- Accepted: ipolish_20050605-1.diff.gz to pool/main/i/ipolish/ipolish_20050605-1.diff.gz ipolish_20050605-1.dsc to pool/main/i/ipolish/ipolish_20050605-1.dsc ipolish_20050605-1_all.deb to pool/main/i/ipolish/ipolish_20050605-1_all.deb ipolish_20050605.orig.tar.gz to pool/main/i/ipolish/ipolish_20050605.orig.tar.gz myspell-pl_20050605-1_all.deb to pool/main/i/ipolish/myspell-pl_20050605-1_all.deb wpolish_20050605-1_all.deb to pool/main/i/ipolish/wpolish_20050605-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ipkungfu 0.5.2-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 4 Jun 2005 22:50:59 +1200 Source: ipkungfu Binary: ipkungfu Architecture: source i386 Version: 0.5.2-3 Distribution: unstable Urgency: low Maintainer: Nigel Jones [EMAIL PROTECTED] Changed-By: Nigel Jones [EMAIL PROTECTED] Description: ipkungfu - iptables-based Linux firewall Closes: 311881 311882 Changes: ipkungfu (0.5.2-3) unstable; urgency=low . * purge not working (Closes: #311881) * remade init.d script to prevent verbose output (Closes: #311882) * setup logging postrm script for log files - help clean verbose output Files: 658b85d21f2f7bd8aa41a5fbd3d61915 563 net optional ipkungfu_0.5.2-3.dsc df803ed261063a0d7463d090291929ce 7063 net optional ipkungfu_0.5.2-3.diff.gz 8dd54498f465704f3da3540082625595 33640 net optional ipkungfu_0.5.2-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCokoggY5NIXPNpFURAhYQAJ4xUDjUjnZIysUZNG+zITLgC/dvIgCgx6uQ jn64g6hY9CRRTciVN9S3GBE= =iRMR -END PGP SIGNATURE- Accepted: ipkungfu_0.5.2-3.diff.gz to pool/main/i/ipkungfu/ipkungfu_0.5.2-3.diff.gz ipkungfu_0.5.2-3.dsc to pool/main/i/ipkungfu/ipkungfu_0.5.2-3.dsc ipkungfu_0.5.2-3_i386.deb to pool/main/i/ipkungfu/ipkungfu_0.5.2-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ht 0.8.0-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 05 Jun 2005 01:52:24 +0200 Source: ht Binary: ht Architecture: source i386 Version: 0.8.0-3 Distribution: unstable Urgency: high Maintainer: Florian Ernst [EMAIL PROTECTED] Changed-By: Florian Ernst [EMAIL PROTECTED] Description: ht - Viewer/editor/analyser (mostly) for executables Changes: ht (0.8.0-3) unstable; urgency=high . * Urgency high due to security fix * Added two integer overflow precautions in the ELF parser [htelfshs.cc, CAN-2005-1545], thanks to Martin 'Joey' Schulze and the Security Team! Files: 7a295332b3fd877cd5eaa1aedd2009a7 577 devel optional ht_0.8.0-3.dsc 4d0927b4a625274b0a8a506844d7599e 7500 devel optional ht_0.8.0-3.diff.gz de3c7a86e345b342775da028da6b16c2 525704 devel optional ht_0.8.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCokNPs3U+TVFLPnwRAqhZAJ4mOOTpX2H/PFdVLtdXq5ENc4C3bACgkgDw pErikpnXNy8nb2gfR/+CYYw= =aeS4 -END PGP SIGNATURE- Accepted: ht_0.8.0-3.diff.gz to pool/main/h/ht/ht_0.8.0-3.diff.gz ht_0.8.0-3.dsc to pool/main/h/ht/ht_0.8.0-3.dsc ht_0.8.0-3_i386.deb to pool/main/h/ht/ht_0.8.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted netselect 0.3.ds1-5 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 16:24:51 +0200 Source: netselect Binary: netselect netselect-apt Architecture: source i386 all Version: 0.3.ds1-5 Distribution: unstable Urgency: low Maintainer: Filippo Giunchedi [EMAIL PROTECTED] Changed-By: Filippo Giunchedi [EMAIL PROTECTED] Description: netselect - Choose the fastest server automatically netselect-apt - Choose the fastest Debian mirror with netselect Closes: 312082 Changes: netselect (0.3.ds1-5) unstable; urgency=low . * now netselect-apt -f should work as expected (patch by Peter Walser) Closes: #312082 Files: 4748826b18e079c387f6567781972a8f 608 net optional netselect_0.3.ds1-5.dsc e0285825b48eaf120e8768d242550ea3 33772 net optional netselect_0.3.ds1-5.diff.gz 7f24e444f372c0a8b22dde993992ced5 8076 net optional netselect-apt_0.3.ds1-5_all.deb 45f98288d312c54540d8fd0b93028058 19592 net optional netselect_0.3.ds1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCoxeQABzeamt51AERAjuKAJ0UfrfEgDSVKWBmFvb//8KnX8jnmgCeM57z EWhAJeKf/lIij6K2Vzd+bas= =I2s4 -END PGP SIGNATURE- Accepted: netselect-apt_0.3.ds1-5_all.deb to pool/main/n/netselect/netselect-apt_0.3.ds1-5_all.deb netselect_0.3.ds1-5.diff.gz to pool/main/n/netselect/netselect_0.3.ds1-5.diff.gz netselect_0.3.ds1-5.dsc to pool/main/n/netselect/netselect_0.3.ds1-5.dsc netselect_0.3.ds1-5_i386.deb to pool/main/n/netselect/netselect_0.3.ds1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hevea-doc 1.08-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 19:13:20 +0200 Source: hevea-doc Binary: hevea-doc Architecture: source all Version: 1.08-1 Distribution: unstable Urgency: low Maintainer: Ralf Treinen [EMAIL PROTECTED] Changed-By: Ralf Treinen [EMAIL PROTECTED] Description: hevea-doc - HeVeA documentation Changes: hevea-doc (1.08-1) unstable; urgency=low . * New upsteam release. * Added debian/watch. * Bumped up dependency on debhelper to = 4.0. Files: 63aad08e6ae56493030f9ca226b2e49e 570 non-free/doc optional hevea-doc_1.08-1.dsc 11c215da188918bc427b37a1714a5c65 134984 non-free/doc optional hevea-doc_1.08.orig.tar.gz 35517bef4e189359a331b056e1a8349b 2575 non-free/doc optional hevea-doc_1.08-1.diff.gz db8ac4fa9569e8adf09977ef5c2e0fcb 142660 non-free/doc optional hevea-doc_1.08-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCozbRtzWmSeC6BMERAippAKD0v+iUT+d/pM5xx5eMXsaph0na8QCg6akK rgbl0Mv9gOwYuDZyBS0Oslc= =TucA -END PGP SIGNATURE- Accepted: hevea-doc_1.08-1.diff.gz to pool/non-free/h/hevea-doc/hevea-doc_1.08-1.diff.gz hevea-doc_1.08-1.dsc to pool/non-free/h/hevea-doc/hevea-doc_1.08-1.dsc hevea-doc_1.08-1_all.deb to pool/non-free/h/hevea-doc/hevea-doc_1.08-1_all.deb hevea-doc_1.08.orig.tar.gz to pool/non-free/h/hevea-doc/hevea-doc_1.08.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtk-led-askpass 0.10-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 12:52:12 +0100 Source: gtk-led-askpass Binary: gtk-led-askpass Architecture: source i386 Version: 0.10-1 Distribution: unstable Urgency: low Maintainer: Dafydd Harries [EMAIL PROTECTED] Changed-By: Dafydd Harries [EMAIL PROTECTED] Description: gtk-led-askpass - GTK+ password dialog suitable for use with ssh-add Closes: 309436 Changes: gtk-led-askpass (0.10-1) unstable; urgency=low . * New upstream version. - This release keeps the dialog window on top. Closes: #309436. Files: 8d48b48056427d5c443fa562d31ec64d 598 net optional gtk-led-askpass_0.10-1.dsc 1d4c18733788f81ff9e18d5e1f5e84b4 16732 net optional gtk-led-askpass_0.10.orig.tar.gz fb7ba75b7f5529c12aff98ebd66f7ceb 7088 net optional gtk-led-askpass_0.10-1.diff.gz 29981b4bc64b38c4ff55397f3671f238 10090 net optional gtk-led-askpass_0.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCoupRpD5tJxKCh+gRAqC/AJ41ZUKaU/Pwz4aFfzjbWVNoR8CI+gCeKN77 +6m3voWU8vNrSIOme0X0vtA= =tL/W -END PGP SIGNATURE- Accepted: gtk-led-askpass_0.10-1.diff.gz to pool/main/g/gtk-led-askpass/gtk-led-askpass_0.10-1.diff.gz gtk-led-askpass_0.10-1.dsc to pool/main/g/gtk-led-askpass/gtk-led-askpass_0.10-1.dsc gtk-led-askpass_0.10-1_i386.deb to pool/main/g/gtk-led-askpass/gtk-led-askpass_0.10-1_i386.deb gtk-led-askpass_0.10.orig.tar.gz to pool/main/g/gtk-led-askpass/gtk-led-askpass_0.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gramps 2.0.2-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 4 Jun 2005 23:05:27 -0400 Source: gramps Binary: gramps Architecture: source all Version: 2.0.2-1 Distribution: unstable Urgency: low Maintainer: James A. Treacy [EMAIL PROTECTED] Changed-By: James A. Treacy [EMAIL PROTECTED] Description: gramps - Genealogical Research and Analysis Management Program Changes: gramps (2.0.2-1) unstable; urgency=low . * New upstream release. Files: c4c55f56b777bfc8583e252cbf95c0c8 805 gnome optional gramps_2.0.2-1.dsc b15acb95922872cd4996d35faed5d7ad 2966004 gnome optional gramps_2.0.2.orig.tar.gz d0ab5768745ea2ff5f1033f675a8ed20 16097 gnome optional gramps_2.0.2-1.diff.gz 3c0fed2762a9aa5a928d914728affc8f 2707522 gnome optional gramps_2.0.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iQCVAwUBQqJvYw9y7Te6Cn61AQKp5gP/S5j/RKK/BKKCVBfT/1gdlpdenqddGsGa gteM6Bf15aD3MTQR0yXFhe86DKjFT0nYBP/CS/IHcjX5b3MGRpO/a7/uQ4jA/CKJ 0wLMpWWfAeiu/78QYcNSXjN2AbzpyBGdCF7mIsq/vK7zmNj4JrFYXuw1O4rSGiV3 qGYGffqjHAA= =bGtr -END PGP SIGNATURE- Accepted: gramps_2.0.2-1.diff.gz to pool/main/g/gramps/gramps_2.0.2-1.diff.gz gramps_2.0.2-1.dsc to pool/main/g/gramps/gramps_2.0.2-1.dsc gramps_2.0.2-1_all.deb to pool/main/g/gramps/gramps_2.0.2-1_all.deb gramps_2.0.2.orig.tar.gz to pool/main/g/gramps/gramps_2.0.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lynx-cur 2.8.6-13 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 5 Jun 2005 08:18:01 +0900 Source: lynx-cur Binary: lynx-cur-wrapper lynx-cur Architecture: source i386 all Version: 2.8.6-13 Distribution: unstable Urgency: low Maintainer: Atsuhito KOHDA [EMAIL PROTECTED] Changed-By: Atsuhito KOHDA [EMAIL PROTECTED] Description: lynx-cur - Text-mode WWW Browser with NLS support (development version) lynx-cur-wrapper - Wrapper for lynx-cur Changes: lynx-cur (2.8.6-13) unstable; urgency=low . * This is of 2.8.6dev.12 Files: 0082df25c9382718c319ac3e618b4262 657 web extra lynx-cur_2.8.6-13.dsc 47791f199bfdb708a2a1f4de686a4046 5999818 web extra lynx-cur_2.8.6-13.diff.gz b3700485cee12583457a44f65db05e14 12288 web extra lynx-cur-wrapper_2.8.6-13_all.deb 9419dc8a1c5d8d072f9ca4da8f8dc3aa 1932126 web extra lynx-cur_2.8.6-13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCojtp1IXdL1v6kOwRAhWOAJ4pNE/2/f3oT9R77fGYN5hvA3XZzACfUtfD QghPNCDdb4z0SKXsOjlCRT0= =Lyi1 -END PGP SIGNATURE- Accepted: lynx-cur-wrapper_2.8.6-13_all.deb to pool/main/l/lynx-cur/lynx-cur-wrapper_2.8.6-13_all.deb lynx-cur_2.8.6-13.diff.gz to pool/main/l/lynx-cur/lynx-cur_2.8.6-13.diff.gz lynx-cur_2.8.6-13.dsc to pool/main/l/lynx-cur/lynx-cur_2.8.6-13.dsc lynx-cur_2.8.6-13_i386.deb to pool/main/l/lynx-cur/lynx-cur_2.8.6-13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
