Re: Re Créer le .change s à partir des autres fichiers
On Tue, Feb 21, 2006, Ludovic Rousseau wrote: dpkg-scanpackages $DIR /dev/null | gzip $DIR/Packages.gz Ça doit aussi fonctionné pour les sources mais je n'ai pas essayé. dpkg-scansources pour les sources. -- adn Mohammed Adnène Trojette -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: Whether CIPE and Windows driver development count isn't a fact, it's an opinion. Since they're both thoroughly pointless, I don't think they do. The fact is it doesn't matter whether they 'count'. They exist, and that is enough to fulfill the requirement. If you have a problem with that, you are free to try to change the rules. --Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Marking BTS spam
On Wed, Feb 22, 2006 at 08:20:45AM +0100, Nico Golde wrote: Hi, * Kevin Mark [EMAIL PROTECTED] [2006-02-22 07:51]: On Tue, Feb 21, 2006 at 01:07:39PM -0700, Shaun Jackman wrote: Is it possible to mark a particular message to the BTS (as in [EMAIL PROTECTED]) as spam? This information could be used for filtering the web page reports, or possibly training the spam filter. there was added a 'button' on all bug-number pages to 'mark as spam' on near the bottom but IIRC it was marked as an experimental project to only collect data for future use. If this has been implemented and affect filtering, I guess the list-master would know. I guess some script-foo could be used to 'click' the spam 'button' on the web page but not my me x-) I also had the idea of making it available via mail so I can make a shortcut for mutt/ng and a little shell script. Don't know what happened in the meantime. Regards Nico Hi Nico, as a mutt user, I'd happily look for a mutt addition to click a few keys to help kill evil spam ! Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
ITP: grouch.app -- AOL Instant Messenger client for GNUstep
Package: wnpp Severity: wishlist * Package name: grouch.app Version : 0.0.20060220 Upstream Author : Andy Sveikauskas [EMAIL PROTECTED] * URL : http://mail.rochester.edu/~asveikau/grouch/ * License : GNU General Public License, version 2 Description : AOL Instant Messenger client for GNUstep http://www.gnustep.org/ This is a graphical AOL Instant Messenger client for GNUstep. -- System Information: Debian Release: testing/unstable Architecture: powerpc Kernel: Linux ibook 2.4.23-ben1 #7 Sat Dec 27 11:20:38 CET 2003 ppc Locale: LANG=POSIX, LC_CTYPE=POSIX -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
More polls and social pressure
[ Reply-to debian-project ] Hi everybody, given the size of the project, it's very difficult for any of us to evaluate the popularity of random ideas/opinions in a short time frame. Jeroen (jvw) recently conducted two informal polls (vi-tiny vs elvis, and maintainer field for ubuntu) and I liked those. My idea would be to officialize a weekly consultation of the developers. Devotee (the voting software) may need to be modified to allow for several votes in a single mail. Each week a mail to d-d-a would contain the results of the vote of the previous week together with the new set of polls for the current week. Those polls are not fully crafted GR so they are not as binding as a GR could be but they should give up a pretty good overview of the current opinion inside the project (if each poll has been well prepared by its proponent). The possible uses are very broad: for example, I'd tempted to start a serie of GRs to officialize by the project at large some decisions which have been implicitely taken. However I don't want to start that if a majority of developers think that this is useless, so I'd like to have the opinion of the project and I'd like to submit a poll. Any DD should be able to submit such a poll to the project. That's so far the normal usage of the polls. But I may have found a new interesting application: In the light of recent events, those polls could be used to give a physical reality to the social peer pressure that should exist on our mailing lists (and maybe avoid going straight to extreme solutions): --- [] XXX behaviour in thread YY is inacceptable [] XXX behaviour in thread YY is borderline [] XXX behaviour in thread YY is OK [] I have no opinion, I didn't check --- [] XXX posts way too much and he repeats his argument over over [] XXX should answer less frequently but with more elaborate mails [] XXX posts many mails, but they are interesting [] I have no opinion, I didn't check --- The result of the polls could eventually be used by the listmasters to take action if needed. This is a civilized way to define what *must change* and what is ok. If you believe someone is misconducting on the lists, or is hurting the project by his behaviour, just submit a poll and in the light of the results, both sides will know what the project thinks (if enough people take the time to vote of course). The current limitation is that we probably ought to open the votes to a larger group than the DD but we might start with DD only and check out the results. So coments are welcome. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Marking BTS spam
Hi, * Kevin Mark [EMAIL PROTECTED] [2006-02-22 09:24]: On Wed, Feb 22, 2006 at 08:20:45AM +0100, Nico Golde wrote: * Kevin Mark [EMAIL PROTECTED] [2006-02-22 07:51]: On Tue, Feb 21, 2006 at 01:07:39PM -0700, Shaun Jackman wrote: Is it possible to mark a particular message to the BTS (as in [EMAIL PROTECTED]) as spam? This information could be used for filtering the web page reports, or possibly training the spam filter. there was added a 'button' on all bug-number pages to 'mark as spam' on near the bottom but IIRC it was marked as an experimental project to only collect data for future use. If this has been implemented and affect filtering, I guess the list-master would know. I guess some script-foo could be used to 'click' the spam 'button' on the web page but not my me x-) I also had the idea of making it available via mail so I can make a shortcut for mutt/ng and a little shell script. Don't know what happened in the meantime. as a mutt user, I'd happily look for a mutt addition to click a few keys to help kill evil spam ! At the moment the spam-report.pl script uses: input type=hidden name=listname value=debian-devel / input type=hidden name=msg value=msg00065.html / input type=hidden name=date value=2005/09 / To identify the message, this wouldn't work with a MUA so the idea came to my mind was to identify the Mail with the message-ID. Paskal Hakim asked what happens if someone fakes the message-ID in the old thread about this topic. Well this could happen, so someone has another idea? Regards Nico -- Nico Golde - JAB: [EMAIL PROTECTED] | GPG: 0x73647CFF http://www.ngolde.de | http://www.muttng.org | http://grml.org Forget about that mouse with 3/4/5 buttons - gimme a keyboard with 103/104/105 keys! pgpDtSQoUZ21J.pgp Description: PGP signature
Re: Marking BTS spam
In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: there was added a 'button' on all bug-number pages to 'mark as spam' on near the bottom but IIRC it was marked as an experimental project to only collect data for future use. If this has been implemented and affect filtering, I guess the list-master would know. I guess some script-foo could be used to 'click' the spam 'button' on the web page but not my me x-) The lists.debian.org spam button doesn't have much immediate effect. The bugs.debian.org spam button, after manual review, is used to clean the BTS and train the spam filters. This review usually occurs daily. An occasional mistake is no problem, but using it excessivly on bugs that don't have spam may get your IP address banned from the BTS web site. I also clean bugs that have gotten messages with questionable spamassassin scores. Scripting using the BTS spam feature is pretty easy, I've done so to process the email to [EMAIL PROTECTED] telling us about spam in a bug. -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Marking BTS spam
On Wed, Feb 22, 2006 at 08:20:45AM +0100, Nico Golde wrote: Hi, * Kevin Mark [EMAIL PROTECTED] [2006-02-22 07:51]: On Tue, Feb 21, 2006 at 01:07:39PM -0700, Shaun Jackman wrote: Is it possible to mark a particular message to the BTS (as in [EMAIL PROTECTED]) as spam? This information could be used for filtering the web page reports, or possibly training the spam filter. there was added a 'button' on all bug-number pages to 'mark as spam' on near the bottom but IIRC it was marked as an experimental project to only collect data for future use. If this has been implemented and affect filtering, I guess the list-master would know. I guess some script-foo could be used to 'click' the spam 'button' on the web page but not my me x-) I also had the idea of making it available via mail so I can make a shortcut for mutt/ng and a little shell script. Don't know what happened in the meantime. Regards Nico Hi Nico, I just had an interesting idea to implement a way to get spam deleted from @debian.org. Create an email address say [EMAIL PROTECTED] You simply bounce/forward a debian.org email address to this address. A script associated with [EMAIL PROTECTED] parses the email and determines which mailing list it came from and then it will delete this mail from the archives and add the email to a 'spam' queue for spamassassin to learn. It requires interested humans to patrol their email and send in 'bug reports' on their @debian.org mailing lists. Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: More polls and social pressure
On Wed, Feb 22, 2006 at 09:43:23AM +0100, Raphael Hertzog wrote: [ Reply-to debian-project ] Hi everybody, given the size of the project, it's very difficult for any of us to evaluate the popularity of random ideas/opinions in a short time frame. Jeroen (jvw) recently conducted two informal polls (vi-tiny vs elvis, and maintainer field for ubuntu) and I liked those. My idea would be to officialize a weekly consultation of the developers. Devotee (the voting software) may need to be modified to allow for several votes in a single mail. Each week a mail to d-d-a would contain the results of the vote of the previous week together with the new set of polls for the current week. Hi Raphael, Ohh. a weekly pool! just like /.! ;-) Where is the Cmdr Taco option? Or maybe the Manoj or Aj Option! Didn't Aj impliment a poll on his blog already? Can't wait to see to what great Flam^H^H^HDiscussions this will initiate! Cheers, Kev -- | .''`. == Debian GNU/Linux == | my web site: | | : :' : The Universal | debian.home.pipeline.com | | `. `' Operating System| go to counter.li.org and | | `-http://www.debian.org/ |be counted! #238656 | | my keysever: pgp.mit.edu | my NPO: cfsg.org | signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. What's the difference? What is so insanely different between two ABI implementations that one ABI implementation can go in main, while the other must go to contrib? The fact that there is free software for one of them, while not for the other? No, doesn't hold; there is free software for both. The fact that there is useful free software for one of them, while not for the other? Shouldn't we let our users decide what's useful and what isn't? Otherwise, I'll declare that I don't find Windows software (_any_ Windows software, including free Windows software) useful, and you're back to square one. I can easily say that without lying: wine doesn't work on my laptop, and running it inside qemu is so insanely slow that it isn't useful. Honestly, I don't see any difference that you can use as an objective argument to allow one in main, but not the other. If running or building wine or ndiswrapper required the use of non-free software in all cases, _then_ you'd have a case. As it is, you don't. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: On Tue, Feb 21, 2006 at 09:11:50PM -0800, Adam McKenna wrote: The reality is that we can't imagine all the uses our users might have for this software, You don't have to imagine all the uses, just the realistic ones, which in this case is simply running non-free Windows drivers for stuff. What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: On Tue, Feb 21, 2006 at 09:11:50PM -0800, Adam McKenna wrote: The reality is that we can't imagine all the uses our users might have for this software, You don't have to imagine all the uses, just the realistic ones, which in this case is simply running non-free Windows drivers for stuff. What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:29:25PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. Furthermore, it's reportedly better than the accounting packages we have. I don't know if it actually runs under Wine though. Hrm, I hadn't thought of that. I wonder if it's worth trying to package with a dependency on wine... Anyway, despite it's acronym, I'd put Wine under the same heading as emulators. But then, I don't know that I'd be that unhappy if emulators were stuck in contrib. There are a few lines you could draw: (1) running non-free drivers in order to use your system (2) a compatability layer to run non-free applications or games you might have (3) a client that allows you to make use of some proprietary servers, for which there's no free server (4) a viewer that allows you to view documents prepared by a proprietary program, for which there's no free writer At present we let all of them into main. What's the difference? What is so insanely different between two ABI implementations that one ABI implementation can go in main, while the other must go to contrib? That's a fair point -- you could reasonably argue that ndiswrapper doesn't depend on non-free drivers, but quite to the contrary, non-free drivers depend on ndiswrapper to operate correctly on Linux. The usual argument that's made to allow (3) into main is to say that it only matters what code's actually running on *your* cpu, not elsewhere; but that seems to indicate ndiswrapper should be in contrib. The fact that there is useful free software for one of them, while not for the other? Shouldn't we let our users decide what's useful and what isn't? Otherwise, I'll declare that I don't find Windows software (_any_ Windows software, including free Windows software) useful, and you're back to square one. Well, fortunately what you do and don't declare doesn't matter that much, though if you're just going to pontificate like that, this conversation isn't going to get anywhere. If running or building wine or ndiswrapper required the use of non-free software in all cases, _then_ you'd have a case. As it is, you don't. Dude, how about you consider the fact that you'd get more benefit out of convincing me of your arguments, than I would of convincing you, and then realise that saying As it is, you don't have a case. is just irritating? And build time dependencies are completely irrelevent to this discussion. Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 12:05:23AM -0800, Adam McKenna wrote: On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: Whether CIPE and Windows driver development count isn't a fact, it's an opinion. Since they're both thoroughly pointless, I don't think they do. The fact is it doesn't matter whether they 'count'. They exist, and that is enough to fulfill the requirement. If you have a problem with that, you are free to try to change the rules. Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the latter of which is considering a resolution to move it right now. I'm not sure why you'd rather continue making bald assertions I've already indicated I don't accept, than actually talk about it properly? Cheers, aj signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 03:52:29AM -0800, Steve Langasek wrote: On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. Emulators/games have been moved[1] from contrib to main after someone has done free data files which are essentially proof of concept in nature. I fail to see why availability of a CIPE driver for ndiswrapper doesn't fall into the same category. A requirement for main must be usefull in a free software only enviroinement is the the beginning of the road to madness. Next theill come for free clients for protocols that (currently) only have non-free servers to connect to. Who the hell has the right to define what is usefull anyway? [1] sarien atleast -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Am Mittwoch, 22. Februar 2006 12:52 schrieb Anthony Towns: Anyway, despite it's acronym, I'd put Wine under the same heading as emulators. Wine reads a different binary format than elf and also provides the libs in the other format. Is the linux kernel on sparc an emulator if it can run solaris applications? However, the wording emulator can have many interpretations. If you refer to wikipedia, wine is an emulator. If you agree to that particular wikipedia article is your free choice. I don't. HS -- Mein GPG-Key ist auf meiner Homepage verfügbar: http://www.hendrik-sattler.de oder über pgp.net PingoS - Linux-User helfen Schulen: http://www.pingos.org pgpA0UzYYUSBc.pgp Description: PGP signature
How to package a Haskell library?
I'm currently using Haskore (http://www.haskell.org/haskore) for a course I teach at the local university. I'm interested in packaging it so that it works both with Hugs and GHC. Are there any specific documents regarding the appropriate way to package Haskell modules? -- Ernesto Hernández-Novich - On Linux 2.6.15 i686 - Unix: Live free or die! Geek by nature, Linux by choice, Debian of course. If you can't apt-get it, it isn't useful or doesn't exist. GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More polls and social pressure
On Wed, Feb 22, 2006 at 09:43:23AM +0100, Raphael Hertzog wrote: [ Reply-to debian-project ] Hi everybody, given the size of the project, it's very difficult for any of us to evaluate the popularity of random ideas/opinions in a short time frame. Jeroen (jvw) recently conducted two informal polls (vi-tiny vs elvis, and maintainer field for ubuntu) and I liked those. One limitation of Jeroen's polls where that they where not anonymous. This may be a choice we can make, but i still think they have more value if they are anonymous, as any kind of pressure and strategic choices can be made if they are open, not that this would be the case for us, us being all nice folk and everyone, but everyone can read those public poll information, and some of those may be less nice :) I strongly vote for this idea in any case. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
il vero portale di leuca http://www.alewalnet.com/
Salento Format organizza un corso di Formazione in OPERATORE DEL SETTORE AGRITURISTICO E DEL TURISMO RURALE Scarica il BANDO qui http://www.leucainfo.com/ Inserimento appartamenti in affitto con il tuo numero telefonico e tre foto sul Vero Portale di Leuca Inserimento oggetti usati con il tuo numero telefonico e tre foto sul Vero Portale di Leuca, Leuca Bazar Insegnamento a domicilio di informatica e utilizzo del Computer nells vita quotidiana Riparazioni P.C. ritiro e consegna a domicilio Per info tel. Dott.ssa Alessia Petese 3294741579 [EMAIL PROTECTED] Da una idea di Walter Petese [EMAIL PROTECTED] parte una serie di iniziative volte al miglioramento del nostro territorio in termini di comunicazione,informazione,attività. Lo Staff. *In conformità con quanto disposto dal garante in materia di spamming, ai sensi della Legge D LGS 196/2003 sulla Privacy, La informiamo che il suo indirizzo E-Mail è stato reperito aul web Richiediamo l´autorizzazione ad inviarle materiale pubblicitario riguardante le nostre iniziative. Sito si riferimento www.alewalnet.com *INFORMATIVA sulla PRIVACY- Dal1°Gennaio 2004 è entrata in vigore la nuova normativa sulla PRIVACY che ai sensi dell´art.13 del decreto legislativo 30 giugno 2003 n°196, abroga e sostituisce la legge del 31 dicembre 1996 n°675 recante disposizioni per la tutela delle persone e degli altri soggetti rispetto al trattamento dei dati personali. Il codice stabilisce che il soggetto interessato debba essere preventivamentei nformato in merito all´utilizzo dei dati che lo riguardano e che il trattamento dei dati personali da parte di terzi è ammesso solo con il consenso espresso del soggetto interessato salvo i casi previsti dalla legge. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More polls and social pressure
On Wed, Feb 22, 2006 at 04:03:09PM +0100, Sven Luther wrote: On Wed, Feb 22, 2006 at 09:43:23AM +0100, Raphael Hertzog wrote: [ Reply-to debian-project ] Hi everybody, given the size of the project, it's very difficult for any of us to evaluate the popularity of random ideas/opinions in a short time frame. Jeroen (jvw) recently conducted two informal polls (vi-tiny vs elvis, and maintainer field for ubuntu) and I liked those. One limitation of Jeroen's polls where that they where not anonymous. This may be a choice we can make, but i still think they have more value if they are anonymous, as any kind of pressure and strategic choices can be made if they are open, not that this would be the case for us, us being all nice folk and everyone, but everyone can read those public poll information, and some of those may be less nice :) I strongly vote for this idea in any case. (for technical polls, use of such ressources for finger-pointing is unacceptable). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
Hi Lars, On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: * Creating /usr/local/lib/foo in postinst, but not removing it in postrm. I don't think that is a problem at all; the administrator ought to feel free to be able to put things in (say) /usr/local/lib/firmware and not have to worry that a full purge / install of the package which happened to create that directory will wipe out things there. Anand -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
* Anand Kumria [Thu, 23 Feb 2006 02:26:43 +1100]: Hi, On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: * Creating /usr/local/lib/foo in postinst, but not removing it in postrm. I don't think that is a problem at all; the administrator ought to feel free to be able to put things in (say) /usr/local/lib/firmware and not have to worry that a full purge / install of the package which happened to create that directory will wipe out things there. Correct, so one would put in foo.postrm: rmdir --ignore-fail-on-non-empty /usr/local/lib/foo Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Everything you read in newspapers is absolutely true, except for that rare story of which you happen to have first-hand knowledge. -- Erwin Knoll -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OpenAL and freealut
( CC:'ing debian-devel as a heads-up for a new transition. ) Ok, this is a status update for openal/freealut and a question for advice. OpenAL Upstream has decided to introduce proper library versioning and will start with an SONAME of libopenal.so.1 in their next upstream release. Currently, we ship an quite old version of openal. This old version has freealut 'built-in'. The current stable release (version 0.0.8) has freealut split in a seperate package, called 'freealut'. Thierry has prepared a 'freealut' package in our svn, which provides libfreealut0. Unfortunately, they kept the old SONAME of libopenal.so.0. I prepared a new version of openal providing a binary package libopenal0a, which Replaces the old libopenal0 package, but installs a file libopenal.so.0.0.8 with SONAME libopenal.so.0. This is to ensure that all reverse dependencies get rebuilt against openal 0.0.8. On the next upstream release, the SONAME will get bumped to libopenal.so.1, so we will have another transition. I propose that we start the libopenal0a transition by uploading both freealut and libopenal0a to unstable, because there are rather few reverse dependencies. Most of them (if not all) should be just rebuilt. If they use the freealut api, they need an additional -lfreealut in their LDFLAGS. If you think that this is too aggressive, we can also first upload both packages to experimental, asking all package maintainers to provide transitioned package to experimental as well. I'd rather like to avoid this because I fear that this could delay the transition. Below a list of affected package along with their maintainers: Marc Dequènes (Duck) [EMAIL PROTECTED] pyopenal Loic Dachary (OuoU) [EMAIL PROTECTED] openalpp-cvs osgal-cvs Ben Armstrong [EMAIL PROTECTED] xpilot-ng Christian Bayle [EMAIL PROTECTED] crystalspace Bartosz Fenski [EMAIL PROTECTED] scorched3d Mike Furr [EMAIL PROTECTED] chromium vegastrike Rudy Godoy [EMAIL PROTECTED] torcs Ove Kaaven [EMAIL PROTECTED] flightgear Debian Games Team [EMAIL PROTECTED] boson-base Ari Pollak [EMAIL PROTECTED] rss-glx Steve M. Robbins [EMAIL PROTECTED] coin2 regards, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
Adeodato Simó [EMAIL PROTECTED] wrote: Correct, so one would put in foo.postrm: rmdir --ignore-fail-on-non-empty /usr/local/lib/foo That's not sufficient, because /usr/local may be mounted ro, and therefore the command may fail even if the directory is empty. rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true or maybe just rmdir /usr/local/lib/foo 2/dev/null || true Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: More polls and social pressure
On Wed, Feb 22, 2006 at 09:43:23AM +0100, Raphael Hertzog wrote: [ Reply-to debian-project ] reply-to, ignored since I feel this is important enough that both lists should see this reponse. Hi everybody, In the light of recent events, those polls could be used to give a physical reality to the social peer pressure that should exist on our mailing lists (and maybe avoid going straight to extreme solutions): [...] The result of the polls could eventually be used by the listmasters to take action if needed. There is a better way. As some of you may be aware, the listmasters use feedback to gauge the desirability / utility of new lists. Likewise while the listmasters monitor the general 'health' of the lists (ebb/flow, posting frequency, etc.), that doesn't necessarily mean they have read everything (although Pascal certainly tries). So, if you feel a particular post was inappropriate / out-of-line bring it to the attention of [EMAIL PROTECTED] This is a civilized way to define what *must change* and what is ok. It is certainly *a* way but I'd hesitate to call it civilised; public non-secret ballots are frequently used in mafia-like organisations. And also within governments too. The current limitation is that we probably ought to open the votes to a larger group than the DD but we might start with DD only and check out the results. If people who have a problem, let [EMAIL PROTECTED] know, they don't even need to be in the new-maintainer queue to be heard. Even your pet dog can complain![1] Anand [1]: On the Internet, no one knows that you're a dog http://www.unc.edu/depts/jomc/academics/dri/idog.html -- `When any government, or any church for that matter, undertakes to say to its subjects, This you may not read, this you must not see, this you are forbidden to know, the end result is tyranny and oppression no matter how holy the motives' -- Robert A Heinlein, If this goes on -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu patches
On 2/21/06, Lionel Elie Mamane [EMAIL PROTECTED] wrote: You probably missed this question, which I also wanted to ask: Frank forwarded it to me, and I replied to him in person -- here's the reply. On Tue, Feb 21, 2006 at 03:55:23PM +0100, Frank Küster wrote: Scott James Remnant [EMAIL PROTECTED] wrote: And the reason 4.23 isn't in the morgue is simple, Debian's morgue ran out of disk space a while ago. What is Debian's morgue? What about using snapshot.debian.net? The morgue is where katie moves packages to once they're expelled from the pool. We used to use snapshot.debian.net until it collapsed last year, since then we've avoided it because their Packages lists still claim to contain all of the sources they lost in the melt-down -- which makes it much harder to find out whether they do or don't have a particular source package. Also unlike the morgue, snapshot only sees those packages that make it as far as the pool; there have been several cases where the developer uploaded three or four versions in one day, snapshot would only see the last one where the morgue had all four. And yes, quite often one of those interim ones has ended up in Ubuntu because of co-operation between the maintainers.
Re: Problems found by piuparts
to, 2006-02-23 kello 02:26 +1100, Anand Kumria kirjoitti: On Mon, Feb 20, 2006 at 08:24:53AM +0200, Lars Wirzenius wrote: * Creating /usr/local/lib/foo in postinst, but not removing it in postrm. I don't think that is a problem at all; the administrator ought to feel free to be able to put things in (say) /usr/local/lib/firmware and not have to worry that a full purge / install of the package which happened to create that directory will wipe out things there. I was referring, not entirely clearly, to Policy 9.1.2 Site-specific programs: As mandated by the FHS, packages must not place any files in /usr/local, either by putting them in the file system archive to be unpacked by dpkg or by manipulating them in their maintainer scripts. However, the package may create empty directories below /usr/local so that the system administrator knows where to place site-specific files. These directories should be removed on package removal if they are empty. The package should not, indeed must not, remove anything else than the directories it creates, and those only if they are empty. Not removing the directories, however, results in cruft building up on the filesystem, which, admittedly, is not a big problem, but still something worth fixing, since it should be very easy. Incidentally, don't go removing the directories with rmdir --parents, that's a good way of removing too much: if /usr/local/lib has only one subdirectory, and no files, it will be removed, too. -- If possible, use code, not comments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 22 Feb 2006, Steve Langasek verbalised: On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 03:33:19PM +1000, Anthony Towns wrote: On Tue, Feb 21, 2006 at 09:11:50PM -0800, Adam McKenna wrote: The reality is that we can't imagine all the uses our users might have for this software, You don't have to imagine all the uses, just the realistic ones, which in this case is simply running non-free Windows drivers for stuff. What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. To me it seems odd that the freedom of a work can be deterined by whether or not there are thirs party works licensed appropriately or not. So I am coming down on the side of treating emulatrs and works that implement abswtract interfaces/protocols licensed freely as free, in the manner of wine. ndiswrapper seems to fall close to that, since it is not specific to any particular driver out there. manoj -- As of next Tuesday, C will be flushed in favor of COBOL. Please update your programs. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
On 2/22/06, Frank Küster [EMAIL PROTECTED] wrote: Adeodato Simó [EMAIL PROTECTED] wrote: Correct, so one would put in foo.postrm: rmdir --ignore-fail-on-non-empty /usr/local/lib/foo That's not sufficient, because /usr/local may be mounted ro, and therefore the command may fail even if the directory is empty. rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true or maybe just rmdir /usr/local/lib/foo 2/dev/null || true Shouldn't logic like that be in one central place (dpkg or a library) and not spread over dozens of packages?
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:32:26PM +1000, Anthony Towns wrote: Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the latter of which is considering a resolution to move it right now. I'm not sure why you'd rather continue making bald assertions I've already indicated I don't accept, than actually talk about it properly? Because you're wrong. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA pimppa
It's yours. Gregory PS: xnc is still up for grabs. +++ Johannes Honkasalo [22/02/06 19:23 +0200]: I'd like to adopt pimppa, if no-one has yet requested it. Best regards, Johannes -- Gregory B. Prokopsky [EMAIL PROTECTED] Debian GNU/Linux http://www.debian.org SableVM - LGPL'ed Java VM http://sablevm.org Why SableVM ?!?http://sablevm.org/wiki/Features signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
Bug CC dropped. On Wed, Feb 22, 2006 at 02:20:42PM +0200, Riku Voipio wrote: A requirement for main must be usefull in a free software only enviroinement is the the beginning of the road to madness. Next theill come for free clients for protocols that (currently) only have non-free servers to connect to. That's already come up as it happens, debian-policy, May 1999. Cheers, aj signature.asc Description: Digital signature
Re: Problems found by piuparts
Olaf van der Spek [EMAIL PROTECTED] wrote: On 2/22/06, Frank Küster [EMAIL PROTECTED] wrote: Adeodato Simó [EMAIL PROTECTED] wrote: Correct, so one would put in foo.postrm: rmdir --ignore-fail-on-non-empty /usr/local/lib/foo That's not sufficient, because /usr/local may be mounted ro, and therefore the command may fail even if the directory is empty. rmdir --ignore-fail-on-non-empty /usr/local/lib/foo || true or maybe just rmdir /usr/local/lib/foo 2/dev/null || true Shouldn't logic like that be in one central place (dpkg or a library) and not spread over dozens of packages? A central library would be nice. But we currently don't have one, and Policy 9.1.2 describes how to handle /usr/local. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[I'm not a developer, just one of Debians users - I hope it is not inappropriate for me to comment on this issue here.] For starters, I'd always thought that contrib was for packages that Depend on a package out of non-free -- basically to ensure that people who have only DFSG-free software in their sources.list or on their CDs don't get broken packages. However, after reading up a bit I gather contrib means something like Packages here need something that is non-free to operate. Policy 2.2.2 has clarifying examples: - free packages which require contrib, non-free packages or packages which are not in our archive at all for compilation or execution, and - wrapper packages or other sorts of free accessories for non-free programs. If ndiswrapper falls in the first category hinges on the definition of require. Judging from its documentation ndiswrapper doesn't need any non-free binaries, the module can be inserted even if no drivers are installed. It might not be very useful like that, but useful is a very subjective thing in any case and doesn't serve as a good guideline as to what one is to expect to find in contrib. (IMHO something is shown to be useful if a developer finds it worth their time to create and maintain a package, but that's just me.) Maybe a clarification of 'require' as used in Policy 2.2.2 and item 1 of the social contract would be helpful. As it stands I think the first example doesn't apply. The much more interesting question is, is it a wrapper package in the sense of 2.2.2? It certainly acts as a wrapper for (non-free) win32 drivers, on the other hand most wrapper packages are for specific pieces of software, whereas ndiswrapper can (theoretically) encapsulate all NIC drivers that conform to a certain reasonably generic spec. Compare this to java-package which works with 6 specific Java VMs (2 versions each by 3 vendors). So maybe it isn't a wrapper but implements an ABI? I don't know, both viewpoints are certainly valid. An argument I don't agree with however, is that there would have to be a (DFSG-)free NDIS driver for ndiswrapper to rightfully be in main -- mainly on the grounds that it is a very vague and unstable criterion. Should an FPS game with no free texture packs be in main? No. If it has free texture packs but no maps? Probably not. What if there's a free map editor? ... Such reasoning just invites endless discussions until someone writes a small free component and people start to argue whether it is actually useful or just a POC. IMHO that's something for users to decide. Rather, this line of reasoning could be used not to include ndiswrapper at all -- how should the maintainer verify and fix bugs in a package when those bugs only occur and can only be verified in conjunction with non-free components? Yet nobody is asking to remove it, are they? All that said, I don't use ndiswrapper as I'm lucky enough to have hardware that works well with free drivers. On the other hand I have one of those white iBooks with no wireless drivers in sight -- if there were an ndiswrapper for the Mac I'd probably replace OS X with Debian in a heartbeat. I would assume owners of PC laptops feel the same way. From this angle it is certainly in the interest of users to have this functionality in the Debian installer even, which AFAIK can't load modules from contrib. Thanks, Christian
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:20:47AM -0800, Adam McKenna wrote: On Wed, Feb 22, 2006 at 09:32:26PM +1000, Anthony Towns wrote: Well, yeah, I am, since I'm both on ftpmaster and on the tech ctte, the latter of which is considering a resolution to move it right now. I'm not sure why you'd rather continue making bald assertions I've already indicated I don't accept, than actually talk about it properly? Because you're wrong. And I should add that these arguments have already been fairly soundly refuted and rejected by others who actually took them seriously, including other members of ctte. You don't appear to want to be convinced. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 09:52:28PM +1000, Anthony Towns wrote: On Wed, Feb 22, 2006 at 12:29:25PM +0100, Wouter Verhelst wrote: On Wed, Feb 22, 2006 at 12:35:06PM +1000, Anthony Towns wrote: The only instance when it's usable without any non-free code is when you're better off using a native driver anyway. The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. ...when you're better off using native Linux software anyway. I can give you a number of applications, free or otherwise, that will do accounting on Linux. Heck, I used to work for a company that wrote accounting software which (also) worked on Linux, so I should know my way around there. Furthermore, it's reportedly better than the accounting packages we have. Many non-free software is reportedly better than some of the software in Debian. OpenOffice.org is reportedly better than MS Office, for example. I tend not to believe third-hand experiences. I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is useless (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? [...] Anyway, despite it's acronym, I'd put Wine under the same heading as emulators. Sure. Personally, I'd put ndiswrapper there, too. [...] There are a few lines you could draw: (1) running non-free drivers in order to use your system (2) a compatability layer to run non-free applications or games you might have (3) a client that allows you to make use of some proprietary servers, for which there's no free server (4) a viewer that allows you to view documents prepared by a proprietary program, for which there's no free writer These are all categories, but I disagree that the distinction between most of them is that significant. At present we let all of them into main. I'm still not convinced that this is actually a bad thing to do. What's the difference? What is so insanely different between two ABI implementations that one ABI implementation can go in main, while the other must go to contrib? That's a fair point -- you could reasonably argue that ndiswrapper doesn't depend on non-free drivers, but quite to the contrary, non-free drivers depend on ndiswrapper to operate correctly on Linux. Exactly. The usual argument that's made to allow (3) into main is to say that it only matters what code's actually running on *your* cpu, not elsewhere; but that seems to indicate ndiswrapper should be in contrib. Actually, I'd say that the argument to allow (3) in main isn't meant to be used outside its context. The fact that there is useful free software for one of them, while not for the other? Shouldn't we let our users decide what's useful and what isn't? Otherwise, I'll declare that I don't find Windows software (_any_ Windows software, including free Windows software) useful, and you're back to square one. Well, fortunately what you do and don't declare doesn't matter that much, though if you're just going to pontificate like that, this conversation isn't going to get anywhere. What I meant was, if it's fair to say that CIPE isn't useful at all, then why is it fair to say that free Windows-software is at all useful? Personally, I think that if it doesn't run on Linux, it isn't useful. Honest. I haven't seen an argument in support of CIPE isn't a good example that didn't boil down to actually it is, but because it defeats my point, I'll just claim it isn't useful. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 07:32:33PM +0100, Wouter Verhelst wrote: The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. ...when you're better off using native Linux software anyway. I can give you a number of applications, free or otherwise, that will do accounting on Linux. You can do accounting in vi if you want. It's not terribly pleasant, but it works well for some circumstances. Of the free accounting programs available, TurboCASH actually looks pretty optimal for a range of circumstances, notably small businesses. It seems to be one of very few free programs that's actually likely to handle Australian accounting requirements reasonably well. Furthermore, it's reportedly better than the accounting packages we have. Many non-free software is reportedly better than some of the software in Debian. OpenOffice.org is reportedly better than MS Office, for example. I tend not to believe third-hand experiences. Then why bother reading a mailing list at all? I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is useless (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? I'm sorry, I thought we had a chance at an interesting conversation here. But if we're at Are you for real? and Because you're wrong. already, I guess I was mistaken. Your concerns have been noted and will be taken into due account in my considerations. Cheers, aj signature.asc Description: Digital signature
Re: Marking BTS spam
On Wed, Feb 22, 2006 at 04:33:57AM -0500, Kevin Mark wrote: [snip] Hi Nico, I just had an interesting idea to implement a way to get spam deleted from @debian.org. Create an email address say [EMAIL PROTECTED] You simply bounce/forward a debian.org email address to this address. A script associated with [EMAIL PROTECTED] parses the email and determines which mailing list it came from and then it will delete this mail from the archives and add the email to a 'spam' queue for spamassassin to learn. It requires interested humans to patrol their email and send in 'bug reports' on their @debian.org mailing lists. Cheers, Kev echo [EMAIL PROTECTED] .forward+debian-devel subscribe to debian-devel with username+debian-devel). Whoops goes the entire list... =) Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Common Light Invitation for Communication Workshop
February 21, 2006 Dear Friends of Common Light, We invite you to join us in a workshop March 24-25 on Resolving Conflict with Self and Others in order to develop valuable peacemaking skills through learning the international conflict resolution language developed by Marshall Rosenberg. Ever since we encountered this nonviolent approach to communication in a workshop with Marshall at Guilford College in the l970s, we have been impressed with its practicality and applicability. Last year 250,000 people around the world took this class, which is currently being taught in 22 countries. We hope you’ll join us to gain practical skills that have proved useful to people of all ages and all walks of life. This will be a workshop taking a “hands on” approach with lots of practice, so that by the end of two days, we will all have developed conscious skills and a strategy to deal with at least two real-time conflicts. We are very excited to be bringing Catherine Clements, a close friend and nationally recognized consultant, counselor, and teacher to Black Mountain to teach this two-day Intensive. Our friendship with Catherine dates from l968 when, as Cathy Lowdermilk, she entered Guilford College in the Richardson Fellows Honors Program for Creative Leadership. A Licensed Professional Counselor in the State of Colorado, she is a member of the American Counseling Association for Multicultural Counseling and Development. Now based in Boulder, CO, her expertise derives from 20 years of practical experience in organizational development, administrative, accounting and human resources management, counseling and mediation training, strategic planning, administrative policy, and systems development in public and private organizations small and large. To learn more about Catherine Clement, including some of the positions she has held and clients she has served, go to Programs on www.commonlight.org. To learn more about Marshall Rosenberg’s work, see www.cnvc.org. The workshop takes place at Common Light Meetingplace, in a wooded setting at the confluence of Flat Creek and Swannanoa River, and weather permitting, there will be pleasant lunches on the deck. It runs all day March 24-25 Friday and Saturday, 9am to 5pm. The,fee, including two lunches, is $90. Scholarships, as always, are available. Registration closes March 1st, so let us hear from you soon! Beth Mel Keiser [EMAIL PROTECTED] 828-669-3616
Re: Bug#320119: sysklogd: Large file support is broken in the sarge version (fwd)
Bug #320119 is marked fixed in 1.4.1-17.1, which is only available in unstable. In the meantime, LFS support has been broken for stable on i386 for the entire lifetime of the current stable release. Will -17.1 be making its way into stable any time soon? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320119 -Chris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Thu, Feb 23, 2006 at 04:58:38AM +1000, Anthony Towns wrote: On Wed, Feb 22, 2006 at 07:32:33PM +0100, Wouter Verhelst wrote: The only instance where wine is serving a purpose without requiring the use of non-free code is when you're better off using native Linux software anyway. TurboCASH is a potential counterexample -- it's a complete, functional, GPLed, Windows-based accounting suite, which hasn't been ported to Linux, and which is non-trivial to port to Linux. ...when you're better off using native Linux software anyway. I can give you a number of applications, free or otherwise, that will do accounting on Linux. You can do accounting in vi if you want. Correct, that's how I keep track of who I need to invoice :-) (though the real accounting is done by an accountant who gets paid for her work) It's not terribly pleasant, but it works well for some circumstances. Of the free accounting programs available, TurboCASH actually looks pretty optimal for a range of circumstances, notably small businesses. Like I said, there are a number of free applications that allow you to natively do accounting on Linux. Since Belgian law is rather strict on those issues, creating free software which would make accounting legal is rather hard[1], but there are a few applications which will run perfectly well on Linux and that allow you to legally do your accounting. [1] one of the requirements is the inability to modify stuff after the fact, which is very hard to meet as a requirement if the source is out for everyone to view. Yes, I agree that such a requirement cannot ever technically be met, but it's still there; and without meeting that requirement according to some committee, you're not allowed to use that software to do accounting -- at least not if you don't want to keep a copy on paper of everything. [...] I don't know if it actually runs under Wine though. What are we talking about, then? You're claiming that it's okay to keep wine in main because there's this GPL'd application that you've apparently never even tried and which *may* work under wine, while there's a driver for ndiswrapper which is useless (hah) that http://ndiswrapper.sourceforge.net (i.e., the main ndiswrapper website) actually links to? Are you for real? I'm sorry, I thought we had a chance at an interesting conversation here. [...] Sorry, that was indeed demeaning. It wasn't meant that way, but in hindsight, it was. Apologies. But if we're at Are you for real? and Because you're wrong. already, That second quote was not by me. My point was that I don't think your reasoning follows logic; your example in support of wine is about something that may work with wine, but that you apparently haven't tried yourself; whereas an example in support of ndiswrapper which is given by the people who wrote ndiswrapper (and who could reasonably well guess what will run and what won't) is dismissed because it isn't useful. It feels like applying to standards to me. But perhaps I'm missing something? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems found by piuparts
On Wed, Feb 22, 2006 at 17:42:00 +, Olaf van der Spek wrote: Shouldn't logic like that be in one central place (dpkg or a library) and not spread over dozens of packages? Something like dh_usrlocal(1)? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to package a Haskell library?
Op wo, 22-02-2006 te 09:41 -0400, schreef Ernesto Hernández-Novich: I'm currently using Haskore (http://www.haskell.org/haskore) for a course I teach at the local university. I'm interested in packaging it so that it works both with Hugs and GHC. Are there any specific documents regarding the appropriate way to package Haskell modules? There is no Haskell packaging policy or something like that, so just look at some other Haskell packages for inspiration. Furthermore you could subscribe to (low volume) debian-haskell mailing list [1]. Greetings, Arjan Oosting [1] http://urchin.earth.li/mailman/listinfo/debian-haskell signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: More polls and social pressure
Anand Kumria [EMAIL PROTECTED] So, if you feel a particular post was inappropriate / out-of-line bring it to the attention of [EMAIL PROTECTED] I suggest using a bug report if it's important enough to track. This is mentioned as an alternative on http://www.debian.org/MailingLists/#maintenance The bugs are public-archived. Are emails to listmaster@ ? -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354043: general: Failed to detect secondary monitor, MergedFB/Clone mode disabled
Package: general Severity: critical Justification: breaks the whole system ATI graphic card seems not to work on the system. While running X , i have several X Error: BadWindow (invalid Window parameter) 3 Major opcode: 20 Minor opcode: 0 Resource id: 0x125 And X freeze. more /var/log/Xorg.0.log | grep WW (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (WW) RADEON(0): Failed to detect secondary monitor, MergedFB/Clone mode disabled (WW) RADEON(0): Enabling DRM support (WW) RADEON(0): Direct rendering disabled xorg.conf (Xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, # using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades # *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically # updated # again, run the following commands as root: # # cp /etc/X11/xorg.conf /etc/X11/xorg.conf.custom # md5sum /etc/X11/xorg.conf /var/lib/xfree86/xorg.conf.md5sum # dpkg-reconfigure xserver-xorg Section Files FontPathunix/:7100# local font server # if the local font server has problems, we can fall # back on these FontPath/usr/lib/X11/fonts/misc #FontPath /usr/lib/X11/fonts/cyrillic FontPath/usr/lib/X11/fonts/100dpi/:unscaled FontPath /usr/lib/X11/fonts/75dpi/:unscaled FontPath /usr/lib/X11/fonts/Type1 #FontPath /usr/lib/X11/fonts/CID FontPath /usr/lib/X11/fonts/100dpi FontPath /usr/lib/X11/fonts/75dpi EndSection Section Module #Load bitmap #Load dbe #Load ddc #Load dri #Load extmod #Load freetype #Load glx #Load int10 #Load record #Load type1 #Load vbe
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[Christian Pernegger] Judging from its documentation ndiswrapper doesn't need any non-free binaries, the module can be inserted even if no drivers are installed. It might not be very useful like that, but useful is a very subjective thing in any case Not *that* subjective. I think you'd be pretty hard-pressed to find anyone who would consider it useful to print an init message to the kernel log, use up a bit of memory, and do absolutely nothing else. In some cases you are correct, useful is hard to define, so one has to be lenient. This isn't one of those cases. (IMHO something is shown to be useful if a developer finds it worth their time to create and maintain a package, but that's just me.) Well, until you find out whether the maintainer would have considered ndiswrapper useful enough to create and maintain if it could only be used with free drivers, or if it didn't support any drivers at all, this distinction doesn't help. An argument I don't agree with however, is that there would have to be a (DFSG-)free NDIS driver for ndiswrapper to rightfully be in main -- mainly on the grounds that it is a very vague and unstable criterion. I don't see what's vague about it. It's unstable, sure. Should an FPS game with no free texture packs be in main? No. If it has free texture packs but no maps? Probably not. What if there's a free map editor? ... Moving something from contrib to main, when its status changes due to additional free software becoming available, is NOT HARD. It's been done before, for example with the Doom game engines. You don't need to worry that contrib is forever. I mean, as well worry about all the software we label as Priority: extra. That's another arbitrary line to draw, judging a package by its degree of usefulness to most people. Oh no, you might say, what if it becomes really popular in the future and deserves to be Priority: optional or even Priority: standard? Answer: you cross that bridge when you come to it. So with putting something in contrib or main. Classifications are allowed to change when the change is justified. Rather, this line of reasoning could be used not to include ndiswrapper at all -- how should the maintainer verify and fix bugs in a package when those bugs only occur and can only be verified in conjunction with non-free components? You have discovered one of the reasons Debian advocates free software. One of the reasons we have separate 'main' and 'contrib' sections. What you say is true: it may well be harder to find and fix bugs in software which uses non-free components, even if the bug is in a part of the software which is free. We think our users deserve free software, partly to avoid that very problem, so we use 'contrib' to label the contents of the archive that may suffer from these restrictions. Maintainers who have packages in 'contrib' and 'non-free' have accepted these limitations and are willing to try to do the job regardless. signature.asc Description: Digital signature
Re: Problems found by piuparts
[Frank Küster] That's not sufficient, because /usr/local may be mounted ro, and therefore the command may fail even if the directory is empty. U. There are lots of things dpkg can do which fail if filesystems are mounted read-only. I don't think this is something worth worrying about. I mean, consider the case that the dir in /usr/local is contained in the package itself, rather than handled by scripts. signature.asc Description: Digital signature
Wide and narrow streams library configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I am currently working on the next version of the log4cxx logging library, and came across an interesting question: Wide and narrow streams (e.g. std::wcerr and std::cerr) can not be used mixed within the same application. So, if a library uses one of those streams, any application linked against this library can never use the other stream type. One solution which comes to my mind is to provide a runtime configuration switch which allows the application to choose the stream type, the other solution is to provide two versions of the library, one compiled for wide streams, the other for narrow streams. Any other suggestions? Anyone knows other libraries which have the same issue and solved it in some cool way? Thanks Best Regards, Andreas - -- Andreas Fester mailto:[EMAIL PROTECTED] WWW: http://www.littletux.net ICQ: 326674288 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/OiCZ3bQVzeW+rsRAoDNAJ426i+Grx/L6pawv18t9o6Rm5q7MgCgkFLM ISjXzlJfrOiS2JxjPqE6csQ= =k9Ud -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#354043: general: Failed to detect secondary monitor, MergedFB/Clone mode disabled
Processing commands for [EMAIL PROTECTED]: reassign 354043 xserver-xorg Bug#354043: general: Failed to detect secondary monitor, MergedFB/Clone mode disabled Bug reassigned from package `general' to `xserver-xorg'. severity 354043 normal Bug#354043: general: Failed to detect secondary monitor, MergedFB/Clone mode disabled Severity set to `normal'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
WBCSD groups Virus Alert
The following message sent by this account has violated system policy: From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Date: Wed, 22 Feb 2006 22:40:09 +0100 Subject: Re: Approved document The following violations were detected: --- Scan information follows --- Virus Name: [EMAIL PROTECTED] File Attachment: document.zip/data.rtf .scr Attachment Status: deleted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
[I originally sent this to Peter directly, my apologies.] I think you'd be pretty hard-pressed to find anyone who would consider it useful to print an init message to the kernel log, use up a bit of memory, and do absolutely nothing else. I'd find it useful for the functionality to be there when I wanted to load a driver with it. What kind of driver (supplied by me) I chose to load with it should be my decision as a user, not Debian's. Debian's policy should govern things it ships, not the data (executable or not) a user might want to feed to a program. (Others in this thread have come up with examples like open file format viewers with no in-the-wild documents yet, programming languages without code written in them, ...) Even if there was a sentence like All software in Debian main must be useful within a pure free software environment. in a binding document, that still leaves objective criteria for useful to be defined. In some cases you are correct, useful is hard to define, so one has to be lenient. This isn't one of those cases. Something that needs to be decided case-by-case basis, possibly leniently, is subjective. (Except of course you have objective criteria for all cases, but that's a catch-22.) However, the main/contrib distinction should like the free / non-free distinction be as objective and transparent as possible. (IMHO something is shown to be useful if a developer finds it worth their time to create and maintain a package, but that's just me.) Well, until you find out whether the maintainer would have considered ndiswrapper useful enough to create and maintain if it could only be used with free drivers, or if it didn't support any drivers at all, this distinction doesn't help. I'm sorry but I don't understand this sentence. I'll try to explain what I meant. If a developer files an ITP for a package and that doesn't get shot down by heated flames, if that developer then actually prepares a functional package - doesn't that show in itself that the package is useful? When all else is equal, except main or contrib, isn't it a little late to ask if the package is useful? When a package isn't useful, why have it at all? I stand by my opinion that usefulness is in the eye of the beholder. Moving something from contrib to main, when its status changes due to additional free software becoming available, is NOT HARD. No, it's not technically hard, it's just confusing, especially in the other direction. ndiswrapper is in main. Maybe it will be moved to contrib as a result of this discussion or of a decision by the technical committee. Maybe it will be moved back and forth a few times, with a heated discussion each time, who knows? Doing it isn't hard, but doing it in regular intervals for every package thus disputed is surely undesirable. I mean, as well worry about all the software we label as Priority: extra. That's another arbitrary line to draw, judging a package by its degree of usefulness to most people. Yes, that's true. However what I'm saying is just that main vs contrib shouldn't be arbitrary, nor does it say anywhere that main and contrib should be differentiated by the usefulness of their packages. We think our users deserve free software, partly to avoid that very problem, so we use 'contrib' to label the contents of the archive that may suffer from these restrictions. Is the definition of contrib then something like free software that shares some of the undesirable traits of non-free software due to the fact that it closely integrates with a non-free component? Nice, actually, if someone who's better than me with words made proper sentence out of it. Would put ndiswrapper firmly in contrib. I guess im just incredulous that Debian, which has clear and concise rules about almost everything, doesn't use a simple checklist to determine if something goes in main or contrib. Thanks, Christian
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 02:20:42PM +0200, Riku Voipio wrote: On Wed, Feb 22, 2006 at 03:52:29AM -0800, Steve Langasek wrote: On Wed, Feb 22, 2006 at 12:43:39PM +0100, Wouter Verhelst wrote: What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. Emulators/games have been moved[1] from contrib to main after someone has done free data files which are essentially proof of concept in nature. It was not my understanding that these were proof-of-concept data files; while not necessarily as appealing as some of the non-free offerings, I was led to believe they were still worthwhile in their own right, at least to some subset of users. I fail to see why availability of a CIPE driver for ndiswrapper doesn't fall into the same category. Well, aside from not believing that anyone is going to use CIPE under ndiswrapper (without someone stepping forward and testifying that this is the case for them), I see a distinction between wine is necessary in order for you to run app $foo on Debian and ndiswrapper is necessary in order for you to run Debian on hardware $foo. I realize this isn't a distinction that everyone agrees is relevant here, but it is the one that stands out to me, and I suspect we can at least all agree that the latter is the real reason why people care about having ndiswrapper in main -- *not* to facilitate loading free toy network drivers -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Wed, Feb 22, 2006 at 10:41:35AM -0600, Manoj Srivastava wrote: On 22 Feb 2006, Steve Langasek verbalised: What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. To me it seems odd that the freedom of a work can be deterined by whether or not there are thirs party works licensed appropriately or not. So I am coming down on the side of treating emulatrs and works that implement abswtract interfaces/protocols licensed freely as free, in the manner of wine. ndiswrapper seems to fall close to that, since it is not specific to any particular driver out there. The distinction between main and contrib isn't one of the freeness of the contents, though; it's of whether the package requires a component outside of Debian/main for use. Actually, let's look at what policy says: 2.2.2. The contrib section -- [...] Examples of packages which would be included in _contrib_ are: * free packages which require _contrib_, _non-free_ packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. ndiswrapper doesn't really require any non-free packages for execution; it requires *some* NDIS driver, but it's probably not useful to package those and definitely not useful for ndiswrapper to depend on a particular one of them. So I guess this makes it a question of whether ndiswrapper is a free wrapper package for non-free programs. Well, the name suggests that it is a wrapper. :) Is it a wrapper for non-free software? That is certainly my understanding of it. Even if free NDIS drivers do exist (and we know that they do), I've heard enough negative comments about the quality of the ndiswrapper shim that I can't really believe that a sane person will want to use it as anything other than a wrapper for non-free drivers. So I have a hard time defending ndiswrapper-in-main on policy grounds. I think most of the people saying it belongs in main are really concerned that putting it in contrib will mean it's less well supported in Debian; it'd be nice if those concerns led to better support/integration for contrib, instead of arguments about where the line should be... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Wed, Feb 22, 2006 at 05:01:21PM -0800, Steve Langasek wrote: Well, aside from not believing that anyone is going to use CIPE under ndiswrapper (without someone stepping forward and testifying that this is the case for them), I see a distinction between wine is necessary in order for you to run app $foo on Debian and ndiswrapper is necessary in order for you to run Debian on hardware $foo. That is a very fine distinction, if it's a distinction at all, considering that the latter statement can easily be rewritten ndiswrapper is necessary in order for you to load drivers for hardware $foo, which is almost identical to the former. Also, the latter statement isn't really 100% valid, since Debian will still run without the ndiswrapper driver. It just won't be able to connect to wireless networks. As far as the second statement being the reason that most of us want ndiswrapper in main, that may be true, but it is no excuse to ignore rules that are very clearly laid out in the SC and DFSG. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
Adam McKenna [EMAIL PROTECTED] writes: As far as the second statement being the reason that most of us want ndiswrapper in main, that may be true, but it is no excuse to ignore rules that are very clearly laid out in the SC and DFSG. I'm a little confused here. How does putting ndiswrapper in contrib violate the SC or the DFSG? It's not as if it's being labelled non-free. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#353277: ndiswrapper in main
On 22 Feb 2006, Steve Langasek told this: On Wed, Feb 22, 2006 at 10:41:35AM -0600, Manoj Srivastava wrote: On 22 Feb 2006, Steve Langasek verbalised: What makes 'running free windows drivers for stuff' so much more unrealistic than 'running free windows software for stuff'? Especially seen as how no Windows software is packaged for Debian, so that our users would have to do this themselves? I can, personally, point to Free Software that I've run under Wine on Debian. I can't do the same for free drivers running under ndiswrapper, and I don't see that anyone else in this discussion has done so either. That makes the second case a hypothetical, and IMHO it seems to be a contrived one. To me it seems odd that the freedom of a work can be deterined by whether or not there are thirs party works licensed appropriately or not. So I am coming down on the side of treating emulatrs and works that implement abswtract interfaces/protocols licensed freely as free, in the manner of wine. ndiswrapper seems to fall close to that, since it is not specific to any particular driver out there. The distinction between main and contrib isn't one of the freeness of the contents, though; it's of whether the package requires a component outside of Debian/main for use. Actually, let's look at what policy says: 2.2.2. The contrib section -- [...] Examples of packages which would be included in _contrib_ are: * free packages which require _contrib_, _non-free_ packages or packages which are not in our archive at all for compilation or execution, and * wrapper packages or other sorts of free accessories for non-free programs. ndiswrapper doesn't really require any non-free packages for execution; it requires *some* NDIS driver, but it's probably not useful to package those and definitely not useful for ndiswrapper to depend on a particular one of them. So I guess this makes it a question of whether ndiswrapper is a free wrapper package for non-free programs. Well, the name suggests that it is a wrapper. :) Is it a wrapper for non-free software? That is certainly my understanding of it. I guess this is where we diverge. ndiswrapper is indeed a free wrapper package for drivers. Are the drivers that can run on it free or not? Well, they do not need to be. Since ndiswrapper does not only install specific software, unlike the sun jdk installers we have around. So, ndiswrpaper is a wrapper around software drivers that work on windows -- and these drivers can be distributed under whatever licenses their authors desire. Even if free NDIS drivers do exist (and we know that they do), I've heard enough negative comments about the quality of the ndiswrapper shim that I can't really believe that a sane person will want to use it as anything other than a wrapper for non-free drivers. I am afraid I do not see this. If there is a free windows driver for some hardware I own, I am far more likely to use a wrapper than try and port the driver on my own -- kernel driver writing is not how I tend to spend my time. So I have a hard time defending ndiswrapper-in-main on policy grounds. I think most of the people saying it belongs in main are really concerned that putting it in contrib will mean it's less well supported in Debian; it'd be nice if those concerns led to better support/integration for contrib, instead of arguments about where the line should be... I am not one of these people. I honestly think that ndiswrapper is free on its own merits. manoj -- I love you more than anything in this world. I don't expect that will last. Elvis Costello Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sysklogd -17.1 NMU build broken in mips/mipsel
On Wed, 22 Feb 2006, Chris Stromsoe wrote: for the entire lifetime of the current stable release. Will -17.1 be making its way into stable any time soon? I seriously doubt so. Changing the stable sysklogd requires an upload to stable (which did not happen), and that the stable release manager approves it. Also, mips and mipsel have failed to build sysklogd -17.1, probably due to toolchain borkage: In file included from /usr/include/asm/atomic.h:26, from module.h:31, from ksym_mod.c:97: /usr/include/asm/cpu-features.h:15:35: error: cpu-feature-overrides.h: No such file or directory Maybe that crap is fixed already in mips/mipsel, and a rebuild request/binNMU request for sysklogd should be done to address that? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sysklogd -17.1 NMU build broken in mips/mipsel
On Thu, Feb 23, 2006 at 12:22:27AM -0300, Henrique de Moraes Holschuh wrote: On Wed, 22 Feb 2006, Chris Stromsoe wrote: for the entire lifetime of the current stable release. Will -17.1 be making its way into stable any time soon? I seriously doubt so. Changing the stable sysklogd requires an upload to stable (which did not happen), and that the stable release manager approves it. Also, mips and mipsel have failed to build sysklogd -17.1, probably due to toolchain borkage: In file included from /usr/include/asm/atomic.h:26, from module.h:31, from ksym_mod.c:97: /usr/include/asm/cpu-features.h:15:35: error: cpu-feature-overrides.h: No such file or directory Maybe that crap is fixed already in mips/mipsel, and a rebuild request/binNMU request for sysklogd should be done to address that? $ dpkg -c l/linux-kernel-headers/linux-kernel-headers_2.6.13+0rc3-2_mips.deb |grep cpu-feature -rw-r--r-- root/root 4858 2005-07-12 21:46:46 ./usr/include/asm/cpu-features.h -rw-r--r-- root/root 414 2005-07-12 21:46:46 ./usr/include/asm/mach-generic/cpu-feature-overrides.h -rw-r--r-- root/root 836 2005-07-12 21:46:46 ./usr/include/asm/mach-ip22/cpu-feature-overrides.h -rw-r--r-- root/root 1039 2005-07-12 21:46:46 ./usr/include/asm/mach-ip27/cpu-feature-overrides.h -rw-r--r-- root/root 1215 2005-07-12 21:46:46 ./usr/include/asm/mach-ip32/cpu-feature-overrides.h -rw-r--r-- root/root 1200 2005-07-12 21:46:46 ./usr/include/asm/mach-ja/cpu-feature-overrides.h -rw-r--r-- root/root 1909 2005-07-12 21:46:46 ./usr/include/asm/mach-mips/cpu-feature-overrides.h -rw-r--r-- root/root 1321 2005-07-12 21:46:46 ./usr/include/asm/mach-ocelot3/cpu-feature-overrides.h -rw-r--r-- root/root 1284 2005-07-12 21:46:46 ./usr/include/asm/mach-rm200/cpu-feature-overrides.h -rw-r--r-- root/root 1042 2005-07-12 21:46:46 ./usr/include/asm/mach-sibyte/cpu-feature-overrides.h -rw-r--r-- root/root 1218 2005-07-12 21:46:46 ./usr/include/asm/mach-yosemite/cpu-feature-overrides.h $ It looks to me like this is still broken on mips. A bug on l-k-h is probably in order. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Bug#353277: ndiswrapper in main
On Wed, Feb 22, 2006 at 05:55:01PM -0800, Thomas Bushnell BSG wrote: Adam McKenna [EMAIL PROTECTED] writes: As far as the second statement being the reason that most of us want ndiswrapper in main, that may be true, but it is no excuse to ignore rules that are very clearly laid out in the SC and DFSG. I'm a little confused here. Not surprising. How does putting ndiswrapper in contrib violate the SC or the DFSG? Who said that it did? --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mirror split, amd64 update
On Thu, 23 Feb 2006 08:40, Anthony Towns wrote: Hi all, The mirror split's underway, see: http://lists.debian.org/debian-mirrors-announce/2006/02/msg0.html As expected, when it's complete amd64 will be added to the archive, see: http://lists.debian.org/debian-amd64/2006/02/msg00382.html Quoting from above; (b) if you are mirroring from ftp.debian.org, and wish to *continue* mirroring all architectures, or choose specific architectures that your users are interested in, you should make sure you are mirroring with rsync (not using wget or similar over http, nor using ftp), and immediately switch to using the debian-all rsync module, instead of the debian rsync module. That is: rsync ... rsync://ftp.debian.org/debian/ /mirror/debian/ becomes: rsync ... rsync://ftp.debian.org/debian-all/ /mirror/debian/ I have built up a fine-grained mirroring script over time which not only selects the architecture but also the version (stable, testing etc) to be mirrored. Unfortunately this script will require ftp/http access to ../debian-all. Is there any reason to restrict access to ../debian-all to rsync? Phil. -- Philip Charles; 39a Paterson Street, Abbotsford, Dunedin, New Zealand +64 3 488 2818Fax +64 3 488 2875Mobile 025 267 9420 [EMAIL PROTECTED] - preferred. [EMAIL PROTECTED] I sell GNU/Linux GNU/Hurd CDs DVDs. See http://www.copyleft.co.nz
Re: Bug#353277: ndiswrapper in main
On Wed, Feb 22, 2006 at 05:29:35PM -0800, Steve Langasek wrote: The distinction between main and contrib isn't one of the freeness of the contents, though; it's of whether the package requires a component outside of Debian/main for use. Actually, let's look at what policy says: Agreed; but the definition of 'require' should be made clear. Debian is an exception as an operating system, since it contains a huge load of application software; most operating systems do not. Do you require at least one application package to run an operating system such as Windows or MacOS? No. Is it useful without that? Less so. The same is true for ndiswrapper, I'd say. [...] ndiswrapper doesn't really require any non-free packages for execution; it requires *some* NDIS driver, but it's probably not useful to package those and definitely not useful for ndiswrapper to depend on a particular one of them. So I guess this makes it a question of whether ndiswrapper is a free wrapper package for non-free programs. Well, the name suggests that it is a wrapper. :) If I rename nbd-server to disk-wrapper, does that make it a wrapper? Is it a wrapper for non-free software? That is certainly my understanding of it. A wrapper, as used in policy, is a little script or similar that will set up an environment (LD_LIBRARY_PATH, LD_PRELOAD, PATH, etc) and then just run the application. ndiswrapper isn't even in the same ballpark. Even if free NDIS drivers do exist (and we know that they do), I've heard enough negative comments about the quality of the ndiswrapper shim that I can't really believe that a sane person will want to use it as anything other than a wrapper for non-free drivers. Debian also exists for non-sane people. So I have a hard time defending ndiswrapper-in-main on policy grounds. I think most of the people saying it belongs in main are really concerned that putting it in contrib will mean it's less well supported in Debian; Not in my case; I just think it's the right thing to do. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ITA pimppa
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi gadek! :-) On 2/23/06, Gregory B. Prokopsky [EMAIL PROTECTED] wrote: PS: xnc is still up for grabs. May I pick this up then, if no else has done it first? Cheers, Zakame - -- Zak B. Elep || http://zakame.spunge.org [EMAIL PROTECTED] || [EMAIL PROTECTED] 1486 7957 454D E529 E4F1 F75E 5787 B1FD FA53 851D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFD/VqKV4ex/fpThR0RAnD2AJ0c2tbyXq/K4eZ/lTFP4aF3UlBK8gCeO4e3 PVKTCz2/VWvtPspFMC+zN0M= =rRoL -END PGP SIGNATURE-
Accepted gitweb 264-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 07:07:27 + Source: gitweb Binary: gitweb Architecture: source all Version: 264-1 Distribution: unstable Urgency: low Maintainer: Andres Salomon [EMAIL PROTECTED] Changed-By: Andres Salomon [EMAIL PROTECTED] Description: gitweb - web-based git version control system browser Closes: 344936 Changes: gitweb (264-1) unstable; urgency=low . * New upstream release (closes: #344936). * Update deps to use git-core, and update package description to not mention cogito. * Update patches/gitweb.conf.patch. Files: e608f9339e1a0b7aa03b04e80575ea9a 567 devel optional gitweb_264-1.dsc b77b3f435c288a666a5d56ed49a555af 15629 devel optional gitweb_264.orig.tar.gz 8aef3efbc542c0db064fc72e3fe78a03 2132 devel optional gitweb_264-1.diff.gz cb56b14c843e15e228fd157274751199 18602 devel optional gitweb_264-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFD/BbwOmXwGc/ULyYRApsCAJ9Onfj6VaYB8vQhugrphNNuUaM67ACfZ6X0 9hHabY5o81EyAqJnHbY/Yhc= =Dzvp -END PGP SIGNATURE- Accepted: gitweb_264-1.diff.gz to pool/main/g/gitweb/gitweb_264-1.diff.gz gitweb_264-1.dsc to pool/main/g/gitweb/gitweb_264-1.dsc gitweb_264-1_all.deb to pool/main/g/gitweb/gitweb_264-1_all.deb gitweb_264.orig.tar.gz to pool/main/g/gitweb/gitweb_264.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted polyxmass-bin 0.9.2-1 (source sparc all)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Format: 1.7 Date: Tue, 21 Feb 2006 10:17:46 +0100 Source: polyxmass-bin Binary: polyxmass-bin-common polyxmass-bin Architecture: source sparc all Version: 0.9.2-1 Distribution: unstable Urgency: low Maintainer: Filippo Rusconi [EMAIL PROTECTED] Changed-By: Filippo Rusconi [EMAIL PROTECTED] Description: polyxmass-bin - Mass spectrometry framework - GUI program polyxmass-bin-common - Mass spectrometry framework - GUI program arch-indep data Changes: polyxmass-bin (0.9.2-1) unstable; urgency=low . * New upstream release that fixes one bug with the window management utility and reporting facility of searched masses results (and found masses thereof). * Changed dependency to polyxmass-bin so as to force the install of the new gui layout definition glade file(s). * Sponsored upload done by Lionel Elie Mamane [EMAIL PROTECTED] Files: 670147126192fabfa69ee139a41dea76 778 science optional polyxmass-bin_0.9.2-1.dsc 12ef6f1dc89adc049503490039d6b6dc 996106 science optional polyxmass-bin_0.9.2.orig.tar.gz 381ec213b6b06f2388cf72725ad0d3e7 3619 science optional polyxmass-bin_0.9.2-1.diff.gz 33b2f0a0815c43cd530fbac6a1188b89 176020 science optional polyxmass-bin-common_0.9.2-1_all.deb 56b6375d57b382b2677f9b551e1f25e0 287950 science optional polyxmass-bin_0.9.2-1_sparc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iEYEAREDAAYFAkP8H8oACgkQscRzFz57S3MzvQCcCTE2VuLtoYgBcEVp+T6vEqUU +CkAnRucqYdhC9lpIYEUKeJ7FMlawpor =LUoM -END PGP SIGNATURE- Accepted: polyxmass-bin-common_0.9.2-1_all.deb to pool/main/p/polyxmass-bin/polyxmass-bin-common_0.9.2-1_all.deb polyxmass-bin_0.9.2-1.diff.gz to pool/main/p/polyxmass-bin/polyxmass-bin_0.9.2-1.diff.gz polyxmass-bin_0.9.2-1.dsc to pool/main/p/polyxmass-bin/polyxmass-bin_0.9.2-1.dsc polyxmass-bin_0.9.2-1_sparc.deb to pool/main/p/polyxmass-bin/polyxmass-bin_0.9.2-1_sparc.deb polyxmass-bin_0.9.2.orig.tar.gz to pool/main/p/polyxmass-bin/polyxmass-bin_0.9.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted postfix-policyd 1.70-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 09:11:29 +0100 Source: postfix-policyd Binary: postfix-policyd Architecture: source i386 Version: 1.70-2 Distribution: unstable Urgency: low Maintainer: OndÅej Surý [EMAIL PROTECTED] Changed-By: OndÅej Surý [EMAIL PROTECTED] Description: postfix-policyd - anti-spam plugin for Postfix Closes: 325322 331254 343798 Changes: postfix-policyd (1.70-2) unstable; urgency=low . * Upgrade build-dependency to libmysqlclient15-dev (Closes: #343798) * Upload to unstable (Closes: #325322) * Updated README.Debian (Closes: #331254) Files: 90e4082287150aff228edddaac568891 644 mail optional postfix-policyd_1.70-2.dsc 44499f54bb2780c7af74c510435f717f 9709 mail optional postfix-policyd_1.70-2.diff.gz c8754d8b4cf31f356a490d02cb464cb7 62396 mail optional postfix-policyd_1.70-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFD/B0+9OZqfMIN8nMRAmDEAJ48sFEN/SN3BJNBTq2Jwzr+0SNhdwCdHfk/ vz9CiYkFDr/rqHROalmicqI= =1RX7 -END PGP SIGNATURE- Accepted: postfix-policyd_1.70-2.diff.gz to pool/main/p/postfix-policyd/postfix-policyd_1.70-2.diff.gz postfix-policyd_1.70-2.dsc to pool/main/p/postfix-policyd/postfix-policyd_1.70-2.dsc postfix-policyd_1.70-2_i386.deb to pool/main/p/postfix-policyd/postfix-policyd_1.70-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted poppler 0.4.5-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 09:36:36 +0100 Source: poppler Binary: libpoppler-glib-dev poppler-utils libpoppler0c2-qt libpoppler-qt-dev libpoppler-dev libpoppler0c2-glib libpoppler0c2 Architecture: source i386 Version: 0.4.5-3 Distribution: unstable Urgency: low Maintainer: OndÅej Surý [EMAIL PROTECTED] Changed-By: OndÅej Surý [EMAIL PROTECTED] Description: libpoppler-dev - PDF rendering library -- development files libpoppler-glib-dev - PDF rendering library -- development files (GLib interface) libpoppler-qt-dev - PDF rendering library -- development files (Qt interface) libpoppler0c2 - PDF rendering library libpoppler0c2-glib - PDF rendering library (GLib-based shared library) libpoppler0c2-qt - PDF rendering library (Qt-based shared library) poppler-utils - PDF utilitites (based on libpoppler) Closes: 340379 347423 347652 348511 348869 348980 349371 351070 353444 Changes: poppler (0.4.5-3) unstable; urgency=low . * Disable cairo output for unstable, cairo rendering will stay enabled in cairo version in experimental. (Closes: #349371, #347652, #348511, #348869, #348980, #347423, #340379, #351070, #353444) Files: debc790fde461cbbcfc267d320d006c0 1732 devel optional poppler_0.4.5-3.dsc e335db04a3d24d030c03bf19ce5ea266 494140 devel optional poppler_0.4.5-3.diff.gz 8cd32f8c538034c6eb6597ce66495cbf 438576 libs optional libpoppler0c2_0.4.5-3_i386.deb 63195d934837d425508431f9a3509793 575208 libdevel optional libpoppler-dev_0.4.5-3_i386.deb c4c5e2a51a463f264705d82a38e49a81 40026 libs optional libpoppler0c2-glib_0.4.5-3_i386.deb ce4edbf5fcde69f1794da692d4503f29 43680 libdevel optional libpoppler-glib-dev_0.4.5-3_i386.deb 36679f106a7ee12e5e6296d23efbd324 28730 libs optional libpoppler0c2-qt_0.4.5-3_i386.deb c90b96d95ce94d572710c99b02ffeb31 29610 libdevel optional libpoppler-qt-dev_0.4.5-3_i386.deb a1fb73ef593ed3f977498aec2d7b03a0 80340 utils optional poppler-utils_0.4.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFD/CQN9OZqfMIN8nMRAsvgAKCtZG1PlxeuHqY3zMtJ8M/+8hP4ZQCdHdi7 V+YDIZmHuya7mpOO87vi+vk= =i/73 -END PGP SIGNATURE- Accepted: libpoppler-dev_0.4.5-3_i386.deb to pool/main/p/poppler/libpoppler-dev_0.4.5-3_i386.deb libpoppler-glib-dev_0.4.5-3_i386.deb to pool/main/p/poppler/libpoppler-glib-dev_0.4.5-3_i386.deb libpoppler-qt-dev_0.4.5-3_i386.deb to pool/main/p/poppler/libpoppler-qt-dev_0.4.5-3_i386.deb libpoppler0c2-glib_0.4.5-3_i386.deb to pool/main/p/poppler/libpoppler0c2-glib_0.4.5-3_i386.deb libpoppler0c2-qt_0.4.5-3_i386.deb to pool/main/p/poppler/libpoppler0c2-qt_0.4.5-3_i386.deb libpoppler0c2_0.4.5-3_i386.deb to pool/main/p/poppler/libpoppler0c2_0.4.5-3_i386.deb poppler-utils_0.4.5-3_i386.deb to pool/main/p/poppler/poppler-utils_0.4.5-3_i386.deb poppler_0.4.5-3.diff.gz to pool/main/p/poppler/poppler_0.4.5-3.diff.gz poppler_0.4.5-3.dsc to pool/main/p/poppler/poppler_0.4.5-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted numactl 0.9.3-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 10:47:02 +1100 Source: numactl Binary: libnuma1 libnuma-dev numactl Architecture: source i386 Version: 0.9.3-2 Distribution: unstable Urgency: low Maintainer: Ian Wienand [EMAIL PROTECTED] Changed-By: Ian Wienand [EMAIL PROTECTED] Description: libnuma-dev - Development files for libnuma libnuma1 - Libraries for controlling NUMA policy numactl- NUMA scheduling and memory placement tool Closes: 350596 Changes: numactl (0.9.3-2) unstable; urgency=low . * Add libdir target in rules to override upstream biarch detection . numactl (0.9.3-1) unstable; urgency=low . * New upstream * Remove __thread detection patch (fixed upstream) . numactl (0.9.2-1) unstable; urgency=low . * New upstream * Closes: #350596 -- check for __thread support * Upstream handles /lib64 better; remove patch we had to deal with that. * Add a patch to work around a problem with __thread detection Files: 825067fc12ba48a7c07b2067ca5b6e78 688 admin optional numactl_0.9.3-2.dsc 6d5dd77c191f104a1df11f1603d214b3 46865 admin optional numactl_0.9.3.orig.tar.gz 2fe7c334a72a3f04e9a62f78a02ff5d5 3850 admin optional numactl_0.9.3-2.diff.gz 6b17c500cab921bd944df47d2dc9221c 23936 admin optional numactl_0.9.3-2_i386.deb e08cb0aa184f8e4c991b7bb28c2be97b 14234 libs optional libnuma1_0.9.3-2_i386.deb b601dbfe87b371fb0a37a8ee1e8b2d3f 19976 libdevel extra libnuma-dev_0.9.3-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/DQ7xa93SlhRC1oRAkP6AJ9PERsJ3PGpAt8LHAvEZjjc7myEmQCfRIVo 4b77t6x5poI9JIdSLEaUFak= =31mc -END PGP SIGNATURE- Accepted: libnuma-dev_0.9.3-2_i386.deb to pool/main/n/numactl/libnuma-dev_0.9.3-2_i386.deb libnuma1_0.9.3-2_i386.deb to pool/main/n/numactl/libnuma1_0.9.3-2_i386.deb numactl_0.9.3-2.diff.gz to pool/main/n/numactl/numactl_0.9.3-2.diff.gz numactl_0.9.3-2.dsc to pool/main/n/numactl/numactl_0.9.3-2.dsc numactl_0.9.3-2_i386.deb to pool/main/n/numactl/numactl_0.9.3-2_i386.deb numactl_0.9.3.orig.tar.gz to pool/main/n/numactl/numactl_0.9.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-apt 0.6.16.1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 10:41:13 +0100 Source: python-apt Binary: python2.3-apt python2.4-apt python-apt Architecture: source all i386 Version: 0.6.16.1 Distribution: unstable Urgency: low Maintainer: APT Development Team deity@lists.debian.org Changed-By: Michael Vogt [EMAIL PROTECTED] Description: python-apt - Python interface to libapt-pkg python2.3-apt - Python interface to libapt-pkg python2.4-apt - Python interface to libapt-pkg Changes: python-apt (0.6.16.1) unstable; urgency=low . * memleak fixed when pkgCache objects are deallocated * typos fixed (thanks to Gustavo Franco) * pkgRecords.Record added to get raw record data * python/cache.cc: key in pkgCache::VerIterator.DependsList[key] is no longer locale specific but always english Files: 41fbfc9a4a0f81eed4a1e94ce13c4eca 705 python optional python-apt_0.6.16.1.dsc ce0a754dedc220622fb6201f04a0218c 60059 python optional python-apt_0.6.16.1.tar.gz a7621d6fe8ad5cfaa2d2c99bb086cbd3 14508 python optional python-apt_0.6.16.1_all.deb 0944ae1b782fa642688b4af6660ea5ef 72932 python optional python2.3-apt_0.6.16.1_i386.deb b50165e09feaa865b7cfe66131c49b43 72928 python optional python2.4-apt_0.6.16.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/DdpliSD4VZixzQRAoQWAJwKuIBf0bxbH1Co2qv8Nj5BicUGVgCeIRbo wJOXILol6B5o8oQuXSMvwOo= =xEIB -END PGP SIGNATURE- Accepted: python-apt_0.6.16.1.dsc to pool/main/p/python-apt/python-apt_0.6.16.1.dsc python-apt_0.6.16.1.tar.gz to pool/main/p/python-apt/python-apt_0.6.16.1.tar.gz python-apt_0.6.16.1_all.deb to pool/main/p/python-apt/python-apt_0.6.16.1_all.deb python2.3-apt_0.6.16.1_i386.deb to pool/main/p/python-apt/python2.3-apt_0.6.16.1_i386.deb python2.4-apt_0.6.16.1_i386.deb to pool/main/p/python-apt/python2.4-apt_0.6.16.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apt 0.6.43.3 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 10:13:04 +0100 Source: apt Binary: apt-utils libapt-pkg-doc libapt-pkg-dev apt-doc apt Architecture: source all i386 Version: 0.6.43.3 Distribution: unstable Urgency: low Maintainer: APT Development Team deity@lists.debian.org Changed-By: Michael Vogt [EMAIL PROTECTED] Description: apt- Advanced front-end for dpkg apt-doc- Documentation for APT apt-utils - APT utility programs libapt-pkg-dev - Development files for APT's libapt-pkg and libapt-inst libapt-pkg-doc - Documentation for APT development Closes: 348968 349084 349154 349210 349407 349474 349514 349806 350483 351592 352419 352803 353936 Changes: apt (0.6.43.3) unstable; urgency=low . * Merge [EMAIL PROTECTED]/apt--main--0 up to patch-186: * ca.po: Completed to 512t. Closes: #351592 * eu.po: Completed to 512t. Closes: #350483 * ja.po: Completed to 512t. Closes: #349806 * pl.po: Completed to 512t. Closes: #349514 * sk.po: Completed to 512t. Closes: #349474 * gl.po: Completed to 512 strings Closes: #349407 * sv.po: Completed to 512 strings Closes: #349210 * ru.po: Completed to 512 strings Closes: #349154 * da.po: Completed to 512 strings Closes: #349084 * fr.po: Completed to 512 strings * vi.po: Completed to 511 strings Closes: #348968 * zh_CN.po: Completed to 512t. Closes: #353936 * it.po: Completed to 512t. Closes: #352803 * pt_BR.po: Completed to 512t. Closes: #352419 * LINGUAS: Add Welsh * *.po: Updated from sources (512 strings) * apt-pkg/deb/deblistparser.cc: - don't explode on a DepCompareOp in a Provides line, but warn about it and ignore it otherwise (thanks to James Troup for reporting it) * cmdline/apt-get.cc: - don't lock the lists directory in DoInstall, breaks --print-uri (thanks to James Troup for reporting it) * debian/apt.dirs: create /etc/apt/sources.list.d * make apt-cache madison work without deb-src entries (#352583) * cmdline/apt-get.cc: only run the list-cleaner if a update was successfull Files: 0660d7782d93d2078421f404dd60014e 789 admin important apt_0.6.43.3.dsc 7d607342ffce8ba8705ae7797cb1a15c 1544598 admin important apt_0.6.43.3.tar.gz 28e259d9e6f4fbd1fcd683d6b9ffb4c0 87054 doc optional apt-doc_0.6.43.3_all.deb 7530ddb0ee3f2d6e4f615bea91ab8920 110442 doc optional libapt-pkg-doc_0.6.43.3_all.deb d2c5c97b96474ee6b84afc9d63b27dae 1304776 admin important apt_0.6.43.3_i386.deb c9ccb080898bba6866570431db1f5899 80654 libdevel optional libapt-pkg-dev_0.6.43.3_i386.deb 2413c485dd43f5cf91d5f3b030b5f86a 195916 admin important apt-utils_0.6.43.3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/DcEliSD4VZixzQRAjPjAJ9zKVJq0plwbGGcRVG3vfu/kz63JACaA5Ne pziNO7PytUxS6bRCje1KzAU= =1Xb0 -END PGP SIGNATURE- Accepted: apt-doc_0.6.43.3_all.deb to pool/main/a/apt/apt-doc_0.6.43.3_all.deb apt-utils_0.6.43.3_i386.deb to pool/main/a/apt/apt-utils_0.6.43.3_i386.deb apt_0.6.43.3.dsc to pool/main/a/apt/apt_0.6.43.3.dsc apt_0.6.43.3.tar.gz to pool/main/a/apt/apt_0.6.43.3.tar.gz apt_0.6.43.3_i386.deb to pool/main/a/apt/apt_0.6.43.3_i386.deb libapt-pkg-dev_0.6.43.3_i386.deb to pool/main/a/apt/libapt-pkg-dev_0.6.43.3_i386.deb libapt-pkg-doc_0.6.43.3_all.deb to pool/main/a/apt/libapt-pkg-doc_0.6.43.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmail-spf-query-perl 1.999-1 (source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 9 Feb 2006 18:57:24 +
Source: libmail-spf-query-perl
Binary: libmail-spf-query-perl
Architecture: source all
Version: 1.999-1
Distribution: unstable
Urgency: low
Maintainer: Debian Perl Group [EMAIL PROTECTED]
Changed-By: Julian Mehnle [EMAIL PROTECTED]
Description:
libmail-spf-query-perl - query SPF (Sender Policy Framework) to validate mail
senders
Closes: 351030
Changes:
libmail-spf-query-perl (1.999-1) unstable; urgency=low
.
Debian:
* Build-Depend, not Build-Depend-Indep, on debhelper. Also, depend on
debhelper = 5.
* Build-Depend-Indep on netbase to allow testing to work when building in a
pbuilder chroot (closes: #351030).
.
Mail::SPF::Query:
* No longer accept malformed SPF records such as \v=spf1 ...\ (spurious
double quotes) or v=spf1 ... (leading whitespace).
* Combine multiple TXT strings into a single string _before_ fallbacks are
tried. Thus, fallbacks now also get applied if there are only non-
v=spf1 TXT records; this wasn't the case before.
* Guard against non-numeric cidr-lengths (closes rt.cpan.org bug #17061).
* Flattened the { 'domain' = { record = '...' } } override and fallback
argument format to just { 'domain' = '...' }. The old format is still
supported for backwards compatibility.
* Added a BUGS section to the man-page documenting M:S:Q's known
deficiencies.
* Lots of minor code improvements.
.
spfquery:
* Correctly recognize the --mail-from (AKA --sender) option. The version
in the M:S:Q 1.998 release was broken in this regard.
* Actually require the --helo option for the --mail-from (AKA --sender)
form.
* Cleaned up command-line argument validation code.
* Cleaned up the inconsistent short and long (--help) usage and man-page
texts.
* Clarified the file input syntax in the help and man-page texts.
* The --override and --fallback options are now actually working and
documented.
.
Tests:
* Overhauled 00_all.t test script:
* Don't skip tests when a non-last test in a test tuple fails (this made
test 223 fail, for example, because Test::Harness thought that some
planned tests were not performed).
* Marked test 219 (SERVFAIL) as non-critical, because it isn't completely
reliable (sometimes, apparently behind some NATs and firewalls, the
query just times out instead of returning SERVFAIL) (closes rt.cpan.org
bug #17099).
* Generate and collect debug log output (internally) along with the normal
M:S:Q-result() calls right away, so that extra just-to-get-debug-output
M:S:Q-result() calls can be saved. Also we can make debug log output
Test::Harness-compatible this way by printing it ourselves with '#'
chars at the beginnings of lines.
* Cleaned up code.
* Cleaned up comments in t/test.dat test data file.
Files:
68a84a4c9a15385a3964b91f8ba1590d 759 perl optional
libmail-spf-query-perl_1.999-1.dsc
c99281f8f1d6d718a7781cc5cd0c46b9 55071 perl optional
libmail-spf-query-perl_1.999-1.tar.gz
adaa74bd37c2750d97b917c6e48d703a 70536 perl optional
libmail-spf-query-perl_1.999-1_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD/Dz9+NMfSd6w7DERAsptAJ99dcJj95UyAGc0W3tDx6qOz/YoowCfUXYF
mHbS7e4eYPcQGsEsp4yRP+k=
=36ji
-END PGP SIGNATURE-
Accepted:
libmail-spf-query-perl_1.999-1.dsc
to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999-1.dsc
libmail-spf-query-perl_1.999-1.tar.gz
to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999-1.tar.gz
libmail-spf-query-perl_1.999-1_all.deb
to
pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999-1_all.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libmail-spf-query-perl 1.999eloy-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 11:41:01 +0100 Source: libmail-spf-query-perl Binary: libmail-spf-query-perl Architecture: source all Version: 1.999eloy-1 Distribution: unstable Urgency: low Maintainer: Debian Perl Group [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libmail-spf-query-perl - query SPF (Sender Policy Framework) to validate mail senders Changes: libmail-spf-query-perl (1.999eloy-1) unstable; urgency=low . * Added debian/watch file * Proper upload of orig.tar.gz file * debian/control - added me to Uploaders Files: dbd8d3547e3629c7c276e6e93984bf03 899 perl optional libmail-spf-query-perl_1.999eloy-1.dsc 7d5e7a0141bd3160234585e78e68819e 54874 perl optional libmail-spf-query-perl_1.999eloy.orig.tar.gz 4b2079e14892ee5414d8d9c4b12350c0 1176 perl optional libmail-spf-query-perl_1.999eloy-1.diff.gz b47e511a2a5f6aba2fd27a1ee41c750a 70662 perl optional libmail-spf-query-perl_1.999eloy-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/ECA+NMfSd6w7DERAj9lAKDDL6jFTpEBsQppnTuXqq5ql6rdbACgtrgq 0HzaKKMdA3cvR5w7qnhcLVc= =BUmH -END PGP SIGNATURE- Accepted: libmail-spf-query-perl_1.999eloy-1.diff.gz to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999eloy-1.diff.gz libmail-spf-query-perl_1.999eloy-1.dsc to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999eloy-1.dsc libmail-spf-query-perl_1.999eloy-1_all.deb to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999eloy-1_all.deb libmail-spf-query-perl_1.999eloy.orig.tar.gz to pool/main/libm/libmail-spf-query-perl/libmail-spf-query-perl_1.999eloy.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted exim4 4.60-4 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 10:30:16 + Source: exim4 Binary: eximon4 exim4-daemon-custom exim4-daemon-heavy exim4-base exim4 exim4-daemon-light exim4-config Architecture: source i386 all Version: 4.60-4 Distribution: unstable Urgency: low Maintainer: Exim4 Maintainers [EMAIL PROTECTED] Changed-By: Marc Haber [EMAIL PROTECTED] Description: exim4 - metapackage to ease exim MTA (v4) installation exim4-base - support files for all exim MTA (v4) packages exim4-config - configuration for the exim MTA (v4) exim4-daemon-heavy - exim MTA (v4) daemon with extended features, including exiscan-ac exim4-daemon-light - lightweight exim MTA (v4) daemon eximon4- monitor application for the exim MTA (v4) (X11 interface) Closes: 342619 Changes: exim4 (4.60-4) unstable; urgency=low . * add rationale to README.Debian explaining why using system passwords for SMTP AUTH is a bad idea. * streamline configuration to decrease differences to upstream default example, and to adopt new things that were added since we last looked there. * Do not set inst_aliases for installation, this only affects example.conf anyway. * fail build if upstream's example configuration has changed. * fix NEWS confusion. Thanks to Andreas for spotting this. * exim4-base.exim4.init: invoke exim4 daemon with the environment cleaned to avoid language confusion. * document tls on connect in README.Debian. * use adduser --quiet instead of /dev/null in *.postinst. * Add require_files directive to userforward router to avoid errors when mailing [EMAIL PROTECTED] * Add comment about setting up TLS in conf.d/auth/30_exim4-config_examples to keep people from blindly allowing cleartext auth. * Replace 37_dns_disable_additional_section patch with 37_upstream_patch_342619, which is the nearly identical patch from upstream CVS, approved by Philip. (mh) Closes: #342619 Files: 15e67edef7599d51bb485ea3b89df810 1044 mail standard exim4_4.60-4.dsc e21f380b10ab85ad2ca83c94eb597022 328742 mail standard exim4_4.60-4.diff.gz c6aa04b110079c6d3b51df6933f26464 874938 mail standard exim4-base_4.60-4_i386.deb fa702543806f4dc83209ba3e701ed89c 392892 mail standard exim4-daemon-light_4.60-4_i386.deb 467016a016bed4d3a637230e276fa957 83138 mail optional eximon4_4.60-4_i386.deb 5284b89edd4fca92c4cb4ec0ee8f855b 445188 mail optional exim4-daemon-heavy_4.60-4_i386.deb e50a410d4165c4f4a24fe31001ab4c1e 263966 mail standard exim4-config_4.60-4_all.deb ba5d649c6825b0e6d55d7166c89804e7 1572 mail standard exim4_4.60-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/Eu4gZalRGu6PIQRAo2AAJ9mkteCvEwDqmYkVkrvcPtpUMSR5gCeJ/zw 6UwjhuijeY+Pj/Fu7nc+Zuk= =lgtx -END PGP SIGNATURE- Accepted: exim4-base_4.60-4_i386.deb to pool/main/e/exim4/exim4-base_4.60-4_i386.deb exim4-config_4.60-4_all.deb to pool/main/e/exim4/exim4-config_4.60-4_all.deb exim4-daemon-heavy_4.60-4_i386.deb to pool/main/e/exim4/exim4-daemon-heavy_4.60-4_i386.deb exim4-daemon-light_4.60-4_i386.deb to pool/main/e/exim4/exim4-daemon-light_4.60-4_i386.deb exim4_4.60-4.diff.gz to pool/main/e/exim4/exim4_4.60-4.diff.gz exim4_4.60-4.dsc to pool/main/e/exim4/exim4_4.60-4.dsc exim4_4.60-4_all.deb to pool/main/e/exim4/exim4_4.60-4_all.deb eximon4_4.60-4_i386.deb to pool/main/e/exim4/eximon4_4.60-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gstreamer0.10-ffmpeg 0.10.0-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 12:22:20 +0100 Source: gstreamer0.10-ffmpeg Binary: gstreamer0.10-ffmpeg Architecture: source i386 Version: 0.10.0-3 Distribution: unstable Urgency: low Maintainer: Maintainers of GStreamer packages [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: gstreamer0.10-ffmpeg - FFmpeg plugin for GStreamer Closes: 353045 Changes: gstreamer0.10-ffmpeg (0.10.0-3) unstable; urgency=low . * Fix missing symbols when registering the ffmpeg plugin, caused by the use of --disable-encoders and buggy #ifdef CONFIG_MUXERS in the autoconfed ffmpeg source version of upstream, thanks Sam Morris; this is a temporary workaround while upstream refreshs the ffmpeg snapshot. (Closes: #353045) [debian/patches/40_fix-missing-symbols_config-muxers.patch] Files: ab749bac6f0228a0b6044289edfcc380 906 libs optional gstreamer0.10-ffmpeg_0.10.0-3.dsc eace5c4129369cf1dda6fc0350c5aed8 7679 libs optional gstreamer0.10-ffmpeg_0.10.0-3.diff.gz 7846f9a4cef270171fef693d3a3f93e2 1165490 libs optional gstreamer0.10-ffmpeg_0.10.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/E144VUX8isJIMARAodEAJ9WnzVdOMFF+Ji+XUqX6lqy1+jfFACfayY1 MTvjqmvWj9kUpFM5EIo8Xbg= =QLTX -END PGP SIGNATURE- Accepted: gstreamer0.10-ffmpeg_0.10.0-3.diff.gz to pool/main/g/gstreamer0.10-ffmpeg/gstreamer0.10-ffmpeg_0.10.0-3.diff.gz gstreamer0.10-ffmpeg_0.10.0-3.dsc to pool/main/g/gstreamer0.10-ffmpeg/gstreamer0.10-ffmpeg_0.10.0-3.dsc gstreamer0.10-ffmpeg_0.10.0-3_i386.deb to pool/main/g/gstreamer0.10-ffmpeg/gstreamer0.10-ffmpeg_0.10.0-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted spamprobe 1.4b-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Feb 2006 14:16:42 +0100 Source: spamprobe Binary: spamprobe Architecture: source i386 Version: 1.4b-1 Distribution: unstable Urgency: low Maintainer: Nicolas Duboc [EMAIL PROTECTED] Changed-By: Nicolas Duboc [EMAIL PROTECTED] Description: spamprobe - Bayesian spam filter Closes: 332964 342596 352501 353685 Changes: spamprobe (1.4b-1) unstable; urgency=low . * New upstream release (closes: #342596, #352501, #353685) * Corrected changelog file to include the license declaration * Added Swedish translation of debconf template by Daniel Nylander. (closes: #332964) * Build depends on libungif4-dev (for scanning of GIF attachments) * Actually include the debian/NEWS file. * Build man page in 'build' target (and not 'install') * Removed the README.txt because the man page is a better reference for the users. * Updated description to advertise the GIF feature. * Updated the man page. Files: f63ea0abbad7fb9766f2637448d827de 603 mail optional spamprobe_1.4b-1.dsc 735a5ef084ca09a39fb88a0334fcc68e 255023 mail optional spamprobe_1.4b.orig.tar.gz 8f03ce1240870320c7bb64e8c2176cc0 22993 mail optional spamprobe_1.4b-1.diff.gz 26977ec125e4a566f1db169472078668 218286 mail optional spamprobe_1.4b-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/FBOEAlStfgBp0MRAhNyAJ9AZHPcrz28+wavU0sXuaRKW9TJXACfZIJC U/GmNNDFZTFppK519ozHkuw= =AElz -END PGP SIGNATURE- Accepted: spamprobe_1.4b-1.diff.gz to pool/main/s/spamprobe/spamprobe_1.4b-1.diff.gz spamprobe_1.4b-1.dsc to pool/main/s/spamprobe/spamprobe_1.4b-1.dsc spamprobe_1.4b-1_i386.deb to pool/main/s/spamprobe/spamprobe_1.4b-1_i386.deb spamprobe_1.4b.orig.tar.gz to pool/main/s/spamprobe/spamprobe_1.4b.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted scorched3d 39.1+cvs20050929-2 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 09:50:25 +0100 Source: scorched3d Binary: scorched3d scorched3d-data scorched3d-doc Architecture: source i386 all Version: 39.1+cvs20050929-2 Distribution: unstable Urgency: high Maintainer: Bartosz Fenski [EMAIL PROTECTED] Changed-By: Bartosz Fenski [EMAIL PROTECTED] Description: scorched3d - 3D artillery game similar to Scorched Earth scorched3d-data - data files for Scorched3D game scorched3d-doc - documentation for Scorched3D game Closes: 265917 288578 333888 334574 337403 Changes: scorched3d (39.1+cvs20050929-2) unstable; urgency=high . * Urgency high due to multiple vurnerability fixes. * Applied many patches by courtesy of Hans de Goede: - fixes all known vulnerabilities: (Closes: #337403) See CVE-2005-3488, CVE-2005-3487, CVE-2005-3486 for details. - fixes compilation issues on 64bit archs. (Closes: #288578) - fixes running issues on 64bit archs. (Closes: #265917) * Fixes in desktop file. (Closes: #333888) * Added versioned dependency on openal. (Closes: #334574) Files: d5920513011045146ef14162f7f1b678 843 games optional scorched3d_39.1+cvs20050929-2.dsc 8a103a8d99f141a8b9406b881f4af949 48377 games optional scorched3d_39.1+cvs20050929-2.diff.gz b011dd95d8aa20851e1c10a9c7699338 33746326 games optional scorched3d-data_39.1+cvs20050929-2_all.deb dc4d054347a297b8151b03481aabdb57 1085476 games optional scorched3d-doc_39.1+cvs20050929-2_all.deb c762eefa699aa5b61d3823cd2fe0334f 1027564 games optional scorched3d_39.1+cvs20050929-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/Ee2hQui3hP+/EARAkmMAKDTmsp+be2MkTnRJ1Efpk22iqUEpwCfUJfa ADwaj2ygSM9mpXrGZ7TWidA= =CVyt -END PGP SIGNATURE- Accepted: scorched3d-data_39.1+cvs20050929-2_all.deb to pool/main/s/scorched3d/scorched3d-data_39.1+cvs20050929-2_all.deb scorched3d-doc_39.1+cvs20050929-2_all.deb to pool/main/s/scorched3d/scorched3d-doc_39.1+cvs20050929-2_all.deb scorched3d_39.1+cvs20050929-2.diff.gz to pool/main/s/scorched3d/scorched3d_39.1+cvs20050929-2.diff.gz scorched3d_39.1+cvs20050929-2.dsc to pool/main/s/scorched3d/scorched3d_39.1+cvs20050929-2.dsc scorched3d_39.1+cvs20050929-2_i386.deb to pool/main/s/scorched3d/scorched3d_39.1+cvs20050929-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted msort 8.16-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 13:22:28 +0100 Source: msort Binary: msort msort-gui Architecture: source i386 all Version: 8.16-1 Distribution: unstable Urgency: low Maintainer: Bartosz Fenski [EMAIL PROTECTED] Changed-By: Bartosz Fenski [EMAIL PROTECTED] Description: msort - utility for sorting records in complex ways msort-gui - tcl/tk gui for msort utility Changes: msort (8.16-1) unstable; urgency=low . * New upstream release. Files: c52bbc7ed19d6b14347c40e681885275 573 utils optional msort_8.16-1.dsc 1434a3eb9ca49972adee9ef721abe84b 320261 utils optional msort_8.16.orig.tar.gz f6402d6aa379f8b496293257a9845fdb 3163 utils optional msort_8.16-1.diff.gz 522239e89177f27d6222d01520d8479c 162748 utils optional msort_8.16-1_i386.deb 835608aa7fe4c1c3478bc3796c1164d3 76824 utils optional msort-gui_8.16-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/FhchQui3hP+/EARAg71AJ9zkuGBDt92/fTkfcFtvxUa6LDQtgCfcvmi f7J1hVqoEompllFvizs9tGY= =l6W4 -END PGP SIGNATURE- Accepted: msort-gui_8.16-1_all.deb to pool/main/m/msort/msort-gui_8.16-1_all.deb msort_8.16-1.diff.gz to pool/main/m/msort/msort_8.16-1.diff.gz msort_8.16-1.dsc to pool/main/m/msort/msort_8.16-1.dsc msort_8.16-1_i386.deb to pool/main/m/msort/msort_8.16-1_i386.deb msort_8.16.orig.tar.gz to pool/main/m/msort/msort_8.16.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted tex-common 0.16 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 13:43:32 +0100 Source: tex-common Binary: tex-common Architecture: source all Version: 0.16 Distribution: unstable Urgency: low Maintainer: teTeX maintainers debian-tetex-maint@lists.debian.org Changed-By: Frank Küster [EMAIL PROTECTED] Description: tex-common - Common infrastructure for using and building TeX in Debian Closes: 351649 352391 352394 352486 352688 Changes: tex-common (0.16) unstable; urgency=low . * Add dh_installtex for public perusal. [preining] - add dh_installtex and man page - replace dh_installtexfonts by a script converting the syntax - give a warning in the dh_installtexfonts man page * common.functions.in: - Add md5sums for tetex-extra's former configuration files (closes: #351649, #352486) [frank] - Also add some forgotten md5sums for tetex-base, and make sure scripts really stop if the md5sum is unknown (closes: #352688) [frank] - remove LaTeX and pdfLaTeX format files before trying to recreate all format (closes: #352391) [frank] - use different variable names for /var/lib/texmf as a texmf.cnf variable and as a maintainer script variable [frank] * rework debconf usage (Closes: #352394) [preining,frank] - only care for ls-R file permissions of the font cache from now on - manage the group and permissions of /var/cache/fonts * TeX Policy Draft: - document dh_installtex and some additional checks needed in maintainer scripts [florent] - Clarify that some files from the Basic TeX Packages stay in TEXMFMAIN [frank] Files: 0ef2af8d3b120ea6cab1bfbcd262e448 734 tex optional tex-common_0.16.dsc 32ad1312ca3b86b5e50fd314f28f448d 257140 tex optional tex-common_0.16.tar.gz f4329f71834dc221c38110874b180238 240320 tex optional tex-common_0.16_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD/F49+xs9YyJS+hoRAqalAKCr0iQfKZggxoOgo/WTS7gNMWrD6wCcC4FO L6VKjTyiad1hUrNJrPep/lc= =4n2c -END PGP SIGNATURE- Accepted: tex-common_0.16.dsc to pool/main/t/tex-common/tex-common_0.16.dsc tex-common_0.16.tar.gz to pool/main/t/tex-common/tex-common_0.16.tar.gz tex-common_0.16_all.deb to pool/main/t/tex-common/tex-common_0.16_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted loop-aes-utils 2.12r-4 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 01:02:41 +0100 Source: loop-aes-utils Binary: loop-aes-utils mount-aes-udeb Architecture: source i386 Version: 2.12r-4 Distribution: unstable Urgency: low Maintainer: Max Vozeler [EMAIL PROTECTED] Changed-By: Max Vozeler [EMAIL PROTECTED] Description: loop-aes-utils - Tools for mounting and manipulating filesystems mount-aes-udeb - Mount utils for loop-AES (udeb) Changes: loop-aes-utils (2.12r-4) unstable; urgency=low . * Depend on gnupg for loop-aes-keygen * Sync with util-linux 2.12r-7 - Added patches/30nfs4 Files: 19135149a992449c8adda4c2a4a96a79 643 admin optional loop-aes-utils_2.12r-4.dsc eb50109acc42f80165d192954aa9c86f 95013 admin optional loop-aes-utils_2.12r-4.diff.gz e359d926ca9f637b9127f550a0d2fa61 156848 admin optional loop-aes-utils_2.12r-4_i386.deb 26b57761aa246dc65e6faea94c09fd02 96654 debian-installer extra mount-aes-udeb_2.12r-4_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/E6xnVvVEbfNotwRArXOAKCNRd5hTZUW8tzsn+DISuIhqvJBkgCcCujO TqUPPRI6GhbpnSQtSFn5Bvc= =P1wL -END PGP SIGNATURE- Accepted: loop-aes-utils_2.12r-4.diff.gz to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r-4.diff.gz loop-aes-utils_2.12r-4.dsc to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r-4.dsc loop-aes-utils_2.12r-4_i386.deb to pool/main/l/loop-aes-utils/loop-aes-utils_2.12r-4_i386.deb mount-aes-udeb_2.12r-4_i386.udeb to pool/main/l/loop-aes-utils/mount-aes-udeb_2.12r-4_i386.udeb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted psqlodbc 1:08.01.0200-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 15:11:00 +0100 Source: psqlodbc Binary: odbc-postgresql Architecture: source i386 Version: 1:08.01.0200-1 Distribution: unstable Urgency: low Maintainer: Peter Eisentraut [EMAIL PROTECTED] Changed-By: Peter Eisentraut [EMAIL PROTECTED] Description: odbc-postgresql - ODBC driver for PostgreSQL Changes: psqlodbc (1:08.01.0200-1) unstable; urgency=low . * New upstream release * Fixed watch file * Updated download location * Changed build system to build ANSI and Unicode variants; odbcinst template changed accordingly * Dropped legacy driver location /usr/lib/postgresql/lib * Updated README.Debian Files: ae708ae0113bb8e90a1bb8d9891d51e2 630 libs optional psqlodbc_08.01.0200-1.dsc 61206229b5d8dfe5e7a4cf81a7a218da 596219 libs optional psqlodbc_08.01.0200.orig.tar.gz 7e017fd15d2250468d6ece308bd85c84 5059 libs optional psqlodbc_08.01.0200-1.diff.gz 1038a28ae70b162cf0a41c398f080a52 336180 libs optional odbc-postgresql_08.01.0200-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/HdRTTx8oVVPtMYRAlwFAKCKlpYoSsCWQ6BLO/yWTW5whrLhKwCfYoWe nvAk8iF14DKzT86GzWxGLYs= =jgwG -END PGP SIGNATURE- Accepted: odbc-postgresql_08.01.0200-1_i386.deb to pool/main/p/psqlodbc/odbc-postgresql_08.01.0200-1_i386.deb psqlodbc_08.01.0200-1.diff.gz to pool/main/p/psqlodbc/psqlodbc_08.01.0200-1.diff.gz psqlodbc_08.01.0200-1.dsc to pool/main/p/psqlodbc/psqlodbc_08.01.0200-1.dsc psqlodbc_08.01.0200.orig.tar.gz to pool/main/p/psqlodbc/psqlodbc_08.01.0200.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgpod 0.3.0-3 (source powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 2 Jan 2006 08:05:03 +0100 Source: libgpod Binary: libgpod-dev libgpod0 Architecture: source powerpc Version: 0.3.0-3 Distribution: unstable Urgency: high Maintainer: Frank Lichtenheld [EMAIL PROTECTED] Changed-By: Frank Lichtenheld [EMAIL PROTECTED] Description: libgpod-dev - a library to read and write songs and artwork to an iPod libgpod0 - a library to read and write songs and artwork to an iPod Closes: 353590 Changes: libgpod (0.3.0-3) unstable; urgency=high . * Add libgtk2.0-dev and libglib2.0-dev to dependencies of libgpod-dev since these are in fact needed. (Closes: #353590) * Use high urgency for trivial RC bug fix. Files: 20077f827edb24671b598c3fa89f240e 661 libs optional libgpod_0.3.0-3.dsc 4cb7cec120020a90de3bbdc2a9af8e23 2346 libs optional libgpod_0.3.0-3.diff.gz 36d4337be8490d4d86c3fc4e4f1c41d4 96032 libdevel optional libgpod-dev_0.3.0-3_powerpc.deb 4beb56f972a7bd4310a19b6edaf958b9 74384 libs optional libgpod0_0.3.0-3_powerpc.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/HqAQbn06FtxPfARAmVoAJ0Xi9y9yFiyRRot1Cr4zZ3muY9CoQCgpUVp zG4ei3YE5LEtEZQouczGFjA= =JfmL -END PGP SIGNATURE- Accepted: libgpod-dev_0.3.0-3_powerpc.deb to pool/main/libg/libgpod/libgpod-dev_0.3.0-3_powerpc.deb libgpod0_0.3.0-3_powerpc.deb to pool/main/libg/libgpod/libgpod0_0.3.0-3_powerpc.deb libgpod_0.3.0-3.diff.gz to pool/main/libg/libgpod/libgpod_0.3.0-3.diff.gz libgpod_0.3.0-3.dsc to pool/main/libg/libgpod/libgpod_0.3.0-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lastfm 1.1.5-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 21 Feb 2006 14:53:28 -0800 Source: lastfm Binary: lastfm Architecture: source i386 Version: 1.1.5-3 Distribution: unstable Urgency: low Maintainer: Paul Telford [EMAIL PROTECTED] Changed-By: Paul Telford [EMAIL PROTECTED] Description: lastfm - an audio player for last.fm personalized radio Changes: lastfm (1.1.5-3) unstable; urgency=low . * Fixed some broken embedded icons Files: 1aff4e54fab7f91fe2ae29ebc0057680 593 sound optional lastfm_1.1.5-3.dsc 4929bd8d5da13e628878272e7880631f 33800 sound optional lastfm_1.1.5-3.diff.gz 91d5ab974daa359e2d227676f2c0ab5c 537500 sound optional lastfm_1.1.5-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+57d1+lDY0MbOLoRAgluAJ4jDoiUBpvYftf4SUYc2YkrA8M4KACfQwfY YzOJGLTuled720wfp7hxvJA= =TitH -END PGP SIGNATURE- Accepted: lastfm_1.1.5-3.diff.gz to pool/main/l/lastfm/lastfm_1.1.5-3.diff.gz lastfm_1.1.5-3.dsc to pool/main/l/lastfm/lastfm_1.1.5-3.dsc lastfm_1.1.5-3_i386.deb to pool/main/l/lastfm/lastfm_1.1.5-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted muse 0.7.1+0.7.2pre5-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 6 Feb 2006 21:38:06 +0100 Source: muse Binary: muse Architecture: source i386 Version: 0.7.1+0.7.2pre5-2 Distribution: unstable Urgency: medium Maintainer: Daniel Kobras [EMAIL PROTECTED] Changed-By: Daniel Kobras [EMAIL PROTECTED] Description: muse - Qt-based midi/audio sequencer Closes: 351477 Changes: muse (0.7.1+0.7.2pre5-2) unstable; urgency=medium . * Added patches: + [10_amd64_rtctimer_segfault_fix_CVS] From upstream CVS. Do not read 64bits of input into a 32bit variable. Fixes a timer related segfault on 64bit archs. Closes: #351477 Files: 3a8949f990170bb46cdf7c3514b3714e 760 sound optional muse_0.7.1+0.7.2pre5-2.dsc 21ab5a9cc6abb060404d0ddc8118ec9d 24295 sound optional muse_0.7.1+0.7.2pre5-2.diff.gz 7f7658bee580a9c0a9ecca2bbed1f581 5336900 sound optional muse_0.7.1+0.7.2pre5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/IjIpOKIA4m/fisRAtErAJ0c4Im6ws3HiKHQWeXWtObEdGg0AgCcCYHu ZiegWjyCaQXn+2TbuhrJ368= =aoDi -END PGP SIGNATURE- Accepted: muse_0.7.1+0.7.2pre5-2.diff.gz to pool/main/m/muse/muse_0.7.1+0.7.2pre5-2.diff.gz muse_0.7.1+0.7.2pre5-2.dsc to pool/main/m/muse/muse_0.7.1+0.7.2pre5-2.dsc muse_0.7.1+0.7.2pre5-2_i386.deb to pool/main/m/muse/muse_0.7.1+0.7.2pre5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted linux-2.6 2.6.15-7 (source all powerpc)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 21 Feb 2006 17:35:21 + Source: linux-2.6 Binary: linux-image-sun3 linux-image-2.6-powerpc-miboot linux-headers-2.6.15-1-rpc linux-image-2.6-footbridge linux-image-2.6.15-1-alpha-legacy linux-tree-2.6.15 linux-image-2.6-parisc64 linux-image-2.6-amd64-generic kernel-image-2.6-686-smp linux-headers-2.6.15-1-parisc-smp linux-image-2.6-486 linux-headers-2.6-atari kernel-image-2.6-386 linux-headers-2.6-s390 linux-image-2.6.15-1-s3c2410 linux-headers-2.6-nslu2 linux-image-mvme16x linux-headers-2.6.15-1-s390 linux-image-itanium linux-image-2.6-amd64-k8-smp linux-image-2.6-rpc linux-image-2.6.15-1-atari linux-image-2.6.15-1-amiga linux-image-2.6-s390 linux-image-q40 linux-headers-2.6-sparc64-smp linux-headers-2.6-mvme147 linux-image-2.6.15-1-parisc linux-image-2.6.15-1-powerpc-smp linux-image-2.6.15-1-itanium linux-image-footbridge kernel-image-2.6-itanium-smp linux-image-2.6.15-1-mvme147 linux-image-2.6.15-1-parisc64-smp linux-headers-2.6-686-smp linux-headers-2.6.15-1-amd64-k8 linux-image-atari linux-doc-2.6.15 linux-image-2.6-q40 linux-image-alpha-legacy kernel-image-2.6-k7-smp linux-headers-2.6.15-1-486 linux-headers-2.6-powerpc-miboot linux-headers-2.6-apus linux-image-2.6.15-1-nslu2 linux-headers-2.6.15 linux-headers-2.6.15-1-powerpc-smp linux-image-2.6.15-1-k7 linux-image-2.6.15-1-parisc64 linux-image-s390 linux-image-apus linux-image-2.6.15-1-sun3 linux-image-nslu2 linux-headers-2.6.15-1-mac linux-image-2.6-itanium linux-image-parisc-smp linux-image-2.6.15-1-s390 linux-image-2.6.15-1-powerpc linux-image-amd64-k8-smp linux-image-2.6-parisc-smp linux-image-2.6.15-1-apus linux-image-2.6.15-1-parisc-smp linux-headers-2.6.15-1-amiga linux-headers-2.6-amd64-generic linux-image-2.6-mckinley-smp linux-image-amiga linux-image-2.6-k7 linux-image-2.6.15-1-686-smp linux-headers-2.6.15-1 linux-image-mckinley-smp linux-image-em64t-p4-smp linux-image-2.6.15-1-sparc64 linux-image-2.6-powerpc linux-image-parisc64-smp linux-headers-2.6-s3c2410 linux-image-2.6-hp linux-headers-2.6.15-1-alpha-generic linux-image-sparc64-smp linux-headers-2.6.15-1-sparc64-smp linux-headers-2.6-parisc64-smp linux-image-2.6-parisc64-smp kernel-image-2.6-mckinley linux-image-2.6.15-1-q40 linux-image-powerpc-smp linux-image-2.6.15-1-mckinley linux-headers-2.6-itanium-smp kernel-image-2.6-power3 linux-headers-2.6.15-1-parisc kernel-image-2.6-powerpc kernel-image-2.6-generic linux-headers-2.6-mvme16x linux-image-2.6.15-1-alpha-generic linux-image-2.6-alpha-generic linux-headers-2.6-amd64-k8-smp linux-image-2.6-em64t-p4 linux-headers-2.6.15-1-mckinley linux-headers-2.6.15-1-bvme6000 linux-image-2.6.15-1-amd64-generic linux-headers-2.6-powerpc linux-image-hp linux-headers-2.6-em64t-p4-smp kernel-image-powerpc-smp linux-headers-2.6-sparc64 linux-image-powerpc64 linux-headers-2.6-hp linux-headers-2.6-powerpc64 linux-image-2.6-apus linux-image-2.6.15-1-powerpc64 linux-headers-2.6.15-1-footbridge linux-headers-2.6.15-1-powerpc64 linux-image-2.6-nslu2 linux-headers-2.6.15-1-sparc64 linux-headers-2.6.15-1-q40 linux-headers-2.6-mac linux-headers-2.6.15-1-686 linux-image-2.6.15-1-amd64-k8-smp linux-headers-2.6-em64t-p4 linux-headers-2.6-rpc linux-image-2.6-mckinley linux-headers-2.6.15-1-s390x linux-headers-2.6-alpha-generic linux-headers-2.6-bvme6000 kernel-image-2.6-sparc64-smp kernel-image-powerpc linux-image-bvme6000 linux-headers-2.6-alpha-smp linux-headers-2.6.15-1-powerpc linux-image-2.6-atari linux-headers-2.6.15-1-alpha-legacy linux-headers-2.6.15-1-em64t-p4 linux-headers-2.6.15-1-parisc64 linux-image-s3c2410 linux-headers-2.6-sun3 linux-image-2.6.15-1-mckinley-smp linux-headers-2.6-mckinley-smp linux-headers-2.6.15-1-ixp4xx kernel-image-2.6-power4-smp linux-image-parisc64 linux-headers-2.6.15-1-k7 linux-image-k7-smp linux-image-2.6.15-1-s390x linux-manual-2.6.15 kernel-image-power3-smp linux-image-2.6-parisc linux-image-2.6-bvme6000 linux-image-mckinley linux-image-2.6-alpha-legacy linux-image-itanium-smp linux-image-2.6-sparc64-smp linux-headers-2.6-s390x linux-headers-2.6-parisc linux-image-2.6.15-1-footbridge linux-image-2.6-ixp4xx linux-image-2.6.15-1-486 linux-headers-2.6-q40 linux-headers-2.6.15-1-alpha-smp kernel-image-2.6-k7 linux-image-2.6.15-1-em64t-p4-smp linux-image-ixp4xx linux-headers-2.6.15-1-nslu2 linux-image-rpc linux-image-2.6-mac kernel-image-2.6-power3-smp linux-headers-2.6.15-1-hp linux-image-2.6-s390x kernel-image-2.6-smp linux-image-2.6.15-1-686 linux-image-alpha-smp linux-image-2.6.15-1-sparc64-smp linux-image-2.6.15-1-k7-smp linux-image-2.6-amd64-k8 linux-image-parisc linux-headers-2.6.15-1-powerpc-miboot linux-headers-2.6-footbridge linux-image-2.6.15-1-bvme6000 linux-image-2.6.15-1-ixp4xx linux-headers-2.6.15-1-mvme147 linux-image-2.6-sparc64 linux-image-amd64-k8 linux-image-2.6.15-1-em64t-p4 linux-image-2.6.15-1-alpha-smp linux-headers-2.6.15-1-em64t-p4-smp
Accepted openthesaurus 20060222-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 17:17:00 +0100 Source: openthesaurus Binary: openthesaurus-de-kword openoffice.org-thesaurus-de openthesaurus-de-text Architecture: source all Version: 20060222-1 Distribution: unstable Urgency: low Maintainer: Rene Engelhard [EMAIL PROTECTED] Changed-By: Rene Engelhard [EMAIL PROTECTED] Description: openoffice.org-thesaurus-de - German Thesaurus for OpenOffice.org openthesaurus-de-kword - German Thesaurus for KWord openthesaurus-de-text - German Text Thesaurus for e.g. ding Changes: openthesaurus (20060222-1) unstable; urgency=low . * new snapshot Files: 459d8f3165a2620debd80979c6d2c1be 743 text optional openthesaurus_20060222-1.dsc a45dd993a1c04d0c275b229dad1a94e5 1552320 text optional openthesaurus_20060222.orig.tar.gz ca4769ec0c821ab80462381484fa529d 2672 text optional openthesaurus_20060222-1.diff.gz c5d198154f77586e5e93282acc984d93 237508 text optional openthesaurus-de-kword_20060222-1_all.deb b7265c3e342086c820763e1d93de357a 217796 text optional openthesaurus-de-text_20060222-1_all.deb 0ecf5e532401661d368eb78358da10f4 1092676 text optional openoffice.org-thesaurus-de_20060222-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/JD6+FmQsCSK63MRAgNdAJ9sZYWeL85u/ct4v7JzgP72tWvTugCggaED hx8N97blM99CIbOJ82DCpZ4= =8j7F -END PGP SIGNATURE- Accepted: openoffice.org-thesaurus-de_20060222-1_all.deb to pool/main/o/openthesaurus/openoffice.org-thesaurus-de_20060222-1_all.deb openthesaurus-de-kword_20060222-1_all.deb to pool/main/o/openthesaurus/openthesaurus-de-kword_20060222-1_all.deb openthesaurus-de-text_20060222-1_all.deb to pool/main/o/openthesaurus/openthesaurus-de-text_20060222-1_all.deb openthesaurus_20060222-1.diff.gz to pool/main/o/openthesaurus/openthesaurus_20060222-1.diff.gz openthesaurus_20060222-1.dsc to pool/main/o/openthesaurus/openthesaurus_20060222-1.dsc openthesaurus_20060222.orig.tar.gz to pool/main/o/openthesaurus/openthesaurus_20060222.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted twisted 2.2.0-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 08:28:04 +0100 Source: twisted Binary: python-twisted-core python2.4-twisted-bin python2.3-twisted-core python2.4-twisted-core twisted-doc-api python2.3-twisted-bin twisted-doc python2.3-twisted python2.4-twisted python-twisted Architecture: source all i386 Version: 2.2.0-1 Distribution: unstable Urgency: low Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: python-twisted - Event-based framework for internet applications (transitional pac python-twisted-core - Event-based framework for internet applications (dummy package) python2.3-twisted - Event-based framework for internet applications (transitional pac python2.3-twisted-bin - Event-based framework for internet applications python2.3-twisted-core - Event-based framework for internet applications python2.4-twisted - Event-based framework for internet applications (transitional pac python2.4-twisted-bin - Event-based framework for internet applications python2.4-twisted-core - Event-based framework for internet applications twisted-doc - The official documentation of Twisted twisted-doc-api - The auto-generated API docs of Twisted Changes: twisted (2.2.0-1) unstable; urgency=low . * New upstream version. Files: 7e7bce4a68cd2ee54534ddcbb75ac3d7 845 python optional twisted_2.2.0-1.dsc a3895d0c09fa5c4abeb6282164d10c72 1531397 python optional twisted_2.2.0.orig.tar.gz b220d37ccd860a951a95137db610596e 23020 python optional twisted_2.2.0-1.diff.gz ed04bf2ab9b11af4cc8d92fce01f7a4e 8586 python optional python-twisted-core_2.2.0-1_all.deb 311e48d53250aeda9a1f9b26ddce2f03 769780 python optional python2.4-twisted-core_2.2.0-1_all.deb ad25a1d7c19fe341366f28ab0677ebcc 769822 python optional python2.3-twisted-core_2.2.0-1_all.deb 26410038377b1114a6a36b62fc36f385 631254 doc optional twisted-doc_2.2.0-1_all.deb da49febce7f60d67181b44afb3a47061 850 doc optional twisted-doc-api_2.2.0-1_all.deb 8f01a57bad44292c0b3866069f530993 1342 python optional python-twisted_2.2.0-1_all.deb 863240cb3fffc8687d6539b38b08d7c9 7974 python optional python2.3-twisted_2.2.0-1_all.deb 7f161d00ce5e9e232f3e32a725947f6f 7970 python optional python2.4-twisted_2.2.0-1_all.deb dad30c3148cc45aa0a945a33cf1118b7 17580 python optional python2.4-twisted-bin_2.2.0-1_i386.deb 1cf109aedad84e720854fa4262b621b4 17578 python optional python2.3-twisted-bin_2.2.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/JGLStlRaw+TLJwRAvE/AJ0RxuUkIikX9a6p9M8snHfuBzsf3QCgrDm3 9ZYZY9qXS/TH8hkASZMKwbE= =NU/B -END PGP SIGNATURE- Accepted: python-twisted-core_2.2.0-1_all.deb to pool/main/t/twisted/python-twisted-core_2.2.0-1_all.deb python-twisted_2.2.0-1_all.deb to pool/main/t/twisted/python-twisted_2.2.0-1_all.deb python2.3-twisted-bin_2.2.0-1_i386.deb to pool/main/t/twisted/python2.3-twisted-bin_2.2.0-1_i386.deb python2.3-twisted-core_2.2.0-1_all.deb to pool/main/t/twisted/python2.3-twisted-core_2.2.0-1_all.deb python2.3-twisted_2.2.0-1_all.deb to pool/main/t/twisted/python2.3-twisted_2.2.0-1_all.deb python2.4-twisted-bin_2.2.0-1_i386.deb to pool/main/t/twisted/python2.4-twisted-bin_2.2.0-1_i386.deb python2.4-twisted-core_2.2.0-1_all.deb to pool/main/t/twisted/python2.4-twisted-core_2.2.0-1_all.deb python2.4-twisted_2.2.0-1_all.deb to pool/main/t/twisted/python2.4-twisted_2.2.0-1_all.deb twisted-doc-api_2.2.0-1_all.deb to pool/main/t/twisted/twisted-doc-api_2.2.0-1_all.deb twisted-doc_2.2.0-1_all.deb to pool/main/t/twisted/twisted-doc_2.2.0-1_all.deb twisted_2.2.0-1.diff.gz to pool/main/t/twisted/twisted_2.2.0-1.diff.gz twisted_2.2.0-1.dsc to pool/main/t/twisted/twisted_2.2.0-1.dsc twisted_2.2.0.orig.tar.gz to pool/main/t/twisted/twisted_2.2.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xfonts-encodings 1:1.0.0-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 31 Jan 2006 20:16:31 -0500 Source: xfonts-encodings Binary: xfonts-encodings Architecture: source all Version: 1:1.0.0-1 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debian-x@lists.debian.org Changed-By: David Nusinow [EMAIL PROTECTED] Description: xfonts-encodings - Encodings for X.Org fonts Changes: xfonts-encodings (1:1.0.0-1) experimental; urgency=low . [ David Nusinow ] * First modular upload to Debian . [ Eugene Konev ] * Move encodings to /usr/share/fonts/X11/encodings Files: 0f4f6c7f9eee54d7eca4b84367692028 767 x11 optional xfonts-encodings_1.0.0-1.dsc 7d40b3c54fe3b46922932392400f7840 688969 x11 optional xfonts-encodings_1.0.0.orig.tar.gz 4c6c146f4b93ccdd14cd2a3ac7e29da8 13918 x11 optional xfonts-encodings_1.0.0-1.diff.gz 7451e65354aa6402144b1f1f92601dd8 583532 x11 optional xfonts-encodings_1.0.0-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+8chyLfpNdY0ad8RAkpjAJ4xlWj8gUAxw0rOnexMjka4KjaV4QCgiM10 HT1aPq0h9T4FxUE2L29CeHc= =0I5x -END PGP SIGNATURE- Accepted: xfonts-encodings_1.0.0-1.diff.gz to pool/main/x/xfonts-encodings/xfonts-encodings_1.0.0-1.diff.gz xfonts-encodings_1.0.0-1.dsc to pool/main/x/xfonts-encodings/xfonts-encodings_1.0.0-1.dsc xfonts-encodings_1.0.0-1_all.deb to pool/main/x/xfonts-encodings/xfonts-encodings_1.0.0-1_all.deb xfonts-encodings_1.0.0.orig.tar.gz to pool/main/x/xfonts-encodings/xfonts-encodings_1.0.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xorg-server 1:1.0.1-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 00:18:45 -0500 Source: xorg-server Binary: xserver-xorg-core xvfb xdmx xserver-xorg-dev xdmx-tools xnest Architecture: source i386 Version: 1:1.0.1-1 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debian-x@lists.debian.org Changed-By: David Nusinow [EMAIL PROTECTED] Description: xdmx - Distributed Multihead X server xdmx-tools - Distributed Multihead X tools xnest - Nested X server xserver-xorg-core - X.Org X server -- core server xserver-xorg-dev - X.Org X server -- development files xvfb - Virtual Framebuffer 'fake' X server Changes: xorg-server (1:1.0.1-1) experimental; urgency=low . * First upload to Debian * Add bison and flex to the build-depends * Define INSTALL in debian/rules * Add xserver-xorg-core dependency xserver-xorg-video-all | xserver-xorg-video. The former is a metapackage that depends on all the video drivers we ship and the latter is a virtual package that each video driver provides. This scheme will install the metapackage by default but will permit any single video driver to satsify the dependency. Do the same thing for the input drivers. * switch dpatch build-dependency to quilt * Deal with mesa packaging rename: build-dep on mesa-swrast-source - mesa-swx11-source * Change xserver-core depends to be on x11-common rather than xorg-common * Have xserver-xorg-dev install the files in /usr/share/aclocal so we get xorg-server.m4 * Manually set permissions on serverabiver installation * Set the default font path to /usr/share/fonts/X11 instead of /usr/share/X11/fonts. Thanks Eugene Konev. Files: d4f0b1f2648eba7a60fb6db62d6d74c3 1880 x11 optional xorg-server_1.0.1-1.dsc 10b93a54c5269c2f3556395a50611511 7898424 x11 optional xorg-server_1.0.1.orig.tar.gz ddc361ececba8b28e8bd53a02799a87c 27264 x11 optional xorg-server_1.0.1-1.diff.gz ed6b103b336291c9861d8ee40f916545 3639608 x11 optional xserver-xorg-core_1.0.1-1_i386.deb 320d1bb040ff262e23b2b2143cdddb71 290780 x11 optional xserver-xorg-dev_1.0.1-1_i386.deb 2f4950361b62632b45d676e0663fdf89 784518 x11 optional xdmx_1.0.1-1_i386.deb 91d1c26288d5c69af794c78ff42d5ce0 12470 x11 optional xdmx-tools_1.0.1-1_i386.deb 1c92e17678b2dbca7fc865032d4d501a 1322774 x11 optional xnest_1.0.1-1_i386.deb 8ac820bfbbaf4fd61cbf1e4c34b16a2c 1471098 x11 optional xvfb_1.0.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+8dVyLfpNdY0ad8RAvjcAJ9hinnCL+8lAtm4y9ZD8Y5HAeZG6QCgmiKW 1mqR2hslriA6ryBB+A/1Ln8= =ITdw -END PGP SIGNATURE- Accepted: xdmx-tools_1.0.1-1_i386.deb to pool/main/x/xorg-server/xdmx-tools_1.0.1-1_i386.deb xdmx_1.0.1-1_i386.deb to pool/main/x/xorg-server/xdmx_1.0.1-1_i386.deb xnest_1.0.1-1_i386.deb to pool/main/x/xorg-server/xnest_1.0.1-1_i386.deb xorg-server_1.0.1-1.diff.gz to pool/main/x/xorg-server/xorg-server_1.0.1-1.diff.gz xorg-server_1.0.1-1.dsc to pool/main/x/xorg-server/xorg-server_1.0.1-1.dsc xorg-server_1.0.1.orig.tar.gz to pool/main/x/xorg-server/xorg-server_1.0.1.orig.tar.gz xserver-xorg-core_1.0.1-1_i386.deb to pool/main/x/xorg-server/xserver-xorg-core_1.0.1-1_i386.deb xserver-xorg-dev_1.0.1-1_i386.deb to pool/main/x/xorg-server/xserver-xorg-dev_1.0.1-1_i386.deb xvfb_1.0.1-1_i386.deb to pool/main/x/xorg-server/xvfb_1.0.1-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xfonts-utils 1:1.0.0-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 31 Jan 2006 21:37:49 -0500 Source: xfonts-utils Binary: xfonts-utils Architecture: source i386 Version: 1:1.0.0-1 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debian-x@lists.debian.org Changed-By: David Nusinow [EMAIL PROTECTED] Description: xfonts-utils - X Window System font utility programs Changes: xfonts-utils (1:1.0.0-1) experimental; urgency=low . [ David Nusinow ] * First modular upload to Debian . [ Eugene Konev ] * Add patch to allow mkfontdir to build properly * Move mkfontdir, mkfontscale, bdf2pcf from xutils to xfonts-utils. * Start moving fonts to /usr/share/fonts. * Fix update-fonts-* * Fix update-fonts-dir to reference proper encodings dir. Files: e8248d69240841c6d5158bc7e7feb781 764 x11 optional xfonts-utils_1.0.0-1.dsc 699cd7dd4014fe364726db250bcd96e5 378205 x11 optional xfonts-utils_1.0.0.orig.tar.gz 4318181ab27e9fa068f8bd993049e606 20104 x11 optional xfonts-utils_1.0.0-1.diff.gz c1f95df14a636d74db52bb667d3ab9d0 63636 x11 optional xfonts-utils_1.0.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+8uzyLfpNdY0ad8RAil+AJ0fq1MMUoeLzCUxlqPP7YjHw6RpqwCfT3+n z5BC33r5uwP0nKC6M8EUKBg= =vUFb -END PGP SIGNATURE- Accepted: xfonts-utils_1.0.0-1.diff.gz to pool/main/x/xfonts-utils/xfonts-utils_1.0.0-1.diff.gz xfonts-utils_1.0.0-1.dsc to pool/main/x/xfonts-utils/xfonts-utils_1.0.0-1.dsc xfonts-utils_1.0.0-1_i386.deb to pool/main/x/xfonts-utils/xfonts-utils_1.0.0-1_i386.deb xfonts-utils_1.0.0.orig.tar.gz to pool/main/x/xfonts-utils/xfonts-utils_1.0.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xorg 1:7.0.0 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 22:10:54 -0500 Source: xorg Binary: xlibs xserver-xorg-video-all xserver-xfree86 xserver-xorg x11-common xorg-dev xserver-xorg-input-all xlibs-data xorg Architecture: source i386 all Version: 1:7.0.0 Distribution: experimental Urgency: low Maintainer: Debian X Strike Force debian-x@lists.debian.org Changed-By: David Nusinow [EMAIL PROTECTED] Description: x11-common - X Window System (X.Org) infrastructure xlibs - transitional package for xkb data xlibs-data - transitional package for X11 client data xorg - X.Org X Window System xorg-dev - the X.Org development libraries xserver-xfree86 - transitional package for moving from xfree86 to X.Org xserver-xorg - the X.Org X server xserver-xorg-input-all - the X.Org X server -- input driver metapackage xserver-xorg-video-all - the X.Org X server -- output driver metapackage Changes: xorg (1:7.0.0) experimental; urgency=low . * First upload to Debian * Add an epoch due to idiocy while working on aborted experimental packages * This is a Debian-native package so version it accordingly * Remove xbase-clients and xutils metapackages. We're just bundling the apps in to one big source package right now * Convert to xsfbs + shell-lib.sh deleted in favor of xsfbs/xsfbs.sh + use targets for script generation and such from xsfbs/xsfbs.mk * Change driver metapackage naming to match individual packages: + xserver-xorg-driver - xserver-xorg-video + Update the packaging variables that define arch-specific drivers to include in the metapackage as well to match these names * Remove extra depends on x11-common from xserver-xorg * Add debconf dependency for xserver-xorg * setuid for /usr/bin/X (stolen from monolith's debian/rules) * Provide xlibs and xlibs-data transitional packages. These are empty packages that depend on the packages that replace them. * Create an xorg metapackage that provides x-window-system(-core). This is a simpler name and should suffice. We don't need this split between -system and -system-core. If people want twm and so forth they can install it. This package installs -core plus xterm currently. * Re-add x-window-system-dev package under the new name of xorg-dev. Note to packagers: this is not meant to be build-dep'ed on, but is a convenience package for users. * Provide a compatibility symlink to /usr/lib/X11/fonts (their new home) at /usr/X11R6/lib/X11/fonts. This will let external fonts work as expected. Thanks Eugene Konev. Files: af9d80aaa91a63dcc818f51380e4b612 779 x11 optional xorg_7.0.0.dsc f5c59d2f35fbc3b5c010d7f7a782012c 547302 x11 optional xorg_7.0.0.tar.gz e79382745983a8df621ffbbdbbcb7b1e 126104 x11 optional xserver-xorg_7.0.0_all.deb db05fab3ba2669fa3cc47b5501d167ca 58342 x11 optional x11-common_7.0.0_i386.deb 9a670ec33db5c1e8db0a1dc077145d39 5924 x11 optional xserver-xfree86_7.0.0_i386.deb 092e38ca22b9ace02d903c5a54552467 6160 x11 optional xserver-xorg-video-all_7.0.0_i386.deb 3dbbdac2f9bc75b52f9de722f64ba44c 6014 x11 optional xserver-xorg-input-all_7.0.0_i386.deb fab695baf453f061a189d62901bc243b 6176 x11 optional xorg_7.0.0_i386.deb bc1cd5b53365e77f29100588d5a3c246 6422 x11 optional xorg-dev_7.0.0_i386.deb 4e557a7113d985188ff72f5cfe6e8dd1 5944 x11 optional xlibs_7.0.0_i386.deb 27f8c629eb34ce453bbf309dc39b2c9a 5978 x11 optional xlibs-data_7.0.0_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+/MSyLfpNdY0ad8RAmYkAJ9b6HlgbIbBjIXanJ1VuNH32loFbwCeKJUh OBd87bo/C2Rc8Q0iA9eF1QU= =+E1c -END PGP SIGNATURE- Accepted: x11-common_7.0.0_i386.deb to pool/main/x/xorg/x11-common_7.0.0_i386.deb xlibs-data_7.0.0_i386.deb to pool/main/x/xorg/xlibs-data_7.0.0_i386.deb xlibs_7.0.0_i386.deb to pool/main/x/xorg/xlibs_7.0.0_i386.deb xorg-dev_7.0.0_i386.deb to pool/main/x/xorg/xorg-dev_7.0.0_i386.deb xorg_7.0.0.dsc to pool/main/x/xorg/xorg_7.0.0.dsc xorg_7.0.0.tar.gz to pool/main/x/xorg/xorg_7.0.0.tar.gz xorg_7.0.0_i386.deb to pool/main/x/xorg/xorg_7.0.0_i386.deb xserver-xfree86_7.0.0_i386.deb to pool/main/x/xorg/xserver-xfree86_7.0.0_i386.deb xserver-xorg-input-all_7.0.0_i386.deb to pool/main/x/xorg/xserver-xorg-input-all_7.0.0_i386.deb xserver-xorg-video-all_7.0.0_i386.deb to pool/main/x/xorg/xserver-xorg-video-all_7.0.0_i386.deb xserver-xorg_7.0.0_all.deb to pool/main/x/xorg/xserver-xorg_7.0.0_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lmodern 0.99.3-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 17:10:15 +0100 Source: lmodern Binary: lmodern Architecture: source all Version: 0.99.3-2 Distribution: unstable Urgency: low Maintainer: Debian teTeX maintainers debian-tetex-maint@lists.debian.org Changed-By: Florent Rougon [EMAIL PROTECTED] Description: lmodern- scalable PostScript fonts based on Computer Modern Changes: lmodern (0.99.3-2) unstable; urgency=low . * Use dh_installtex in debian/rules and Build-depend on tex-common (= 0.16) for this reason. Files: 47531c58ba55470ab37b3f9b54a55eb7 829 tex optional lmodern_0.99.3-2.dsc 4c87ef12dc2d04502dd0518c85c625f0 19643 tex optional lmodern_0.99.3-2.diff.gz bb98bce3f391fb58673221a56967cfc5 10398220 tex optional lmodern_0.99.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/JcAdkCUdmd1b10RAtFLAKCEC/0RhU+hhPKi0Bn/oOomrnQPkwCg2o4f wQB77zo6nR+gA7VaJxu9qd0= =LXrZ -END PGP SIGNATURE- Accepted: lmodern_0.99.3-2.diff.gz to pool/main/l/lmodern/lmodern_0.99.3-2.diff.gz lmodern_0.99.3-2.dsc to pool/main/l/lmodern/lmodern_0.99.3-2.dsc lmodern_0.99.3-2_all.deb to pool/main/l/lmodern/lmodern_0.99.3-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted udev 0.085-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 19 Feb 2006 15:00:46 +0100 Source: udev Binary: udev udev-udeb Architecture: source i386 Version: 0.085-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri [EMAIL PROTECTED] Changed-By: Marco d'Itri [EMAIL PROTECTED] Description: udev - /dev/ and hotplug management daemon udev-udeb - /dev/ and hotplug management daemon (udeb) Closes: 350613 353052 353145 Changes: udev (0.085-1) unstable; urgency=medium . * New upstream release. Fixes: + a typo in udev(7). (Closes: #350613) * Load again sg for type 5 SCSI devices (TYPE_ROM), because it's needed to burn CDs. (Closes: #353052) * Silently delete the example /etc/scsi_id.config which was installed by mistake by some old version, if it was not modified. (Closes: #353145) * Added code to preinst and postinst to handle upgrades from sarge. If /etc/udev/kernel-upgrade exists the kernel version check will be ignored and udevd will not be restarted. * Updated patch ifrename_wait_retry to the new version in Ubuntu, because the first one was totally broken. Files: 0ae36b8419f176bb992527b51d482db6 590 admin optional udev_0.085-1.dsc 4ccbe69bd6cdc84b3015906c371bab1f 191854 admin optional udev_0.085.orig.tar.gz 5ce735fa21a66d04acdbc69ff7f3921d 48519 admin optional udev_0.085-1.diff.gz 6b9f761aebc2fc0b9628cd78a9e76aef 277464 admin optional udev_0.085-1_i386.deb c214356cfab586b6185f5a930a44c7b4 44300 debian-installer optional udev-udeb_0.085-1_i386.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+d0ZFGfw2OHuP7ERAj/UAKCVopCZpaSchJMsD2+fs83nHZVyzACeKzlE jI+suUptI8fVTjW/ZBjU7a0= =bgey -END PGP SIGNATURE- Accepted: udev-udeb_0.085-1_i386.udeb to pool/main/u/udev/udev-udeb_0.085-1_i386.udeb udev_0.085-1.diff.gz to pool/main/u/udev/udev_0.085-1.diff.gz udev_0.085-1.dsc to pool/main/u/udev/udev_0.085-1.dsc udev_0.085-1_i386.deb to pool/main/u/udev/udev_0.085-1_i386.deb udev_0.085.orig.tar.gz to pool/main/u/udev/udev_0.085.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libcatalyst-modules-perl 0.09 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 23:08:50 +0100 Source: libcatalyst-modules-perl Binary: libcatalyst-modules-perl Architecture: source all Version: 0.09 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libcatalyst-modules-perl - Modules for Catalyst Changes: libcatalyst-modules-perl (0.09) unstable; urgency=low . * changes in debian/make-module.sh * rewritten debian/rules * changed layout of tarballs directory * Catalyst::Plugin::HTML::Widget added Files: 0c62f01ab5b3366830163df8c1f51baa 1351 perl optional libcatalyst-modules-perl_0.09.dsc 06e32e203e48573f4e5eca9786c5c77d 133715 perl optional libcatalyst-modules-perl_0.09.tar.gz c5e171c61dc09614ee0c2e301dad543d 149650 perl optional libcatalyst-modules-perl_0.09_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/JKM+NMfSd6w7DERAmhtAJ43Omdsf/ftqut0CorsvYKJj3/MgwCfdgO3 D8kbHlc/SFFx5aywaWf/wOA= =KOGl -END PGP SIGNATURE- Accepted: libcatalyst-modules-perl_0.09.dsc to pool/main/libc/libcatalyst-modules-perl/libcatalyst-modules-perl_0.09.dsc libcatalyst-modules-perl_0.09.tar.gz to pool/main/libc/libcatalyst-modules-perl/libcatalyst-modules-perl_0.09.tar.gz libcatalyst-modules-perl_0.09_all.deb to pool/main/libc/libcatalyst-modules-perl/libcatalyst-modules-perl_0.09_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ipcheck 0.233-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 17:51:33 + Source: ipcheck Binary: ipcheck Architecture: source all Version: 0.233-1 Distribution: unstable Urgency: low Maintainer: Mark Purcell [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: ipcheck- Dyndns.org client to register your dynamic IP address Closes: 353944 Changes: ipcheck (0.233-1) unstable; urgency=low . * New upstream release * v0.226 Gene Cumm Barricade fixes and SSL check improvement - Not using SSL (Closes: #353944) * Refer to v0.141 in description not 1.4.1 Files: ebadd9a2f2a802f3715becb525d561c4 580 net optional ipcheck_0.233-1.dsc 3db43e933d2dfaabfb04d3ad1283cb51 39094 net optional ipcheck_0.233.orig.tar.gz 8af15ae5342c70eeafd0b44ddf0f01a0 7971 net optional ipcheck_0.233-1.diff.gz a3526b199ef0556257b673a7c0db3ac8 45796 net optional ipcheck_0.233-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/KTUoCzanz0IthIRAlUyAJ96wDfnHbudq4wkiKtcT3KHvzlwsgCggX6f l4Z1pRxtCXqENEuomFsle5A= =ohUK -END PGP SIGNATURE- Accepted: ipcheck_0.233-1.diff.gz to pool/main/i/ipcheck/ipcheck_0.233-1.diff.gz ipcheck_0.233-1.dsc to pool/main/i/ipcheck/ipcheck_0.233-1.dsc ipcheck_0.233-1_all.deb to pool/main/i/ipcheck/ipcheck_0.233-1_all.deb ipcheck_0.233.orig.tar.gz to pool/main/i/ipcheck/ipcheck_0.233.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted denyhosts 2.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 09:56:02 +0100 Source: denyhosts Binary: denyhosts denyhosts-python2.3 denyhosts-common denyhosts-python2.4 Architecture: source all Version: 2.1-2 Distribution: unstable Urgency: low Maintainer: Marco Bertorello [EMAIL PROTECTED] Changed-By: Marco Bertorello [EMAIL PROTECTED] Description: denyhosts - an utility to help sys admins thwart ssh hackers denyhosts-common - an utility to help sys admins thwart ssh hackers denyhosts-python2.3 - an utility to help sys admins thwart ssh hackers denyhosts-python2.4 - an utility to help sys admins thwart ssh hackers Closes: 353951 Changes: denyhosts (2.1-2) unstable; urgency=low . * Fixed lockfile in configuration file (Closes: #353951) Files: bda3a89dd2c0c68379ae8bea9c9c7944 661 net optional denyhosts_2.1-2.dsc c65becba3c11fd7b6390ca4f2402cabe 4998 net optional denyhosts_2.1-2.diff.gz 4da42cd0ce0c7f232c24cc28811545df 18536 net optional denyhosts-common_2.1-2_all.deb e9b92c3a81f9bc060bf0b81cab14788d 7954 net optional denyhosts_2.1-2_all.deb d1ee5bd9dbfdef9732bebe4eba37f258 29416 net optional denyhosts-python2.3_2.1-2_all.deb a10a057ef01a9d071d216a477728dc91 29128 net optional denyhosts-python2.4_2.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/KeaaGRzDfCV5eQRAkOsAJ41ULoljuDXV/3ZMFCnvJWRa83jzACfcGow 6wkY9LzxbaDwog0a3v6p2V4= =uez8 -END PGP SIGNATURE- Accepted: denyhosts-common_2.1-2_all.deb to pool/main/d/denyhosts/denyhosts-common_2.1-2_all.deb denyhosts-python2.3_2.1-2_all.deb to pool/main/d/denyhosts/denyhosts-python2.3_2.1-2_all.deb denyhosts-python2.4_2.1-2_all.deb to pool/main/d/denyhosts/denyhosts-python2.4_2.1-2_all.deb denyhosts_2.1-2.diff.gz to pool/main/d/denyhosts/denyhosts_2.1-2.diff.gz denyhosts_2.1-2.dsc to pool/main/d/denyhosts/denyhosts_2.1-2.dsc denyhosts_2.1-2_all.deb to pool/main/d/denyhosts/denyhosts_2.1-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kmymoney2 0.8.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 17:40:49 + Source: kmymoney2 Binary: kmymoney2 Architecture: source i386 Version: 0.8.3-1 Distribution: unstable Urgency: low Maintainer: Debian KDE Extras Team [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: kmymoney2 - Personal finance manager for KDE Closes: 311768 311782 314006 329995 345581 345815 347698 347698 Changes: kmymoney2 (0.8.3-1) unstable; urgency=low . * New upstream release . Account tree collapses without user approval (Closes: #347698) . qif import: crash in finishImport() (Closes: #329995) . '???' symbols in russian locale (Closes: #311768) . each account and category should be sum of subaccounts/subcategories (Closes: #311782) . [INTL: en_GB] [PATCH] Completes the en_GB.po translation (Closes: #345581) . [INTL:de] German PO file corrections (Closes: #314006) . Account tree collapses without user approval (Closes: #347698) . default geometry too large for screen (Closes: #345815) Files: 32de111361ee145a81ec7b14825d3248 816 utils optional kmymoney2_0.8.3-1.dsc 7a9e54098e4e5cb6c38a2315a9342fd4 6549309 utils optional kmymoney2_0.8.3.orig.tar.gz 491f976ba1edc44bb96962cc18cd6bc8 4900 utils optional kmymoney2_0.8.3-1.diff.gz 2e14b88182ef12e3dab3c96b0eb2323c 6707484 utils optional kmymoney2_0.8.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/KahoCzanz0IthIRAkKzAJ4jNeZGt20bmAzO+psbdi038BpMBQCfTJVK muFbekEywWqBASg27NCkPXM= =hGLV -END PGP SIGNATURE- Accepted: kmymoney2_0.8.3-1.diff.gz to pool/main/k/kmymoney2/kmymoney2_0.8.3-1.diff.gz kmymoney2_0.8.3-1.dsc to pool/main/k/kmymoney2/kmymoney2_0.8.3-1.dsc kmymoney2_0.8.3-1_i386.deb to pool/main/k/kmymoney2/kmymoney2_0.8.3-1_i386.deb kmymoney2_0.8.3.orig.tar.gz to pool/main/k/kmymoney2/kmymoney2_0.8.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted hpoj 0.91-10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 18:38:27 + Source: hpoj Binary: hpoj-xojpanel hpoj Architecture: source i386 Version: 0.91-10 Distribution: unstable Urgency: low Maintainer: Mark Purcell [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: hpoj - HP OfficeJet Linux driver (hpoj) hpoj-xojpanel - HP OfficeJet Linux QT-based LCD panel display Closes: 302846 338744 339584 Changes: hpoj (0.91-10) unstable; urgency=low . * Run hpoj as root to allow access to parallel devices - ptal-mlcd reports Access denied to parallel port! (Closes: #339584) - hpoj 635 on parport not detected (Closes: #302846) * Remove usb/hotplug support - requires the obsolete /etc/hotplug/usb/ interface (Closes: #338744) Files: c8a5507d16b4a6504ae73bc57f736da0 651 utils optional hpoj_0.91-10.dsc 36ed02c230604c6b44cc823e57d0bd1b 63210 utils optional hpoj_0.91-10.diff.gz ebb5691a6637ab328a3608d97a8bb294 454950 utils optional hpoj_0.91-10_i386.deb 752bb5f5665404d0c16dcd5733976c0c 58844 utils optional hpoj-xojpanel_0.91-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/LLAoCzanz0IthIRAqBkAJwLmtE9rpeSLq2OjlvkGw7n/pDO/ACgjvt8 KPTN5Zuiw7s0EsafL0osBiI= =hozi -END PGP SIGNATURE- Accepted: hpoj-xojpanel_0.91-10_i386.deb to pool/main/h/hpoj/hpoj-xojpanel_0.91-10_i386.deb hpoj_0.91-10.diff.gz to pool/main/h/hpoj/hpoj_0.91-10.diff.gz hpoj_0.91-10.dsc to pool/main/h/hpoj/hpoj_0.91-10.dsc hpoj_0.91-10_i386.deb to pool/main/h/hpoj/hpoj_0.91-10_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted shadow 1:4.0.14-7 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 06:58:47 +0100 Source: shadow Binary: login passwd Architecture: source i386 Version: 1:4.0.14-7 Distribution: unstable Urgency: low Maintainer: Shadow package maintainers [EMAIL PROTECTED] Changed-By: Christian Perrier [EMAIL PROTECTED] Description: login - system login tools passwd - change and administer password and group data Closes: 333706 352494 353813 Changes: shadow (1:4.0.14-7) unstable; urgency=low . * The Carré d'Aurillac release (let's stay in Cantal) * Upstream bugs or fixes not already fixed in upstream releases or CVS: - 467_useradd_-r_LSB: add a -r option for adding system users for LSB compatibility. Closes: #333706 - 493_selinux_no_proc: Only check selinux_check_passwd_access on SELinux enabled system. This fix issues in passwd, chage, chfn and chsh when /proc is not mounted. Closes: #352494 * Debian packaging fixes: - Stop replacing manpages-it (login only, newusers is still conflicting on passwd) and manpages-hu as new releases removed the conflicting manpages - passwd.config: Better POSIX compliance and avoid failure if root password is set to '!' Thanks to Vagrant Cascadian for reporting and providing the patch Closes: #353813 Files: d1d4047820f2db31820c47b06805a132 1030 admin required shadow_4.0.14-7.dsc 7136007b057731da3634a5568271f5ab 177515 admin required shadow_4.0.14-7.diff.gz 82b17d748b0b50f28a54b68c3fe03c1f 730374 admin required passwd_4.0.14-7_i386.deb 45f159325898f156ca6dadcb22ec8bf4 653292 admin required login_4.0.14-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/Lis1OXtrMAUPS0RAidaAJ9AppWsN4t11uyrEAsncEUS1iPNCgCfYhH/ PqOdgsprj7mTX9bKo/qq88I= =ocPE -END PGP SIGNATURE- Accepted: login_4.0.14-7_i386.deb to pool/main/s/shadow/login_4.0.14-7_i386.deb passwd_4.0.14-7_i386.deb to pool/main/s/shadow/passwd_4.0.14-7_i386.deb shadow_4.0.14-7.diff.gz to pool/main/s/shadow/shadow_4.0.14-7.diff.gz shadow_4.0.14-7.dsc to pool/main/s/shadow/shadow_4.0.14-7.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted epiphany-extensions 1.8.2-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Feb 2006 19:48:31 +0100 Source: epiphany-extensions Binary: epiphany-extensions Architecture: source i386 Version: 1.8.2-5 Distribution: unstable Urgency: low Maintainer: Jordi Mallach [EMAIL PROTECTED] Changed-By: Jordi Mallach [EMAIL PROTECTED] Description: epiphany-extensions - Extensions for Epiphany web browser Closes: 351984 Changes: epiphany-extensions (1.8.2-5) unstable; urgency=low . * Apply patch from Mike Hommey to build against libxul-dev (closes: #351984). - debian/control.in: + Changed Build-deps from mozilla-browser to libxul-dev. + Changed dependencies and conflicts accordingly. - debian/rules: Add --with-mozilla=xulrunner to the configure line. * debian/control.in: bump epiphany-browser dependency to = 1.8.5, first version using libxul. Files: 1214bd756abc219550565ee3ec585099 1914 gnome optional epiphany-extensions_1.8.2-5.dsc e2881a843bf2115e2440db8bdb95a7d2 3438 gnome optional epiphany-extensions_1.8.2-5.diff.gz 9e12067e6c627d4843bc37b137bc75f7 363820 gnome optional epiphany-extensions_1.8.2-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD+iGAJYSUupF6Il4RArcrAKDTbrAUT1VYJtdDbn6dnn8+Dvy3GwCfWGHU sJ6zfIizS6+gXa5GXXutEhE= =ZIea -END PGP SIGNATURE- Accepted: epiphany-extensions_1.8.2-5.diff.gz to pool/main/e/epiphany-extensions/epiphany-extensions_1.8.2-5.diff.gz epiphany-extensions_1.8.2-5.dsc to pool/main/e/epiphany-extensions/epiphany-extensions_1.8.2-5.dsc epiphany-extensions_1.8.2-5_i386.deb to pool/main/e/epiphany-extensions/epiphany-extensions_1.8.2-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted moto4lin 0.3+cvs20050925-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 18 Feb 2006 18:38:02 +0100 Source: moto4lin Binary: moto4lin Architecture: source i386 Version: 0.3+cvs20050925-2 Distribution: unstable Urgency: low Maintainer: Miguel Gea Milvaques [EMAIL PROTECTED] Changed-By: Miguel Gea Milvaques [EMAIL PROTECTED] Description: moto4lin - file manager and seem editor for Motorola phones (like C380/C650) Changes: moto4lin (0.3+cvs20050925-2) unstable; urgency=low . * Enough time in experimental, now first release to unstable. Files: d30cb366e318135f49538defe860db02 649 comm optional moto4lin_0.3+cvs20050925-2.dsc f7392588ef1455188420e39b869de8e1 3974 comm optional moto4lin_0.3+cvs20050925-2.diff.gz 0f6861dcf83fe848641b1ec4d6213f23 145536 comm optional moto4lin_0.3+cvs20050925-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/OCRw3ao2vG823MRAtIzAJ0QuuGMPpGcMepnB5XiqS5swUscKACfWXJH gCAYTWEG/UqiyB3j1UWlfdY= =dOfX -END PGP SIGNATURE- Accepted: moto4lin_0.3+cvs20050925-2.diff.gz to pool/main/m/moto4lin/moto4lin_0.3+cvs20050925-2.diff.gz moto4lin_0.3+cvs20050925-2.dsc to pool/main/m/moto4lin/moto4lin_0.3+cvs20050925-2.dsc moto4lin_0.3+cvs20050925-2_i386.deb to pool/main/m/moto4lin/moto4lin_0.3+cvs20050925-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted skencil 0.6.17-3 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 22 Feb 2006 15:15:00 +0100 Source: skencil Binary: sketch skencil Architecture: source i386 all Version: 0.6.17-3 Distribution: unstable Urgency: low Maintainer: Daniel Baumann [EMAIL PROTECTED] Changed-By: Daniel Baumann [EMAIL PROTECTED] Description: skencil- Interactive vector drawing program for X11 sketch - Transition package for skencil rename Closes: 350867 Changes: skencil (0.6.17-3) unstable; urgency=low . * Fixed wrong version in Conflicts (Closes: #350867). Files: b27160b721d114382f8d954989470b68 655 graphics optional skencil_0.6.17-3.dsc 1c2d377d7844775f6f8fc0bd70ca10dc 12702 graphics optional skencil_0.6.17-3.diff.gz ceeb7bfa3a57ef22d86b5a917c908447 977696 graphics optional skencil_0.6.17-3_i386.deb 64e76e2ffbc84764a47514bd3991eda6 8716 graphics optional sketch_0.6.17-3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFD/OPXxa93SlhRC1oRAiy6AJ0btYGrvdzHh1G48QCATieNFI9peACglDyK p20R0KXjYLJ7bcAjeJ+wY/I= =EZiN -END PGP SIGNATURE- Accepted: skencil_0.6.17-3.diff.gz to pool/main/s/skencil/skencil_0.6.17-3.diff.gz skencil_0.6.17-3.dsc to pool/main/s/skencil/skencil_0.6.17-3.dsc skencil_0.6.17-3_i386.deb to pool/main/s/skencil/skencil_0.6.17-3_i386.deb sketch_0.6.17-3_all.deb to pool/main/s/skencil/sketch_0.6.17-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
