OpenLanParty v1.0 (stable)
Molti sono gia' tornati dalle ferie ma non tutti hanno ripreso a lavorare o stanno lavorando ma nell'aria e' ancora la voglia di vacanza. Basta con corsi, seminari, dottorati, saldatori e masterizzatori! Dedichiamo 24 ore alla Debian? Perche' no?! = Quale occasione migliore per un sabato ludico? Sabato 30 agosto 2003 dalle 10:00 alle 22:00 (12 ore), di colpi bassi a suon di giochi a licenza aperta. = Dopo il piacere il 'dovere'. Dopo le 22:00 si chiudono le ostilita' anche per ridurre il rumore, i vicini sono sempre proppo vicini, e comincia la seconda faccia della giornata con del sano hacking (quello vero) in bug fixing della testing. Sabato 30 agosto dalle 22:00 alle 10:00 di domenica 31 agosto, Debian Bug Release Critical Fixing. Il 16 agosto e' stato il compleanno della Debian e la prossima stabile (Sarge) e' prevista per il 1 dicembre 2003, ma serve una mano. = Dove? Nelle due aule sede di OpenLabs via Ornato 7, Milano (citofonare tensioniCrative) = Come funziona? Si porta il proprio computer (portatile e non). Gratite anche patatine, biscotti, beveraggio (c'e' il frigo), dolcumi di varia forma e colore. Portate pure non si offendera' nessuno e mi pare un ottimo conributo spese! [;) Noi mettiamo tavolo, sedia, una presa di rete e una di alimentazione. Ci saranno CD e gadget Debian in vendita un cui ricavato andra' a finanziare il progetto: adesivi, CD di Woody e Knoppyx 3.2 (donati da OpenLabs) e le magliette della Debian (Debian Italia). Si gioca solo con giochi presenti su Debian GNU/Linux: c'e' da scegliere fra circa 379 pacchetti... Altre proposte ben accette anche perche' c'e' a disposizione connettivita' (fastweb) per scaricare cio' che puo' servire. Per ogni partita registreremo i risultati del torneo. NB: per i giochi in OpenGL sono necessari computer con accellerazione 3D (possibilemente gia' configurata se non c'e' troppo casino vi si da una mano a farlo). = A cosa si gioca? Alla faccia di chi dice che con Linux non ci si giuoca e approfittando della calma piatta di questo mese sei invito a partecipare al primo OpenLanParty dedicato a Debian per il suo primo 10° compleanno. Non e' una limitazione di distribuzione per chi partecipare ma una scusa vale l'altra per giocare, quindi sono ben accetti cappelli rossi, diavoletti con sparp' da tenis, cani gialli, samaleonti, ecc. Insomma non c'e' limite di sistemi operativi, distro ma attenzione che i giochi siano di versioni coerenti. Non e' da escludersi una successiva birra per chiudere le ostilita'. Le proposte iniziali sono le seguenti graditissime aggiunte. Sezione Console * netris: Tetris in rete multiplayer * moon buggy: Vintage gaming a caratteri Sezione X * Gtetrinet: Tetris in rete multiplayer * Tag: Simil Risiko via rete multiplayer * freeciv: gioco di strategia multiplayer clone libero di Civilization II * xblast: bomberman in rete max in 6 a lanciarsi bombe Sezione 3D * TuxRacer: Una bella discesa col pinguino! OpenGL * Quake II: Dopo doom venne Quake! OpenGL * Doom Legacy: versione OpenGL del mitico Doom * BzFlag: Arena multiplayer OpenGL * Armagetron: gioco in OpenGL ispirato a Tron * Crack Attack: tetris in OpenGL * CannonSmash: ping pong da tavolo in OpenGL = Debian Bug Release Critical Fixing? Solo Debian ha un Assicurazione di Qualita' (inglese): http://qa.debian.org/ Bug interessati: http://bugs.debian.org/cgi-bin/claims.cgi Ci saranno a disposizione iMac e qualche postazione sulle quali poter lavorare. = Vi aspettiamo numerosi (ma non troppo altrimenti non ci entriamo tutti!) Ciao a tutti Fabrizio G. Ficca (Fab) -- Se leggete SOLO questa riga OutLook e' bacato: guardate l'allegato! .. | www.AutoriVari.net | www.OpenLabs.it| | GNU/IT Consulting | Associazione Culturale | | [EMAIL PROTECTED] | [EMAIL PROTECTED]| `' pgpr9KnLir2Fv.pgp Description: PGP signature
Re: maintaining upstream snapshot package (was: Bits from the RM)
On Sun, Aug 24, 2003 at 07:45:26AM +0900, Tatsuya Kinoshita wrote: In order to ease some of the pressure on unstable, we're encouraging greater usage of experimental. [...] I'm a maintainer of Debian wl/wl-beta packages (Wanderlust: mail/news reader for Emacsen). Debian wl package provides the upstream stable version (latest version is 2.10.1-2). Debian wl-beta package provides the upstream CVS snapshot which reaches Debian release-quality (latest version is 2.11.7+0.20030814-1). I intended to include both wl and wl-beta in Debian unstable/ testing/stable. Why? If wl-beta is Debian release-quality, why would anyone want to use wl? Are you doing this for the benefit of users, or because you're worried you might be guessing wrong, or because it's what upstream prefers, or what? Should we remove Debian wl-beta package from unstable? Only distributing one version of the package is less confusing for users; but there may be other reasons to distribute multiple versions that are more important. cf exim and exim4, eg. Should we rename Debian wl/wl-beta packages if we want to put both packages in unstable/testing/stable? That seems like a bad idea; package renames are generally more of a nuisance than a benefit. If, as maintainer, you think the current way of doing things is the best way, don't change. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgp4YuOfcXT6h.pgp Description: PGP signature
Re: packages mucking in /usr/local/?
Colin Watson [EMAIL PROTECTED] writes: On Sun, Aug 24, 2003 at 05:35:41AM +0800, Dan Jacobson wrote: Gentlemen, do $ find /usr/local -mtime -222 /usr/local/lib/libxbase-2.0.so.0 /usr/local/lib/libxbase.so If those came from a package, they're bugs. /usr/local/lib/python2.2/site-packages /usr/local/lib/python2.3/site-packages /usr/local/lib/texmf/ls-R /usr/local/share/emacs/21.3 /usr/local/share/emacs/21.3/site-lisp /usr/local/share/octave/site-m... Those aren't bugs (well, possibly apart from the TeX one, dunno about that). Same idea as described below (tex is slightly different, its packaging system likes to have an index file). 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. Note, that this applies only to directories _below_ `/usr/local', not _in_ `/usr/local'. Packages must not create sub-directories in the directory `/usr/local' itself, except those listed in FHS, section 4.5. However, you may create directories below them as you wish. You must not remove any of the directories listed in 4.5, even if you created them. -- A.J. Rossini [EMAIL PROTECTED]http://www.analytics.washington.edu/ Biomedical and Health Informatics University of Washington Biostatistics, SCHARP/HVTN Fred Hutchinson Cancer Research Center UW : FAX=206-543-3461 | moving soon to a permanent office FHCRC: 206-667-7025 FAX=206-667-4812 | Voicemail is pretty sketchy/use Email CONFIDENTIALITY NOTICE: This e-mail message and any attachments may be confidential and privileged. If you received this message in error, please destroy it and notify the sender. Thank you.
Re: packages mucking in /usr/local/?
On Sun, 24 Aug 2003 05:50:07 +0200, Colin Watson wrote: /usr/local/lib/texmf/ls-R Those aren't bugs (well, possibly apart from the TeX one, dunno about that). ls-R is an index generated by texhash, so that Debian's teTeX can use TeX packages installed under /usr/local. -- Best Regards, | Hi! I'm a .signature virus. Copy me into Sebastian | your ~/.signature to help me spread!
Mail delivery failed: returning message to sender
Your message attached below could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED]: Due to technical difficulties, we have temporarily suspended our main e-mail address, please re-send your message to [EMAIL PROTECTED] ---BeginMessage--- [ Message body suppressed (exceeded 5 bytes) ]---End Message---
Re: Debian Weekly News - August 19th, 2003
[John: Not only did you ignore my Mail-Followup-To header, to which I drew your attention in the very first line of my reply, but you mailed me a private copy of your message. Please review the Debian Mailing List Code of Conduct. Followups set, AGAIN.] On Fri, Aug 22, 2003 at 03:34:06PM -0500, John Goerzen wrote: On Fri, Aug 22, 2003 at 12:06:39PM -0500, Branden Robinson wrote: The Social Contract[1] says that Debian will remain 100% Free Software, and that the Debian Free Software Guidelines shall be a tool that we use to for determining whether something in the Debian distribution is Free Software or not. Debian Developers have pledged to The corrolary is that 0% of Debian is non-free software. Documentation is not software at all. I see you have not taken my advice to read the archives of debian-legal. http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00027.html The Social Contract does not say: Debian Will Remain 100% Free Software and Some Other Things That Aren't Software But Which Are Also Free But Meet a Different Definition Of Free Than That Which Applies to Software, Plus Some Other Stuff That Isn't Free By Any Stretch Of The Imagination But Which We Thought Would Be Nice To Have. The mere fact that the social contract says that 100% of Debian is Free Software does not magically make everything that is part of Debian software. Just saying something is so is begging the question, and I am getting tired of that game. I'm getting tired of the game that interprets: This food product is 100% fat free. as: The stuff that isn't fat in this food product is 100% fat-free, but the non-fat-free stuff might have fat in it. I'm also getting tired of having words put in my mouth. I have at no time (and neither has any other opponent of different standards of freedom for documentation within the Debian Project, to my knowledge), asserted that documentation *IS* software. Please cease these fallacious straw man attacks. I'm also getting tired of you not familiarizing yourself with the voluminous past discussions of this subject. If you take Clause 1 of the Social Contract to literally mean that Debian contains nothing save software that is free, then that clause has never been true since it was introduced, since we have always contained many non-software items (documentation, bibles, Linux Gazette issues, RFCs, graphics, wallpapers, sounds, etc.) http://lists.debian.org/debian-legal/2001/debian-legal-200112/msg00023.html If it's not *Software* then either, 1) We must treat it as such, or; 2) We have no mandate to deal with it at all. Wow, look at that. December 2001. I wonder if people have talked about these issues while you weren't paying attention? If you take Clause 1 of the Social Contract to mean that all software in Debian is free, it makes a lot of sense to me, and does not itself remove the moral requirement that documentation and other files are free as well. Everything we possibly can ensure to be Free in Debian must be Free. That means everything except legal notices (copyright notices, license terms, warranty disclaimers, and the like). We could do without that stuff as well, except we'd either expose ourselves to legal liability, or be left only with public domain materials. Either would mean there wouldn't be a Debian Project for much longer. I guess at this point you can, if you like, argue that losing the GNU Emacs Manual, with its inseparable GNU Manifesto, would deal the Project an equally fatal blow. Not that I see that this whole discussion bears any relevance to the DFSG/GFDL discussion. It's a discussion of the Social Contract, for which the correct forum is debian-project. This is not a technical discussion. Please stop grandstanding on debian-devel. -- G. Branden Robinson|It was a typical net.exercise -- a Debian GNU/Linux |screaming mob pounding on a greasy [EMAIL PROTECTED] |spot on the pavement, where used to http://people.debian.org/~branden/ |lie the carcass of a dead horse. pgpNdSWnIlF68.pgp Description: PGP signature
Re: maintaining upstream snapshot package
On August 24, 2003 at 2:25PM +1000, Anthony Towns aj@azure.humbug.org.au wrote: Debian wl package provides the upstream stable version (latest version is 2.10.1-2). Debian wl-beta package provides the upstream CVS snapshot which reaches Debian release-quality (latest version is 2.11.7+0.20030814-1). I intended to include both wl and wl-beta in Debian unstable/ testing/stable. Why? If wl-beta is Debian release-quality, why would anyone want to use wl? Are you doing this for the benefit of users, or because you're worried you might be guessing wrong, or because it's what upstream prefers, or what? wl-beta has new features, bug fixes, etc. I feel that wl-beta is useful and reaches Debian release-quality. But wl is more stable than wl-beta, because wl-beta might have new/unknown bugs. Users might prefer the upstream stable version instead of the CVS snapshot. So, I provided user option, wl/wl-beta. I can find `User-Agent: Wanderlust/2.10' (stable version) and `User-Agent: Wanderlust/2.11' (CVS version) in Debian mailing lists. I think that providing wl/wl-beta helps users. If, as maintainer, you think the current way of doing things is the best way, don't change. Could you, Release Manager, accept putting wl and wl-beta in Debian unstable/testing/stable? If so, I don't change the current way (uploading wl and wl-beta in unstable). BTW, I have a similar issue for the mew package. I ITPed mew-beta (Bug#203991) on 2003-08-03, but it is now pending because of this issue. I'll do the same way as wl for mew. -- Tatsuya Kinoshita
Re: Debian Weekly News - August 19th, 2003
[Followups set.] On Sat, Aug 23, 2003 at 03:21:00AM +0200, Marco d'Itri wrote: I'd say that you have your priorities wrong. If we decide that documentation is not software then there is no reason to waste time to figure out if the GFDL is DFSG-free or not. It's not within debian-legal's purview to attempt to answer one question; it is to attempt to answer the other. If you want documentation to be subjected to a different standard than software (whatever those are), then set about drafting that different standard. On debian-project. So far no one has managed to do it.[1] [1] draft a standard, *or* discuss this on the correct mailing list -- G. Branden Robinson|Freedom is kind of a hobby with me, Debian GNU/Linux |and I have disposable income that [EMAIL PROTECTED] |I'll spend to find out how to get http://people.debian.org/~branden/ |people more of it. -- Penn Jillette pgpQjpKJ7JdDL.pgp Description: PGP signature
Re: Debian Weekly News - August 19th, 2003
On Sat, Aug 23, 2003 at 02:00:49AM +0300, Richard Braakman wrote: The survey asks whether the GFDL _does_ satisfy the DFSG, not whether it needs to. Did you misspeak here? Yes. I wrote that reply in hot blood. I didn't write my survey thus. -- G. Branden Robinson| Yesterday upon the stair, Debian GNU/Linux | I met a man who wasn't there. [EMAIL PROTECTED] | He wasn't there again today, http://people.debian.org/~branden/ | I think he's from the CIA. pgpbtFGnvej4M.pgp Description: PGP signature
Re: Update: Patch needs Sponsor - List of easily NMUed RC bugs
Goswin von Brederlow (2003-08-23 23:59:31 +0200) : Goswin von Brederlow [EMAIL PROTECTED] writes: Hi, I went through the RC bug list and collected Bugs with trivial patches and sorted them a bit. They realy don't need much work so if you have a minute pick one. If you want to NMU any of them check the then currently claimed bugs (url under claimed bugs). Changes: pending (+1), fixed(+13). Keep up the good work sponsoring those uploads. Keep up the good work yourself. I find this kind of message very useful. Also, Joshua's patches on some (if not most) of these bugs are a treat, too. Thanks to you both. Now for the real content: people, don't start working on a bug before you've checked http://bugs.debian.org/cgi-bin/claims.cgi for effort duplication. I've wasted enough time myself already :-) Roland. -- Roland Mas [...] Des fois, y'a des trous. -- (Ptiluc) -- Signatures à collectionner, série n°2, partie 3/3.
Re: What does that (from wanna-build stats) mean?
Op za 23-08-2003, om 12:53 schreef Joerg Wendland: Hi, when looking at [0] I see the following about my python-bz2: python/python-bz2_1.1-6: Failed by buildd-caballero [optional:out-of-date] Reasons for failing: [Category: none] bug #181674, missing build dep on bzip2 Previous state was Building until 2003 Aug 13 11:47:54 Does that mean that the build failed (which it indeed did for a bug in dh_python) and the package is not tried to be rebuilt because of the (long closed in versions before) bug mentioned aboved? Yes. You'll want to contact the ia64 porters -- or upload a new version, if appropriate -- to get this fixed. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
unsubscribe
Pozdrawy PoLi ,-, | [EMAIL PROTECTED] | `-'
Re: Correct Directory for networkboot clients
Am Sam, 2003-08-23 um 20.00 schrieb Petter Reinholdtsen: [Goswin von Brederlow] Then it must be read-only. To the client and the server. No changing of links or hostame or anything in there. LTSP keep all the client specific files in RAM file system. The NFS-mounted root is not written to by the client. So I go to use this directory usr/share/ltsp/arch/ or any more comments ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Retrieve my key from: www.keyserver.de blackhole.pca.dfn.de horowitz.surfnet.nl keyID 7B196671 or send email with subject fetch key signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Update: Patch needs Sponsor - List of easily NMUed RC bugs
Hi, I went through the RC bug list and collected Bugs with trivial patches and sorted them a bit. They realy don't need much work so if you have a minute pick one. If you want to NMU any of them check the then currently claimed bugs (url under claimed bugs). Changes (~24h): pending (-2), fixed(+16), patch(-1). Keep up the good work sponsoring those uploads. Roland Mas [EMAIL PROTECTED] writes: Keep up the good work yourself. I find this kind of message very useful. Also, Joshua's patches on some (if not most) of these bugs are a treat, too. Thanks to you both. Now for the real content: people, don't start working on a bug before you've checked http://bugs.debian.org/cgi-bin/claims.cgi for effort duplication. I've wasted enough time myself already :-) By they way: How do you claim a bug? How does/Can a non DD claim bugs? I would love to have this added to the BTS. Have a Claim link on each webpage where one can add ones email and a timeframe (24h/1d/1w) before the claim expires. Is there an Bug-Squashing-Party webpage anywhere I should make readers aware in mails like this? A HowTo? Irc channel? ML? Here we go, the remainders for today: g++-3.3 fixes: -- The same problem comes up again and again, allways the same fix. #196324 xosview: FTBFS with g++-3.3: strstream.h is gone #195527 mysql++: FTBFS with g++-3.3: Missing cassert include #202032 rumba-manifold: FTBFS with g++-3.3: Missing #include cassert #196450 simplecdrx: FTBFS with g++-3.3: Missing cassert include #197214 libggi: FTBFS with gcc-3.3: Uses multiline strings #195577 libnids: FTBFS with gcc-3.3: Uses multiline strings #197762 nte: FTBFS with gcc-3.3: Uses multiline strings #198317 pimppa: FTBFS with gcc-3.3: Uses multiline strings #193067 rust: FTBFS: g++ 3.2 errors #198113 stardict: FTBFS with g++-3.3 #190942 tcl-sql: FTBFS: g++ 3.2 errors Perl touched: - One involves perl knowing a bit perl might be good. #204859 FTBFS (unstable/m68k): perl makes abiword fails to build, bad C++ Other easy stuff: - Bits and pieces #190260 Segmentation fault on alpha #184885 LSB 1.3 test suite failures #196149 mkswap creates invalid swap files #196850 wall is being distributed under wrong license #102675 libggi2-dev: should provide static archives #204456 libjdom-java: Wrong build-dep: does not need xalan2 nor saxon #203750 log4cpp: FTBFS: `long long' error #203823 gnuyahoo: FTBFS: automake error Stuff that should be looked over and tested first: -- Those patches have some impact on the packages or arent so clear cut #192545 pcb: Fails to build with current flex #194168 preferences: FTBFS with gobjc-3.3: #import is obsolete #194164 preferences-app: FTBFS with gobjc-3.3: #import is obsolete #191197 rats: Fails to build with current flex #166737 snmpkit: FTBFS with gcc 3.2 #173762 FTBFS: Build failure of haddock on i386 #167054 FTBFS: Build failure of xview on i386 MfG Goswin
where to install additional kernel modules?
i see pcmcia-source and comedi-source installing the modules into /lib/modules/`uname -r`/pcmcia and /lib/modules/`uname -r`/comedi. my bcm4400-source and bcm5700-source packages install into /lib/modules/`uname -r`/kernel/drivers/net/bcm. Thinking about it, I argue that it would be better to install them into /lib/modules/`uname -r`/bcm since /lib/modules/`uname -r`/kernel is the hierarchy used by the kernel-image and should not be touched by additional modules that are not part of the kernel image. is there a policy item that covers this? what do people think? -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpOMl7fOstts.pgp Description: PGP signature
Re: where to install additional kernel modules?
#include hallo.h * martin f krafft [Sun, Aug 24 2003, 01:00:47PM]: Thinking about it, I argue that it would be better to install them into /lib/modules/`uname -r`/bcm since /lib/modules/`uname -r`/kernel is the hierarchy used by the kernel-image and should not be touched by additional modules that are not part of the kernel image. is there a policy item that covers this? what do people think? IMHO the right location is /lib/modules/`uname -r`/net. .../bcm is wrong since it is not a new device/driver group. MfG, Eduard. -- Hier wird zwar nicht viel gemacht, aber was gemacht wird, ist nicht zu gebrauchen. pgpjKuFmoqpfF.pgp Description: PGP signature
Re: [Proposal] Debconf4 in Brazil
[Carlos Laviola] As Michelle Ribeiro announced in -project[0] but hasn't garnered much attention from the community, we thought it would be better to repost this revised version of our proposal here. We're looking forward for your comments on this idea. I do not expect to be able to find funding to come there, but I think it is a good idea to spread the location of debconf to different continents over time. So I support the proposal, and expect some debconf in the future to be closer to me. :)
Re: where to install additional kernel modules?
also sprach Eduard Bloch [EMAIL PROTECTED] [2003.08.24.1353 +0200]: IMHO the right location is /lib/modules/`uname -r`/net. So what about Bug#189297? Where then should comedi install itself? comedi drivers are for data acquisition cards. -- Please do not CC me when replying to lists; I read them! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! pgpa3oe1i0ZCW.pgp Description: PGP signature
Re: SURVEY: Is the GNU FDL a DFSG-free license?
* Branden Robinson Part 1. DFSG-freeness of the GNU Free Documentation License 1.2 Please mark with an X the item that most closely approximates your opinion. Mark only one. [ X ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is not a license compatible with the Debian Free Software Guidelines. Works under this license would require significant additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, is a license compatible with the Debian Free Software Guidelines. In general, works under this license would require no additional permission statements from the copyright holder(s) for a work under this license to be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] The GNU Free Documentation License, version 1.2, as published by the Free Software Foundation, can be a license compatible with the Debian Free Software Guidelines, but only if certain restrictions stated in the license are not exercised by the copyright holder with respect to a given work. Works under this license will have to be scrutinized on a case-by-case basis for us to determine whether the work can be be considered Free Software and thus eligible for inclusion in the Debian OS. [ ] None of the above statements approximates my opinion. Part 2. Status of Respondent Please mark with an X the following item only if it is true. [ ] I am a Debian Developer as described in the Debian Constitution as of the date on this survey. -- Tore Anderson
NUT packages status checkpoint
Hi fellows, Hope you're all fine, and that the summer is not too hard for you. Here is a small checkpoint about NUT (and related) packages status in Sid: 1) 1.4.1-pre1-1 is in the upload queue since yesterday. It closes all current NUT bugs but #196513 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196513 and #196513. (http://walnut.tuxfamily.org/packages/debian/i386/nut_1.4.1-pre1-1_i386.changes) The later will be closed by the next upstream release! 1.4.1-pre1-1 also introduces the nut-snmp package, with an SNMP Manager, while waiting for the Agent. @Karl: we'll need to sync on #196513 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196513 to solve it... 2) here is my todo list about the nut packages (don't hesitate to complete or close some, but announce it!): * check debconf usage issue in preinst scripts (cf Karl's mail) and more generally recheck all scripts. * create an /usr/share/lintian/overrides/nut file for packaging, containing: script-in-etc-init.d-not-registered-via-update-rc.d /etc/init.d/ups-monitor to override lintian warning, and look if there is an issue (linked to the previous point). * remove /lib/nut/ and /etc/nut/*.sample in nut.postrm(purge) * check dh_shlibdeps -Xupsfetch.o issue (outdated) * create a nut-usb package (need upstream changes) to deal more cleanly with hiddev and other upcoming usb drivers (fixes the current Makefile rule override). * nut.init: in stop) rule, switch start_stop_server stop and start_stop_client stop to stop upsmon first. * nut-snmp.prerm: create and add upsdrvctl stop [snmp] (if snmp-ups is loaded at remove time, it will keep running after removal!) * check if update from 1.2 needs [more] controls * check for doc updates So, lots of things remaining to be done ;-) Other things are currently under development state in NUT for the upcoming 2.0, but will have effect on NUT package splitting in Debian... 3) related NUT packages: * knutclient 0.7-pre2 is in the upload queue for few days, and will close ITP #201015 * wmnut is fine for the moment (0.58). I plan the next upstream for NUT 2.0 switch (undermove with 1.5) * Other existing and not packaged NUT clients are outdated/broken! To conclude, our collaboration (Karl and myself) on NUT bug squashing was really productive! I think he also should be listed as NUT Co Maintainer to officialise it, as Karl is also one of the most active people in the NUT Community! While waiting to read you, Arnaud
Snort: Mass Bug Closing
Hi, I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, 135603, 161659, 165107, 165135, 165351, 171190, 172529, 173663, 174506, 174508, 174509, 192401, 193544, 101725, 122689, 159575, 165126, 182280, and 189780 with a nice message telling that the bug was reported on a really old package-version and the bug is really old too, including a URL to an up to date version of the package, where most probably all these bugs are fixed. If you haven't guessed already, this again is about snort stable. I'm having a huge pile of bugs on the package, of which a lot filed on 1.8.4* packages. I will not be doing anything to fix the bugs found in these 1.8.4* packages. Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Still a lot of people use the outdated and utterly broken 1.8.4 release and complain. Although these complaints are correct, I will from now on close them and tell the submitter to use my backported, newer packages or compile his/her own. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) It's for the users best interrest that I tell them to use the new version. So. I will first backport the current snort package again, and then close the bugs metioned above, if no one in the near future objects to this 'mass bug closing'. Concept close-bug-message: Hello, You have submitted this bug to the snort package. Most probably against the version of snort found in the stable release of Debian. Because much has changed during the past time, and a lot of security related things have been fixed in newer versions of Snort, I am now closing this bug without actually fixing that version of Snort in Stable. Instead I provided up to date, signed packages at this[1] url. You can put this URL in your apt's sources.list like so[2], to have automatic installation of newer backported packages when they are released. If you feel this bug to be closed incorrectly, or the problem still exists in the newer version of snort, please reopen this bug. Thanks for your interrest in improving snort! Kind regards, Sander Smeenk. Snort package maintainer. [1] http://people.debian.org/~ssmeenk/snort-stable-i386/ [2] deb http:///people.debian.org/~ssmeenk/snort-stable-i386/ ./ -- | Do jellyfish get gas from eating jellybeans? | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D -- | A box withouth hinges, key, or lid, yet golden treasure inside is hid. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Hi, I'm about to close 95153, 133049, 158040, 16, 170580, 173331, 176223, (...) I object. Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Still a lot of people use the outdated and utterly broken 1.8.4 release and complain. Although these complaints are correct, Maybe because they are not aware of your backporting efforts. I will from now on close them and tell the submitter to use my backported, newer packages or compile his/her own. Yes, these utterly broken release is in all Debian CDs and mirrors. Bugs are bugs, if they are not fixed then don't close them. BTW, they are not even tagged properly (i.e. 'stable') Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) Then you should work towards fixing them in stable or having ftp-masters agreeing with including a new (backported) version at proposed-updates. It's for the users best interrest that I tell them to use the new version. It is for the best interest of the users that you provide a proper snort version in proposed-updates. Having bugs closed in a package which is still distributed leads to a false sense of workability of the package. Having all these bugs marked 'stable' and tagged 'wontfix' tells users best that they should not be using them at all! For example, closing bug #173254 instead of reassigning it to www.debian.org or ftp.debian.org was not proper. It should be marked 'stable', or reassigned to other team! You should not close bugs just because you cannot solve them, they will not go away just because of that. This is a similar situation to #183524. We have to determine a way to remove packages completely out of stable (due to unfixable security bugs, for example) in a way that do not leave users exposed to these and their bugs. Having a dummy package at proposed-updates which just says please do X, Y, and z to have package A in your Debian stable system might be one of them. Regards Javi pgp1VE348GaBe.pgp Description: PGP signature
NMUs applying sleeping wishlist bugs about translation (was something else)
On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote: * Christian Perrier ([EMAIL PROTECTED]) wrote: Quoting Stephen Frost ([EMAIL PROTECTED]): I, for sure, cannot hijack any package for which nothing has been done for translation related bugs. I would quickly end up with dozens of packages I'm responsible for, the majority of which I'm perfectly unable to maintain. If you can't maintain the package then you shouldn't be NMU'ing it. It's real simple, learn that. WowThere's a strong difference between maintaining a package, which means following it along its entire life and making one single fix for a very specific thing. Except what you don't realize is that one should never, ever, ever just NMU and then forget about the package. If you do an NMU then you need to make sure it worked, follow the package and make sure there aren't problems with it and follow up with the maintainer on the bugs. I don't care what you change in the package, if you NMU then you need to do that at a *minimum*, just as if you were the maintainer. It's not until the official maintainer incorporates the NMU changes and closes the bugs that the NMU'er can forget about it. Dude, translators already more than this. When I translate a package, I register to its PTS to check that my translation does not trigger any translation bug report. Are you one of the guys considering translators as a technically handicaped plague of the Debian world? I know that most of the time, the problem is between the screen and the chair, but that's not always the case ;) Of course, translators can only do that for the package whom they translate the po files or documentation. People translating the debconf templates feel often responsible for a few hundreds of them. The lack of i18n tag to bug reports makes it impossible for them to watch the state of their work efficiently that way. For NMU, I know that Christian tracks every NMUed packages until the next maintainer upload, to check that his changes are not broken or ignored. If you speak some french, come on debian-l10n-french for one week, to see the logistic issues we are facing, and how we address them. If you speak another language, go to the relevant debian-l10n- list, I'm sure that the french team is not an exception here, but rather the average. I'm perfectly able to do the changes required by the NMU i send, mostly po-debconf switches or translation incormoration. But, if a bug related to something completely different in the package occurs, then I cannot fix it be cause I'm not invloved in the given software. Then you shouldn't be doing an NMU on it. When you NMU something you take responsibility for it temporairly until the maintainer gets back. Could you point the poor stupid monkeys we are to the relevant part of the policy or developer reference or whatever other document ? I really do not understand what let you think about NMU that way, especially after the last bits of the RM... For what I read, it is not required to be able to maintain everything for a given package for being able to NMU it. It is just required to be able to fix possible introduced bugs Then what you read is wrong. Again, why? Stating without argumenting will only bring us in yet another fruitless flamewar. Please help us avoiding that curse. They're not complex at all. Most of the time (for russian translations), it is just required to know how to uudecode file and how should a debconf translation be named... :-) A patch would probably still be easier, but whatever. No offense intended, but this statement clearly shows a misunderstanding of the issues the russian (and japaneese) translators are facing. If they provide a simple patch, it is almost certain that the maintainer with extract it from the mail and apply it with tools not well suited to the weird encoding they need, leading to catastrophic results such as undisplayable texts on user boxes, which is even worst than untranslated ones, isn't it? On the other hand, uuencoding the patchs helps to make sure that the encoding will be preserved by the stupid mailers and wrong configurations out there. This is precisely what's currently happening.. :-) Glad to hear it, perhaps some day you will, though personally I hope to hell you never manage to get it considered an RC bug, and I'll work to make sure that doesn't happen. Who, beside you, spoke of raising the gravity of translation bugs to RC ? Christian certainly meant that the normal gravity may be better appropriated to such bugs, since it *does* make the package unusable under some conditions (when the user cannot speak english, obviously). Let's be provocative: Stating the contrary may be bring down to the point that free software is about making software freely available (as in free speach) to the american, british and autralian people on the earth, plus some elites of the other
Re: Snort: Mass Bug Closing
Sander, in principle, I agree that fixing those bugs by backporting patches is not worth the effort, but let me suggest an alternative plan (which the SRM will hate me for, so you should probably ask him before): - Check which of those bugs are really fixed in the newest version - Upload a backported package that + Pre-Depends on debconf + in its preinst gives the user the choice to abort the installation along with a message describing the situation (no new rules in the old format, ...). + includes a script to convert rules from the old to the new format + closes all the bugs in the changelog (they will be closed when the SRM installs the packages in the next point release or on security, depending on what you and the SRM agree is more appropriate) This way, all users will benefit from the upgrade, not only those who have sent in bug reports. If people have written local rule files, they get the chance to convert them to the new format and are not suddenly left with a system that cannot read their rule files. While this may not be a good idea to go about every outdated package in stable, I do think this particular update makes sense. Also, you don't have to worry about other arches that way, since they will be autobuilt. Then go on backporting necessary fixes to that version, so people aren't forced into an incompatible upgrade again. Simon (who didn't mean to turn on his box while officially on vacation) -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgpJlG645KUrj.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) It's for the users best interrest that I tell them to use the new version. [2] deb http:///people.debian.org/~ssmeenk/snort-stable-i386/ ./ ~ Typo. I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. -- 2. That which causes joy or happiness.
Building kernel modules for stock kernels is a hell of a job!
Hello, After having worked with Debian testing for about 2 years, I'm getting fed up with the seemingly unnecessarily complicated way of building kernel modules for the stock kernels. I'm talking about packages like lm-sensors-source, the nvidia kernel modules (haven't done that in a year though, I switched video cards), and the experimental Debian packages that provide CVS versions of the DRM module by Michel Daenzer (for my ATI card). Currently, I'm having the following stock kernel installed: kernel-image-2.4.21-4-k7, meaning my kernel modules are in /lib/modules/2.4.21-4-k7. The procedure I'm going through is as follows (being root all the time) 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 3) do the usual ln -s kernel-source-2.4.21 linux 4) to avoid having to configure the kernel again, copy the configuration: cp /boot/config-2.4.21-4-k7 /usr/src/linux/.config 5) apt-get install [modulename-source] (sometimes -src), e.g. lm-sensors-source. 6) this should give [modulename].tar.gz in /usr/src; extract it: tar xzvf [modulename].tar.gz now, the source is in /usr/src/modules/[modulename] 7) and now, I always do the following (in bash): export APPEND_TO_VERSION -4-k7 if this is omitted, the kernel modules will be installed in the wrong directory, in this case in /lib/modules/2.4.21/, which doesn't even exist (it is created though). 8) go to /usr/src/linux and type: make-kpkg modules_image this will build the sources and should result in a Debian package in /usr/src, named something like this: [module-name]-2.4.21-4-k7_[version_of_module_source_package]+10.00.Custom_i386.deb If you didn't use the export in step 7, you'll see that the name is like this: [module-name]-2.4.21_[version_of_module_source_package]+10.00.Custom_i386.deb Probably you can also get this version number correctly by using a --append-to-version command line option in the make-kpkg command line 9) install the just built package(s) with dpkg -i [package_name] now the kernel modules should be in the right dir in /lib/modules and modprobe (or modconf) can find them. That's it. Notes: - If you have just installed a new kernel-image package (i.e. a new stock kernel), you need to do everything from the start *after* booting this new kernel - In my experience, if you forget the export of step 7, you have to wipe your whole kernel source tree and start at step 2. I know I'm supposed to do a make-kpgk modules clean, but that didn't do the trick; I still got errors like The changelog says we are creating 2.4.21-4-k7, but I thought the version is 2.4.21 or something similar (I didn't actually copy paste this from a real situation, it might have been the other way round). - If you have more modules to build, repeat steps 5, 6, 8 and 9 for all the source packages. - all of the above really works, so I must be doing something right. QUESTIONS: A) Why isn't this procedure documented properly somewhere? Especially the APPEND_TO_VERSION was something that took me very long to figure out. It also wasn't mentioned in the installation instructions in the NVIDIA packages at the time I installed them. This caused a lot of mental suffering for me. (Which brings us to another thing: WHY oh WHY, isn't the procedure to get and install the NVIDIA drivers more automated!?) B) Is there a faster or easier way to this? If not, why not? There's a lot of trivial stuff there that could easily be automated, I think. If so, (again:) why isn't it properly documented somewhere!?? See also this: http://lists.debian.org/debian-devel/2002/debian-devel-200203/msg01794.html and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=189513 People, stock kernels are very comfortable, but building modules for them is not! Please tell me what I did wrong, or make the procedure a lot easier! (The latter especially applies to the maintainers of that NVIDIA package...) Luckily, David Z. Maze has the lm-sensors as binary package in unstable nowadays... :) (Although not yet for 2.4.21...) THANKS in advance. Best regards, A quite frustrated Manuel Bilderbeek :-)
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 03:57:45PM +0200, Sander Smeenk wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? -- Jamin W. Collins Remember, root always has a loaded gun. Don't run around with it unless you absolutely need it. -- Vineet Kumar
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 04:51:08PM +0200, Josip Rodin wrote: Instead I provide signed backported packages on p.d.o which I will keep 'semi up to date'. Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) It's for the users best interrest that I tell them to use the new version. [2] deb http:///people.debian.org/~ssmeenk/snort-stable-i386/ ./ ~ Typo. I've upgraded to this version and it has required me to press y to replace modified conffiles in /etc/snort/rules/ about two dozen times, while I'm pretty sure I never touched any of them. That's an pretty impressive amount of annoyance you managed to cause there. Oh and it didn't even want to start properly -- and the init script wasn't even so kind to tell me, I had to learn from syslog that Aug 24 16:57:23 hostname snort: FATAL ERROR: Unable to open rules file: ../rules/bad-traffic.rules or /etc/snort/../rules/bad-traffic.rules All it took to make it work was to change RULE_PATH from ../rules to /etc/snort/rules, but it's still broken that it didn't detect this properly. -- 2. That which causes joy or happiness.
Re: Building kernel modules for stock kernels is a hell of a job!
#include hallo.h * Manuel Bilderbeek [Sun, Aug 24 2003, 04:32:45PM]: The procedure I'm going through is as follows (being root all the time) 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 Why don't you use the kernel-headers packages and use them as partial kernel source? They provide header files (including the complete kernel version) and the .config that belongs to them. Notes: - If you have just installed a new kernel-image package (i.e. a new stock kernel), you need to do everything from the start *after* booting this new kernel No, you don't. If some package requries it, file a bug report. To make the kernel find the modules you have to reboot anyways (so depmod is executed from the init script) or the modules package runs depmod (with the special path arguments for the new kernel) in postinst. - In my experience, if you forget the export of step 7, you have to wipe your whole kernel source tree and start at step 2. I know I'm supposed to do a make-kpgk modules clean, but that didn't do the trick; I still got errors like The changelog says we are creating 2.4.21-4-k7, but I thought the version is 2.4.21 or something similar (I didn't actually copy paste this from a real situation, it might have been the other way round). Should not happen. If it fails, file a bug report. - all of the above really works, so I must be doing something right. QUESTIONS: A) Why isn't this procedure documented properly somewhere? Especially This is not the default procedure. Working with kernel-headers is documented in some FAQs and many README.Debian files of the ...-src packages. NVIDIA packages at the time I installed them. This caused a lot of mental suffering for me. (Which brings us to another thing: WHY oh WHY, isn't the procedure to get and install the NVIDIA drivers more automated!?) I fail to see your problem. Read /usr/share/doc/nvidia-kernel-src/README.Debian.gz and follow the steps in the section: METHOD #1 Using a kernel-headers package *** MfG, Eduard. -- Ihr wollt also mit ein oder mehreren PHP-Leuten ins LinuxTag-Büro einziehen wegen Kommunikationsproblemen (mit wem?!), aber nicht sagen, warum? Und wer verteilt hier eigentlich Redeverbote? -- Klaus Knopper
Re: Update: Patch needs Sponsor - List of easily NMUed RC bugs
On Sun, Aug 24, 2003 at 12:22:31PM +0200, Goswin von Brederlow wrote: How do you claim a bug? How does/Can a non DD claim bugs? See my post to -devel-announce; and no, respectively. If a debian-developer wants to sponse a non-maintainer's claim (and will upload the fixed package for him/her), make a file like ajt-sponsoring-mrvn in the claims directory. Ideally add a .forward-sponsoring-mrvn file so people can easily email the claimant. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpsrQ0KgaEw0.pgp Description: PGP signature
Re: maintaining upstream snapshot package
On Sun, Aug 24, 2003 at 03:45:20PM +0900, Tatsuya Kinoshita wrote: If, as maintainer, you think the current way of doing things is the best way, don't change. Could you, Release Manager, accept putting wl and wl-beta in Debian unstable/testing/stable? If so, I don't change the current way (uploading wl and wl-beta in unstable). I don't have any problem with it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpwydD6tIzQ4.pgp Description: PGP signature
Re: where to install additional kernel modules?
martin f krafft [EMAIL PROTECTED] writes: Where then should comedi install itself? comedi drivers are for data acquisition cards. /lib/modules/VERSION/misc? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 01:00:47PM +0200, martin f krafft wrote:
i see pcmcia-source and comedi-source installing the modules into
/lib/modules/`uname -r`/pcmcia and /lib/modules/`uname -r`/comedi.
my bcm4400-source and bcm5700-source packages install into
/lib/modules/`uname -r`/kernel/drivers/net/bcm.
Thinking about it, I argue that it would be better to install them
into /lib/modules/`uname -r`/bcm since
/lib/modules/`uname -r`/kernel is the hierarchy used by the
kernel-image and should not be touched by additional modules that
are not part of the kernel image.
is there a policy item that covers this? what do people think?
the right place is /lib/modules/${kver}/${package}
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 12:03:23PM -0400, Aaron M. Ucko wrote: martin f krafft [EMAIL PROTECTED] writes: Where then should comedi install itself? comedi drivers are for data acquisition cards. /lib/modules/VERSION/misc? no. that's wrong for 2.4+ kernels.
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 12:13:03PM -0400, Aaron M. Ucko wrote:
Christoph Hellwig [EMAIL PROTECTED] writes:
no. that's wrong for 2.4+ kernels.
Interesting, as it seems to be the status quo; I have a bunch of
modules in /lib/modules/2.4.21/misc (from four different modules
packages produced via make-kpkg), which incidentally all seem to load
fine.
They will of course still load fine, but one of the reasons for
the module directory layout change is that each package gets its
own directory under /lib/modules/${kver}/
No need to Cc me, BTW.
Then setup your headers properly..
Re: Re: Building kernel modules for stock kernels is a hell of a job!
2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 Why don't you use the kernel-headers packages and use them as partial kernel source? They provide header files (including the complete kernel version) and the .config that belongs to them. Because for some of them it wasn't enough. So, to be on the safe side, I used the sources. A) Why isn't this procedure documented properly somewhere? Especially This is not the default procedure. Working with kernel-headers is documented in some FAQs and many README.Debian files of the ...-src packages. I haven't seen any README.Debian package that had a description of the procedure that worked out-of-the-box. Most of the time, using stock kernels is not taken into account, so the APPEND_TO_VERSION stuff is missing. NVIDIA packages at the time I installed them. This caused a lot of mental suffering for me. (Which brings us to another thing: WHY oh WHY, isn't the procedure to get and install the NVIDIA drivers more automated!?) I fail to see your problem. Read /usr/share/doc/nvidia-kernel-src/README.Debian.gz and follow the steps in the section: METHOD #1 Using a kernel-headers package *** At the time I still used it (again, one year ago or so), this didn't work out-of-the-box, because of the APPEND_TO_VERSION stuff. I see this has been fixed in the meantime, in step 4 of the installation instructions in the file you mentioned. Still, couldn't this be a lot more automated? -- Grtjs, Manuel PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ ) PPS: Visit my homepage at http://manuel.msxnet.org/
Re: where to install additional kernel modules?
Christoph Hellwig [EMAIL PROTECTED] writes: no. that's wrong for 2.4+ kernels. Interesting, as it seems to be the status quo; I have a bunch of modules in /lib/modules/2.4.21/misc (from four different modules packages produced via make-kpkg), which incidentally all seem to load fine. No need to Cc me, BTW. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: where to install additional kernel modules?
Moin Christoph! Christoph Hellwig schrieb am Sunday, den 24. August 2003: Where then should comedi install itself? comedi drivers are for data acquisition cards. /lib/modules/VERSION/misc? no. that's wrong for 2.4+ kernels. Any evidence? AFAICS modutils don't have problems with it. MfG, Eduard. -- Wer ist hier idle? -- Kester Habermann
Re: where to install additional kernel modules?
also sprach Christoph Hellwig [EMAIL PROTECTED] [2003.08.24.1806 +0200]:
the right place is /lib/modules/${kver}/${package}
says who?
--
Please do not CC me when replying to lists; I read them!
.''`. martin f. krafft [EMAIL PROTECTED]
: :' :proud Debian developer, admin, and user
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver!
pgpTkg3v8wwFy.pgp
Description: PGP signature
This is not a policy bug
reassign 206928 nullmailer thanks Hi, Firstly, a violation of a SHOULD directive in policy is a bug. Policy defines what the meaning of must, should, and may is in the context of policy, and developers are supposed to have familiarized themselves with Debian policy. Secondly, Debian policy trumps the LSB, as far as Debian packages are concerned. If there is a conflict, packages need to follow policy first. While is is desirable to follow the directives of the LSB, we have not yet committed to o so when it conflicts wioth thte way debian currently works. Thirdly, there is a reason that init scripts should be silent when the package is removed but not purged; since init scripts are conffiles, and remain on the system after removal; unnecessary chatter from these scripts is distrcting to the end user, and there is no need to inform him; since the package removal was done at the request of the admin. I am sending this bug back to nullmailer (violating policy as it does means it is a bug in nullmailer). If you disagree with policy, and wish to change it, open ANOTHER, wishlist, bug against policy, detailing the rationale and text of your proposed change. manoj -- Anxious after the delay, Gruber doesn't waste any time getting the Koenig [a modified Porsche] up to speed, and almost immediately we are blowing off Alfas, Fiats, and Lancias full of excited Italians. These people love fast cars. But they love sport too and no passing encounter goes unchallenged. Nothing serious, just two wheels into your lane as you're bearing down on them at 130-plus -- to see if you're paying attention. Road Track article about driving two absurdly fast cars across Europe. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 04:39:58PM +0200, Javier Fern?ndez-Sanguino Pe?a wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, and is completely outdated in catching crooks (rulefiles) and detection mechanisms. Not to speak of package stability ;) Then you should work towards fixing them in stable or having ftp-masters agreeing with including a new (backported) version at proposed-updates. That's for Martin Schulze (Joey - Stable Release Manager) and/or the security team to decide; not ftpmaster. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpZprBrwjcR3.pgp Description: PGP signature
Re: configure --host= breaks libtool ?
On Sun, 2003-08-24 at 04:51, Glenn McGrath wrote:
Im having problems compiling libextractor on at least ia64 and m68k
On those arch's dpkg-buildpackage fails with
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
libtool hasn't found a compiler capable of producing the cross-compile
you request (yes, you requested a cross-compile).
In debian rules i am specifying host and build, so on ia64 configure is
called with.
./configure --host=ia64-linux --build=ia64-linux (..other stuff)
If i run ./configure;make it compiles, but if i run ./configure
--host=ia64-linux; make then i get the error.
*sigh* ...
If the configure script was generated with Autoconf 2.5x:
./configure --build=ia64-linux
or if it was generated with Autoconf 2.13:
./configure ia64-linux
I cant see any other differences, anyone have any ideas ?
Its using the latest autotools, including libtool 1.5-1
Install autotools-dev, ensure config.{sub,guess} are up to date from
that package. Then run ./config.guess to see what triplet you should be
using, and pass that instead.
Then go and read Henrique's excellent
/usr/share/doc/autotools-dev/README.Debian.gz
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
Your Edmunds.com Inquiry
Thank you for contacting Edmunds.com Customer Service. We want to acknowledge that we have received your e-mail. However, because of the large number of e-mails we receive each day, we may not be able to respond to your inquiry with a personalized response. The answer(s) to your question(s) may already be published on our Web site. Please check the Edmunds.com Help Page and FAQ (Frequently Asked Questions) Pages. You may also visit the message boards in Town Hall, which contain the knowledgeable insights of other Edmunds.com visitors. Please note that if your e-mail was not for the purpose of asking a question or for our assistance, it might be better directed to our Letters to the Editor. You may write to them at: [EMAIL PROTECTED] Thank you for visiting Edmunds.com. - Edmunds.com Customer Service Help Page: http://www.edmunds.com/help/ FAQ Pages: http://www.edmunds.com/help/faq.html Town Hall: http://townhall.edmunds.com ---This e-mail address does not accept replies. Please do not reply to this e-mail---
Debian
hi there, i'm new to Debian and i would like to learn Debian and help out with Development, i have spare time on my hands and i would like to use that spare time wizely, please can you send me some information. Many Thanks Regards Gavin Thomas
Re: Debian
On Sun, Aug 24, 2003 at 06:19:22PM +0100, Gavin Thomas wrote: hi there, i'm new to Debian and i would like to learn Debian and help out with Development, i have spare time on my hands and i would like to use that spare time wizely, please can you send me some information. If you want to help out, just do so. There's no reason why you can't. Have a look at http://bugs.debian.org/, and look for unfixed bugs, preferably those of severity 'serious' or higher, or that have the 'help' tag applied, and try to find solutions to those bugs; sending in a (tested!) patch is usually appreciated. On an unrelated note: it's usually appreciated _not_ to send HTML mail to Debian-related mailinglists. Please configure your mailer to stop doing so. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
Re: Debian
On Sun, Aug 24, 2003 at 06:19:22PM +0100, Gavin Thomas wrote: hi there, i'm new to Debian and i would like to learn Debian and help out with Development, i have spare time on my hands and i would like to use that spare time wizely, please can you send me some information. Make sure to check out www.debian.org and especially: http://www.debian.org/devel/join/ http://www.debian,org/devel/ and http://www.debian.org/doc/maint-guide/ Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
* Martin Quinson ([EMAIL PROTECTED]) wrote: On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote: Except what you don't realize is that one should never, ever, ever just NMU and then forget about the package. If you do an NMU then you need to make sure it worked, follow the package and make sure there aren't problems with it and follow up with the maintainer on the bugs. I don't care what you change in the package, if you NMU then you need to do that at a *minimum*, just as if you were the maintainer. It's not until the official maintainer incorporates the NMU changes and closes the bugs that the NMU'er can forget about it. Dude, translators already more than this. When I translate a package, I register to its PTS to check that my translation does not trigger any translation bug report. I'm not special caseing translations, nor do I feel they should be. I'm referring to NMU's in general. Are you one of the guys considering translators as a technically handicaped plague of the Debian world? I know that most of the time, the problem is between the screen and the chair, but that's not always the case ;) Are you one of the guys who tries to put words in the mouths of others with the intent to reduce their credibility when they've said nothing anything like what you infer? Of course, translators can only do that for the package whom they translate the po files or documentation. People translating the debconf templates feel often responsible for a few hundreds of them. The lack of i18n tag to bug reports makes it impossible for them to watch the state of their work efficiently that way. This hasn't got anything to do with NMU's. For NMU, I know that Christian tracks every NMUed packages until the next maintainer upload, to check that his changes are not broken or ignored. If you speak some french, come on debian-l10n-french for one week, to see the logistic issues we are facing, and how we address them. If you speak another language, go to the relevant debian-l10n- list, I'm sure that the french team is not an exception here, but rather the average. Yet he admits that he can't actually maintan the packages he uploads via an NMU. That's what I have a problem with. Then you shouldn't be doing an NMU on it. When you NMU something you take responsibility for it temporairly until the maintainer gets back. Could you point the poor stupid monkeys we are to the relevant part of the policy or developer reference or whatever other document ? I really do not understand what let you think about NMU that way, especially after the last bits of the RM... The RM is the one who said we should be taking more care doing NMUs than doing your own packages. For what I read, it is not required to be able to maintain everything for a given package for being able to NMU it. It is just required to be able to fix possible introduced bugs Then what you read is wrong. Again, why? Stating without argumenting will only bring us in yet another fruitless flamewar. Please help us avoiding that curse. I've pointed out numerous times in this thread already why it's wrong to believe that you can NMU a package without having any responsibility to it afterwards, except maybe for the bits you changed. Having that kind of an attitude is detrimental to the distribution as a whole. A patch would probably still be easier, but whatever. No offense intended, but this statement clearly shows a misunderstanding of the issues the russian (and japaneese) translators are facing. If they provide a simple patch, it is almost certain that the maintainer with extract it from the mail and apply it with tools not well suited to the weird encoding they need, leading to catastrophic results such as undisplayable texts on user boxes, which is even worst than untranslated ones, isn't it? patch won't handle it properly? Attaching the patch to a mail message instead of including it directly doesn't work? Funny, I recall applying a patch for OpenLDAP using just such a mechanism without having a problem. On the other hand, uuencoding the patchs helps to make sure that the encoding will be preserved by the stupid mailers and wrong configurations out there. So you're talking about it actually being a patch just uuencoded? That doesn't seem to agree with what you were saying earlier. Personally I'd probably be annoyed to have a patch uuencode'd instead of in the mail as a MIME attachment. This is precisely what's currently happening.. :-) Glad to hear it, perhaps some day you will, though personally I hope to hell you never manage to get it considered an RC bug, and I'll work to make sure that doesn't happen. Who, beside you, spoke of raising the gravity of translation bugs to RC ? Christian certainly meant that the normal gravity may be better appropriated to such bugs, since it *does* make the package unusable under some conditions (when the
Re: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 17:16:25 +0200 Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Manuel Bilderbeek [Sun, Aug 24 2003, 04:32:45PM]: The procedure I'm going through is as follows (being root all the time) 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 2) go to /usr/src and tar xjvf kernel-source-2.4.21.tar.bz2 Why don't you use the kernel-headers packages and use them as partial kernel source? They provide header files (including the complete kernel version) and the .config that belongs to them. Notes: - If you have just installed a new kernel-image package (i.e. a new stock kernel), you need to do everything from the start *after* booting this new kernel snip NVIDIA packages at the time I installed them. This caused a lot of mental suffering for me. (Which brings us to another thing: WHY oh WHY, isn't the procedure to get and install the NVIDIA drivers more automated!?) I fail to see your problem. I don't. He certainly has a point, and I wanted to post a message about this, only he was faster. I recently installed debian for a friend, installed alsa and was completely helpless as to where to obtain them. I tried looking for alsa-modules, or kernel source for the stock kernel so I could compile them myself... This kind of trouble isn't something I'm used to, since I always replace the stock kernels with my own (accepting to deal with troubles that might result), but since the chap was a complete newbie, I wanted to give him a standard system. I failed, he has a standard kernel, but no sound. Now, since you say the package's name is kernel-headers, it'd go allright, but I (quite an experienced GNU/Linux user, but only using Debian for about half a year) didn't manage to find that out. justification The most trouble you get when you're convinced you know what you're doing, and don't RTFM as you should - I knew that I can compile kernel modules because I have the kernel source, so it didn't occur to me that the package might contain the headers only. /justification This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, at the very most leaving the user the option to have them not installed, albeit dissuading from doing so. It would also be nice if an installation script would read lilo.conf and make a /usr/src/linux symlink to the default kernel headers. This way, even a newbie who's been told that he has to compile drivers for his exotic hardware could download the sources, compile and install them with little assistance, and with no knowledge of the magic that enabled him to do so. I'm a member of several newbie-help lists, and I dare say that most failures to install drivers are due to a missing kernel source. By no means should the headers be a non-intuitively named package you read about in the 27th howto or in a newsgroup months later. Don't get me wrong - I'm not trying to shove off the responsibility for my disgraceful performance to Debian, that was my fault. Only, seeing that virtually all driver packages require kernel headers, it appears to me so essentially common sense to install them that I have to wonder why virtually no distro does so. Meanwhile, I see no negative effects to this - most people have enough space to accomodate them; the installation proces wouldn't be much more complicated (after all, while installing Debian I'm asked, say, whether I want to install gnuplot with the setuid bit set - which I don't use and don't care about - so why can't a nice screen ask me whether I want to install kernel headers and call me a fool if I select no?) Again: BINARY KERNEL WITHOUT HEADERS IS A CRIPPLED KERNEL. Please, whoever has the power to do so, let no crippled kernels be installed by default. Cheers P.S: I just joined. Hi, everybody. -- Horror Vacui Registered Linux user #257714 Go get yourself... counted: http://counter.li.org/ - and keep following the GNU.
Re: Hungarian DDTP on the Xth B'day
Hello all, On behalf of our group, let me express our thanks towards Nicolas that he came to our party - it was an excellent opportunity for us to get to know such a dedicated person! We are glad that he considers his stay a good time. ;) Yes, unfortunately Gluck was down for almost the whole two days long so we lost some time until we could locally build an environment that enabled us to translate. One of the solutions we had was that we borrowed the world-wide famous OpenOffice translation web interface (developed by some of our Hungarian fellows, so we didn't have a too hard job) and took the latest Packages.gz as the basis for the translations. In the meantime Nicolas was working hard to start a local DDTS so that we could use also his client (ddtc) and finally we were able to use that one also. Since we worked offline, we will first have to upload all the translations - I'm planning to use ddtc as a perfect tool for that purpose. We are of course expecting collisions with the existing live database on the DDTS but we will handle those. (The person in charge for that will be Attila SZERVÁC sas, the new Hungarian coordinator for the DDTP. He was the project manager also for this Debian X Party and did an excellent job.) In the longer run we will probably merge the two utilities to get a web-based translation system that relies heavily on ddtc and its features. We hope that on our next DDTP party we will have such a system in our hands. Of course we will share it will you all as well. Again - thank you, Nicolas! Finally: long live Debian! :) Regards, Csan and the AHLU Debian Group Quoting Nicolas Bertolissio [EMAIL PROTECTED]: Hi all, The main goal of this party was to translate Debian package descriptions. Unfortunately Gluck, where the ddts server is, was down quite a long time and installing a local server was not so easy as it was the first time I did this. The local server was up only a few minutes before Gluck come back. Anyway, this experience let me find a bug in the server and so was quite interresting. I would like to thanks everyone at Budapest for the good time I spend there for the Debian 10th birthday last week-end. Regards Nicolas Bertolissio -- Csan alias Janos Holanyi Debian Group leader - Association of Hungarian Linux Users URL: http://debian.linux.hu/ Email: csani AT lme.linux.hu gpg --keyserver hkp://pgp.mit.edu --recv-keys 82CBB661
Re: Debian Weekly News - August 19th, 2003
Marco d'Itri [EMAIL PROTECTED] writes: On Aug 22, Brian T. Sniffen [EMAIL PROTECTED] wrote: Additionally, whether the DFSG should apply to documentation in Debian is not relevant to the survey, which asks whether the GFDL complies with the DFSG: we can deal with the insanity of whether this software over here is or is not software later, but figuring out whether the GFDL is a DFSG-free licence for software is also important. That's what the survey's asking about. I'd say that you have your priorities wrong. If we decide that documentation is not software then there is no reason to waste time to figure out if the GFDL is DFSG-free or not. Of course there is: there is source code licensed under the GFDL in several Debian packages. In order to not have to do surgery on the GNU Emacs and GCC packages, the GFDL will have to be found DFSG-free anyway. -Brian
Re: What doing with an uncooperative maintainer ?
* Norbert Tretkowski [EMAIL PROTECTED] wrote: * Eduard Bloch [EMAIL PROTECTED] wrote: IMO if we do not get answers, Ryan's ignorance implies a simple answer: Hijack this package! Yes, as Ryan doesn't like NMUs, I decided to hijack gqview and uploaded the new package to DELAYED/4-day. Ryan uploaded 1.3.2-1 (and not 1.2.2 again with a new epoche, as he purposed) without any explanation, my package was rejected. Ryan, you can close #196851 now. Norbert -- .''`. : :' :Norbert Tretkowski [EMAIL PROTECTED] `. `' Debian GNU/Linux Developer - http://www.debian.org/ `-
Re: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 18:02:32 +0200, Manuel Bilderbeek [EMAIL PROTECTED] said: At the time I still used it (again, one year ago or so), this didn't work out-of-the-box, because of the APPEND_TO_VERSION stuff. I see this has been fixed in the meantime, in step 4 of the installation instructions in the file you mentioned. Still, couldn't this be a lot more automated? Working patches gladly accepted. manoj -- Death is nature's way of saying `Howdy'. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Debian Weekly News - August 19th, 2003
On Sun, Aug 24, 2003 at 02:25:51PM -0400, Brian T. Sniffen wrote: Marco d'Itri [EMAIL PROTECTED] writes: On Aug 22, Brian T. Sniffen [EMAIL PROTECTED] wrote: Additionally, whether the DFSG should apply to documentation in Debian is not relevant to the survey, which asks whether the GFDL complies with the DFSG: we can deal with the insanity of whether this software over here is or is not software later, but figuring out whether the GFDL is a DFSG-free licence for software is also important. That's what the survey's asking about. I'd say that you have your priorities wrong. If we decide that documentation is not software then there is no reason to waste time to figure out if the GFDL is DFSG-free or not. Of course there is: there is source code licensed under the GFDL in several Debian packages. In order to not have to do surgery on the GNU Emacs and GCC packages, the GFDL will have to be found DFSG-free anyway. -Brian Pardon? I seriously hope that you're being sarcastic, because trying to bend over backwards and deliberately trying to misinterpret the DFSG just to get accept certain software is just hipocrisy. Yes, gcc would be nearly impossible to replace, but reasonably one can assume that the parts of it that are licensed under the GFDL are small enough that they are replacable, either by using earlier versions of those files and doing a lot of work on our own to redo the rest, or by rewriting them from scratch. As for GNU Emacs, the situation is less serious, since it's an editor, not a build-essential package. I am pretty sure the same thing can be done here, though. And if its manual is licensed under the GFDL, we'll simply have to make due without the manual, sad but true. Or have the manual in non-free, whatever feels is most appropriate (let's not start a discussion about removing non-free now, shall we?) Regards: David Weinehall -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Debian Weekly News - August 19th, 2003
What I'm referring to is the excerpts of C and E-Lisp source in those manuals. They're clearly both documentation and software, even if you don't believe that text can be both documentation and software. I don't believe even the non-optional parts of the GFDL can be found DFSG-free (as a software license), so something's going to have to change. -Brian
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
Stephen Frost [EMAIL PROTECTED] wrote: [...] Then you shouldn't be doing an NMU on it. When you NMU something you take responsibility for it temporairly until the maintainer gets back. Could you point the poor stupid monkeys we are to the relevant part of the policy or developer reference or whatever other document ? I really do not understand what let you think about NMU that way, especially after the last bits of the RM... The RM is the one who said we should be taking more care doing NMUs than doing your own packages. Parse error. I cannot see a connection between answer and question. [...] I've pointed out numerous times in this thread already why it's wrong to believe that you can NMU a package without having any responsibility to it afterwards, except maybe for the bits you changed. Having that kind of an attitude is detrimental to the distribution as a whole. [...] I've loosely followed the thread but your only argument in favour of this statement seems to be that if people NMU'd to upgrade the translation there will be an delay in us recognizing the package missing a proper maintainer and orphaning or removing it. I do not think that argument holds, an unmaintained package will show other signs of negligance, and the qa people checking for unmaintained packages know how to differ between NMU and maintainer upload. I'd like to see an answer to [EMAIL PROTECTED], BTW. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote: * Martin Quinson ([EMAIL PROTECTED]) wrote: On Fri, Aug 22, 2003 at 12:28:55PM -0400, Stephen Frost wrote: Dude, translators already more than this. When I translate a package, I register to its PTS to check that my translation does not trigger any translation bug report. I'm not special caseing translations, nor do I feel they should be. I'm referring to NMU's in general. Maybe that's the point. Christian won't handle the same way non translation bugs, because the changes implied are bigger and possibly more intrusive. Of course, translators can only do that for the package whom they translate the po files or documentation. People translating the debconf templates feel often responsible for a few hundreds of them. The lack of i18n tag to bug reports makes it impossible for them to watch the state of their work efficiently that way. This hasn't got anything to do with NMU's. With NMU in general, maybe not. But I see this as rather relevant to the kind of NMU we are talking about. If we add such tag, translators could follow the result of their work. Same thing for NMUer of translations. For NMU, I know that Christian tracks every NMUed packages until the next maintainer upload, to check that his changes are not broken or ignored. If Yet he admits that he can't actually maintan the packages he uploads via an NMU. That's what I have a problem with. Well, he said that he cannot handle any kind of bugs rising in any kind of package. Yet, he can handle any kind of issue related to l10n and a bunch of i18n issues. The RM is the one who said we should be taking more care doing NMUs than doing your own packages. And that's exactly what is done here. We are not speaking of automated mass NMU, but manual carfull and as rare as possible ones, with tracking the future of the package afterward. I understand your point about what could be an NMU fest, but this is not the case. The procedure *is* followed (beside the fact that they imply wishlist bugs). I've pointed out numerous times in this thread already why it's wrong to believe that you can NMU a package without having any responsibility to it afterwards, except maybe for the bits you changed. Having that kind of an attitude is detrimental to the distribution as a whole. Fully agreed. Who behave so badly ? A patch would probably still be easier, but whatever. No offense intended, but this statement clearly shows a misunderstanding of the issues the russian (and japaneese) translators are facing. If they provide a simple patch, it is almost certain that the maintainer with extract it from the mail and apply it with tools not well suited to the weird encoding they need, leading to catastrophic results such as undisplayable texts on user boxes, which is even worst than untranslated ones, isn't it? patch won't handle it properly? Attaching the patch to a mail message instead of including it directly doesn't work? Funny, I recall applying a patch for OpenLDAP using just such a mechanism without having a problem. Well, either you were lucky, or you use good and well configurated mail tools. But if my language did need a funky encoding, I would not let my work depend of such conditions. Don't get me wrong. I mean that in such condition, uuencoding prevents the DD from shouting himself in the foot, and I've the feeling that it helps anyone, including the developer. So you're talking about it actually being a patch just uuencoded? That Err. Yes, that's what I meant. I may say it wrong, though. Sorry about that. Who, beside you, spoke of raising the gravity of translation bugs to RC ? Christian certainly meant that the normal gravity may be better appropriated to such bugs, since it *does* make the package unusable under some conditions (when the user cannot speak english, obviously). I'm tired of having to repeat for you what's been said in the thread. Try reading it before you attempt to comment on it. Christian said: The key point, as usual, is the wishlist status of translation bug reports. I, as a non native english speaker, do not consider translation to be only a wish, but a requirement. I considered 'requirement' to be 'RC' level. He didn't disagree. I did read this mail. He did not agree either. Christian did say that he felt that discution leaded to nowhere because of radical opinion divergence, and that he prefered not to continue. So, once again, nobody here is threating to open RC bugs against all packages not translated in a given language. Nobody even spoke of opening bugs because a given program is not translated. That would be stupid, and that will not be done. One of the reason is that RC means: if this bug is not fixed, Debian should not distribute the package. At all. (bts-howto). Translation bugs are only sufficient to make the package useless for a subset of its
Re: stack protection
On Sun, Aug 24, 2003 at 01:40:28PM +1000, Russell Coker wrote: [...] I agree, but writing secure (not perfectly secure) software may be nearly possible. I don't like to start flame war, but must mention djbdns and qmail. Yes, however they have less functionality than the alternatives that most people want to use. Someone could say that for Linux comparing it with WinXX. Also I don't expect DJB to write replacements for dhcpd, dhclient, ftpd, cron, Maybe someone else should do that, I hope at least. [...] That couldn't be solved by SE Linux (or similar code) but just mitigated a little. No, it means that a badly written daemon running as UID 0 can not trash your system. So a sound server that has a bug can at worst play sounds and record sounds in a malicious manner, and refuse to do what it is supposed to do. Much better than allowing it to write to /etc/shadow! If attacker can poison DNS cache or fake DHCP server to do something nasty then the problem with SE Linux is just mitigated, not solved. I'm not against SE Linux, RSBAC GRSec, LIDS etc. I'm using some them on servers and playing with all of them. I just like to say that putting limits in the (our loved (Debian)/Linux) is not good thing, IMO. Why is it a limit? We are not talking about making any of these mandatory for Debian users. We want to give them a choice of all of the above. I'm not against choice, I just don't like idea that that stack protection and similar code could become mainstream one day. P.S. I appreciate you contribution to Linux (and Debian) security a lot, and I play with *your* SE Linux host when I have time.
Re: A possible GFDL compromise
Fedor Zuev, missing the point AGAIN, said: I cannot see any connection between disagreement with anyone opinion, and the right to censor somebody else's opinion, so angrily demanded by you. There's no censorship involved. *sigh* The GNU Manifesto would still be freely available from the FSF website. Lack of forced distribution is not censorship. Get a clue, or a dictionary.
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
* Andreas Metzler ([EMAIL PROTECTED]) wrote: Parse error. I cannot see a connection between answer and question. Life's a beach. There's all of one line in the developer's reference which talks about your responsibilities when doing an NMU: Follow what happens, you're responsible for any bug that you introduced with your NMU. Now, this works fine when the official maintainer is going to follow up; it doesn't work worth a damn if the official maintainer isn't taking care of the package at all anymore. Prior to doing an NMU you tend to have a pretty good idea which is the case, or you should at least. [...] I've pointed out numerous times in this thread already why it's wrong to believe that you can NMU a package without having any responsibility to it afterwards, except maybe for the bits you changed. Having that kind of an attitude is detrimental to the distribution as a whole. [...] I've loosely followed the thread but your only argument in favour of this statement seems to be that if people NMU'd to upgrade the translation there will be an delay in us recognizing the package missing a proper maintainer and orphaning or removing it. I do not think that argument holds, an unmaintained package will show other signs of negligance, and the qa people checking for unmaintained packages know how to differ between NMU and maintainer upload. You've obviously not been paying very much attention at all then. You should have a pretty good idea if the package is unmaintained or not prior to doing an NMU. If it's not then you're uploading a package which fixes some specific bug but leaves the package unmaintained. That's irresponsible. Stephen pgp5hGTmX8DTM.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
On Sun, Aug 24, 2003 at 08:59:06AM -0600, Jamin W. Collins wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? Largely this is because snort should simply be removed from stable completely, as it is not useful, even if the security exploits are fixed. Snort depends on a set of rules to detect potentially malicious traffic. Obviously this set of rules needs to be updates on a regular basis in order to keep up with new security issues. The problem is that the version of snort in stable is old enough that the upstream maintainers are no longer releasing new rulesets for it. Thus, it can't detect potentially harmful traffic. A person responsible for the security of a system or network of systems needs to know if attacks on current vulnerabilities are being made on his system at least as bad as he needs to know that two year old vulnerabilities are being probed. snort 1.8.4 cannot report such activity, and can only lead to a false sense of security. Thus, trusting an old version of snort is more dangerous than not using it at all, IMHO. In the case of tools like snort, I strongly believe that we either need to remove it from stable or permit new upstream versions to be released for stable with point releases. noah pgpcNGk76ZOYD.pgp Description: PGP signature
Re: Debian
On Sun, Aug 24, 2003 at 06:19:22PM +0100, Gavin Thomas wrote: hi there, i'm new to Debian and i would like to learn Debian and help out with Development, i have spare time on my hands and i would like to use that spare time wizely, please can you send me some information. Check out the list of bugs holding up the next release. Currently it can be found at http://lists.debian.org/debian-devel-announce/2003/debian-devel-announce-200308/msg00015.html Find one or more that you think you can fix. Log your fix with the bug, by sending it to bug_number@bugs.debian.org. At this point in time, that really is the best way you can contribute to the project. The developers and users will appreciate your help. noah pgppMty4ZAzWd.pgp Description: PGP signature
Re: Snort: Mass Bug Closing
Noah L. Meyerhans [EMAIL PROTECTED] writes: On Sun, Aug 24, 2003 at 08:59:06AM -0600, Jamin W. Collins wrote: Before you object to this rather 'rude' bughandling, please keep in mind that version 1.8.4 of snort, which is in stable, has 3 severe security exploits, So, why hasn't a security update been released for it? Largely this is because snort should simply be removed from stable completely, as it is not useful, even if the security exploits are fixed. Snort depends on a set of rules to detect potentially malicious traffic. Obviously this set of rules needs to be updates on a regular basis in order to keep up with new security issues. ... In the case of tools like snort, I strongly believe that we either need to remove it from stable or permit new upstream versions to be released for stable with point releases. Why don't you add an option to load newer rulesets and/or update information to snort. Once a day/week/month snort you probe some url for a signed ruleset or news file and report to the user about any updates. That way you can have the binary in stable and still provide changes on a more regular basis. Of cause you should first get up to a still suported version,but you could put that in the news file. MfG Goswin
Re: stack protection
Milan P. Stanic [EMAIL PROTECTED] writes: On Sun, Aug 24, 2003 at 01:40:28PM +1000, Russell Coker wrote: Why is it a limit? We are not talking about making any of these mandatory for Debian users. We want to give them a choice of all of the above. I'm not against choice, I just don't like idea that that stack protection and similar code could become mainstream one day. Properly designed the stack protection, array bounds checking and pointer validating routines can be put into queue slots that would otherwise go idle on modern cpus. One might even fit it in along with other instructions and not even blow up the programm size with every check. For most programm it realy doesn't hurt and for everything thats dangerous (suid, servers, other root stuff) making it the default might be the right[tm] way. Compared to the binaries now you probably waste as much on the checks as you save if you optimize for your cpu. MfG Goswin
Re: Building kernel modules for stock kernels is a hell of a job!
On Sun, 24 Aug 2003 20:16:21 +0200, horrorvacui [EMAIL PROTECTED] said: I don't. He certainly has a point, and I wanted to post a message about this, only he was faster. I recently installed debian for a friend, installed alsa and was completely helpless as to where to obtain them. I tried looking for alsa-modules, or kernel source for the stock kernel so I could compile them myself... This kind of trouble isn't something I'm used to, since I always replace the stock kernels with my own (accepting to deal with troubles that might result), but since the chap was a complete newbie, I wanted to give him a standard system. I failed, he has a standard kernel, but no sound. Now, since you say the package's name is kernel-headers, it'd go allright, but I (quite an experienced GNU/Linux user, but only using Debian for about half a year) didn't manage to find that out. justification The most trouble you get when you're convinced you know what you're doing, and don't RTFM as you should - I knew that I can compile kernel modules because I have the kernel source, so it didn't occur to me that the package might contain the headers only. /justification This is my view: the kernel headers and the configuration used when compiling a stock kernel are to be viewed as an *integral part of that kernel*. The headers should be installed by default, Heh. You are describing how things used to be, with the kernel-headers always installed by kerel-image, and the symlink kept in place. Looking at the CVS, you could have any number of headers or sources in place, and the /usr/src/linux symlink was kept pointing to the latest version, as determined by the most recent kernel-image isntalled. Of course, it all used to fall apart for user who had multiple kernels installed, and woh used to swithc in between, people who had limited amount of space in /usr, and people who wanted to compile for a different machine than the current one. The current behaviour was introduced to allow for increased flexibility. manoj -- If anything can go wrong, it will. Edsel Murphy Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 01:33:37AM +0200, Goswin von Brederlow wrote: Why don't you add an option to load newer rulesets and/or update information to snort. Once a day/week/month snort you probe some url for a signed ruleset or news file and report to the user about any updates. That way you can have the binary in stable and still provide changes on a more regular basis. That's a perfect solution, but only works for the cases which the snort binary can understand the rulesets which are being downloaded. The way I understand the current situation the real problem is that the stable snort cannot understand the newer rule files; because it's simply too old. However the solution would have to be a little bit more complex than that which you select - blindly installing the rulesets might not be the best idea. I'd love to see a system which used a simple curses interface to: 1. List all new rulesets with a discription of their use. (eg. msblast.snrt - Alert on MSBlaster worm probes). 2. Upgrade all the rules which are currently installed. (Essentially apt-get + apt-cache for snort rules. Clearly packaging a single rule file within one package is a gross misuse of resources but it might be sufficient if they were signed and hosted somewhere sensible..) Steve -- pgpWkMvO3c77w.pgp Description: PGP signature
Re: where to install additional kernel modules?
On Sun, Aug 24, 2003 at 06:19:16PM +0200, martin f krafft wrote:
also sprach Christoph Hellwig [EMAIL PROTECTED] [2003.08.24.1806 +0200]:
the right place is /lib/modules/${kver}/${package}
says who?
It's always been this way. However, before 2.4, modutils had a set
list of directories that it looked at in /lib/moduiles/${kvers},
which included pcmcia, mtd, and rtai, all of which were for non-kernel
source module packages. Other packages (including Comedi) put their
modules in misc/, rather than bother asking for another directory. I
eventually asked David Hinds to add comedi to the list of search
directories, and mentioned something about searching all directories.
The next release searched all directories.
In reality, it doesn't matter what directory you put modules in,
since they all share the same namespace. You can't have two module
files called module_x.o and expect it to work. Users, however,
appreciate the separation.
dave...
Fw: Debian-devel! EX0TlC Iatina girIs in C!R/\-Z-Y ACTl0N! x k RnaA 5kJ
Hey BwDFvyfuhYw Debian-devel AthLt 0426 061
VIRUS IN IHRER NACHRICHT AN thorsten@ipcon.de
V I R U S A L A R M Der Virenscanner der IPCON Informationssysteme hat in Ihrer Nachricht an [EMAIL PROTECTED] einen Virus gefunden. Die Nachricht wurde aus Sicherheitsgruenden nicht zugestellt! Ueberpruefen Sie Ihr System auf Viren. Zur Orientierung hier der Kopf der betroffenen Nachricht: - ANFANG Received: (qmail 15166 invoked for bounce); 25 Aug 2003 01:31:50 - Received: from unknown (HELO BETH) (202.103.190.93) by www.ipcon.de with SMTP; 25 Aug 2003 01:31:50 - From: debian-devel@lists.debian.org To: [EMAIL PROTECTED] Subject: Re: That movie Date: Mon, 25 Aug 2003 9:09:11 +0800 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600. X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_NextPart_000_0049996E X-AntiVirus: scanned for viruses by IPCON Informationssysteme v0.986 -- ENDE -
Re: Snort: Mass Bug Closing
On Mon, Aug 25, 2003 at 02:27:41AM +0100, Steve Kemp wrote: (Essentially apt-get + apt-cache for snort rules. Clearly packaging a single rule file within one package is a gross misuse of resources but it might be sufficient if they were signed and hosted somewhere sensible..) Such a system as you describe would be fine, and should somehow be incorporated into the Debian release design (especially since snort is by no means the only package that would benefit) but it doesn't get you around the current issue, which is that there simply are no new rules being developed for woody's snort. I can think off-hand of at least one other security related tool that needs frequent updating of a ruleset: nessus. It is an active probing tool that scans a network for vulnerable systems. If it doesn't have a current set of rules, it may fail to identify vulnerable systems, leading to the same issues that snort has. noah pgp0miX4DCekT.pgp Description: PGP signature
Re: NMUs applying sleeping wishlist bugs about translation (was something else)
* Martin Quinson ([EMAIL PROTECTED]) wrote: On Sun, Aug 24, 2003 at 01:38:33PM -0400, Stephen Frost wrote: I'm not special caseing translations, nor do I feel they should be. I'm referring to NMU's in general. Maybe that's the point. Christian won't handle the same way non translation bugs, because the changes implied are bigger and possibly more intrusive. Translations should not be special cased. It's a new upload of the package just like any other NMU. This hasn't got anything to do with NMU's. With NMU in general, maybe not. But I see this as rather relevant to the kind of NMU we are talking about. If we add such tag, translators could follow the result of their work. Same thing for NMUer of translations. As I said above, which you apparently missed, I'm referring to NMU's in general. For NMU, I know that Christian tracks every NMUed packages until the next maintainer upload, to check that his changes are not broken or ignored. If Yet he admits that he can't actually maintan the packages he uploads via an NMU. That's what I have a problem with. Well, he said that he cannot handle any kind of bugs rising in any kind of package. Yet, he can handle any kind of issue related to l10n and a bunch of i18n issues. The RM is the one who said we should be taking more care doing NMUs than doing your own packages. And that's exactly what is done here. We are not speaking of automated mass NMU, but manual carfull and as rare as possible ones, with tracking the future of the package afterward. I understand your point about what could be an NMU fest, but this is not the case. The procedure *is* followed (beside the fact that they imply wishlist bugs). I'm starting to tire of this. If you can't maintain the package you shouldn't be NMU'ing it. It's really that simple. I've pointed out numerous times in this thread already why it's wrong to believe that you can NMU a package without having any responsibility to it afterwards, except maybe for the bits you changed. Having that kind of an attitude is detrimental to the distribution as a whole. Fully agreed. Who behave so badly ? Just about everyone else appears to feel all they should care about is the changes they make in their NMU instead of actually caring about the package and the distribution. There's this feeling of not my problem. patch won't handle it properly? Attaching the patch to a mail message instead of including it directly doesn't work? Funny, I recall applying a patch for OpenLDAP using just such a mechanism without having a problem. Well, either you were lucky, or you use good and well configurated mail tools. But if my language did need a funky encoding, I would not let my work depend of such conditions. Don't get me wrong. I mean that in such condition, uuencoding prevents the DD from shouting himself in the foot, and I've the feeling that it helps anyone, including the developer. It'd just get in my way. You're making generalizations where I've already pointed out you can't make them. I'm tired of having to repeat for you what's been said in the thread. Try reading it before you attempt to comment on it. Christian said: The key point, as usual, is the wishlist status of translation bug reports. I, as a non native english speaker, do not consider translation to be only a wish, but a requirement. I considered 'requirement' to be 'RC' level. He didn't disagree. I did read this mail. He did not agree either. Christian did say that he felt that discution leaded to nowhere because of radical opinion divergence, and that he prefered not to continue. That was later, as I recall, though I'm too tired of this crap to bother looking for it explicitly. So, once again, nobody here is threating to open RC bugs against all packages not translated in a given language. Nobody even spoke of opening bugs because a given program is not translated. You, again, didn't read the thread. No one said anything about threating to open RC bugs, etc, etc. There was, however, a discussion about the possibility of changing the severity level at some point in the future to where translations would be considered RC-level bugs. You might read the thread to see our opinions on that. That would be stupid, and that will not be done. One of the reason is that RC means: if this bug is not fixed, Debian should not distribute the package. At all. (bts-howto). Translation bugs are only sufficient to make the package useless for a subset of its potential users. But we do fill (wishlist) bugs when we did translate a part of the package, and then, when the translation rots in the BTS, we feel ok to NMU the package for that (as long as the procedure is respected). Doing an NMU of a package you can't maintain is irresponsible. You're implying that we cannot consider software 'free' unless it's translated to every language. If you want to
Re: Building kernel modules for stock kernels is a hell of a job!
Manuel Bilderbeek [EMAIL PROTECTED] writes: After having worked with Debian testing for about 2 years, I'm getting fed up with the seemingly unnecessarily complicated way of building kernel modules for the stock kernels. 1) install the kernel source for the kernel, e.g. kernel-source-2.4.21 Since you're singling out lm-sensors here, I can tell you that lm-sensors-source does build fine against the correct kernel-headers package; the normal binary package build-depends on a kernel-build package to get all of the kernel-headers, and uses those without any particular magic. 5) apt-get install [modulename-source] (sometimes -src), e.g. lm-sensors-source. 6) this should give [modulename].tar.gz in /usr/src; extract it: tar xzvf [modulename].tar.gz now, the source is in /usr/src/modules/[modulename] At this point, I think what I would tell you to do is (untested): cd $MODULE_LOC/$modulename debian/rules kdist-image KDREV=2.4.21-4 KVERS=2.4.21-4-k7 \ KSRC=/usr/src/kernel-headers-2.4.21-4-k7 \ KMAINT=Your Name KEMAIL=[EMAIL PROTECTED] \ APPEND_TO_VERSION=-4-k7 ROOT_CMD=fakeroot which will produce the binary package you're looking for in /usr/src. This is just using the interface required by kernel-package. 9) install the just built package(s) with dpkg -i [package_name] now the kernel modules should be in the right dir in /lib/modules and modprobe (or modconf) can find them. - If you have just installed a new kernel-image package (i.e. a new stock kernel), you need to do everything from the start *after* booting this new kernel You shouldn't need to. (Though you go through a little more effort to get the right .config file.) - In my experience, if you forget the export of step 7, you have to wipe your whole kernel source tree and start at step 2. I know I'm supposed to do a make-kpgk modules clean, but that didn't do the trick; 'rm -rf /usr/src/modules' is often quite theraputic for odd problems like this. Screwing up --append-to-version using kernel-package has kind of unfortunate side effects for recovering. :-/ People, stock kernels are very comfortable, but building modules for them is not! Please tell me what I did wrong, or make the procedure a lot easier! (The latter especially applies to the maintainers of that NVIDIA package...) Luckily, David Z. Maze has the lm-sensors as binary package in unstable nowadays... :) (Although not yet for 2.4.21...) In some ways, doing this feels a lot like a very slow game of Whack-A-Mole. The process goes something like this: (1) Notice that Debian kernel 2.4.21-1 exists. (2) Install kernel-build-2.4.21-1. Change debian/rules to reference the right kernel. (3) Actually rebuild the package. This winds up taking quite a long time for me, particularly since there are seven different kernel flavors and I'm foolishly doing the build over AFS over a cable modem. (Should probably fix that. :-) (4) Upload. (5) Wait for ftpmaster, since these are all new packages. (6) Notice that Debian kernel 2.4.21-2 exists. (7) ftpmaster accepts lm-sensors-2.4.21-1-*, which depend on kernel-image-2.4.21-1-*, which is no longer in the repository. (8) Go to 2. It's also a bit frustrating to look at cross-platform compatability, and realize that the magic to get things built is just going to be different on each platform, since the platform-specific kernel packages are all different. Plus getting stock kernel modules built is presently entirely in the hands of the module maintainers, and the glue code in debian/rules to actually do that is kind of groady. I suspect for unstable, there's just not a lot to be done. For sarge, we should probably pick a kernel and a kernel ABI (or sets thereof) and not change it, so that packages that provide prebuilt kernel modules can do that more reasonably. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
debian-devel@lists.debian.org
¼ÓÃ˻ƽðÊéÓѻᣬ¿ÉÏíÊÜÍøÉ϶ÁÊé ÍøÉÏ׬ǮµÄÀÖȤ¡£ÏêÇé http://www.ad-book.com/reg.asp?user=wlvwlv
Re: configure --host= breaks libtool ?
Then go and read Henrique's excellent /usr/share/doc/autotools-dev/README.Debian.gz I added the following to my rules file from his README and all is well. # FOR AUTOCONF 2.52 AND NEWER ONLY ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) confflags += --build $(DEB_HOST_GNU_TYPE) else confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE) endif I still dont understand what the problem was, config.[guess|sub] were upto date, the same gcc was being used, configure resolved build and host the same way, and it worked in testing. There must be a bug in there somewhere. (brain dump) All is well. Glenn
Re: A possible GFDL compromise
On Sun, Aug 24, 2003 at 06:05:55PM -0400, Nathanael Nerode wrote: Fedor Zuev, missing the point AGAIN, said: I cannot see any connection between disagreement with anyone opinion, and the right to censor somebody else's opinion, so angrily demanded by you. There's no censorship involved. *sigh* The GNU Manifesto would still be freely available from the FSF website. Lack of forced distribution is not censorship. Get a clue, or a dictionary. Please keep this argument on debian-legal, not debian-devel. -- G. Branden Robinson| I am only good at complaining. Debian GNU/Linux | You don't want me near your code. [EMAIL PROTECTED] | -- Dan Jacobson http://people.debian.org/~branden/ | pgpgenTLGWFEH.pgp Description: PGP signature
Accepted guile-1.6 1.6.4-2.2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 20 Aug 2003 14:16:10 +0200 Source: guile-1.6 Binary: guile-1.6-slib libguile-ltdl-1 guile-1.6-libs guile-1.6-dev guile-1.6 libqthreads-12 guile-1.6-doc Architecture: source all i386 Version: 1.6.4-2.2 Distribution: unstable Urgency: low Maintainer: Rob Browning [EMAIL PROTECTED] Changed-By: Andreas Rottmann [EMAIL PROTECTED] Description: guile-1.6 - the GNU extension language and Scheme interpreter guile-1.6-dev - development files for Guile 1.6 guile-1.6-doc - reference and tutorial documentation for Guile 1.6 guile-1.6-libs - main Guile libraries guile-1.6-slib - Guile SLIB support libguile-ltdl-1 - Guile's patched version of libtool's libltdl libqthreads-12 - QuickThreads library for Guile Closes: 198858 Changes: guile-1.6 (1.6.4-2.2) unstable; urgency=low . * NMU. * debian/guile-1.6-dev.install: + Added guile-config (closes: #198858). * debian/control: + Standards-Version 3.6.0. Files: 07402bb96f4695ed5087129c3e3fcac6 746 - optional guile-1.6_1.6.4-2.2.dsc 980c24eb5440fa2eaef21bd9e849ad0b 5783 - optional guile-1.6_1.6.4-2.2.diff.gz e2a4afbcdee12d1533c4cacc1e755d99 377396 doc optional guile-1.6-doc_1.6.4-2.2_all.deb a82fb173f8458dc57972b08bb039d1a5 3350 devel optional guile-1.6-slib_1.6.4-2.2_all.deb 15bc79520b9ccf1ac77f4b5c71eac65d 31318 interpreters optional guile-1.6_1.6.4-2.2_i386.deb 68ec1c63a3c7ccf9bd61184bde9ff331 460116 devel optional guile-1.6-dev_1.6.4-2.2_i386.deb 7f1dd7b3b1419414be8cb0e62f72598b 557716 libs optional guile-1.6-libs_1.6.4-2.2_i386.deb a45dcbd7cf42bdd53a5aee2ac65d18fd 5294 libs optional libqthreads-12_1.6.4-2.2_i386.deb d76fbf9560d4f96374725b83e4f940e0 14472 libs optional libguile-ltdl-1_1.6.4-2.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q2p8+S/PxQH9W2IRAkctAJ4lJKsdtTiinIQdHLnGxQbYTAE+DwCglFRs HDqNNU4z4u1qRfxTl5YObY0= =WF37 -END PGP SIGNATURE- Accepted: guile-1.6-dev_1.6.4-2.2_i386.deb to pool/main/g/guile-1.6/guile-1.6-dev_1.6.4-2.2_i386.deb guile-1.6-doc_1.6.4-2.2_all.deb to pool/main/g/guile-1.6/guile-1.6-doc_1.6.4-2.2_all.deb guile-1.6-libs_1.6.4-2.2_i386.deb to pool/main/g/guile-1.6/guile-1.6-libs_1.6.4-2.2_i386.deb guile-1.6-slib_1.6.4-2.2_all.deb to pool/main/g/guile-1.6/guile-1.6-slib_1.6.4-2.2_all.deb guile-1.6_1.6.4-2.2.diff.gz to pool/main/g/guile-1.6/guile-1.6_1.6.4-2.2.diff.gz guile-1.6_1.6.4-2.2.dsc to pool/main/g/guile-1.6/guile-1.6_1.6.4-2.2.dsc guile-1.6_1.6.4-2.2_i386.deb to pool/main/g/guile-1.6/guile-1.6_1.6.4-2.2_i386.deb libguile-ltdl-1_1.6.4-2.2_i386.deb to pool/main/g/guile-1.6/libguile-ltdl-1_1.6.4-2.2_i386.deb libqthreads-12_1.6.4-2.2_i386.deb to pool/main/g/guile-1.6/libqthreads-12_1.6.4-2.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gkrellongrun 0.6.1-2.2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 22 Aug 2003 17:37:31 -0500 Source: gkrellongrun Binary: gkrellongrun Architecture: source i386 Version: 0.6.1-2.2 Distribution: unstable Urgency: low Maintainer: Taku YASUI [EMAIL PROTECTED] Changed-By: Gunnar Wolf [EMAIL PROTECTED] Description: gkrellongrun - LongRun plug-in for GKrellM Closes: 199280 Changes: gkrellongrun (0.6.1-2.2) unstable; urgency=low . * NMU by Gunnar Wolf [EMAIL PROTECTED] * Changed build dependency back from gkrellm-common to gkrellm (build process requires the presence of the gkrellm binary) (Closes: #199280) Files: 71cf6e6cf690c3eff3db81bf6a698e03 622 x11 optional gkrellongrun_0.6.1-2.2.dsc e504aefe74fe32ac2beed8b197416b0b 203436 x11 optional gkrellongrun_0.6.1-2.2.diff.gz ec888f8281afbfdfedf22c5d39fa8183 14806 x11 optional gkrellongrun_0.6.1-2.2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Rpws2A7zWou1J68RAvNQAKCb31xSclMtIJ36+Stjw7MIy0pepQCgpJWd Rtw7EBqfzTeuqwgjsocGSMg= =3Loe -END PGP SIGNATURE- Accepted: gkrellongrun_0.6.1-2.2.diff.gz to pool/main/g/gkrellongrun/gkrellongrun_0.6.1-2.2.diff.gz gkrellongrun_0.6.1-2.2.dsc to pool/main/g/gkrellongrun/gkrellongrun_0.6.1-2.2.dsc gkrellongrun_0.6.1-2.2_i386.deb to pool/main/g/gkrellongrun/gkrellongrun_0.6.1-2.2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted putty 0.53-b-2003-08-23-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Aug 2003 00:03:28 +0100 Source: putty Binary: pterm putty Architecture: source i386 Version: 0.53-b-2003-08-23-1 Distribution: unstable Urgency: low Maintainer: Colin Watson [EMAIL PROTECTED] Changed-By: Colin Watson [EMAIL PROTECTED] Description: pterm - PuTTY terminal emulator putty - A Telnet/SSH client for X Changes: putty (0.53-b-2003-08-23-1) unstable; urgency=low . * New upstream snapshot. Among other things: - Fix a (non-security-critical) segfault in PuTTY's zlib code. - Selection handling improved: selection timestamps are set more accurately and X cut buffers are supported. - Shadow bold can be requested explicitly. Files: c4f2b9fd6a2706f0270d38ed4e850907 688 net optional putty_0.53-b-2003-08-23-1.dsc fd4d6da1d4d5ef78fa5e387c41f1ed0c 857887 net optional putty_0.53-b-2003-08-23.orig.tar.gz e2bf7cad324bd2d0e30698a0521dba24 4568 net optional putty_0.53-b-2003-08-23-1.diff.gz 47b79ef8c5949d5024dcf4118b001eab 144216 x11 optional pterm_0.53-b-2003-08-23-1_i386.deb 7354baa9f15031cfb2f62f708f470594 249108 net optional putty_0.53-b-2003-08-23-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) Comment: Colin Watson [EMAIL PROTECTED] -- Debian developer iD8DBQE/R/WJ9t0zAhD6TNERAqGCAJ92TYp5CgNP6prDemkAhrY4cBQqUACdEWUX spk/P4GSSaTSdFcQ5FR/1Zo= =sFRX -END PGP SIGNATURE- Accepted: pterm_0.53-b-2003-08-23-1_i386.deb to pool/main/p/putty/pterm_0.53-b-2003-08-23-1_i386.deb putty_0.53-b-2003-08-23-1.diff.gz to pool/main/p/putty/putty_0.53-b-2003-08-23-1.diff.gz putty_0.53-b-2003-08-23-1.dsc to pool/main/p/putty/putty_0.53-b-2003-08-23-1.dsc putty_0.53-b-2003-08-23-1_i386.deb to pool/main/p/putty/putty_0.53-b-2003-08-23-1_i386.deb putty_0.53-b-2003-08-23.orig.tar.gz to pool/main/p/putty/putty_0.53-b-2003-08-23.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted easyfw 2.2-3 (all source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Sun, 24 Aug 2003 01:16:34 +0200 Source: easyfw Binary: easyfw Architecture: source all Version: 2.2-3 Distribution: unstable Urgency: low Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: easyfw - Graphical interface to ipchains/ipfwadm Closes: 189619 Changes: easyfw (2.2-3) unstable; urgency=low . * Added Build-Depends-Indep: debhelper (Closes: #189619) Files: fee732b5cd2497095171a3d4ccea70d0 670 admin optional easyfw_2.2-3.dsc 42753c9ba39ac488a836b0445277559a 2411 admin optional easyfw_2.2-3.diff.gz 5bce2d3db6ec65dbf5de518074d06f1f 39508 admin optional easyfw_2.2-3_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBP0f2CftEPvakNq0lAQGzNAP/W/RdLIoqsRRrxNHUW8TxuLwFRpGJXEdk cvdvSLSHaEnTaa/9IYrzRHMNwrhek2ggSltBNfXiGxsWJ6/T4qVUnBhPFaRdLO0t Np1jV9V4dAKYHlYjiK/cHgHzXGYJmpOXcLNFIAKL4rdXESSoYxGQd397dkhTi9qi ulylJ+lSBEI= =8RY0 -END PGP SIGNATURE- Accepted: easyfw_2.2-3.diff.gz to pool/main/e/easyfw/easyfw_2.2-3.diff.gz easyfw_2.2-3.dsc to pool/main/e/easyfw/easyfw_2.2-3.dsc easyfw_2.2-3_all.deb to pool/main/e/easyfw/easyfw_2.2-3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnophone 0.2.4+cvs.20020624-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Aug 2003 01:33:00 +0200 Source: gnophone Binary: gnophone Architecture: source i386 Version: 0.2.4+cvs.20020624-7 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Pierre Machard [EMAIL PROTECTED] Description: gnophone - An internet telephone application Changes: gnophone (0.2.4+cvs.20020624-7) unstable; urgency=low . * QA Upload * Last upload of the day. Definitely comment /usr/bin/gnomephone:3 Files: 779be6dce4499bc2a320aea4b2424421 716 sound optional gnophone_0.2.4+cvs.20020624-7.dsc ebd90fbb7b553c2f9a4103c0703e5f0a 169397 sound optional gnophone_0.2.4+cvs.20020624-7.diff.gz 8854ef62b0dea0fa813e35877b7ef994 198640 sound optional gnophone_0.2.4+cvs.20020624-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/R/tys6AtZiNwb4cRAmESAJ9+BQyJBridlhGvNIVzCZh69+7+ZACgljkI GAdtSFphykCSEBdpwZ2jXKA= =5eCB -END PGP SIGNATURE- Accepted: gnophone_0.2.4+cvs.20020624-7.diff.gz to pool/main/g/gnophone/gnophone_0.2.4+cvs.20020624-7.diff.gz gnophone_0.2.4+cvs.20020624-7.dsc to pool/main/g/gnophone/gnophone_0.2.4+cvs.20020624-7.dsc gnophone_0.2.4+cvs.20020624-7_i386.deb to pool/main/g/gnophone/gnophone_0.2.4+cvs.20020624-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted user-es 0.29 (all source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Sun, 24 Aug 2003 01:40:04 +0200 Source: user-es Binary: user-euro-es user-es Architecture: source all Version: 0.29 Distribution: unstable Urgency: low Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: user-es- Settings for Spanish speaking users user-euro-es - Settings for european Spanish speaking users Closes: 199262 199978 Changes: user-es (0.29) unstable; urgency=low . * Moved to po-based debconf translations (Closes: #199262) * Added french translation (Closes: #199978) * Slight changes in the spanish translation Files: 11278bd481ce25a7ca434a16201db7b1 626 misc optional user-es_0.29.dsc 4f46449a8c791967cd222e8b46cc4c97 50993 misc optional user-es_0.29.tar.gz 16dfba88669803ea7cb11504aa855f4a 22732 misc optional user-es_0.29_all.deb f1ededa5ca8cd9ce51a271e9298b7313 28156 misc optional user-euro-es_0.29_all.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBP0f73vtEPvakNq0lAQF0dwP+IASA54nATGE96MUv9RQcRFT6fJGZ4CO3 TZbQk5N7hEgzLizDty8gEbOpp7MDNrm/CNo11SP6SlRLOFTD8VMRkrrsrgnpm49j Twm7rSCmWUM0vanSQYGnIXGjwrymEaHYauHcoG9tszDV4vimfRyl9C60xYYqXILN 3nD1O21qdEI= =CDS9 -END PGP SIGNATURE- Accepted: user-es_0.29.dsc to pool/main/u/user-es/user-es_0.29.dsc user-es_0.29.tar.gz to pool/main/u/user-es/user-es_0.29.tar.gz user-es_0.29_all.deb to pool/main/u/user-es/user-es_0.29_all.deb user-euro-es_0.29_all.deb to pool/main/u/user-es/user-euro-es_0.29_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted samhain 1.7.10-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Sun, 24 Aug 2003 01:44:14 +0200 Source: samhain Binary: samhain Architecture: source i386 Version: 1.7.10-3 Distribution: unstable Urgency: low Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED] Description: samhain- Data integrity and host intrusion alert system Closes: 205167 Changes: samhain (1.7.10-3) unstable; urgency=low . * Added dutch po-debconf translation (Closes: #205167) Files: a3606073fb8c3629a52de77e4d6ca52d 702 admin optional samhain_1.7.10-3.dsc 6bdfcb4d8571cc6f3181dee5747f7c11 35214 admin optional samhain_1.7.10-3.diff.gz 8db87aa388537f421c864ded843535b4 401776 admin optional samhain_1.7.10-3_i386.deb -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQCVAwUBP0f90ftEPvakNq0lAQGzagP/Z4rghnLy/WXapohtR/uBY8OzAVShuG9y Girlm5LmSdq0gxEESmbWgkmFtcXrlRpzOda4YedocNxAnfTSgH4KL5vjjdPpFOZE 5guJ7BJsQgj8Hs3BGYLKh/3lQ5JZ//Ft7giU/3Wu/IOxTcspb4bEsYXMDq7OW0WX VdG/jZgGvp0= =th/T -END PGP SIGNATURE- Accepted: samhain_1.7.10-3.diff.gz to pool/main/s/samhain/samhain_1.7.10-3.diff.gz samhain_1.7.10-3.dsc to pool/main/s/samhain/samhain_1.7.10-3.dsc samhain_1.7.10-3_i386.deb to pool/main/s/samhain/samhain_1.7.10-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dbs 0.24 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Aug 2003 09:51:30 +1000 Source: dbs Binary: dbs Architecture: source all Version: 0.24 Distribution: unstable Urgency: low Maintainer: Brian May [EMAIL PROTECTED] Changed-By: Brian May [EMAIL PROTECTED] Description: dbs- Allows Debian source packages with multiple patches Closes: 204617 204944 Changes: dbs (0.24) unstable; urgency=low . * Force LC_COLLATE=C before calling sort (closes: #204617). * Ignore hidden files in patch directory (closes: #204944). Files: 03a72bebe8cd7ca0db81a53d0b5fe99d 515 devel optional dbs_0.24.dsc c3d0c66a69e2d2831266856384dd6c81 64361 devel optional dbs_0.24.tar.gz d279ddd6b6bd2cfe6536947201e98c6e 20582 devel optional dbs_0.24_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj9IAMAACgkQuCinHABTDCQ+CwCfdOGkbgmCmaarY3iYIwL08Brk MIYAniXWOswnHze2haI9XBffRIsB/zpg =IEkR -END PGP SIGNATURE- Accepted: dbs_0.24.dsc to pool/main/d/dbs/dbs_0.24.dsc dbs_0.24.tar.gz to pool/main/d/dbs/dbs_0.24.tar.gz dbs_0.24_all.deb to pool/main/d/dbs/dbs_0.24_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pygopherd 2.0.2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Aug 2003 17:29:20 -0500 Source: pygopherd Binary: pygfarm pygopherd Architecture: source all Version: 2.0.2 Distribution: unstable Urgency: low Maintainer: John Goerzen [EMAIL PROTECTED] Changed-By: John Goerzen [EMAIL PROTECTED] Description: pygfarm- Collection of add-on modules for Pygopherd pygopherd - Modular Multiprotocol Gopher/HTTP/WAP Server in Python Changes: pygopherd (2.0.2) unstable; urgency=low . * Can now autodetect many WAP browsers. Files: 7c19354e4842c87f627707ed9834ebdd 541 net optional pygopherd_2.0.2.dsc c4bf99f10d0a58c6eaf1adfb3c0fc6e8 429557 net optional pygopherd_2.0.2.tar.gz 78037c8c33d72c8a6fb0104e4afa3504 151202 net optional pygopherd_2.0.2_all.deb 2cfacca45e6b2c51acecd3ba595a25dd 6354 net optional pygfarm_2.0.2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/SAipgxaZAmAh+EsRAjNZAJ9s0oPMckWY6K7Z4wDH5Gwkv1QdIwCcDY/Y S1/Kg6MimWw4m7riPbjl+aQ= =jUK+ -END PGP SIGNATURE- Accepted: pygfarm_2.0.2_all.deb to pool/main/p/pygopherd/pygfarm_2.0.2_all.deb pygopherd_2.0.2.dsc to pool/main/p/pygopherd/pygopherd_2.0.2.dsc pygopherd_2.0.2.tar.gz to pool/main/p/pygopherd/pygopherd_2.0.2.tar.gz pygopherd_2.0.2_all.deb to pool/main/p/pygopherd/pygopherd_2.0.2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fluidsynth 1.0.2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Aug 2003 02:26:38 +0200 Source: fluidsynth Binary: libfluidsynth-dev libfluidsynth1 fluidsynth Architecture: source i386 Version: 1.0.2-1 Distribution: unstable Urgency: low Maintainer: [EMAIL PROTECTED] Changed-By: Eric Van Buggenhaut [EMAIL PROTECTED] Description: fluidsynth - Real-time MIDI software synthesizer libfluidsynth-dev - Real-time MIDI software synthesizer libfluidsynth1 - Real-time MIDI software synthesizer Changes: fluidsynth (1.0.2-1) unstable; urgency=low . * New upstream release * Removed build-dep on automake. We now run automake on the unpacked source tree and then ship the changed Makefile.in's in the diff.gz. Files: 5c2613663d06df6e4a13ce7ccb0ddf7f 664 sound optional fluidsynth_1.0.2-1.dsc 9765e1601ba0fc546f5bf2e0d966784b 784737 sound optional fluidsynth_1.0.2.orig.tar.gz f38e8b491b9901eaa2bf4743ce51ba60 19127 sound optional fluidsynth_1.0.2-1.diff.gz 5e156bc7a6d169693fb5296fe0639efe 31750 sound optional fluidsynth_1.0.2-1_i386.deb 04d18e433ac283efdec2e15130c3e382 128934 libs optional libfluidsynth1_1.0.2-1_i386.deb 7bd7ed1c66d0bccb7b93824086af0790 159830 libdevel optional libfluidsynth-dev_1.0.2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/SAt04VLuWbCehTARAj1xAJwM3x+6OS6Ivg+eHUOEAy7VXLtXygCfSZBH ou3T+y6kWooImTjBWQZmO4Y= =NrvS -END PGP SIGNATURE- Accepted: fluidsynth_1.0.2-1.diff.gz to pool/main/f/fluidsynth/fluidsynth_1.0.2-1.diff.gz fluidsynth_1.0.2-1.dsc to pool/main/f/fluidsynth/fluidsynth_1.0.2-1.dsc fluidsynth_1.0.2-1_i386.deb to pool/main/f/fluidsynth/fluidsynth_1.0.2-1_i386.deb fluidsynth_1.0.2.orig.tar.gz to pool/main/f/fluidsynth/fluidsynth_1.0.2.orig.tar.gz libfluidsynth-dev_1.0.2-1_i386.deb to pool/main/f/fluidsynth/libfluidsynth-dev_1.0.2-1_i386.deb libfluidsynth1_1.0.2-1_i386.deb to pool/main/f/fluidsynth/libfluidsynth1_1.0.2-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mcmcpack 0.4-2-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 9 Aug 2003 22:44:39 -0500 Source: mcmcpack Binary: r-cran-mcmcpack Architecture: source i386 Version: 0.4-2-1 Distribution: unstable Urgency: low Maintainer: Chris Lawrence [EMAIL PROTECTED] Changed-By: Chris Lawrence [EMAIL PROTECTED] Description: r-cran-mcmcpack - routines for Markov Chain Monte Carlo model estimation in R Changes: mcmcpack (0.4-2-1) unstable; urgency=low . * New upstream release. * Revised packaging to be more compatible with new upstream versions. Files: f91f293be8cc6728df8f5f0c4497b473 903 math optional mcmcpack_0.4-2-1.dsc 04ff17a7af20610a580c62632e2ed00d 154779 math optional mcmcpack_0.4-2.orig.tar.gz 73e8892ae7af39ff47ec66dca04e0bd9 3294 math optional mcmcpack_0.4-2-1.diff.gz 41a06b6a5344b39150d5841c1ee8e170 290192 math optional r-cran-mcmcpack_0.4-2-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iQEXAwUBP0gbcFxpg5e5AmZiFALDiwP5AUds+dYw4k63g88ftsw18LWOTrA/9WC1 gG72tD51/2XLzbkm4agUGeS9X+vnHP13D1uzOgkddsgtA/AypEjkwYtTBCPhCPVk igI5STSkaOWvPqHTMOnWx+NT95TLw0/SRUw33nN2HUFOkx1jBTxzenBDRVAE1UOx Ed2SyHbI4n8EAMDhW6gKlE+DNFE/k4mP751z10m9XUz/ZbSnx9vdMQmUGF2yuBbV qnCejEwnNgwtvuSJ+E2wBGiJwGHmgc6ngZ/D1OBa1M0cjinVJHT+EcMfjhNTRhHY XI/bvzCTcgGE20H0/Bo9OsE67aBdi/4C9RM4dEHOQHhx9ej6b1SYZYQm =cRnZ -END PGP SIGNATURE- Accepted: mcmcpack_0.4-2-1.diff.gz to pool/main/m/mcmcpack/mcmcpack_0.4-2-1.diff.gz mcmcpack_0.4-2-1.dsc to pool/main/m/mcmcpack/mcmcpack_0.4-2-1.dsc mcmcpack_0.4-2.orig.tar.gz to pool/main/m/mcmcpack/mcmcpack_0.4-2.orig.tar.gz r-cran-mcmcpack_0.4-2-1_i386.deb to pool/main/m/mcmcpack/r-cran-mcmcpack_0.4-2-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pygopherd 2.0.3 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Aug 2003 20:59:12 -0500 Source: pygopherd Binary: pygfarm pygopherd Architecture: source all Version: 2.0.3 Distribution: unstable Urgency: low Maintainer: John Goerzen [EMAIL PROTECTED] Changed-By: John Goerzen [EMAIL PROTECTED] Description: pygfarm- Collection of add-on modules for Pygopherd pygopherd - Modular Multiprotocol Gopher/HTTP/WAP Server in Python Changes: pygopherd (2.0.3) unstable; urgency=low . * Fixed a silly typo in wap.py. Files: 6fcb46f6bca68a635a4645b6e9c64057 541 net optional pygopherd_2.0.3.dsc e79144cb93eab75fef01a4018d55f9d9 429559 net optional pygopherd_2.0.3.tar.gz eb3c2911e48860b7bf144708cc331ea6 151224 net optional pygopherd_2.0.3_all.deb d9995a094fdcbff0dc8fa9fc29917321 6380 net optional pygfarm_2.0.3_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/SBwIgxaZAmAh+EsRAse8AJ9Gy02nx8KEmRjHxj7CIB37JB1tJQCgnBG+ lA9FE4mJjRq50K2anU1oz+M= =3J3K -END PGP SIGNATURE- Accepted: pygfarm_2.0.3_all.deb to pool/main/p/pygopherd/pygfarm_2.0.3_all.deb pygopherd_2.0.3.dsc to pool/main/p/pygopherd/pygopherd_2.0.3.dsc pygopherd_2.0.3.tar.gz to pool/main/p/pygopherd/pygopherd_2.0.3.tar.gz pygopherd_2.0.3_all.deb to pool/main/p/pygopherd/pygopherd_2.0.3_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted php4 4:4.3.2+rc3-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 17 Aug 2003 00:19:38 -0500 Source: php4 Binary: php4-cgi php4-sybase php4-recode php4-dev php4-snmp php4-odbc php4-xslt php4-domxml php4-mysql php4-gd php4-ldap php4-imap php4-curl php4 php4-pear php4-mcal caudium-php4 php4-mhash Architecture: source i386 all Version: 4:4.3.2+rc3-4 Distribution: unstable Urgency: low Maintainer: Adam Conrad [EMAIL PROTECTED] Changed-By: Steve Langasek [EMAIL PROTECTED] Description: caudium-php4 - A server-side, HTML-embedded scripting language php4 - A server-side, HTML-embedded scripting language php4-cgi - A server-side, HTML-embedded scripting language php4-curl - CURL module for php4 php4-dev - Files for PHP4 module development php4-domxml - XMLv2 module for php4 php4-gd- GD module for php4 php4-imap - IMAP module for php4 php4-ldap - LDAP module for php4 php4-mcal - MCAL calendar module for php4 php4-mhash - MHASH module for php4 php4-mysql - MySQL module for php4 php4-odbc - ODBC module for php4 php4-pear - PEAR - PHP Extension and Application Repository php4-recode - Character recoding module for php4 php4-snmp - SNMP module for php4 php4-sybase - Sybase / MS SQL Server module for php4 php4-xslt - XSLT module for php4 Closes: 143436 180497 206120 206404 Changes: php4 (4:4.3.2+rc3-4) unstable; urgency=low . * Have all php extensions automatically detect and configure for any installed SAPIs (closes: #143436). * Remove spurious dependencies from php4-dev, and replace autoconf2.13 with autoconf (closes: #180497). * Conflict with old php4-pgsql as we do with php4-mysql, as it manifests the same bug. * Add preliminary rules for building apache2 SAPI, but don't enable. * Call db_stop before trying to run apacheconfig (closes: #206404). * Check for the existence of /etc/php4 before trying to rmdir it, since there are apparently those who remove such directories prematurely (closes: #206120). Files: b193251cf1f147a64a0407b2afb43d3d 1522 web optional php4_4.3.2+rc3-4.dsc 680f10d102e4ff14479b07551dd6a036 86249 web optional php4_4.3.2+rc3-4.diff.gz 632acf238bcaa3b1f06cfa45a2d44022 741970 web optional php4_4.3.2+rc3-4_i386.deb 45ccc9c23c7b04bf41468eb9a3ceca5f 13874 web optional php4-curl_4.3.2+rc3-4_i386.deb 57b0b660fb6e8aeb364889de365c3f26 32368 web optional php4-domxml_4.3.2+rc3-4_i386.deb 58eb79d1a0603ca8a39b25678d8cd346 24616 web optional php4-gd_4.3.2+rc3-4_i386.deb bc6dd12e2981fbcc3e5c7ffd7e440eb0 31256 web optional php4-imap_4.3.2+rc3-4_i386.deb 1a192356feaad9798dfd9148c2d6a147 17042 web optional php4-ldap_4.3.2+rc3-4_i386.deb fc69a371e9fb859d2b580c88f4651271 14492 web optional php4-mcal_4.3.2+rc3-4_i386.deb 92247cc8cbcd229f7b5d6c5acd775ae1 5724 web optional php4-mhash_4.3.2+rc3-4_i386.deb 195ae1b1cdf16d8e01b523f7cd9c3570 18494 web optional php4-mysql_4.3.2+rc3-4_i386.deb 0009d22ca757668c60af0dd0c19831eb 23398 web optional php4-odbc_4.3.2+rc3-4_i386.deb 820b4316c681ebff0ea30294ad70c603 5416 web optional php4-recode_4.3.2+rc3-4_i386.deb 1b479b2bbfe4e3f519b5b36c69fcbf56 13622 web optional php4-xslt_4.3.2+rc3-4_i386.deb 2b41f63fd8ea9dffb584a3f2fd29d050 10188 web optional php4-snmp_4.3.2+rc3-4_i386.deb d4977d19bf88798716b10cff8a04a50f 16652 web optional php4-sybase_4.3.2+rc3-4_i386.deb ec146fd514860a03ce4ff20a9b130963 1273534 web optional php4-cgi_4.3.2+rc3-4_i386.deb ea5bf3e99b26c10efe9289f319539e40 735624 web optional caudium-php4_4.3.2+rc3-4_i386.deb 2f9b47d8f510bd28908f8d99f6bf882f 792434 devel optional php4-dev_4.3.2+rc3-4_all.deb 91252bfbc471432f47e1e82b73220d5a 276712 web optional php4-pear_4.3.2+rc3-4_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/SCFJKN6ufymYLloRAvl1AJ4/8i4Du1fCF3gCEJBatCH0kL7bpwCeON1a LZnRfOKTmT6Ulg9iqHCodl0= =zV+c -END PGP SIGNATURE- Accepted: caudium-php4_4.3.2+rc3-4_i386.deb to pool/main/p/php4/caudium-php4_4.3.2+rc3-4_i386.deb php4-cgi_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-cgi_4.3.2+rc3-4_i386.deb php4-curl_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-curl_4.3.2+rc3-4_i386.deb php4-dev_4.3.2+rc3-4_all.deb to pool/main/p/php4/php4-dev_4.3.2+rc3-4_all.deb php4-domxml_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-domxml_4.3.2+rc3-4_i386.deb php4-gd_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-gd_4.3.2+rc3-4_i386.deb php4-imap_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-imap_4.3.2+rc3-4_i386.deb php4-ldap_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-ldap_4.3.2+rc3-4_i386.deb php4-mcal_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-mcal_4.3.2+rc3-4_i386.deb php4-mhash_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-mhash_4.3.2+rc3-4_i386.deb php4-mysql_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-mysql_4.3.2+rc3-4_i386.deb php4-odbc_4.3.2+rc3-4_i386.deb to pool/main/p/php4/php4-odbc_4.3.2+rc3-4_i386.deb php4-pear_4.3.2+rc3-4_all.deb to pool/main/p/php4/php4-pear_4.3.2+rc3-4_all.deb
Accepted smpeg 0.4.5+cvs20030823-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Sat, 23 Aug 2003 23:32:20 -0400
Source: smpeg
Binary: smpeg-plaympeg libsmpeg-dev smpeg-gtv libsmpeg0
Architecture: source i386
Version: 0.4.5+cvs20030823-1
Distribution: unstable
Urgency: low
Maintainer: Joe Drew [EMAIL PROTECTED]
Changed-By: Joe Drew [EMAIL PROTECTED]
Description:
libsmpeg-dev - SDL MPEG Player Library - development files
libsmpeg0 - SDL MPEG Player Library - shared libraries
smpeg-gtv - SMPEG GTK+ MPEG audio/video player
smpeg-plaympeg - SMPEG command line MPEG audio/video player
Closes: 148478 200297
Changes:
smpeg (0.4.5+cvs20030823-1) unstable; urgency=low
.
* New upstream release + CVS changes. Our old SMPEG was horribly outdated.
* Update config.{sub, guess} to ensure no build breakage
* Acknowledge merge changes from Sam Hocevar's NMU (Closes: Bug#200297)
Thanks, Sam!
* debian/rules:
+ Update DEB_BUILD_OPTIONS for new policy
* debian/control:
+ Update to Standards-Version 3.6.1.
* debian/smpeg-gtv.menu:
+ Added menu entry for gtv. (Closes: Bug#148478)
* Patch smpeg.m4 for Bug#197002. Fix apparent copy and paste line breaking
errors which broke configure. Programs which use smpeg.m4 will need
to re-run aclocal. Patch sent upstream.
Files:
9d740d0029004c694b1c35864250f618 742 libs optional smpeg_0.4.5+cvs20030823-1.dsc
83dd80ffc086506a930ba9ea79192012 340288 libs optional
smpeg_0.4.5+cvs20030823.orig.tar.gz
5624c71b38cc59c35ae10d1f068988c5 23851 libs optional smpeg_0.4.5+cvs20030823-1.diff.gz
fc559768817e17ce2be67be163108f23 95750 libs optional
libsmpeg0_0.4.5+cvs20030823-1_i386.deb
dfa1cbedbc8aaa59fb1ba7e135961102 108682 devel optional
libsmpeg-dev_0.4.5+cvs20030823-1_i386.deb
7f65053ab4bd2d5d74121ee566192684 22232 graphics optional
smpeg-plaympeg_0.4.5+cvs20030823-1_i386.deb
1ba7add2f634fe81259f71e9160ae03a 27512 graphics optional
smpeg-gtv_0.4.5+cvs20030823-1_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/SDP+o7ginaV9i/cRAkSQAKCpRcC7hXnBZg+gp6xdtTr4yHsv2QCeLpie
5It2vZnOVFKV8iWAA/JM4hc=
=/0qr
-END PGP SIGNATURE-
Accepted:
libsmpeg-dev_0.4.5+cvs20030823-1_i386.deb
to pool/main/s/smpeg/libsmpeg-dev_0.4.5+cvs20030823-1_i386.deb
libsmpeg0_0.4.5+cvs20030823-1_i386.deb
to pool/main/s/smpeg/libsmpeg0_0.4.5+cvs20030823-1_i386.deb
smpeg-gtv_0.4.5+cvs20030823-1_i386.deb
to pool/main/s/smpeg/smpeg-gtv_0.4.5+cvs20030823-1_i386.deb
smpeg-plaympeg_0.4.5+cvs20030823-1_i386.deb
to pool/main/s/smpeg/smpeg-plaympeg_0.4.5+cvs20030823-1_i386.deb
smpeg_0.4.5+cvs20030823-1.diff.gz
to pool/main/s/smpeg/smpeg_0.4.5+cvs20030823-1.diff.gz
smpeg_0.4.5+cvs20030823-1.dsc
to pool/main/s/smpeg/smpeg_0.4.5+cvs20030823-1.dsc
smpeg_0.4.5+cvs20030823.orig.tar.gz
to pool/main/s/smpeg/smpeg_0.4.5+cvs20030823.orig.tar.gz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted aspell 0.50.3-13 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 23 Aug 2003 20:42:10 -0700 Source: aspell Binary: libpspell-dev libaspell15 aspell libaspell-dev aspell-doc aspell-bin Architecture: source i386 all Version: 0.50.3-13 Distribution: unstable Urgency: low Maintainer: Brian Nelson [EMAIL PROTECTED] Changed-By: Brian Nelson [EMAIL PROTECTED] Description: aspell - GNU Aspell spell-checker aspell-bin - GNU Aspell standalone spell-check utilities aspell-doc - Documentation for GNU Aspell spell-checker libaspell-dev - Development files for applications with GNU Aspell support libaspell15 - The GNU Aspell spell-checker runtime toolkits libpspell-dev - Development files for applications with pspell support Closes: 206236 Changes: aspell (0.50.3-13) unstable; urgency=low . * Added tetex-extra, gs-common, and psutils to the Build-Depends-Indep so that the postscript documents generated actually contain something (Closes: #206236) * Bumped up standards version to 3.6.1 Files: ff7889f391f8a73e0607b60d5e2ccd38 726 text optional aspell_0.50.3-13.dsc 0a29c06dcfd0ae48fd6faee28b652605 235210 text optional aspell_0.50.3-13.diff.gz 394045694f139bfb79eb207dfb55f9de 15128 text optional aspell_0.50.3-13_all.deb 8e51012eefa3b55ffbcbd43518749cb1 459818 doc optional aspell-doc_0.50.3-13_all.deb e1d2aeb05cdb8306c25ec3adc5411e7e 70168 text optional aspell-bin_0.50.3-13_i386.deb 4794bd48691a52ab09d4d9e0f1a6b339 252078 libs optional libaspell15_0.50.3-13_i386.deb 811732fbd02ca33e9492f4ff99e89ecd 15096 libdevel optional libaspell-dev_0.50.3-13_i386.deb ad52238ba28d278cd1e42aaa659364a9 12694 libdevel optional libpspell-dev_0.50.3-13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/SD8S1Ng1YWbyRSERAsuIAKCjoaYb6X0j9il0mOXsgfDGOdl3rwCeMly5 KuByQ2715jidEwnKKqGMm1I= =SJw1 -END PGP SIGNATURE- Accepted: aspell-bin_0.50.3-13_i386.deb to pool/main/a/aspell/aspell-bin_0.50.3-13_i386.deb aspell-doc_0.50.3-13_all.deb to pool/main/a/aspell/aspell-doc_0.50.3-13_all.deb aspell_0.50.3-13.diff.gz to pool/main/a/aspell/aspell_0.50.3-13.diff.gz aspell_0.50.3-13.dsc to pool/main/a/aspell/aspell_0.50.3-13.dsc aspell_0.50.3-13_all.deb to pool/main/a/aspell/aspell_0.50.3-13_all.deb libaspell-dev_0.50.3-13_i386.deb to pool/main/a/aspell/libaspell-dev_0.50.3-13_i386.deb libaspell15_0.50.3-13_i386.deb to pool/main/a/aspell/libaspell15_0.50.3-13_i386.deb libpspell-dev_0.50.3-13_i386.deb to pool/main/a/aspell/libpspell-dev_0.50.3-13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted parmetis 3.0-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 7 Aug 2003 20:01:45 -0400 Source: parmetis Binary: parmetis-doc libparmetis-dev libparmetis3.0 parmetis-test Architecture: source all i386 Version: 3.0-3 Distribution: unstable Urgency: low Maintainer: Adam C. Powell, IV [EMAIL PROTECTED] Changed-By: Adam C. Powell, IV [EMAIL PROTECTED] Description: libparmetis-dev - Parallel Graph Partitioning and Sparse Matrix Ordering Libs: Deve libparmetis3.0 - Parallel Graph Partitioning and Sparse Matrix Ordering Shared Lib parmetis-doc - Parallel Graph Partitioning and Sparse Matrix Ordering Lib - Docs parmetis-test - Parallel Graph Partitioning and Sparse Matrix Ordering Tests Closes: 200904 Changes: parmetis (3.0-3) unstable; urgency=low . * Fixed parmetis.h to work with C++. (closes: #200904) * Added shared library with its very own package. * Changed name of -dev package. * Added -test package with binaries and example files from Test dir. * Added overrides files because lintian mistakenly thinks this is gpl. :-) Files: 566c8befb7e246a953cc713959d2a718 624 non-free/math extra parmetis_3.0-3.dsc 1b11d8cf5108fbd0977b7fda5bddbfc5 8060 non-free/math extra parmetis_3.0-3.diff.gz 99868c6b85018f17e88e4a0dbabc43b5 7544544 non-free/doc extra parmetis-doc_3.0-3_all.deb 09a432345072e511f66bd9b3e0745d7f 233084 non-free/libdevel extra libparmetis-dev_3.0-3_i386.deb e457c194a3e468c1caab018f913b3a8a 331554 non-free/libs extra libparmetis3.0_3.0-3_i386.deb ff3b1968e169b07fe36651881c8bcda2 7364744 non-free/math extra parmetis-test_3.0-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/MuwEUm8B6FZO5LYRAocSAJ9w64KmOey9mISt4opys8/RdM9HzACfQaD4 ZqngoygSEtE+cvELWmdAztY= =6Y78 -END PGP SIGNATURE- Accepted: libparmetis-dev_3.0-3_i386.deb to pool/non-free/p/parmetis/libparmetis-dev_3.0-3_i386.deb libparmetis3.0_3.0-3_i386.deb to pool/non-free/p/parmetis/libparmetis3.0_3.0-3_i386.deb parmetis-doc_3.0-3_all.deb to pool/non-free/p/parmetis/parmetis-doc_3.0-3_all.deb parmetis-test_3.0-3_i386.deb to pool/non-free/p/parmetis/parmetis-test_3.0-3_i386.deb parmetis_3.0-3.diff.gz to pool/non-free/p/parmetis/parmetis_3.0-3.diff.gz parmetis_3.0-3.dsc to pool/non-free/p/parmetis/parmetis_3.0-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted openvrml 0.13.0-0.1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Aug 2003 09:44:28 +0200 Source: openvrml Binary: libopenvrml3 openvrml-lookat libopenvrml3-dev Architecture: source i386 Version: 0.13.0-0.1 Distribution: unstable Urgency: low Maintainer: Maurizio Boriani (baux) [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: libopenvrml3 - cross-platform runtime shared library for VRML libopenvrml3-dev - developer's libraries for openvrml openvrml-lookat - VRML X11 viewer Closes: 199292 Changes: openvrml (0.13.0-0.1) unstable; urgency=low . * NMU. * New upstream version (Closes: #199292). * Re-ran the bootstrap sequence (libtoolize -f -c aclocal-1.7 -I macros autoconf autoheader automake-1.7 -f -a -c). The magic is no longer needed for C++ libraries since I used libtool 1.5. * debian/control: + Renamed libopenvrml0c102 into libopenvrml3. + Put lookat in /usr/bin instead of /usr/X11R6/bin. * debian/rules: + Split the build rule into configure and build. + Use debian/compat instead of DH_VERSION. + Removed lots of cruft. * debian/docs: + Do not install the generic INSTALL document. * src/openvrml/OpenVRML/vrml97node.cpp: + Fixed the use of std::binary_function with gcc-3.3. Files: 6646cd50734c34749e892390eaa080fb 729 libs optional openvrml_0.13.0-0.1.dsc f386b8365f7987222927bf3a28c95fd9 1436672 libs optional openvrml_0.13.0.orig.tar.gz 8617c808260ba5722dd64c704b93366a 284265 libs optional openvrml_0.13.0-0.1.diff.gz 7df950e7ac87b4b7ba2642101a91567e 923150 libs optional libopenvrml3_0.13.0-0.1_i386.deb 9bdebc6d705aff97b81e904f4d3978bd 1655222 libdevel optional libopenvrml3-dev_0.13.0-0.1_i386.deb 0bdba19c8e0bdb6b455074532fedd168 48318 x11 optional openvrml-lookat_0.13.0-0.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/O0tIfPP1rylJn2ERAoNMAJwKXpEYgNJ34+VVybmxWuHzpnDlOACdFFBr cfYPF2rYhdfE4uXoJFr3TBs= =hYVK -END PGP SIGNATURE- Accepted: libopenvrml3-dev_0.13.0-0.1_i386.deb to pool/main/o/openvrml/libopenvrml3-dev_0.13.0-0.1_i386.deb libopenvrml3_0.13.0-0.1_i386.deb to pool/main/o/openvrml/libopenvrml3_0.13.0-0.1_i386.deb openvrml-lookat_0.13.0-0.1_i386.deb to pool/main/o/openvrml/openvrml-lookat_0.13.0-0.1_i386.deb openvrml_0.13.0-0.1.diff.gz to pool/main/o/openvrml/openvrml_0.13.0-0.1.diff.gz openvrml_0.13.0-0.1.dsc to pool/main/o/openvrml/openvrml_0.13.0-0.1.dsc openvrml_0.13.0.orig.tar.gz to pool/main/o/openvrml/openvrml_0.13.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cbmlink 0.9.6-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 10 Aug 2003 22:00:00 +0100 Source: cbmlink Binary: cbmlink-cbmc2n cbmlink cbmlink-cbmprg cbmlink-cbmutils Architecture: source all i386 Version: 0.9.6-1 Distribution: unstable Urgency: low Maintainer: Peter Karlsson [EMAIL PROTECTED] Changed-By: Peter Karlsson [EMAIL PROTECTED] Description: cbmlink- Transfer data to/from Commodore 8-bit computers cbmlink-cbmc2n - Commodore C2N232 images for cbmlink cbmlink-cbmprg - Commodore binaries for cbmlink cbmlink-cbmutils - Commodore utility programs for cbmlink Closes: 177635 Changes: cbmlink (0.9.6-1) unstable; urgency=low . * Initial Release. (Closes: Bug#177635 (ITP)) Files: b1a23332fec7c2fec0872de49c8bf3b1 638 otherosfs extra cbmlink_0.9.6-1.dsc f235c62f081cd7971773124f08eca655 102738 otherosfs extra cbmlink_0.9.6.orig.tar.gz 3196b6bfd7ce82c2f580f126705e53bb 4124 otherosfs extra cbmlink_0.9.6-1.diff.gz 4517aa99b30a847cba15f40d59dc86b4 25552 otherosfs extra cbmlink-cbmprg_0.9.6-1_all.deb 4718b4e165d00ea098bcc2892921cbdf 8698 otherosfs extra cbmlink-cbmc2n_0.9.6-1_all.deb 933225899cf0826ee5fb1937b290fec5 6068 otherosfs extra cbmlink-cbmutils_0.9.6-1_all.deb d99ec6eb7dc3b215966035401088232f 53950 otherosfs extra cbmlink_0.9.6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/NrUIkryUdmOUJl4RAhjYAJ4iltjNy31D6R8VT4e1tA+AXqzgdACfdQpL 3LTXrT9NM0Jvs+sfkaV48r0= =23CU -END PGP SIGNATURE- Accepted: cbmlink-cbmc2n_0.9.6-1_all.deb to pool/main/c/cbmlink/cbmlink-cbmc2n_0.9.6-1_all.deb cbmlink-cbmprg_0.9.6-1_all.deb to pool/main/c/cbmlink/cbmlink-cbmprg_0.9.6-1_all.deb cbmlink-cbmutils_0.9.6-1_all.deb to pool/main/c/cbmlink/cbmlink-cbmutils_0.9.6-1_all.deb cbmlink_0.9.6-1.diff.gz to pool/main/c/cbmlink/cbmlink_0.9.6-1.diff.gz cbmlink_0.9.6-1.dsc to pool/main/c/cbmlink/cbmlink_0.9.6-1.dsc cbmlink_0.9.6-1_i386.deb to pool/main/c/cbmlink/cbmlink_0.9.6-1_i386.deb cbmlink_0.9.6.orig.tar.gz to pool/main/c/cbmlink/cbmlink_0.9.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted fixedpoint 0.1.2-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 13 Aug 2003 18:25:51 +0530 Source: fixedpoint Binary: python2.2-fixedpoint python2.3-fixedpoint python-fixedpoint Architecture: source all Version: 0.1.2-2 Distribution: unstable Urgency: low Maintainer: Ganesan Rajagopal [EMAIL PROTECTED] Changed-By: Ganesan Rajagopal [EMAIL PROTECTED] Description: python-fixedpoint - A fixed point math object for python [dummy package] python2.2-fixedpoint - A fixed point math object for python (2.2.x) python2.3-fixedpoint - A fixed point math object for python (2.3.x) Closes: 187139 Changes: fixedpoint (0.1.2-2) unstable; urgency=low . * Changed source package name to match the sourceforge download. * Fixed E-mail address in copyright file. (Closes: #187139). Files: af5c0b1593e70abe7d3c4a9effe66491 666 python optional fixedpoint_0.1.2-2.dsc 9caf53d030cdd173473d8ac9818f59cb 16409 python optional fixedpoint_0.1.2.orig.tar.gz 8cc0b033e0d362d83bf39f811558b54f 10887 python optional fixedpoint_0.1.2-2.diff.gz 5ac811f43eb2223512e4f6f67c14de42 22586 python optional python2.2-fixedpoint_0.1.2-2_all.deb ccc919712aa8c93cf330042f2f95f993 21512 python optional python2.3-fixedpoint_0.1.2-2_all.deb 465875eb9a9ee60b9e2315b5c95c8212 1584 python optional python-fixedpoint_0.1.2-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/O2NmFeACul2MEuoRAkj4AKC2TwLVOwVfbwbu6fA5hIvXRQipHwCfZdkd vFrklie5ytAAcbuATURQhfM= =MTnp -END PGP SIGNATURE- Accepted: fixedpoint_0.1.2-2.diff.gz to pool/main/f/fixedpoint/fixedpoint_0.1.2-2.diff.gz fixedpoint_0.1.2-2.dsc to pool/main/f/fixedpoint/fixedpoint_0.1.2-2.dsc fixedpoint_0.1.2.orig.tar.gz to pool/main/f/fixedpoint/fixedpoint_0.1.2.orig.tar.gz python-fixedpoint_0.1.2-2_all.deb to pool/main/f/fixedpoint/python-fixedpoint_0.1.2-2_all.deb python2.2-fixedpoint_0.1.2-2_all.deb to pool/main/f/fixedpoint/python2.2-fixedpoint_0.1.2-2_all.deb python2.3-fixedpoint_0.1.2-2_all.deb to pool/main/f/fixedpoint/python2.3-fixedpoint_0.1.2-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted python-bsddb3 3.3.0-5.3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Aug 2003 12:57:36 +0200 Source: python-bsddb3 Binary: python2.2-bsddb3 python2.3-bsddb3 python-bsddb3-doc python-bsddb3 Architecture: source i386 Version: 3.3.0-5.3 Distribution: unstable Urgency: low Maintainer: Nathan Hawkins [EMAIL PROTECTED] Changed-By: Josselin Mouette [EMAIL PROTECTED] Description: python-bsddb3 - Python interface to libdb3 python-bsddb3-doc - Documentation for the python libdb3 interface module python2.2-bsddb3 - Python 2.2 interface to libdb3 python2.3-bsddb3 - Python 2.3 interface to libdb3 Closes: 204702 Changes: python-bsddb3 (3.3.0-5.3) unstable; urgency=low . * NMU. * Rebuild against python 2.3 (closes: #204702). * Use dh_python. * Standards-Version is 3.6.0. * Correct copyright file. * bsddb3/dbshelve.py: remove interpreter line. Files: dbe80de00014202f53f80203683874ca 713 interpreters optional python-bsddb3_3.3.0-5.3.dsc eaec9a6621706309eb696c77b496011b 3243 interpreters optional python-bsddb3_3.3.0-5.3.diff.gz 9a05e0b3415d34b2a20a185d77ca3946 3182 interpreters optional python-bsddb3_3.3.0-5.3_i386.deb e301b594224d35c335a9607c776b8c34 40830 interpreters optional python2.3-bsddb3_3.3.0-5.3_i386.deb d56b15cb04aa9f1b02046392399e2067 40828 interpreters optional python2.2-bsddb3_3.3.0-5.3_i386.deb af60a4df293b78e769abf9dfe874c51d 70924 interpreters optional python-bsddb3-doc_3.3.0-5.3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/O3KOrSla4ddfhTMRAsv6AKCiKh8+IomxQ58TKbKCS7s+OK7aEwCgzNaU aVtZN8th4tk/TS0AmeBbV9Q= =qxIl -END PGP SIGNATURE- Accepted: python-bsddb3-doc_3.3.0-5.3_i386.deb to pool/main/p/python-bsddb3/python-bsddb3-doc_3.3.0-5.3_i386.deb python-bsddb3_3.3.0-5.3.diff.gz to pool/main/p/python-bsddb3/python-bsddb3_3.3.0-5.3.diff.gz python-bsddb3_3.3.0-5.3.dsc to pool/main/p/python-bsddb3/python-bsddb3_3.3.0-5.3.dsc python-bsddb3_3.3.0-5.3_i386.deb to pool/main/p/python-bsddb3/python-bsddb3_3.3.0-5.3_i386.deb python2.2-bsddb3_3.3.0-5.3_i386.deb to pool/main/p/python-bsddb3/python2.2-bsddb3_3.3.0-5.3_i386.deb python2.3-bsddb3_3.3.0-5.3_i386.deb to pool/main/p/python-bsddb3/python2.3-bsddb3_3.3.0-5.3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gnome-themes 2.3.3-4 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 24 Aug 2003 07:39:36 +0200 Source: gnome-themes Binary: gtk2-engines-thinice gnome-themes-common gnome-accessibility-themes gnome-themes gtk2-engines-crux gtk2-engines-mist gtk2-engines-lighthouseblue Architecture: source i386 all Version: 2.3.3-4 Distribution: unstable Urgency: low Maintainer: Christian Marillat [EMAIL PROTECTED] Changed-By: Christian Marillat [EMAIL PROTECTED] Description: gnome-accessibility-themes - GNOME 2 accessibility themes gnome-themes - GNOME 2 Desktop themes gnome-themes-common - GNOME 2 Desktop themes - common files gtk2-engines-crux - GTK+2.0 Crux theme engine gtk2-engines-lighthouseblue - LighthouseBlue theme for GTK+ 2.0 gtk2-engines-mist - A flat theme for GTK+ 2.x gtk2-engines-thinice - ThinIce theme for GTK+ 2 Changes: gnome-themes (2.3.3-4) unstable; urgency=low . * Why s390 is missing in my previous patch ? Last upload for this version ? * debian/control remove unneeded Build-Depends-Indep line Files: 6282d6ca754d456c28e30ef301db7cd9 797 gnome optional gnome-themes_2.3.3-4.dsc 4a674adc8d33a2ee4a422e5662c98944 16912 gnome optional gnome-themes_2.3.3-4.diff.gz ffefe892483907376d260f4883792c11 232298 gnome optional gnome-themes_2.3.3-4_all.deb 9da847123bc7eb90365d681d718aeb89 48838 gnome optional gnome-themes-common_2.3.3-4_all.deb 3f61972bcc6a9c9075adfb7fa16cb491 1659828 gnome optional gnome-accessibility-themes_2.3.3-4_i386.deb 1d9de5c01fc9f7d075ba01442a6a888b 192030 graphics optional gtk2-engines-crux_2.3.3-4_i386.deb bf9aebea2ae938f4427e050ffb6ef715 22090 x11 optional gtk2-engines-lighthouseblue_2.3.3-4_i386.deb ab97329ee4e8fbdeba6bc33dc1eccaa6 189608 x11 optional gtk2-engines-mist_2.3.3-4_i386.deb 39b9cd149698266986361ee2b3d9e1f7 32072 graphics optional gtk2-engines-thinice_2.3.3-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/SFL8B9xWPR9BuQcRAmFiAJ47QK+Omq4u+KHhNHbxv/5VIrJ5GQCdGTEj muRMy32tNPAO5yVl/ZNa30U= =scJB -END PGP SIGNATURE- Accepted: gnome-accessibility-themes_2.3.3-4_i386.deb to pool/main/g/gnome-themes/gnome-accessibility-themes_2.3.3-4_i386.deb gnome-themes-common_2.3.3-4_all.deb to pool/main/g/gnome-themes/gnome-themes-common_2.3.3-4_all.deb gnome-themes_2.3.3-4.diff.gz to pool/main/g/gnome-themes/gnome-themes_2.3.3-4.diff.gz gnome-themes_2.3.3-4.dsc to pool/main/g/gnome-themes/gnome-themes_2.3.3-4.dsc gnome-themes_2.3.3-4_all.deb to pool/main/g/gnome-themes/gnome-themes_2.3.3-4_all.deb gtk2-engines-crux_2.3.3-4_i386.deb to pool/main/g/gnome-themes/gtk2-engines-crux_2.3.3-4_i386.deb gtk2-engines-lighthouseblue_2.3.3-4_i386.deb to pool/main/g/gnome-themes/gtk2-engines-lighthouseblue_2.3.3-4_i386.deb gtk2-engines-mist_2.3.3-4_i386.deb to pool/main/g/gnome-themes/gtk2-engines-mist_2.3.3-4_i386.deb gtk2-engines-thinice_2.3.3-4_i386.deb to pool/main/g/gnome-themes/gtk2-engines-thinice_2.3.3-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted multisync 0.80.1-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Aug 2003 16:10:21 +0100 Source: multisync Binary: libmultisync-plugin-irmc multisync libmultisync-plugin-syncml libmultisync-plugin-backup libmultisync-plugin-all libmultisync-plugin-irmc-bluetooth libmultisync-plugin-evolution libmultisync-plugin-opie Architecture: source i386 all Version: 0.80.1-1 Distribution: unstable Urgency: low Maintainer: Mikael Andersson [EMAIL PROTECTED] Changed-By: Mikael Andersson [EMAIL PROTECTED] Description: libmultisync-plugin-all - Pseudo package wish depends on all plugins for MultiSync libmultisync-plugin-backup - Backup plug for MultiSync libmultisync-plugin-evolution - Ximian Evolution plugin for MultiSync libmultisync-plugin-irmc - IrMc Mobile plugin for MultiSync libmultisync-plugin-irmc-bluetooth - Adds Bluetooth support to the IrMC plugin libmultisync-plugin-opie - Opie plugin for MultiSync libmultisync-plugin-syncml - SyncML plugin for MultiSync multisync - A program to synchronize PIM data Closes: 197736 203916 Changes: multisync (0.80.1-1) unstable; urgency=low . * New upstream version . * Evolution plugin now compatible with evolution 1.4 (Closes: #197736,#203916) * Remote plugin is now replaced with SyncML plugin. . * New Opie Plugin Files: 3a883aa374751fdc3f8fea689ab88955 1109 x11 optional multisync_0.80.1-1.dsc f1b1ff5665d7de82b2a2948752b818c7 1592241 x11 optional multisync_0.80.1.orig.tar.gz 0a5a628c65450f195e0d5768560c52f3 16385 x11 optional multisync_0.80.1-1.diff.gz 0ee47117a64eccfca7d81b480bfd6ccc 3414 libs optional libmultisync-plugin-all_0.80.1-1_all.deb 67a060b0f3f4849d92889fe380084590 67550 x11 optional multisync_0.80.1-1_i386.deb d517b8e82a9af9a7ee77f3a489dc322a 50614 mail optional libmultisync-plugin-evolution_0.80.1-1_i386.deb a0807d33f4861d7053c68424d6c3d633 28652 libs optional libmultisync-plugin-backup_0.80.1-1_i386.deb 9345c8588336ca5c92bd1f1546f867bc 74584 libs optional libmultisync-plugin-irmc_0.80.1-1_i386.deb 92d366897a8126365e1e5052be2d19dd 9442 libs optional libmultisync-plugin-irmc-bluetooth_0.80.1-1_i386.deb d4255e058ada103d909a920d99c01551 84418 libs optional libmultisync-plugin-syncml_0.80.1-1_i386.deb 7d592e9f541697402fc482bfdb47a1f3 3440 libs optional libmultisync-plugin-opie_0.80.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/O+TBWh5L3SDpPo4RAoLEAJkB3e2MFloP2/FtjdRchL+qDu33LwCfcMC4 48qBFlKE9XlSvuP1SkyIGa8= =YpCQ -END PGP SIGNATURE- Accepted: libmultisync-plugin-all_0.80.1-1_all.deb to pool/main/m/multisync/libmultisync-plugin-all_0.80.1-1_all.deb libmultisync-plugin-backup_0.80.1-1_i386.deb to pool/main/m/multisync/libmultisync-plugin-backup_0.80.1-1_i386.deb libmultisync-plugin-evolution_0.80.1-1_i386.deb to pool/main/m/multisync/libmultisync-plugin-evolution_0.80.1-1_i386.deb libmultisync-plugin-irmc-bluetooth_0.80.1-1_i386.deb to pool/main/m/multisync/libmultisync-plugin-irmc-bluetooth_0.80.1-1_i386.deb libmultisync-plugin-irmc_0.80.1-1_i386.deb to pool/main/m/multisync/libmultisync-plugin-irmc_0.80.1-1_i386.deb libmultisync-plugin-opie_0.80.1-1_i386.deb to pool/main/m/multisync/libmultisync-plugin-opie_0.80.1-1_i386.deb libmultisync-plugin-syncml_0.80.1-1_i386.deb to pool/main/m/multisync/libmultisync-plugin-syncml_0.80.1-1_i386.deb multisync_0.80.1-1.diff.gz to pool/main/m/multisync/multisync_0.80.1-1.diff.gz multisync_0.80.1-1.dsc to pool/main/m/multisync/multisync_0.80.1-1.dsc multisync_0.80.1-1_i386.deb to pool/main/m/multisync/multisync_0.80.1-1_i386.deb multisync_0.80.1.orig.tar.gz to pool/main/m/multisync/multisync_0.80.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-blowfish 0.3-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Aug 2003 21:46:03 -0600 Source: cl-blowfish Binary: cl-blowfish Architecture: source all Version: 0.3-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: cl-blowfish - Common Lisp Blowfish encryption Changes: cl-blowfish (0.3-1) unstable; urgency=low . * Initial upload Files: 9aa5e6d185ce9ea92bc8f249d68f2f06 578 devel optional cl-blowfish_0.3-1.dsc 495cdbeeacea0d6f5a70c4af03a7dfe8 41516 devel optional cl-blowfish_0.3.orig.tar.gz 636fe9026ba24bfd68d69d581b48a9aa 3517 devel optional cl-blowfish_0.3-1.diff.gz e5845ce33f79bae832b6eff89e161093 19040 devel optional cl-blowfish_0.3-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/PG2HES7N8sSjgj4RAkWuAJ9ZOachndv8DhypWc929X5jvfqqdgCff+Dn 371APtCt5B0ayzZ2Aae3NyU= =7zap -END PGP SIGNATURE- Accepted: cl-blowfish_0.3-1.diff.gz to pool/main/c/cl-blowfish/cl-blowfish_0.3-1.diff.gz cl-blowfish_0.3-1.dsc to pool/main/c/cl-blowfish/cl-blowfish_0.3-1.dsc cl-blowfish_0.3-1_all.deb to pool/main/c/cl-blowfish/cl-blowfish_0.3-1_all.deb cl-blowfish_0.3.orig.tar.gz to pool/main/c/cl-blowfish/cl-blowfish_0.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-blowfish 0.3-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 14 Aug 2003 23:28:09 -0600 Source: cl-blowfish Binary: cl-blowfish Architecture: source all Version: 0.3-2 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: cl-blowfish - Common Lisp Blowfish encryption Changes: cl-blowfish (0.3-2) unstable; urgency=low . * Fix upstream URL Files: 8d388174fd50347fbb6860526c5a20bb 578 devel optional cl-blowfish_0.3-2.dsc 18ced387a466081a557707f5cbb33318 3554 devel optional cl-blowfish_0.3-2.diff.gz a74cb09cde18253a2f1fc344181b296f 19118 devel optional cl-blowfish_0.3-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/PG9/ES7N8sSjgj4RArGHAJ9tMVXu0+zdG6AeKqc5DGbQEyISsQCfV31A IHLOdGXfrUr620/CoJX6OeI= =lVUu -END PGP SIGNATURE- Accepted: cl-blowfish_0.3-2.diff.gz to pool/main/c/cl-blowfish/cl-blowfish_0.3-2.diff.gz cl-blowfish_0.3-2.dsc to pool/main/c/cl-blowfish/cl-blowfish_0.3-2.dsc cl-blowfish_0.3-2_all.deb to pool/main/c/cl-blowfish/cl-blowfish_0.3-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xml-core 0.01 (all source)
-BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Sat, 16 Aug 2003 12:50:43 -0500 Source: xml-core Binary: xml-core Architecture: source all Version: 0.01 Distribution: unstable Urgency: low Maintainer: Ardo van Rangelrooij [EMAIL PROTECTED] Changed-By: Ardo van Rangelrooij [EMAIL PROTECTED] Description: xml-core - utilities to maintain XML catalog files Changes: xml-core (0.01) unstable; urgency=low . * Initial official release Files: 47487b0d06247ba8a5d074c819990944 607 text optional xml-core_0.01.dsc f1b3a8e3fe37a97e9b7297bb497300c8 14491 text optional xml-core_0.01.tar.gz 6ab83f6f7acc4ee6561f6d7b601b3d81 8534 text optional xml-core_0.01_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iQCVAwUBPz5vKT6XMRfcxSjpAQEMQgP/dtoqkuAqFMT4us3aB0poYS5gRHnPKeQM HjnGaZETY+aOxE/zOerZuI87fSuakX8UQK3CIr8AfGi3P0+bFSRZF6nE5/+DjHbU YoG+IT3QPw1YdKSEDJiiEVWB/2wl0VtJt4RmQyQNKApGTD1elPa+PV+TmTO2AY/9 CEpYm7dCB6c= =2Sfr -END PGP SIGNATURE- Accepted: xml-core_0.01.dsc to pool/main/x/xml-core/xml-core_0.01.dsc xml-core_0.01.tar.gz to pool/main/x/xml-core/xml-core_0.01.tar.gz xml-core_0.01_all.deb to pool/main/x/xml-core/xml-core_0.01_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ppp 2.4.1.uus2-2 (i386 source all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 21 Aug 2003 17:33:21 +0200
Source: ppp
Binary: ppp-udeb ppp-dev ppp
Architecture: source i386 all
Version: 2.4.1.uus2-2
Distribution: unstable
Urgency: low
Maintainer: Russell Coker [EMAIL PROTECTED]
Changed-By: Marco d'Itri [EMAIL PROTECTED]
Description:
ppp- Point-to-Point Protocol (PPP) daemon
ppp-dev- Selected headers from the ppp package
ppp-udeb - Point-to-Point Protocol (PPP) daemon (udeb)
Closes: 46896 51880 56963 60250 85173 93936 101618 119878 125697 126656 128875 130716
140587 140587 144368 152398 156672 160169 162895 169694 169697 170771 171200 172317
175480 180720 182103 182107 187756 200639 202680 203243 205046
Changes:
ppp (2.4.1.uus2-2) unstable; urgency=low
.
* New co-maintainer. (Closes: #180720)
* Switch to DBS.
* PAM configuration updated to the new style.
* Stop deleting /etc/ppp/* on purge, this is evil. (Closes: #202680)
* Kill pppd at K86 instead of K14. (Closes: #200639)
* Add a generic chatscript for PAP/CHAP sites. (Closes: #182107)
* Add a newline at the end of /etc/pam.d/ppp. (Closes: #182103)
* Add two ip-{up,down} scripts to support usepeerdns and the resolvconf
package. (Closes: #187756, #203243)
* Add a patch from Herbert Xu to fix the PPPIOCDETACH bug. This is
not the same bug of Inappropriate ioctl for device(25).
(Closes: #172317, #175480)
* 2.0 kernels are not supported by debian, remove kernel.fix-2.0.30-2.
(Closes: #171200)
* Add bash completion script. (Closes: #170771)
* Restore SIGPIPE for childs (Herbert Xu). (Closes: #169697)
* Fix the holdoff option (Herbert Xu). (Closes: #128875, #169694)
* Add a logrotate file. (Closes: #162895)
* Make pon print an error message if the user is not in the dip group.
(Closes: #156672)
* Improve the ability of poff of finding the right process.
(Closes: #160169)
* Remove deflate support from pppdump, just to be sure. (Closes: #144368)
* Use poff -a at shutdown time. (Closes: #140587)
* Add the popp example script from Tomas Pospisek. (Closes: #130716)
* Clarify pon(1). (Closes: #126656)
* Fix the code which reads /etc/networks/ (Closes: #125697)
* Add support for /var/log/ppp-ipupdown.log. (Closes: #152398)
* Add support for /etc/ppp/ip-{up,down}.local. (Closes: #85173, #119878)
* Create a new ppp-dev package for headers. (Closes: #101618)
* Add an example script from Brian May which implements exponential
redialing retries. (Closes: #56963, #140587, #205046)
* Add example scripts to support per-user ip-{up,down}.d directories.
(Closes: #46896, #60250)
* Export the call options as an environment variable. (Closes: #51880)
* Restore support for the 'quick' argument to pon.
* Add the cifdefroute.dif patch (from the SuSE ppp package).
(Closes: #93936)
Files:
473f921fbded4b0e5372a01cd8dfdf6f 686 base optional ppp_2.4.1.uus2-2.dsc
e01a32c46ecd8872f3cf44e706ce6fa3 57722 base optional ppp_2.4.1.uus2-2.diff.gz
0d06552775cb2a0911e35244f6290da5 238168 base optional ppp_2.4.1.uus2-2_i386.deb
618954da52cab7550540695e16f1cc88 103228 debian-installer optional
ppp-udeb_2.4.1.uus2-2_i386.udeb
583cc84b58a6a4b74244f204f47a1f3a 34594 devel extra ppp-dev_2.4.1.uus2-2_all.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/RPIXFGfw2OHuP7ERAsZuAJ95yl62FNs/E3QM/LPO2BSsSb+62gCfYk07
zOQmMUAnkOvhLyCLX15qml8=
=XhbB
-END PGP SIGNATURE-
Accepted:
ppp-dev_2.4.1.uus2-2_all.deb
to pool/main/p/ppp/ppp-dev_2.4.1.uus2-2_all.deb
ppp-udeb_2.4.1.uus2-2_i386.udeb
to pool/main/p/ppp/ppp-udeb_2.4.1.uus2-2_i386.udeb
ppp_2.4.1.uus2-2.diff.gz
to pool/main/p/ppp/ppp_2.4.1.uus2-2.diff.gz
ppp_2.4.1.uus2-2.dsc
to pool/main/p/ppp/ppp_2.4.1.uus2-2.dsc
ppp_2.4.1.uus2-2_i386.deb
to pool/main/p/ppp/ppp_2.4.1.uus2-2_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
