Work-needing packages report for Aug 29, 2003
Report about packages that need work for Aug 29, 2003 Total number of packages offered up for adoption: 59 Number of packages offered up for adoption this week: 1 Total number of orphaned packages: 205 Number of packages orphaned this week: 20 The number in parenthesis after each package name is the corresponding bug report number. Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages are orphaned: [NEW] 3dwm (#206870), orphaned 5 days ago Description: libzorn development files Reverse Depends: 3dwm-pickclient 3dwm-texclient 3dwm-csgclient libcelsius-dev libpolhem-dev libgarbo-dev libnobel-dev 3dwm-vncclient libsolid-dev 3dwm-clock 3dwm-server libzorn-dev 3dwm-geoclient [NEW] autotrace (#206859), orphaned 5 days ago Description: Bitmap to vector graphics converter Reverse Depends: mftrace libautotrace-dev autotrace [NEW] cint (#207713), orphaned today Description: A C/C++ interpreter Reverse Depends: ginaccint [NEW] dbd-xbase (#206878), orphaned 5 days ago Description: Perl module to access xbase files (optionally through DBI). [NEW] jitterbug (#206880), orphaned 5 days ago Description: A cgi-bin tool for problem reporting and tracking [NEW] labelnation (#206857), orphaned 5 days ago Description: A command-line label-printing program [NEW] libcorba-orbit-perl (#206879), orphaned 5 days ago Description: ORBit module for Perl Reverse Depends: libgnome-gnorba-perl [NEW] libglade (#206886), orphaned 5 days ago Description: Development files for libglade. Reverse Depends: illuminator-demo gnome-find gabber oregano gnucash-hbci libglade-gnome0-dev libpong0 python-gnome libglade-ruby gnucash libgal23 guikachu r-gnome gmail drgenius libglade-bonobo0-dev libglade-gnome0 gfax libgtkada1-dev guppi-gnumeric gtkhtml gnotepad+ yank pong ogle-gui multi-gnome-terminal bins ghemical libgladexml-perl encompass gnomesword xemacs21-gnome-mule gnobog gpredict peacock libpong-common lodju pike7.2-gtk visualos php-gtk zapping mdk libglade-bonobo0 glame liblablgtk-ocaml pike7.4-gtk libglade0-dev multisync xemacs21-gnome-mule-canna-wnn libguppi-dev xsitecopy gnome-chess libpong-dev gco gdkxft-capplet python-glade libgtkada1-glade libgtkhtml20 xemacs21-gnome-nomule gnomp3 gnuvd-gnome stars exult-studio garchiver [NEW] libgnome-gnorba-perl (#206882), orphaned 5 days ago Description: Gnorba module for Perl [NEW] libgtk-perl (#206885), orphaned 5 days ago Description: Perl module for the libgtkxmhtml library. Reverse Depends: libgtkglarea-perl libgtk-imlib-perl libgladexml-perl bloksi bastille pronto pcsc-tools hamsoft libgnome-print-perl libgtkxmhtml-perl glade-perl gutenbook gtkgrepmail greenwich libglade-perl iceconf dmbt dfontmgr libgnome-perl gimp-perl libgtk-pixbuf-perl bins [NEW] libjttui-ruby (#206718), orphaned 6 days ago [NEW] libopengl-perl (#206883), orphaned 5 days ago Description: Perl module to display 3D data using OpenGL, GLU, GLUT, and GLX [NEW] meshio (#206871), orphaned 5 days ago Description: MeshIO is a simple C++ library for the loading of 3D model files Reverse Depends: libmeshio-dev 3dwm-geoclient [NEW] pymbus (#206866), orphaned 5 days ago Description: bus messaging for application comunication [NEW] python-happydoc (#206862), orphaned 5 days ago Description: Python Documentation Extraction Tool Documentation [NEW] python-pmw (#206861), orphaned 5 days ago Description: Pmw -- Python MegaWidgets Reverse Depends: mc-foo ptkei forg pymol [NEW] wordinspect (#206889), orphaned 5 days ago Description: GTK-based Dictionary Client [NEW] wp2x (#206860), orphaned 5 days ago Description: WordPerfect 5.x to whatever converter [NEW] xpa (#206869), orphaned 5 days ago Description: Documentation for xpa [NEW] xtend (#207154), orphaned 3 days ago Description: xtend - X10 status monitoring daemon Pente (#195686), orphaned 88 days ago Description: Five in a row game for X and the console addressbook (#174699), orphaned 241 days ago Description: Tk personal address manager amiwm (#206021), orphaned 10 days ago (non-free) Description: The Amiga look-alike window manager animals (#202174), orphaned 39 days ago Description: Traditional AI animal guessing engine using a binary tree DB Reverse Depends: junior-games-text arpd (#191870), orphaned 116 days ago Description: User-space ARP daemon aseqview (#201357), orphaned 44 days ago Description: ALSA Sequencer Event Viewer asis (#154095), orphaned 400 days ago Description: Ada Semantic Interface Specification Reverse Depends: gch asis-programs libasis-3.14p-1-dev awesfx (#199241), orphaned 60 days ago Description:
[RESULTS] SURVEY: Is the GNU FDL a DFSG-free license?
A little over one week ago, I posted a survey[1] to the debian-legal mailing list, requesting the opinion of subscribers regarding one of a pair of related questions that have been asked with increasing frequency on that list, and in a few other forums around the Internet. Does the GNU Free Documentation License, in its current form, satisfy the Debian Free Software Guidelines? My survey included four possible answers to this question; they included three answers that represented points of view that I have seen on the debian-legal mailing list as the GNU FDL has been discussed over the past two years, and a fourth option was included so that people whose opinions were not represented could indicate their dissatisfaction with the alternatives. The four possible answers were: 1 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. 2 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. 3 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. 4 None of the above statements approximates my opinion. The above answers can be crudely summarized as no, yes, sometimes, and none of the above. I also asked each respondent to indicate whether he was a Debian Developer as described in the Debian Constitution as of the date of the survey, and asked that people who so indicated GPG-sign their replies so that I could verify this claim. I originally neglected to announce when I would be tabulating results, so I rectified that defect on 24 August[2], indicating that I'd close the polls at Thursday, 28 August, 0500 UTC. By that time, 63 responses had been received. Of course, since the responses are public, people can continue to reply, and anyone may independently keep track of the survey's future progress. Here are the results of the survey. possible non- developers developers developers - option 1 (no) 18 3 22 option 2 (yes) 1 0 1 option 3 (sometimes) 8 4 4 option 4 (none of the above) 1 0 1 Possible developers are people who claimed to be Debian Developers but did not have a well-formed GPG signature on their responses, so I was unable to verify their claims. More information about these responses is MIME-attached. Possibly the most satisfying result for me personally is that so few people selected option 4; I can have at least some hope that my survey was not defective. A recurring theme (the other of the related questions I mentioned above) throughout recent discussions of the GNU FDL on the -legal mailing list have been vigorous challenges to the notion that we, the Debian Project, should bother to apply the Debian Free Software Guidelines to documentation at all. Advocates of this position frequently note that clause one of the Debian Social Contract[3] refers to software, not documentation. These advocates also just as frequently fail to indicate what alternative guidelines, if any, should be used for evaluating licenses on works in the Debian GNU/Linux Distribution that are not software. Bruce Perens, the primary author of the Debian Social Contract and Debian Free Software Guidelines, indicated in a recent message that he intended for the entire contents of that CD to be under the rights stated in the DFSG - be they software, documentation, or data. In my opinion, and in the opinion of several other people on the debian-legal mailing list, if we are to deviate from the understanding that everything in Debian main (apart from legal notices that we are required to include where applicable) must satisfy the DFSG, then we, as a Project, must draft a General Resolution to alter the Social Contract and say
Re: Fusionner mes modifs a la nouvelle version du paquet
Raphael Hertzog [EMAIL PROTECTED] a écrit : | Le Thu, Aug 28, 2003 at 11:29:12PM -0400, Daniel Déchelotte écrivait: | et j'aimerais maintenant profiter des corrections de la 0.80.1-8. | Quelle est la procedure a suivre pour, evidemment, ne pas perdre mes | bidouilles ? | | S'assurer qu'on les réapplique ? Evidemment, certains ne seront plus | nécessaires et d'autres le seront. A toi de faire le tri dans | debian/patches des patchs qui sont encore nécessaires ... (et à modifier | la variable correspondante dans debian/rules) Attends, j'ai pas de diff pour mes modifications : j'ai sauvagement modifie les fichiers sources (ca m'a paru normal sur le coup :-p). OK, la je realise que je suis loin du compte. Je vais me refaire une lecture de la dev-reference et du maint-guide, pour voir si ca aide :( [snip du reste, je vais *vraiment* me taper la lecture de la doc] Quand meme : comment je suis sense modifier les sources ? Directement, ou dans une seconde arborescence, de sorte a pouvoir generer un (gros) diff a mettre dans debian/patches a chaque fois que je veux compiler ? Daniel -- http://yo.dan.free.fr/
Fusionner mes modifs a la nouvelle version du paquet
Bonjour, J'ai commence a modifier wmaker lorsqu'il en etait a la version 0.80.1-6, et j'aimerais maintenant profiter des corrections de la 0.80.1-8. Quelle est la procedure a suivre pour, evidemment, ne pas perdre mes bidouilles ? Questions connexes : si je veux faire une copie de sauvegarde de mon travail, le fichier paquet_version.diff est-il suffisant ? Comment le generer ? Et quand au juste sont appliques les patches de debian/patches/* ? Je realise que ca fait pas mal de questions ; j'ai peut-etre mal lu mais les reponses ne semblent pas etre dans la _Référence_du_développeur_ _Debian_ ni dans man dpkg-*. Enfin j'espere ;-) Daniel -- http://yo.dan.free.fr/
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 08:59:04PM -0700, Joshua Kwan wrote: On Fri, Aug 29, 2003 at 01:51:58PM +1000, Russell Coker wrote: It's a bit extreme but I'm sick of deleting such messages, especially in light of the Blaster worm. Not extreme at all. I imagine there are some legitimate people I might receive emails from, reply to them and never know it didn't get sent. That's my only problem with this approach, although it would be possible to tell procmail to stick C-R responses into some special folder... Do you *really* want to converse with people so clue-adverse that they don't whitelist people they send mail to? I don't think I'd want to. Might catch some of that stupidity. Lord knows I suffer enough already. - Matt
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Because users that submitted bugs using the Debian BTS do not deserve the right to get a mail meaningful about the bug they reported? The bug has been fixed is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, the bug has been fixed. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Friday 29 August 2003 09:28, Steve Lamb wrote: On Fri, 29 Aug 2003 00:36:57 -0700 Adam McKenna [EMAIL PROTECTED] wrote: Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. exacerbate is probably what you meant here. ben
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Adam Heath [EMAIL PROTECTED] wrote:
On Wed, 27 Aug 2003, Ean R. Schuessler wrote:
-BEGIN PGP SIGNED MESSAGE-
Format: 1.7
Date: Wed, 27 Aug 2003 17:18:37 -0500
Source: kaffe
Binary: kaffe
Architecture: source i386
Version: 1:1.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Ean R. Schuessler [EMAIL PROTECTED]
Changed-By: Ean R. Schuessler [EMAIL PROTECTED]
Description:
kaffe - A JVM to run Java bytecode
Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021
170059 193263 196254 196867 197617 200434 202779
Changes:
kaffe (1:1.1.1-1) unstable; urgency=low
.
* New upstream release closes many bugs. (Closes: #51230, #61264,
#75800, #77869, #116802, #141597, #158743, #170021, #170059,
#193263, #196254, #197617, #202779, #81389, #200434, #196867)
* /usr/lib/jni is now checked for JNI libraries. (Closes: #167936)
This is not a proper changelog entry.
A proper entry is as follows:
* New upstream release.
* no longer does foo when bar happens. Closes: #12345
* wrapper script rewritten to not use $$ in tempfile names. Closes: #12345
Please, everyone remember, a changelog documents *changes*. It's not a tool
to close bugs automatically.
This is bullshit.
We've gone through this many times already. Upstream changes should
not be documented in the Debian changelog, even if they fix bugs in
the Debian BTS.
If I were the maintainer of this package, I would close these bugs again.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: looking for nco maintainer Brain Mays
On Wed, Aug 27, 2003 at 08:25:30PM -0400, Brian Mays wrote: Thus, the situation is as follows. If someone can point me to an new upstream source that is fairly similar to the source in the current Debian package, then I can incorporate these changes into Debian in a very short time. If, however, the upstream source contains significant improvements to the way the software is built (i.e., it has extensive changes), then don't expect anything from me before the middle of September. Why not ask for help and/or co-maint? We are going into mainstream towards sarge releasing, so you couldn't have sufficient time for usual release-test cycle of a new upstream release. -- Francesco P. Lovergine
Re: source code on sh4
On Friday 29 August 2003 10:29, wrote: debian-develHi Where can I find the source code on sh4 for Debian linux http://www.m17n.org/linux-sh/debian/ and go from there. greetings -- vbi -- Sterility is inherited. If your parents never had kids, odds are you wont either. -- William R. James in news.admin.net-abuse.email pgp04io0V5TgU.pgp Description: signature
GDM in sid does not read /etc/environment anymore
I upgraded sid two days ago, and starting X via gdm does not set the environment variable I've set in /etc/environment. Anyone has the same problem ..? -- Fabio Rafael da Rosa - f 2 r [EMAIL PROTECTED] Debian- http://debian.org Debian-BR - http://debian-br.org Debian-SP - http://sp.debian-br.org Let the programmers be many and the managers few then all will be productive.
Re: GDM in sid does not read /etc/environment anymore
[Fabio Rafael da Rosa] I upgraded sid two days ago, and starting X via gdm does not set the environment variable I've set in /etc/environment. Anyone has the same problem ..? It is probably a PAM configuration problem. You need the following line in the /etc/pam.d/ file used by gdm: auth required pam_env.so For kdm in Woody, the file is called 'kde'. I'm not sure which file gdm is using.
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 16:31:59 + benfoley [EMAIL PROTECTED] wrote: On Friday 29 August 2003 09:28, Steve Lamb wrote: Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. exacerbate is probably what you meant here. Quite so. 1:30am emails before the requisite round of CS to wake-up are prone to errors, no? -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgpMC75FKYQ9o.pgp Description: PGP signature
Re: MEI Whitelist Autoresponse
on Fri, Aug 29, 2003 at 09:20:53AM +1000, Russell Coker ([EMAIL PROTECTED]) wrote: On Fri, 29 Aug 2003 07:55, Adam McKenna wrote: My own inbox supports this statement. 140 responses to Sobig.F mails, of which 43 are virus or other content-based autoresponders, and 97 being delivery failure messages or other autoresponders (e.g.: ISP help desk). How many were challenges from mailing list software? Yes, another class of software that automatically issues challenges (specifically, to new subscriptions and to non-list members if the list is closed). So I guess you should also file bugs against majordomo, mailman, ezmlm-src, and any other mailing list managers that do this. The comparison to mailing list software makes no sense. I am prepared to put up with majordomo or mailman responses to virus messages because it's for the greater good. Having a single unwanted message go to me is much better than having that message being sent out to each of the 10,000 people on a big mailing list! For challenge-response systems it's totally different. I don't want to receive a single message because a lazy asshole wants to push all his problems on other people. People who take the attitude of Sobig wasn't a problem, my machine just sent out 4000 challenge messages to random victims can only be described as lazy assholes. Karsten M. Self repeats the preceding allegations of the Complaint as if set forth here in full[1]. Mailing lists are a rather small subset of all mail recipients, though they may be overrepresented in address lists harvested by spammers. In addition, however, list software _should_ filter virus and spam mail prior to sending a your message to foo list awaits moderation. Peace. Notes: 1. Someone has been sending too much time reading legal docs. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? SCO vs IBM Linux lawsuit info: http://sco.iwethey.org pgp79zv54k5Uj.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton [EMAIL PROTECTED] wrote: On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Because users that submitted bugs using the Debian BTS do not deserve the right to get a mail meaningful about the bug they reported? The bug has been fixed is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, I do. --Nikolaus
Re: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 09:20:49PM +0100, Karsten M. Self wrote: The virus responses are irresponsible, and have been for almost two years as the number of sender-spoofing emails has grown. BTW, amavisd-new has # Treat envelope sender address as unreliable and don't send sender # notification / bounces if name(s) of detected virus(es) match the list. # Note that virus names are supplied by external virus scanner(s) and are # not standardized, so virus names may need to be adjusted. # See README.lookups for syntax. # $viruses_that_fake_sender_re = new_RE( qr'nimda|hybris|klez|bugbear|yaha|braid|sobig|fizzer|palyh|peido|holar'i ); -- 2. That which causes joy or happiness.
Olivia Erickson is out of the office.
I will be out of the office starting 08/28/2003 and will not return until 09/02/2003. I will respond to your message when I return.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Herbert Xu [EMAIL PROTECTED] a tapoté : Adam Heath [EMAIL PROTECTED] wrote: On Wed, 27 Aug 2003, Ean R. Schuessler wrote: -BEGIN PGP SIGNED MESSAGE- Format: 1.7 Date: Wed, 27 Aug 2003 17:18:37 -0500 Source: kaffe Binary: kaffe Architecture: source i386 Version: 1:1.1.1-1 Distribution: unstable Urgency: low Maintainer: Ean R. Schuessler [EMAIL PROTECTED] Changed-By: Ean R. Schuessler [EMAIL PROTECTED] Description: kaffe - A JVM to run Java bytecode Closes: 51230 61264 75800 77869 81389 116802 141597 158743 167936 170021 170059 193263 196254 196867 197617 200434 202779 Changes: kaffe (1:1.1.1-1) unstable; urgency=low . * New upstream release closes many bugs. (Closes: #51230, #61264, #75800, #77869, #116802, #141597, #158743, #170021, #170059, #193263, #196254, #197617, #202779, #81389, #200434, #196867) * /usr/lib/jni is now checked for JNI libraries. (Closes: #167936) This is not a proper changelog entry. A proper entry is as follows: * New upstream release. * no longer does foo when bar happens. Closes: #12345 * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 Please, everyone remember, a changelog documents *changes*. It's not a tool to close bugs automatically. This is bullshit. We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Because users that submitted bugs using the Debian BTS do not deserve the right to get a mail meaningful about the bug they reported? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: MEI Whitelist Autoresponse
On Fri, 29 Aug 2003 07:55, Adam McKenna wrote: My own inbox supports this statement. 140 responses to Sobig.F mails, of which 43 are virus or other content-based autoresponders, and 97 being delivery failure messages or other autoresponders (e.g.: ISP help desk). How many were challenges from mailing list software? Yes, another class of software that automatically issues challenges (specifically, to new subscriptions and to non-list members if the list is closed). So I guess you should also file bugs against majordomo, mailman, ezmlm-src, and any other mailing list managers that do this. The comparison to mailing list software makes no sense. I am prepared to put up with majordomo or mailman responses to virus messages because it's for the greater good. Having a single unwanted message go to me is much better than having that message being sent out to each of the 10,000 people on a big mailing list! For challenge-response systems it's totally different. I don't want to receive a single message because a lazy asshole wants to push all his problems on other people. People who take the attitude of Sobig wasn't a problem, my machine just sent out 4000 challenge messages to random victims can only be described as lazy assholes. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
* Adam McKenna #0, #1, #2 and #11 are basically opinion and rhetoric. Well. Let's take a look at what Karsten had to say about point #2, Misplaced burden: [...] «C-R may place the burden on third parties either inadvertently (via spoofed sender spam or virus mail), or deliberately (see Joe-job below).» [...] You dismiss this as basically opinion and rhetoric. Yet, I see a unsolicited junk mail from you, yes - *you* Adam, in my mailbox. I'd be very interested in hearing how that could've been a result of 'opinion and rhetoric', so please, let me know. Earlier, you've stated that your time is precious. Well, so is mine. How dare you assume that the time I spent reviewing *your* callenge mail and deciding it was junk is less precious than the time you (could have) spent reviewing the mail that spurred the challenge in the first place? I admit my first email was written in hot blood, but if TMDA actually endorses this selfish behaviour, I still feel it is something that do not belong in Debian. On the other hand, if the junk mail in my inbox was a result of a misconfiguration on your part, then I'm sorry for yelling so loud. Errare humanum est. -- Tore Anderson
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Herbert Xu wrote: This is bullshit. We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Fine. Then don't close them with the Debian changelog at all; instead, use [EMAIL PROTECTED], with an explanation that it is fixed in such-and-such a version. The changelog bug closing facility is only a convenience.
Re: MEI Whitelist Autoresponse
On Fri, Aug 29, 2003 at 11:37:57AM +1000, Russell Coker wrote: If someone is to Joe-Job me then I'd rather that mailing lists bounce the messages, if it gets bad I could filter out all mailing list messages temporarily. Hmm, how about giving tmda its own special header so we can auto-filter out messages from people who use C-R systems? It's a bit extreme but I'm sick of deleting such messages, especially in light of the Blaster worm. -- Joshua Kwan pgp5YUHB41QSw.pgp Description: PGP signature
Re: MEI Whitelist Autoresponse
On Fri, 29 Aug 2003 09:47, Adam McKenna wrote: On Fri, Aug 29, 2003 at 09:20:53AM +1000, Russell Coker wrote: The comparison to mailing list software makes no sense. Maybe not in the context of viruses, but for the Joe Job problem it does. If someone is to Joe-Job me then I'd rather that mailing lists bounce the messages, if it gets bad I could filter out all mailing list messages temporarily. If someone Joe-Jobbing me results in messages from me getting delivered to mailing lists then that would be worse than having the lists bounce them IMHO (before you ask, I've been Joe-Jobbed before). When someone else gets Joe-Jobbed I'd rather deal with the spam using DNSBL and spam-assasin to protect myself. For spam that gets through that I would rather just report it to SpamCop myself than add to the problems of the poor sod who's being Joe-Jobbed. Viruses can and should be filtered out before they reach the C-R system. True, that's one of the things that should be in large warnings on any C-R system in Debian. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
* GOTO Masanori ([EMAIL PROTECTED]) [030829 11:05]: I may need to explain the status glibc: [...] The current version is 2.3.2-4. We're working for fixing bugs, some bugs were resolved. Sorry, I didn't want to step on your feet. I know that glibc is a nasty beast, and you're really good at handling it. glibc was just an example that a base package might be broken for some time when there are major updates; one just can't prevent that (otherwise we won't need unstable, testing and stable and a freeze phase). Only - that this hinders binary compatibility between the different releases. To the glibc-team: Keep up your good work. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: On packages depending on up-to-date data (was Re: Snort: Mass Bug Closing)
Quoting Javier Fernández-Sanguino Peña ([EMAIL PROTECTED]): [Short version: see the patch below.] (after a few days w/o answers from Snort's maintainer) Sander, any comments wrt to this patch? Please at least say wether you are going to forward this to Snort maintainers or use it in order to not break snort packages on upgrades. Thanks for that patch. I'm forwarding it to snort-devel. I hope they'll implement it. I wasn't planning on using it to patch debian released snorts, really. Sander. -- | Visitors always give pleasure: if not on arrival, then on the departure. | 1024D/08CEC94D - 34B3 3314 B146 E13C 70C8 9BDB D463 7E41 08CE C94D pgpsxazqDS3d6.pgp Description: PGP signature
Re: GDM in sid does not read /etc/environment anymore
On Fri, Aug 29, 2003 at 05:01:54PM +0200, Petter Reinholdtsen wrote: [Fabio Rafael da Rosa] I upgraded sid two days ago, and starting X via gdm does not set the environment variable I've set in /etc/environment. Anyone has the same problem ..? It is probably a PAM configuration problem. You need the following line in the /etc/pam.d/ file used by gdm: Not really, I believe it's bug #133578 and #147091 and #192143. Feel free to pester the maintainer, let's hope this gets fixed (i.e. before sarge gets frozen) Regards Javi pgp5JZLSYL0pG.pgp Description: PGP signature
MAIL FOLDER INBOX - IMOBILIARE CLOSED DUE TO ACCESS ERROR
I do receive a lot of messages and use pine's filtering features to sort them out to different folders. The same thing happened with folder IMOBILIARE. I have sorted there some messages after i've readed them. After i renamed the folder from Imobiliare to IMOBILIARE no one folder's open enymore.Each time i try to acces Folders (trash, sent etc) it rites me: ERROR: Could not complete request. Query: EXAMINE INBOX IMOBILIARE Reasone Given: Invalid Mailbox What should i do now? Please give me an advice. --- WWW.COM - Where The Web Begins! http://www.www.com/
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 02:46:48AM +0200, Tore Anderson wrote: Earlier, you've stated that your time is precious. Well, so is mine. How dare you assume that the time I spent reviewing *your* callenge mail and deciding it was junk is less precious than the time you (could have) spent reviewing the mail that spurred the challenge in the first place? I admit my first email was written in hot blood, but if TMDA actually endorses this selfish behaviour, I still feel it is something that do not belong in Debian. On the other hand, if the junk mail in my inbox was a result of a misconfiguration on your part, then I'm sorry for yelling so loud. Errare humanum est. I've already stated that I've modified my incoming mail filters so that these viruses will no longer hit TMDA. I feel bad that others were affected due to my misconfiguration, but it was user error (or laziness in this case) that caused this, not a fundamental problem with the software. When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 00:36:57 -0700 Adam McKenna [EMAIL PROTECTED] wrote: Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. Oddly enough Spamassassin doesn't exasperate the problem. TDMA does. -- Steve C. Lamb | I'm your priest, I'm your shrink, I'm your PGP Key: 8B6E99C5 | main connection to the switchboard of souls. ---+- pgp81Uf26k2Ll.pgp Description: PGP signature
Re: Details
hello, Can't reply to your mail at the moment, I will reply as soon when possible. If you didn't send a message, please control your pc for virusses. greetings christophe
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton [EMAIL PROTECTED] a tapoté : The bug has been fixed is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, the bug has been fixed. On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: This approach surely don't raise the level of Debian. Maybe *you* do not care of the details about the bug you reported. But a Debian developer is entitled, normally, to provide information according to what *users* can expect. On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: I do. If you want to see every change which was made to the source, read the upstream Changelog. If you want to see Debian packaging changes, read the Debian Changelog. It's simple really. :) The debian changelog have the wonderful advantage to be sent by mail when a bug is closed. This person do not want to see every change which was made to the source neither do her want to see Debian packaging changes but want to see the change about the submitted bug. To get that information in the mail sent, the only solution would be to have it included in the debian changelog. There's at least one other solution: what if, when a bug tagged upstream was closed, the mail sent would include the upstream ChangeLog (hopefully named ChangeLog in the top directory of the package)? Can someone familiar with the BTS code tell whether this change is trivial or not? -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 04:31:59PM +, benfoley wrote:
On Friday 29 August 2003 09:28, Steve Lamb wrote:
On Fri, 29 Aug 2003 00:36:57 -0700
Adam McKenna [EMAIL PROTECTED] wrote:
Well, since we're pointing fingers, it's really SMTP that's broken by
design, and all anti-spam programs (including C-R systems) are merely
stopgap measures that try to make up for SMTP's shortcomings.
Oddly enough Spamassassin doesn't exasperate the problem. TDMA does.
exacerbate is probably what you meant here.
Actually, I think exasperate is perfectly valid as well.
From WordNet (r) 1.7 [wn]:
exasperate
v 1: exasperate or irritate [syn: {exacerbate}, {aggravate}]
2: make furious [syn: {outrage}, {infuriate}, {incense}]
3: make worse; This drug aggravates the pain [syn: {worsen},
{aggravate}, {exacerbate}] [ant: {better}]
- Keegan
pgpkdhOOQymzr.pgp
Description: PGP signature
Re: NEED HELP: Making woody LSB compliant
Martin Schulze wrote: Updated alien The alien changes have been in testing and unstable for a similar amount of time. Unfortunately I can't find the source for the above packages. ...? Context error. I also remember some talk about start-stop-daemon having to be altered. What about this one? Task: Review and discuss the changes against original packages The relevant differences in alien are those made in revisions 8.15, 8.16, 8.17, and 8.20. All of these have to do with handling of user, groups, and permissions in files in the converted packages. None of thsse are strictly necessary for LSB compliance, they're all just bug fixes for corner cases that some lsb packages could possibly trigger. One lsb package that happens to trigger some of them is the lsb test suite rpm. -- see shy jo pgpL3OacHtPfO.pgp Description: PGP signature
Bug#207709: ITP: module-assistant -- helper script to automate kernel module building
Package: wnpp Version: unavailable; reported 2003-08-28 Severity: wishlist * Package name: module-assistant Version : 0.1 (currently beeing written) Upstream Author : myself, nativ package * URL : http://modass.alioth.debian.org (when it has been approved) * License : LGPL Description : helper script to automate kernel module building Here the current usage info and rationale, package description will be done when the most functionality is there: # # Script to assist users with building of the kernel modules # First purpose: automate as much as possible for Joe User # Second purpose: have a database about the source of module packages # (and all steps needed to get it) # Third purpose: provide general debian/rules include snippets # USAGE: # autobuild name|all|dir-list [ alternatives headers dir, list ] # locate the right kernel source or headers directory and build the # given modules with them. Primary choice for most people. # # auto-install (ai) # like autobuild but also tries to install the created packages # # list-available (la), list-installed (li), list-everything (le) # get name|all|dir-list [ alternative headers dir, list ] # download (gets implies download) # update (update the lists, version numbers) # build name|all|dir-list [ alternatives headers dir, list ] # Lists are collon-separated Directory tree of the module-assistant How does the whole thing work? Every package that should be controlled with modass provides a maintainer script (see below) that accepts the following commands: update updates the intenal data when needed, eg. version number. Scripts can do whatever they want, any may use the /var/lib/modass/cache directory as playground for caching the data. version outputs the current version of the package; syntax == dpkg-style lastpkg outputs the filename (full path) of the last built package. Empty if the build was not successful. download installs the source package or fetches the source with apt-get/apt-src/whatever unpack unpacks the downloaded package source in $MODULE_LOC purge removes the working source directory and cached data purge-all like purge plus removes the binary packages built from the source Ressource directory (planned location: /usr/share/modass) modass |-- include (files to be sourced by package maintaining scripts and makefile includes) |-- overrides (package maintscripts taking precedence over the default ones) `-- packages(some default scripts, provided by the modass package itself) Package maintainence scripts are either shipped with module-assistant or installed by other binary package that have something to do with the modules. For example, cloop-utils installs one into modass/overrides/. Of course no module source package does support all this know. For this reason, I plan to import them all in a big SVN repository on alioth, having the Debian branch and Modified branch and working on them. All good things from their rules files will be extracted and merged into common rules which will become part of module-assistang (similar to the story of dbs and dpatch packages). Eduard. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.20-wolk4.6s #1 Mi Aug 6 11:42:42 CEST 2003 i686 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8
Anti-Virus software has detected a virus in a document you authored.
Please contact your system administrator. The infected file attachment in the scanned document was deleted. Virus Information: The attachment your_details.pif contained the virus [EMAIL PROTECTED] and was deleted.
$B!ZL$>5Bz9-9p![K\F|Cf$K(B100$BK|Kx(B
$B"#5^$0$"$J$?$N6/$$L#J}!*%"%$%(!<%+!<%I$N%b%P%$%k%-%c%C%7%s%0(B $B"#$*?=$79~$_$+$i?69~$_$^$G:GB.(B20$BJ,!#5^$J=PHq$G$*:$$j$NJ}92$F$kA0$K$^$:Ev
source code on sh4
debian-develHi Where can I find the source code on sh4 for Debian linux Best Regard! Cong Ming [EMAIL PROTECTED] 2003-08-29
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
on Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna ([EMAIL PROTECTED]) wrote: On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: #2, Misplaced burden, is the reason for the 'grave' severity. People have a right to ask that unkown people that e-mail them confirm the e-mail. I'm sorry you don't agree with this, but your opinion is hardly justification for a grave bug. People also have the responsibility to accept, personally, the responsibility for using, developing, and distributing systems which impose this burden on others. If you wish to undertake the distribution of TMDA yourself, with your own resources, you are free to do so. You may not demand the right to transfer these consequences on the Debian Project and SPI over the objections (if present) of the project at large. Determining the will of the Debian project is a purpose of this discussion. - TMDA should carry a warning to the user about possible consequences of activating the C-R mechanism, including sending spam, risking blacklisting or registration in spam-reduction services such as SpamCop, and a likelihood that some, and perhaps a majority of challenges will not be responded to. The warning should require the user to assume full responsibility for doing so. Sorry, but no. I will not do this. The user presumably knows what he is installing. The User demonstrably does not, in all, and possibly in most, circumstances. In my own cites of TMDA mailing list experiences, users have apparently spammed thousands of arbitrary addresses with C-R challenges, and have found their own systems listed by spam-prevention systems, with neither the user, nor the architect of TMDA realizing the significance and externalized costs of TMDA. Moreover, inclusion of debconf warning messages is *NOT* a responsibility of upstream, but of the Debian package maintainer. - Configuration templates for C-R challenges _must_ incorporate virus and spam filtering, _prior_ to issuing a C-R challenge. Preferably, tests against obvious header spoofing, if possible, should be performed. Debian tmda packages _must_ depend on corresponding spam and virus filters, if this functionality isn't built into TMDA. - Additional strong validation mechanisms, including RFC 2015 PGP signed mail and S/MIME signatures, _must_ be used to validate sender, including use of web of trust to identify a reasonable probability of trusted user status. - If possible, TMDA should be moved to SMTP-time filtering, so that mail rejection occurs at SMTP time. As SMTP doesn't offer a protocol for challenge-response, this introduces interesting challenges for TMDA's developers. - TMDA's performance _must_ be independently validated and the target maximum of 2% challenges to spoofed addresses be confirmed. I'm not going to pretend that these are easy fixes. I'm not a user of this package. I _am_ negatively impacted by it, however, and if it continues to display similarly poor consideration of security, abuse, and adverse side effects, I fear for Debian, SPI, and the generosity of our sponsors. I do feel the remedies are necessary and advised. They should be communicated upstream, naturally. I suggest you take these suggestions to the TMDA worker's mailing list at tmda.net, and file wishlist bugs against TMDA for each desired feature. For what reason can these suggestions not be accomplished (excepting SMTP-time filtering and independent validation) through providing a template which applies the proper processing order to a C-R challenge issuing change, and C-R issuance be disabled unless working AV, spamfilters, and signature validation SW are installed? Seems to me upstream needn't be involved at all. Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What Part of Gestalt don't you understand? Sick of mal-formed websites? A stylesheet to override poor design: http://twiki.iwethey.org/Main/UserContentCSS pgpmcc4tXb539.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:41:54PM +0100, Mark Brown wrote: That doesn't help all that much - it's also important see why the bug has been closed. Because it is fixed... whatever it was I was trying to do when I generated the error rather than by fixing the error handling. it wont help you, if it says print a helpful error message. If you realy care that much, look up the patch. Gruss 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: MEI Whitelist Autoresponse
On Thu, Aug 28, 2003 at 09:20:49PM +0100, Karsten M. Self wrote: on Thu, Aug 28, 2003 at 01:03:37AM -0700, Adam McKenna ([EMAIL PROTECTED]) wrote: Also, I don't have any hard data to support this, but it's obvious to me that the volume of mail generated by virus scanners in response to Sobig.f eclipses the volume of TMDA challenges by at least a factor of 10. So far, I haven't received *one* TMDA challenge that was due to Sobig, but I've received *hundreds* of messages from virus scanners all over the net. So, I guess we should add virus scanners to the list of verboten software. My own inbox supports this statement. 140 responses to Sobig.F mails, of which 43 are virus or other content-based autoresponders, and 97 being delivery failure messages or other autoresponders (e.g.: ISP help desk). How many were challenges from mailing list software? Yes, another class of software that automatically issues challenges (specifically, to new subscriptions and to non-list members if the list is closed). So I guess you should also file bugs against majordomo, mailman, ezmlm-src, and any other mailing list managers that do this. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. Why not make your tmda package depend on amavis-new and clamav-freshclam? If they are installed and correctly configured then virus filters should get updated as fast as is possible. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
reassign 207300 humanity thanks On pe, 2003-08-29 at 10:36, Adam McKenna wrote: Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. The fact that SMTP now needs authentication and what not points at the real problem: there are greedy and evil people willing to exploit anything for their personal benefit. In the interest of fixing things once and for all, that flaw in humanity needs to be fixed. It is not enough to kill all greedy and evil people, since new ones will be born. I propose killing all humans and letting the planet be inherited by us Martians. On a more serious note, it would be interesting to have a thought experiment of how an e-mail system could be designed from scratch (no compatibility with SMTP needed). Debian-devel is not the forum for it, though. I develop and maintain one mailing list manager, and it will send confirmation requests for subscriptions, unsubscriptions, and messages that will wait for moderation. I'll make it so that it will avoid sending them if the message that triggered them looks too much like spam. At least that much good results from this thread. :) -- http://liw.iki.fi/liw/photos/swordmaiden/
Re: libraries being removed from the archive
On Tue, 05 Aug 2003 07:32:57 +0200, Matthias Urlichs wrote: Hi, Peter Mathiasson wrote: [...] distcc sends the complete preprocessed source code across the network for each job. Hmm, OK, but that would just speedup the actual compilation. Granted, that's the largest chunk, but cpp/asm/ld could do with a speed-up too. As a point of information, distcc runs the assembler remotely too (in this case, on the x86). cpp's CPU usage is usually negligible, and while ld can be slow it is often a small fraction of the total time. Building a cross suite with the excellent Debian toolchain-source package is easy, and I regularly use that to have several x86 machines help with ia64 builds. For many packages the biggest problem is actually ./configure, since it is slow and not parallelizable. -- Martin
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Thu, Aug 28, 2003 at 08:21:22AM -0700, Adam McKenna wrote: On Thu, Aug 28, 2003 at 12:35:25PM +0100, Karsten M. Self wrote: #2, Misplaced burden, is the reason for the 'grave' severity. People have a right to ask that unkown people that e-mail them confirm the e-mail. the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. such software is too brain-damaged to use. there is more than enough spam, viruses and other garbage clogging SMTP servers around the world without making things worse by using programs which falsely claim to be part of the solution. junk like this does not solve the problem, it is not part of the solution - it just amplifies the original problem: every virus or spam with forged headers results in even more confirmation and/or notification messages being sent in response. in short, it is automated spamware that contributes to denial of service attacks. craig
debian-devel@lists.debian.org
TEL13311210700 010-85762212 E-mail : [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 12:12:58PM +1000, Russell Coker wrote: On Fri, 29 Aug 2003 11:16, Adam McKenna wrote: When the next address-spoofing virus hits, if I need to update my filters again, I'll make a better effort to do it ASAP instead of letting it go for several days. Why not make your tmda package depend on amavis-new and clamav-freshclam? If they are installed and correctly configured then virus filters should get updated as fast as is possible. Does Amavis automatically configure itself for whatever MTA is installed and start scanning mail immediately? If not, then I don't see how a Depends: would help. I would consider adding a Suggests: or Recommends:. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
Ross Burton [EMAIL PROTECTED] a tapoté : On Fri, 2003-08-29 at 14:18, Mathieu Roy wrote: We've gone through this many times already. Upstream changes should not be documented in the Debian changelog, even if they fix bugs in the Debian BTS. Because users that submitted bugs using the Debian BTS do not deserve the right to get a mail meaningful about the bug they reported? The bug has been fixed is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, the bug has been fixed. This approach surely don't raise the level of Debian. Maybe *you* do not care of the details about the bug you reported. But a Debian developer is entitled, normally, to provide information according to what *users* can expect. We are not here speaking about what some people do not care about but what some debian users do care about and how they can be easily satisfied. The fact that frequently we have to talk about that proves at least one thing: some users do care about details of the bugs and expect to get them in the changelog they receive by mails. If as debian developer you do care about what some *users* wants, the safest solution is to provide this information. It should takes you about 3 minutes to document these bugfixes. It is too much? Regards, -- Mathieu Roy Homepage: http://yeupou.coleumes.org Not a native english speaker: http://stock.coleumes.org/doc.php?i=/misc-files/flawed-english
debian-devel@lists.debian.org
µã»÷ http://hengingv.533.net ½Ì¸øÄúÈçºÎÀûÓÃÍøÂç׬Ǯ
dpkg -- overwrite empty directories?
Hello, I have a package that Replaces: another package. The former package stored files in a particular directory (/usr/lib/foo); when the package is removed, it leaves that directory behind, empty. The new package has a symlink at that location, instead of a directory. dpkg, however, does not replace the directory with the symlink. Hence, I have to specifically check for this situation in maintainer scripts, and remove the empty directory if it exists. Am I way off base here, or would it be robust behavior for dpkg to replace empty directories with symlinks, files, whatever, if the empty directory is not claimed by a currently installed package? It could be argued that the package that left the empty directory behind is broken, so I'm looking for circumstances in which my proposed behavior would present a problem. Perhaps a warning would also be a good idea, so that the replacement package doesn't silently fail when a directory was attempted to be overwritten. -- Ryan Underwood, nemesis at icequake.net, icq=10317253
Re: glibc 2.3.2 and testing
On Fri, Aug 29, 2003 at 05:46:54PM +0200, Mike Dornberger wrote: I'd like to know, why all recently updated and new packages in testing have a dependancy on glibc = 2.3.2? Wouldn't it be enough if they depend just on glibc? Binaries built against glibc 2.3.2 really do depend on glibc 2.3.2 [1]. They may not if built against glibc 2.3.1, but that's a different matter. [1] Well, they may depend on glibc 2.3.2, at least. We don't have the infrastructure yet to pick apart symbol versioning in order to say for sure, but in the absence of that it's better to be conservative. On my system 'objdump -p /bin/cat' shows that cat requires glibc 2.3, so glibc alone is certainly not adequate. BTW: Why are all those packages going into testing if they are uninstallable? I'm afraid you're mistaken. I've just checked, and there are no packages currently in testing that depend on glibc 2.3.2. You must actually be using unstable. Cheers, -- Colin Watson [EMAIL PROTECTED]
Bug#207791: ITP: ITP: libdata-formvalidator-perl -- Library for easily validating user input, mainly for HTML
Package: wnpp Version: unavailable; reported 2003-08-29 Severity: wishlist * Package name: ITP: libdata-formvalidator-perl Version : 3.12 Upstream Author : Mark Stosberg [EMAIL PROTECTED] * URL : http://www.cpan.org/modules/by-module/Data/ * License : GPL + Artistic Description : Library for easily validating user input, mainly for HTML Provides a clean interface to present the user with template-generated forms, which will be later automatically validated, in a very easy to use and understand fashion. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux jerx 2.4.21-gwolf #1 Fri Jun 27 13:04:09 CDT 2003 i686 Locale: LANG=en_US, LC_CTYPE=en_US -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Thu, Aug 28, 2003 at 10:05:21AM -0500, Adam Heath wrote: A proper entry is as follows: * New upstream release. * no longer does foo when bar happens. Closes: #12345 * wrapper script rewritten to not use $$ in tempfile names. Closes: #12345 Please, everyone remember, a changelog documents *changes*. It's not a tool to close bugs automatically. It documents which revision closed bug #12345. That's useful information for a changelog. It's certainly not worse than saying only new upstream revision and closing the bugs manually. The BTS sends these close messages to the submitter when the bug is closed. However, the email above has no reason as to why the bug was closed. It's not sufficient to just say a new upstream version was uploaded, which just happens to fix the bug. As a submitter, would you feel satisified that you had just gotten such a mail? Absolutely! I reported a bug, and the mail says that the bug I reported has been fixed. That's all I need to know. If I report segmentation fault in ls, I--as a user of ls, not a developer--couldn't care less about why it was segfaulting or how the bug was fixed; I only care that it's been fixed. If a developer wants to spend their limited time researching how the bug was fixed and summarizing it in a changelog, great, but it's certainly not something I'd expect everyone to do. (As a user, I'd certainly be rather annoyed at receiving duplicate close reports because someone reopened the bug for frivelous reasons, however. I get enough junk mail already.) -- Glenn Maynard
Re: GDM in sid does not read /etc/environment anymore
I've actually sent him an email but got no answer. I've posted in debian-devel few days ago and nobody complained that GDM could source /etc/environment in the init script. That's an one-line patch (already tagged as patch in bts for more than a year)... I think that if the maintainer doesn't take that, a NMU will be neecessary. Em Sex, 2003-08-29 às 14:33, Javier Fernández-Sanguino Peña escreveu: On Fri, Aug 29, 2003 at 05:01:54PM +0200, Petter Reinholdtsen wrote: [Fabio Rafael da Rosa] I upgraded sid two days ago, and starting X via gdm does not set the environment variable I've set in /etc/environment. Anyone has the same problem ..? It is probably a PAM configuration problem. You need the following line in the /etc/pam.d/ file used by gdm: Not really, I believe it's bug #133578 and #147091 and #192143. Feel free to pester the maintainer, let's hope this gets fixed (i.e. before sarge gets frozen) Regards Javi
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 08:48:13PM +0200, Mathieu Roy wrote: There's at least one other solution: what if, when a bug tagged upstream was closed, the mail sent would include the upstream ChangeLog (hopefully named ChangeLog in the top directory of the package)? Can someone familiar with the BTS code tell whether this change is trivial or not? It's not trivial in the slightest, sorry. The BTS doesn't remotely have this information available to it, and it's not even easy to arrange for it to be available. -- Colin Watson [EMAIL PROTECTED]
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
The bug has been fixed is everything I would need to know. I don't really care if it was a typo, a new library, a rebuild or some magic incantation with black dribbling candles, the bug has been fixed. On Fri, 2003-08-29 at 17:46, Mathieu Roy wrote: This approach surely don't raise the level of Debian. Maybe *you* do not care of the details about the bug you reported. But a Debian developer is entitled, normally, to provide information according to what *users* can expect. On Fri, 2003-08-29 at 16:12, Nikolaus Rath wrote: I do. If you want to see every change which was made to the source, read the upstream Changelog. If you want to see Debian packaging changes, read the Debian Changelog. It's simple really. :) Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
glibc 2.3.2 and testing
Hi, I'd like to know, why all recently updated and new packages in testing have a dependancy on glibc = 2.3.2? Wouldn't it be enough if they depend just on glibc? BTW: Why are all those packages going into testing if they are uninstallable? Regards, Mike Dornberger PS: Please Cc me, I'm not subscribed to dd.
Re: MEI Whitelist Autoresponse
On Fri, 29 Aug 2003 12:12, Joshua Kwan wrote: On Fri, Aug 29, 2003 at 11:37:57AM +1000, Russell Coker wrote: If someone is to Joe-Job me then I'd rather that mailing lists bounce the messages, if it gets bad I could filter out all mailing list messages temporarily. Hmm, how about giving tmda its own special header so we can auto-filter out messages from people who use C-R systems? Sounds like a good idea! Or even better don't make it a TMDA header make it a generic C-R header, I don't want a header check rule for every C-R system out there. It's a bit extreme but I'm sick of deleting such messages, especially in light of the Blaster worm. Not extreme at all. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: dpkg -- overwrite empty directories?
On Fri, 29 Aug 2003, Ryan Underwood wrote: Hello, I have a package that Replaces: another package. The former package stored files in a particular directory (/usr/lib/foo); when the package is removed, it leaves that directory behind, empty. The new package has a symlink at that location, instead of a directory. dpkg, however, does not replace the directory with the symlink. Hence, I have to specifically check for this situation in maintainer scripts, and remove the empty directory if it exists. Am I way off base here, or would it be robust behavior for dpkg to replace empty directories with symlinks, files, whatever, if the empty directory is not claimed by a currently installed package? It could be argued that the package that left the empty directory behind is broken, so I'm looking for circumstances in which my proposed behavior would present a problem. Nope. Check the dpkg bug list and policy. This is not a feature that will change. Hint: consider when an admin moves a dir to a new location, and places a symlink at the old location.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, 29 Aug 2003, Glenn Maynard wrote: If I report segmentation fault in ls, I--as a user of ls, not a developer--couldn't care less about why it was segfaulting or how the bug was fixed; I only care that it's been fixed. If a developer wants to spend their limited time researching how the bug was fixed and summarizing it in a changelog, great, but it's certainly not something I'd expect everyone to do. It's not about summarizing how the bug was fixed. It's about summarizing the bug *itself* in the changelog. The description of the bug is already available(as the title of the bug report). At the very least this should be placed in the debian changelog.
unsubscribe
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 29, 2003 2:08 AM Subject: debian-devel-digest Digest V2003 #1147
Re: DebToo: Debian, Gentoo-style
On Thu, Aug 28, 2003 at 09:16:04PM +1000, Brian May wrote: Of course there are downsides either way, but there is no dispute that the size of the Debian archive is huge, and mirrors are struggling to keep up as a result. Is this so? I havent seen reports in this area for a while. 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: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 09:31:29AM -0400, Joe Drew wrote: Fine. Then don't close them with the Debian changelog at all; instead, use [EMAIL PROTECTED], with an explanation that it is fixed in such-and-such a version. The changelog bug closing facility is only a convenience. I'm confused. We have three cases: 1. Close bug #12345 directly (12345-done), noting the version that fixed it. 2. Note in the changelog that bug #12345 is fixed; the bug receives a notification of the version that fixed it. 3. Note in the changelog that bug #12345, ls --crash crashes, is fixed; the bug receives a notification of the version that fixed it. #3 is obviously ideal, if the maintainer has time; no debate there. However, you're saying that #1 is preferable to #2. Why? It seems to have no disadvantage to #1, with the added advantages that I can check which version fixed bug #12345 without hitting the network (since it's documented in the changelog), and saves developer time. What am I missing? -- Glenn Maynard
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. Really? TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. Well, since we're pointing fingers, it's really SMTP that's broken by design, and all anti-spam programs (including C-R systems) are merely stopgap measures that try to make up for SMTP's shortcomings. --Adam -- Adam McKenna [EMAIL PROTECTED] [EMAIL PROTECTED]
MISC
Dear Candidate, Thank you for getting in touch with Prometric Auto Response System. We are in receipt of your e-mail. This e-mail contains the following I. KEY WORDS TO PUT IN THE SUBJECT FIELD OF YOUR E-MAIL TO US. In order to get a reply from us, you are required to put ONE of the relevant key words in the subject field of your e-mail to us. ** I. KEY WORDS TO BE PUT IN THE SUBJECT FIELD OF YOUR E-MAIL In order to get a reply from us, you are required to put ONE of the relevant key words in the subject field of your e-mail to us. FAILING THIS, WE WOULD BE UNABLE TO RESPOND TO YOU ANY FURTHER . KEY WORDS A. CONFIRMATION: All queries related to your exam date. Also queries on test date allocated to you. B. RESCHEDULE: Request FOR RESCHEDULING test date, queries regarding rescheduled test date allocated. Also for requests for CANCELLATION of test date, and queries regarding the same.. C. PAYMENT : All queries related to Credit card decline notice Credit Card not charged ASR Payments D. NAME :Queries related to candidate's name as it appears in the test registration E. TEST CENTER ADDRESS: F. SCORE REPORTS: In case you would like to get the answers to the most frequently asked questions by candidates, please write the name of the test ( GRE or GMAT or TOEFL) in your e-mail. * Candidate Services (India) Prometric , a part of the Thomson Corporation Senior Plaza 160 A Gautam Nagar Yusuf Sarai New Delhi 110049
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 04:34:58PM -0500, Adam Heath wrote: It's not about summarizing how the bug was fixed. It's about summarizing the bug *itself* in the changelog. The description of the bug is already available(as the title of the bug report). At the very least this should be placed in the debian changelog. How is this abusive? The maintainer is putting useful information in the changelog (the release a given bug was fixed), and closing the bug in the process. Not including a description of the bug seems no worse than not listing closed bugs in the changelog at all, and closing them all separately later on; I'm sure many maintainers without time to revisit lots of bugs after each upstream release do this. A script to convert eg. * New upstream release .* (Closes: #1, #2, #3) to * New upstream release \1 * fixed BTS summary line of #1 Closes: #1 * fixed BTS summary line of #2 Closes: #2 * fixed BTS summary line of #3 Closes: #3 in changelogs would probably go a lot further to correcting this very minor issue than reopening dozens of bug reports that belong closed, annoying users with BTS garbage, and repeating the same thread on debian-devel over and over. -- Glenn Maynard
Re: MEI Whitelist Autoresponse
On Fri, Aug 29, 2003 at 01:51:58PM +1000, Russell Coker wrote: It's a bit extreme but I'm sick of deleting such messages, especially in light of the Blaster worm. Not extreme at all. I imagine there are some legitimate people I might receive emails from, reply to them and never know it didn't get sent. That's my only problem with this approach, although it would be possible to tell procmail to stick C-R responses into some special folder... And once you have reached that point it's nearly as bad as not filtering them at all. Granted, lack of a reply is earned punishment for using a C-R system IMNSHO. -- Joshua Kwan pgpH4aEhJ3Y8L.pgp Description: PGP signature
Re: Sarge+1: ideas for Experimental V1.2 (or is that 0.2?)
At Thu, 28 Aug 2003 10:24:15 +0200, Andreas Barth wrote: Really? The latest glibc in sarge is from 2003-03-22, and there are currently 1103 packages waiting for glibc. I may need to explain the status glibc: 2003-03-22 glibc is 2.3.1-17. The next version of glibc is 2.3.2-2, which was uploaded in 2003-08-06. So, this block has kept from 2003-08-06. About 3 weeks. The reason I duploaded information at: http://lists.debian.org/debian-glibc/2003/debian-glibc-200308/msg00047.html The current version is 2.3.2-4. We're working for fixing bugs, some bugs were resolved. Regards, -- gotom
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 01:42:53AM +1000, Russell Coker wrote: PS Before someone raises the issue of license of viruses. I believe that anyone who distributes a virus does so with the desire that it be installed on as many systems as possible and that the implied license permits you to have a copy of it for whatever purposes you desire. People who wish to limit the use of their software in any way should make it refrain from installing itself on hundreds of thousands of machines without the consent of the owners. :-# ... but you don't always get the source code, this is required by the DFSG ;-). -- Brian May [EMAIL PROTECTED]
Re: Bug#207300: tmda: Challenge-response is fundamentally broken
On Fri, Aug 29, 2003 at 03:48:13PM +1000, Craig Sanders wrote: the point that you keep on missing is that TMDA and similar programs send confirmation emails to innocent third-parties who did *NOT* send an email. TMDA and all C-R systems are broken-by-design, just as many stupid end-user autoresponders and AV-scanners that send notifications back to the forged sender address are broken-by-design. You saying that any SMTP MTA that sends bounces to unauthenticated E-Mail addresses is also broken? That is the idea behind autorespoonders after all, to tell the sender that his mail didn't get through because it didn't meet some required criteria. The other option which many people seem to want is to discard the E-Mail without giving either party any indication of what happened. E-Mail that looks suspicious can be valid mail at times, for instance somebody I knew tried to send a ZIP file that happened to be executable via E-Mail. Do you simply discard such E-Mails (which gives no indication that something went wrong), or do you try to contact the sender to indicate that something went wrong? The problem is that I see no easy way to fix this problem to the large scale required on the Internet while keeping store-and-forward feature of SMTP. One approach for instance would be to modify the SMTP standard, and say if a host accepts the E-Mail then it is guaranteed to get it to the destination (ie. it signal OK until the message has been delivered), but that would break store-and-forward capabilities of secondary mail servers. Even encryption does not help here, or at least I have not seen any proposals for any system that could scale to the Internet. GPG for instance only verifies the sender to the receiver, it could not be used to verify every sender to the MTAs involved. -- Brian May [EMAIL PROTECTED]
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
I'm cc'ing PSG, maybe he'll be interested. * New upstream release .* (Closes: #1, #2, #3) to * New upstream release \1 * fixed BTS summary line of #1 Closes: #1 * fixed BTS summary line of #2 Closes: #2 * fixed BTS summary line of #3 Closes: #3 in changelogs would probably go a lot further to correcting this very minor issue than reopening dozens of bug reports that belong closed, annoying users with BTS garbage, and repeating the same thread on debian-devel over and over. Yes, that sounds pretty intesresting; an addition to debian-changelog-mode would be interesting. It should be possible to get bugs.debian.org/ and parse the resulting HTML for the title and the original submitter, and placing it. Some addition to debian-changelog-close-bug, possibly optional, that utilizes debian-bug-* (there's no debian-bug-to-buffer... hmm?) to parse the bugreport ? regards, junichi
debian archive disk space requirements.
Hi, I've noticed the growth in the debian archive with some concern over the last few weeks/months. We're now hitting the limit of the partition that debian is on and it will be quite difficult technically for us to deal with this in the short term. We have some new storage which is being comissioned but it won't be in place for about a month and the debian archive has already filled up a 100G partition we've dedicated to it here (that doesn't include the debian-cd or debian-non-US or other debian related archives.. just the main debian one). I'm stuck between a rock and a hard place here as we have a large dependency tree before we can move equipment over and get access to the new disk.. Is there any way to reduce the size of the archive over the next 4-6 weeks ? regards, -jason
Re: That movie
Your email to Crown International has been sent. You should receive a response within 1 business day. If you need a faster response, feel free to contact us Toll Free at 1-800-715-4227 during regular business hours. Thank You, James P. Cox President, Crown International
configure web proxy via DHCP server
Is this possible? It would be really cool(tm) if I didn't have to reconfigure every program on my laptop to use a different proxy server every time I plug it into a different network. Just venting my irritation for the day... -- Brian May [EMAIL PROTECTED]
Re: configure web proxy via DHCP server
On Sat, Aug 30, 2003 at 12:01:42PM +1000, Brian May wrote: Is this possible? It would be really cool(tm) if I didn't have to reconfigure every program on my laptop to use a different proxy server every time I plug it into a different network. Just venting my irritation for the day... [snip] Run a local proxy that forwards connections to the (external) proxy of your choice, and point all applications at it? T -- Do not reason with the unreasonable; you lose by definition.
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
On Fri, Aug 29, 2003 at 06:00:51PM -0400, Glenn Maynard wrote: A script to convert eg. * New upstream release .* (Closes: #1, #2, #3) to * New upstream release \1 * fixed BTS summary line of #1 Closes: #1 * fixed BTS summary line of #2 Closes: #2 * fixed BTS summary line of #3 Closes: #3 in changelogs would probably go a lot further to correcting this very minor issue than reopening dozens of bug reports that belong closed, annoying users with BTS garbage, and repeating the same thread on debian-devel over and over. One big problem with this approach is that the same maintainers who are too lazy to write proper entries for bug-closers in their changelog entries are going to be too lazy to ensure that a bug report has a meaningful summary in the first place. -- G. Branden Robinson|America is at that awkward stage. Debian GNU/Linux |It's too late to work within the [EMAIL PROTECTED] |system, but too early to shoot the http://people.debian.org/~branden/ |bastards. -- Claire Wolfe pgpaB7wR3YuAx.pgp Description: PGP signature
Accepted ncurses-ruby 0.7.1-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 18:49:49 -0400 Source: ncurses-ruby Binary: libncurses-ruby Architecture: source i386 Version: 0.7.1-4 Distribution: unstable Urgency: low Maintainer: Brian M. Almeida [EMAIL PROTECTED] Changed-By: Brian M. Almeida [EMAIL PROTECTED] Description: libncurses-ruby - Ruby Extension for the ncurses C library Changes: ncurses-ruby (0.7.1-4) unstable; urgency=low . * Really build with -fPIC Files: 492aed9ce0529068e4a50d1fb0d5173d 634 interpreters optional ncurses-ruby_0.7.1-4.dsc a6f23617e594d79a19785532b94b49c1 1158 interpreters optional ncurses-ruby_0.7.1-4.diff.gz 54168cf7c6f70ad04f530b0f6acb1253 36558 interpreters optional libncurses-ruby_0.7.1-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TodcvN0db6ENkYwRAoHCAJ0R2HGRtzUZrX7ol8evs/A8fPdSxACdF8GW XpfHo8PHCdOn22GnSnqtx4E= =rp3v -END PGP SIGNATURE- Accepted: libncurses-ruby_0.7.1-4_i386.deb to pool/main/n/ncurses-ruby/libncurses-ruby_0.7.1-4_i386.deb ncurses-ruby_0.7.1-4.diff.gz to pool/main/n/ncurses-ruby/ncurses-ruby_0.7.1-4.diff.gz ncurses-ruby_0.7.1-4.dsc to pool/main/n/ncurses-ruby/ncurses-ruby_0.7.1-4.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted devfsd 1.3.25-16 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 09:04:00 +1000 Source: devfsd Binary: devfsd Architecture: source i386 Version: 1.3.25-16 Distribution: unstable Urgency: medium Maintainer: Russell Coker [EMAIL PROTECTED] Changed-By: Russell Coker [EMAIL PROTECTED] Description: devfsd - Daemon for the device filesystem Closes: 145352 166805 169642 190034 197072 205363 Changes: devfsd (1.3.25-16) unstable; urgency=medium . * Applied patch for umask when running modprobe etc, now ALL external programs run with umask 0022. Closes: #197072 . * Changed the permissions line for /dev/nb to avoid setting perms on the directory. Closes: #145352 . * Changed the group of /dev/agpgart from video to audio. Closes: #166805 . * Skip config files who's name starts with '#' to avoid emacs silly files. Closes: #169642 . * Fix the permissions entry for dasd devices such that they don't change the permissions of directories. Closes: #190034 . * Have the script to make sym-links and run mknod use ':' syntax of chown. Closes: #205363 Files: d35a46b482b427c6d425009b27966575 567 admin optional devfsd_1.3.25-16.dsc a2e21e7fc18f98243300638b144f14e0 21786 admin optional devfsd_1.3.25-16.diff.gz ff3966c4b5f3b73784405b26c4066fa2 44574 admin optional devfsd_1.3.25-16_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ToscwrB5/PXHUlYRAkcbAJ0at6LGolq/qtFRq41GpUgiiuLipwCdHcUu //vS3PBA8IowBXLY3B9xcE0= =XxIi -END PGP SIGNATURE- Accepted: devfsd_1.3.25-16.diff.gz to pool/main/d/devfsd/devfsd_1.3.25-16.diff.gz devfsd_1.3.25-16.dsc to pool/main/d/devfsd/devfsd_1.3.25-16.dsc devfsd_1.3.25-16_i386.deb to pool/main/d/devfsd/devfsd_1.3.25-16_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gimp1.3 1.3.19-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 11:40:21 -0400 Source: gimp1.3 Binary: libgimp1.3 gimp1.3 gimp1.3-nonfree gimp1.3-python libgimp1.3-dev Architecture: source i386 Version: 1.3.19-1 Distribution: unstable Urgency: low Maintainer: Ari Pollak [EMAIL PROTECTED] Changed-By: Ari Pollak [EMAIL PROTECTED] Description: gimp1.3- The GNU Image Manipulation Program, development version gimp1.3-nonfree - GIF support for the GNU Image Manipulation Program gimp1.3-python - Python support and plugins for The GIMP libgimp1.3 - Libraries necessary to run the GIMP, development version libgimp1.3-dev - Headers and other files for compiling plugins for The GIMP Closes: 205280 20 Changes: gimp1.3 (1.3.19-1) unstable; urgency=low . * New upstream release * Improve python policy conformance (Closes: #205280) * Bump version requirement on GTK as per upstream changes * Update build-depends (Closes: #20) Files: cff5de27a168449f857754e98ff29bae 959 graphics optional gimp1.3_1.3.19-1.dsc 055687f52dfeca98aee8d80ccf4bdadf 15260518 graphics optional gimp1.3_1.3.19.orig.tar.gz b01ec15f66bf78c8a5969a922c2d55a8 16579 graphics optional gimp1.3_1.3.19-1.diff.gz 6c70e2ff8bea577f7508e5540efeb5b5 659884 libs optional libgimp1.3_1.3.19-1_i386.deb f66b646692120a2e51d33732d0d441d2 389246 non-free/graphics optional gimp1.3-nonfree_1.3.19-1_i386.deb 80428b5ba195117bfff39a5e0967f5db 757892 graphics optional gimp1.3-python_1.3.19-1_i386.deb 2cdbae280f995db089e47ac181acd49b 7670240 graphics optional gimp1.3_1.3.19-1_i386.deb d7173f5847833235b60d76d74b423407 1078024 libdevel optional libgimp1.3-dev_1.3.19-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TorowO+u47cOQDsRAkYAAJ0ZViRK2m5gT1w6Qnst1gbpQOuiZACeMFvh FbHYe+EyFzoJf5g7NUH1imI= =ms1J -END PGP SIGNATURE- Accepted: gimp1.3-nonfree_1.3.19-1_i386.deb to pool/non-free/g/gimp1.3/gimp1.3-nonfree_1.3.19-1_i386.deb gimp1.3-python_1.3.19-1_i386.deb to pool/main/g/gimp1.3/gimp1.3-python_1.3.19-1_i386.deb gimp1.3_1.3.19-1.diff.gz to pool/main/g/gimp1.3/gimp1.3_1.3.19-1.diff.gz gimp1.3_1.3.19-1.dsc to pool/main/g/gimp1.3/gimp1.3_1.3.19-1.dsc gimp1.3_1.3.19-1_i386.deb to pool/main/g/gimp1.3/gimp1.3_1.3.19-1_i386.deb gimp1.3_1.3.19.orig.tar.gz to pool/main/g/gimp1.3/gimp1.3_1.3.19.orig.tar.gz libgimp1.3-dev_1.3.19-1_i386.deb to pool/main/g/gimp1.3/libgimp1.3-dev_1.3.19-1_i386.deb libgimp1.3_1.3.19-1_i386.deb to pool/main/g/gimp1.3/libgimp1.3_1.3.19-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted microwindows 0.90-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 15:47:49 -0700 Source: microwindows Binary: microwindows microwindows-fb libmicrowindows-dev libmicrowindows0 Architecture: source i386 Version: 0.90-2 Distribution: unstable Urgency: low Maintainer: David Schleef [EMAIL PROTECTED] Changed-By: David Schleef [EMAIL PROTECTED] Description: libmicrowindows-dev - Development files for the Microwindows library libmicrowindows0 - X11 runtime for the Microwindows library microwindows - Windowing environment for smaller/embedded devices (for X11) microwindows-fb - Windowing environment for embedded devices (for framebuffer) Closes: 207667 207695 Changes: microwindows (0.90-2) unstable; urgency=low . * src/mwin/bmp/convbmp.c: Fix build problems on 64-bit architectures (Closes: #207667) * Fix short description on microwindows and microwindows-fb (Closes: #207695) Files: b142de77eabdcf175af18637edb9cc68 674 devel optional microwindows_0.90-2.dsc 60efa58502c061d71d3529f272940917 10153 devel optional microwindows_0.90-2.diff.gz 3cd579ba41cc988fea61ab1e3ebb5286 714876 devel optional libmicrowindows-dev_0.90-2_i386.deb 2a37ccf7b205cd6b4ae2984d60ef9948 221436 devel optional libmicrowindows0_0.90-2_i386.deb 43ffd9836be097ecc9821c46d796a8ab 824400 devel optional microwindows_0.90-2_i386.deb 12bb78efc42aec8ac1fe932d49acae9f 114710 devel optional microwindows-fb_0.90-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Tote2vJMr9bVSaoRAiCQAKCOeu2nbJTglJpQxozJGLmN1ttsWACgvDA7 GldMX1V5ZIuS0FwakPGe0pw= =oyPY -END PGP SIGNATURE- Accepted: libmicrowindows-dev_0.90-2_i386.deb to pool/main/m/microwindows/libmicrowindows-dev_0.90-2_i386.deb libmicrowindows0_0.90-2_i386.deb to pool/main/m/microwindows/libmicrowindows0_0.90-2_i386.deb microwindows-fb_0.90-2_i386.deb to pool/main/m/microwindows/microwindows-fb_0.90-2_i386.deb microwindows_0.90-2.diff.gz to pool/main/m/microwindows/microwindows_0.90-2.diff.gz microwindows_0.90-2.dsc to pool/main/m/microwindows/microwindows_0.90-2.dsc microwindows_0.90-2_i386.deb to pool/main/m/microwindows/microwindows_0.90-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wmtv 0.6.5-15 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 22:53:19 +0200 Source: wmtv Binary: wmtv Architecture: source i386 Version: 0.6.5-15 Distribution: unstable Urgency: low Maintainer: Nicolas Boullis [EMAIL PROTECTED] Changed-By: Nicolas Boullis [EMAIL PROTECTED] Description: wmtv - Dockable video4linux TV player for WindowMaker Changes: wmtv (0.6.5-15) unstable; urgency=low . * Fixed long description thanks to Colin Watson. * Fixed manpages thanks to Anthony DeRobertis. * Fixed versionned build-dependency on debhelper thanks to lintian. * Removed superfluous (s) to Upstream Author(s) to please lintian. * Updated Makefile and debian/rules to support noopt in $DEB_BUILD_OPTIONS. * Bump Standards-Version: to 3.6.1. Files: adaf1465275c8baf1704bd92afec01ae 565 x11 extra wmtv_0.6.5-15.dsc 0dbf1d14eb7ff94d7aa75b6bdbf8a570 15503 x11 extra wmtv_0.6.5-15.diff.gz bccf6e51125b1024f8e207b76bfaf7ab 32042 x11 extra wmtv_0.6.5-15_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/To9mwmyXkG1Pxm8RAmb3AKC+tdQuJDPigaD7kyM789anRxLVswCfVbnH ilboiJ8jka59czFrdJ8LgHE= =pjmz -END PGP SIGNATURE- Accepted: wmtv_0.6.5-15.diff.gz to pool/main/w/wmtv/wmtv_0.6.5-15.diff.gz wmtv_0.6.5-15.dsc to pool/main/w/wmtv/wmtv_0.6.5-15.dsc wmtv_0.6.5-15_i386.deb to pool/main/w/wmtv/wmtv_0.6.5-15_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted loadwatch 1.0+1.1alpha1-5 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 01:27:13 +0200 Source: loadwatch Binary: loadwatch Architecture: source i386 Version: 1.0+1.1alpha1-5 Distribution: unstable Urgency: low Maintainer: Nicolas Boullis [EMAIL PROTECTED] Changed-By: Nicolas Boullis [EMAIL PROTECTED] Description: loadwatch - Run a program using only idle cycles Changes: loadwatch (1.0+1.1alpha1-5) unstable; urgency=low . * Fixed long description thanks to Colin Watson. * Fixed manpages thanks to Anthony DeRobertis and Nick Rusnov. * Bump Standards-Version: to 3.6.1. Files: a9da0ccad22ce2459cf56ea4f53886af 595 utils optional loadwatch_1.0+1.1alpha1-5.dsc ef8baee32d02464156de0bf5bf57c235 5632 utils optional loadwatch_1.0+1.1alpha1-5.diff.gz a82b7b3e1c7a8591e2d814ef8f3a59a1 12316 utils optional loadwatch_1.0+1.1alpha1-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TpD7wmyXkG1Pxm8RAhtSAKCSZd9oVtuS/OM8iE5Ram8J9J8nCwCgtSYg kFXFoy3R72eL2c63z1jX9z8= =ZRlf -END PGP SIGNATURE- Accepted: loadwatch_1.0+1.1alpha1-5.diff.gz to pool/main/l/loadwatch/loadwatch_1.0+1.1alpha1-5.diff.gz loadwatch_1.0+1.1alpha1-5.dsc to pool/main/l/loadwatch/loadwatch_1.0+1.1alpha1-5.dsc loadwatch_1.0+1.1alpha1-5_i386.deb to pool/main/l/loadwatch/loadwatch_1.0+1.1alpha1-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kcd 0.1.3.1-3 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 09:29:05 +1000 Source: kcd Binary: kcd Architecture: source i386 Version: 0.1.3.1-3 Distribution: unstable Urgency: low Maintainer: Ben Burton [EMAIL PROTECTED] Changed-By: Ben Burton [EMAIL PROTECTED] Description: kcd- a CD player applet for KDE Kicker Changes: kcd (0.1.3.1-3) unstable; urgency=low . * Bumped standards-version to 3.6.0. * Updated package sections. Files: 0dc943fa1862424de749464ec08faf37 576 kde optional kcd_0.1.3.1-3.dsc dc70dd3f3fd80af92cbc220127d24f18 2941 kde optional kcd_0.1.3.1-3.diff.gz 27b82a8ac118bf39ddfe0aad51a53b9b 30672 kde optional kcd_0.1.3.1-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TpOMMQNuxza4YcERAgMPAJ0Z2TtmOZL4jOYqwgRxkPhH3vvvyACeJQDQ k8cr3uY3vpAB7jJKzPpfPJM= =gsqv -END PGP SIGNATURE- Accepted: kcd_0.1.3.1-3.diff.gz to pool/main/k/kcd/kcd_0.1.3.1-3.diff.gz kcd_0.1.3.1-3.dsc to pool/main/k/kcd/kcd_0.1.3.1-3.dsc kcd_0.1.3.1-3_i386.deb to pool/main/k/kcd/kcd_0.1.3.1-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted file-roller 2.3.5-2 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 00:53:09 +0200 Source: file-roller Binary: file-roller Architecture: source i386 Version: 2.3.5-2 Distribution: unstable Urgency: low Maintainer: Sebastien Bacher [EMAIL PROTECTED] Changed-By: Sebastien Bacher [EMAIL PROTECTED] Description: file-roller - An archiver for GNOME Closes: 199514 Changes: file-roller (2.3.5-2) unstable; urgency=low . * Fixed the bug with konqueror .war files (Closes: #199514). Files: ea0cf175cca993c5c175e014efe10033 693 gnome optional file-roller_2.3.5-2.dsc e2587747fbdd8c51a1190f0f4cecf332 3532 gnome optional file-roller_2.3.5-2.diff.gz 927dc91d6b7456798acaa360b3dfadae 595704 gnome optional file-roller_2.3.5-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TpaIQxo87aLX0pIRAlBsAKCIvhy7bC0y0G923aDJkIpTYvspEgCgh208 QEg7jSgbn4b5J51oDoRvjZQ= =h7ws -END PGP SIGNATURE- Accepted: file-roller_2.3.5-2.diff.gz to pool/main/f/file-roller/file-roller_2.3.5-2.diff.gz file-roller_2.3.5-2.dsc to pool/main/f/file-roller/file-roller_2.3.5-2.dsc file-roller_2.3.5-2_i386.deb to pool/main/f/file-roller/file-roller_2.3.5-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted limewire 3.4.5-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 16:43:48 -0700 Source: limewire Binary: limewire Architecture: source all Version: 3.4.5-2 Distribution: unstable Urgency: low Maintainer: Michael Cardenas [EMAIL PROTECTED] Changed-By: michael cardenas [EMAIL PROTECTED] Description: limewire - a Java based gnutella servent Changes: limewire (3.4.5-2) unstable; urgency=low . * Added build-dependency on virtual java-compiler package. Files: 6d2902a8f15c13212695ed5044dc23c6 584 contrib/net optional limewire_3.4.5-2.dsc 14536b5f91b26be542f16fa54356fa15 8317 contrib/net optional limewire_3.4.5-2.diff.gz 5bc208ca235fe6c6f27b85d02b4046bf 7788444 contrib/net optional limewire_3.4.5-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TpoJ19dB+DmKDEoRAuVEAKC+NhrnHcuGl+PAN7OISU4GcJp9bQCbB3uz 2DzHSB3sT+QUOAKjmAeeTsc= =yGHb -END PGP SIGNATURE- Accepted: limewire_3.4.5-2.diff.gz to pool/contrib/l/limewire/limewire_3.4.5-2.diff.gz limewire_3.4.5-2.dsc to pool/contrib/l/limewire/limewire_3.4.5-2.dsc limewire_3.4.5-2_all.deb to pool/contrib/l/limewire/limewire_3.4.5-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gtetrinet 0.7.4-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 02:09:32 +0200 Source: gtetrinet Binary: gtetrinet Architecture: source i386 Version: 0.7.4-1 Distribution: unstable Urgency: low Maintainer: Jordi Mallach [EMAIL PROTECTED] Changed-By: Jordi Mallach [EMAIL PROTECTED] Description: gtetrinet - multiplayer tetris-like game Closes: 205656 205658 Changes: gtetrinet (0.7.4-1) unstable; urgency=low . * New upstream release. + fixes a segfault when restoring default keys (closes: #205656). + fixes a condition where the keyboard and game keys wouldn't work at all when playing (closes: #205658). * debian/control: + bump debhelper build dependency to (= 4.1.0). + add cdbs to build-deps. + bump Standards-Version to 3.6.1.0 (no changes). * debian/rules: rewrite using CDBS. Files: abe89f4e28e891945d3e5256f55d194d 627 gnome optional gtetrinet_0.7.4-1.dsc d18201443a386d54b7240bea99d2efe5 459483 gnome optional gtetrinet_0.7.4.orig.tar.gz 372e5501525c5ad28b98082df464b818 5166 gnome optional gtetrinet_0.7.4-1.diff.gz 8c792520aac12ab0dcb69dd9297d318e 259340 gnome optional gtetrinet_0.7.4-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TqQ+JYSUupF6Il4RAirPAJ4pkn0qEH3Aq8DjpJ2Heu3z+wvwuQCguwt1 Nl8d1GoNRXN8vq/PbQgKsMM= =DIfv -END PGP SIGNATURE- Accepted: gtetrinet_0.7.4-1.diff.gz to pool/main/g/gtetrinet/gtetrinet_0.7.4-1.diff.gz gtetrinet_0.7.4-1.dsc to pool/main/g/gtetrinet/gtetrinet_0.7.4-1.dsc gtetrinet_0.7.4-1_i386.deb to pool/main/g/gtetrinet/gtetrinet_0.7.4-1_i386.deb gtetrinet_0.7.4.orig.tar.gz to pool/main/g/gtetrinet/gtetrinet_0.7.4.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted apcalc 2.11.8.1-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 00:50:57 +0200 Source: apcalc Binary: apcalc apcalc-dev Architecture: source i386 Version: 2.11.8.1-1 Distribution: unstable Urgency: low Maintainer: Martin Buck [EMAIL PROTECTED] Changed-By: Martin Buck [EMAIL PROTECTED] Description: apcalc - Arbitrary precision calculator (original name: calc) apcalc-dev - Library for arbitrary precision arithmetic Changes: apcalc (2.11.8.1-1) unstable; urgency=low . * New upstream release * Use pager instead of more * Moved apcalc-dev from section math to devel to match override file Files: 96b06bd793ff7b84342b620f1d21fdcf 641 math optional apcalc_2.11.8.1-1.dsc d94efca11c686d9e7db1409d0c90483f 956892 math optional apcalc_2.11.8.1.orig.tar.gz 0d2904a834cce5ed768803a94e5809c2 4876 math optional apcalc_2.11.8.1-1.diff.gz 543c6eaa4bf4c4a8fa5c133ecb414796 1082760 math optional apcalc_2.11.8.1-1_i386.deb 1d88341318fb7ad2067d30bbf78657be 493412 devel optional apcalc-dev_2.11.8.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TqfA5na4Z/jVQlkRAvjwAJ40InpHqIWvMr2Gp04W96oKtOo0CwCggMrs R9Pd0M0yEd9eDVGzl6ni71U= =mGqq -END PGP SIGNATURE- Accepted: apcalc-dev_2.11.8.1-1_i386.deb to pool/main/a/apcalc/apcalc-dev_2.11.8.1-1_i386.deb apcalc_2.11.8.1-1.diff.gz to pool/main/a/apcalc/apcalc_2.11.8.1-1.diff.gz apcalc_2.11.8.1-1.dsc to pool/main/a/apcalc/apcalc_2.11.8.1-1.dsc apcalc_2.11.8.1-1_i386.deb to pool/main/a/apcalc/apcalc_2.11.8.1-1_i386.deb apcalc_2.11.8.1.orig.tar.gz to pool/main/a/apcalc/apcalc_2.11.8.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted remem 2.11-7 (i386 source)
-BEGIN PGP SIGNED MESSAGE-
Format: 1.7
Date: Fri, 29 Aug 2003 02:36:25 +0200
Source: remem
Binary: remembrance-agent
Architecture: source i386
Version: 2.11-7
Distribution: unstable
Urgency: low
Maintainer: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Changed-By: Javier Fernandez-Sanguino Pen~a [EMAIL PROTECTED]
Description:
remembrance-agent - Emacs mode to help find relevant texts
Changes:
remem (2.11-7) unstable; urgency=low
.
* Fixed postinst since the replacement was not working properly
(use perl instead of sed to allow for variable substitution)
* Added note on the remembrance-agent.el file wrt to the changes
made by dpkg-reconfigure.
* Properly defined scope (as an empty string) so that the database
in /var/lib/emacs/remembrance-agent can be used. Otherwise it
tries to use non-existant scopes ('mail' and 'notes'). Note that
users can setup their own scopes if they want to.
Files:
8442c42813773c6541074f50f287f051 707 misc optional remem_2.11-7.dsc
0aa58f5b9685fd798add37b9b97d0963 40907 misc optional remem_2.11-7.diff.gz
2e6d53c4a8f74ab37c5e125551cab80a 118128 misc optional
remembrance-agent_2.11-7_i386.deb
-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv
iQCVAwUBP06p1PtEPvakNq0lAQFzJAP/WVIP5nQLEDtQZ8OHYYUnBzi2ApQG0cFj
NVsYGOi5MQSJguXWRUZZK8/qtPaqNSACS4h243/fSW7YxIyc62ZZCyxfU7p8tP7G
FlnctgrzOcA1SpEv1uLRBAbzLIJbbppvF8qXYOUwoJgklywKNIF8WhJIO1q20F1z
5vST0azVUSQ=
=BGle
-END PGP SIGNATURE-
Accepted:
remem_2.11-7.diff.gz
to pool/main/r/remem/remem_2.11-7.diff.gz
remem_2.11-7.dsc
to pool/main/r/remem/remem_2.11-7.dsc
remembrance-agent_2.11-7_i386.deb
to pool/main/r/remem/remembrance-agent_2.11-7_i386.deb
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quantlib-python 0.3.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 21:01:49 -0500 Source: quantlib-python Binary: quantlib-python Architecture: source i386 Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel [EMAIL PROTECTED] Changed-By: Dirk Eddelbuettel [EMAIL PROTECTED] Description: quantlib-python - Python bindings for the Quantlib Quantitative Finance library Changes: quantlib-python (0.3.3-1) unstable; urgency=low . * Upgraded to new upstream version 0.3.3 (to be announced next week) * debian/control: Build-Depends upgraded to libquantlib0-dev (= 0.3.3) * debian/control: Standards-Version upgraded to 3.6.1.0 Files: 776386ec34313783e33d7138df08191f 656 python optional quantlib-python_0.3.3-1.dsc 3d3715520cfd63aaf72ef5e5447871ad 202573 python optional quantlib-python_0.3.3.orig.tar.gz b0280d3f6d2f454473a38d98c721928b 5015 python optional quantlib-python_0.3.3-1.diff.gz da8243a9ca1bbaec2bd25c983b4469b0 712242 python optional quantlib-python_0.3.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TrVqCZSR95Gw07cRAgHPAJ41M+o7CSl4ooX+wQn0ysOEysR1hwCeIQn+ YTK0xufu18nsR4siJV2hfuQ= =+SE3 -END PGP SIGNATURE- Accepted: quantlib-python_0.3.3-1.diff.gz to pool/main/q/quantlib-python/quantlib-python_0.3.3-1.diff.gz quantlib-python_0.3.3-1.dsc to pool/main/q/quantlib-python/quantlib-python_0.3.3-1.dsc quantlib-python_0.3.3-1_i386.deb to pool/main/q/quantlib-python/quantlib-python_0.3.3-1_i386.deb quantlib-python_0.3.3.orig.tar.gz to pool/main/q/quantlib-python/quantlib-python_0.3.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted quantlib-ruby 0.3.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 21:03:06 -0500 Source: quantlib-ruby Binary: quantlib-ruby Architecture: source i386 Version: 0.3.3-1 Distribution: unstable Urgency: low Maintainer: Dirk Eddelbuettel [EMAIL PROTECTED] Changed-By: Dirk Eddelbuettel [EMAIL PROTECTED] Description: quantlib-ruby - Ruby bindings for the Quantlib Quantitative Finance library Changes: quantlib-ruby (0.3.3-1) unstable; urgency=low . * Upgraded to new upstream version 0.3.3 (to be announced next week) * debian/control: Build-Depends upgraded to libquantlib0-dev (= 0.3.3) * debian/control: Standards-Version upgraded to 3.6.1.0 Files: a9b2940b64ea0830aa421bee8a1774fc 671 interpreters optional quantlib-ruby_0.3.3-1.dsc 3910119e0116c78a827b02a96c5e5583 167005 interpreters optional quantlib-ruby_0.3.3.orig.tar.gz c83c7fb58cfc12af45409799cd5074f0 4414 interpreters optional quantlib-ruby_0.3.3-1.diff.gz c0e1722cfffe71256536de8ed8f7f1c9 553784 interpreters optional quantlib-ruby_0.3.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TrbBCZSR95Gw07cRAumFAJ9cKIr0+gd1OYvdasYiDeqrxof8RgCfVz5j TSGBLeh3/nyg3RBGcPjB4Lc= =3+Nq -END PGP SIGNATURE- Accepted: quantlib-ruby_0.3.3-1.diff.gz to pool/main/q/quantlib-ruby/quantlib-ruby_0.3.3-1.diff.gz quantlib-ruby_0.3.3-1.dsc to pool/main/q/quantlib-ruby/quantlib-ruby_0.3.3-1.dsc quantlib-ruby_0.3.3-1_i386.deb to pool/main/q/quantlib-ruby/quantlib-ruby_0.3.3-1_i386.deb quantlib-ruby_0.3.3.orig.tar.gz to pool/main/q/quantlib-ruby/quantlib-ruby_0.3.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted spamassassin 2.59pre2.60rc3-1 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 20:59:24 -0400 Source: spamassassin Binary: spamassassin spamc Architecture: source all i386 Version: 2.59pre2.60rc3-1 Distribution: experimental Urgency: low Maintainer: Duncan Findlay [EMAIL PROTECTED] Changed-By: Duncan Findlay [EMAIL PROTECTED] Description: spamassassin - Perl-based spam filter using text analysis spamc - Client for perl-based spam filtering daemon Closes: 199217 201324 207233 207234 Changes: spamassassin (2.59pre2.60rc3-1) experimental; urgency=low . * New upstream release (candidate) includes: Numerous rule improvements and bug fixes. GA-assigned scores (previous cvs packages did not). New Bayes backend with different DB format (automatic upgrade). dccifd support added. Better support for personal installation (Closes: #199217) Dropped support for database formats other than DB_File (which most should already be using). (See README.Upgrade) * Works around symlinks being left behind in /etc/logcheck on upgrade. (Closes: #201324) * Added symlink from /etc/mail/spamassassin to /etc/spamassassin (Closes: #207233, #207234) Files: be6671875f670c784cb1e6c93992ec57 692 mail optional spamassassin_2.59pre2.60rc3-1.dsc 141a73b07d46324865ea7ead49375043 949876 mail optional spamassassin_2.59pre2.60rc3.orig.tar.gz f9856e0123dca8c0e99ade0374aa4d4a 22710 mail optional spamassassin_2.59pre2.60rc3-1.diff.gz d419073af8ddf388cb15d1a20b63e2e8 752244 mail optional spamassassin_2.59pre2.60rc3-1_all.deb 33634ece9f833e1c37147d14e4b6cd13 169442 mail optional spamc_2.59pre2.60rc3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TrliqjUzNGvmnNARAuVSAJ0W7LhbPiA20N3X84qryCxiOwpqqACfZQuP TonvKRH5G7TciChMUqsbWE8= =5d8a -END PGP SIGNATURE- Accepted: spamassassin_2.59pre2.60rc3-1.diff.gz to pool/main/s/spamassassin/spamassassin_2.59pre2.60rc3-1.diff.gz spamassassin_2.59pre2.60rc3-1.dsc to pool/main/s/spamassassin/spamassassin_2.59pre2.60rc3-1.dsc spamassassin_2.59pre2.60rc3-1_all.deb to pool/main/s/spamassassin/spamassassin_2.59pre2.60rc3-1_all.deb spamassassin_2.59pre2.60rc3.orig.tar.gz to pool/main/s/spamassassin/spamassassin_2.59pre2.60rc3.orig.tar.gz spamc_2.59pre2.60rc3-1_i386.deb to pool/main/s/spamassassin/spamc_2.59pre2.60rc3-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted circuslinux 1.0.3-8 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 21:22:02 -0400 Source: circuslinux Binary: circuslinux Architecture: source i386 Version: 1.0.3-8 Distribution: unstable Urgency: low Maintainer: Christian T. Steigies [EMAIL PROTECTED] Changed-By: Christian T. Steigies [EMAIL PROTECTED] Description: circuslinux - The clowns are trying to pop balloons to score points! Closes: 206942 207241 Changes: circuslinux (1.0.3-8) unstable; urgency=low . * add Brazilian Portuguese debconf template translations (closes: #206942) * add German templates, am I allowed to do that myself? * add French debconf template translations (closes: #207241) Files: aa785a7f284e0a8ef3dc8f2802c851d8 719 games optional circuslinux_1.0.3-8.dsc 3405d869d021727cba54646ae504d469 39906 games optional circuslinux_1.0.3-8.diff.gz cebc5bd8cef72209a23099760a7160af 1209408 games optional circuslinux_1.0.3-8_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TsCchWcuXd2lEoARAmXzAJ9f0mUQACeuinpib+/bgTzos2y8sQCfSZhG rMYekqsXdD34pDJPa0oIoFQ= =AaXs -END PGP SIGNATURE- Accepted: circuslinux_1.0.3-8.diff.gz to pool/main/c/circuslinux/circuslinux_1.0.3-8.diff.gz circuslinux_1.0.3-8.dsc to pool/main/c/circuslinux/circuslinux_1.0.3-8.dsc circuslinux_1.0.3-8_i386.deb to pool/main/c/circuslinux/circuslinux_1.0.3-8_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted xfree86 4.2.1-11 (powerpc all source)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Thu, 28 Aug 2003 13:17:07 -0500
Source: xfree86
Binary: xlibmesa3-gl xserver-common libxaw7-dbg xlibmesa-glu-dev xbase-clients twm
xlibmesa3-dbg xfonts-scalable xfonts-75dpi libdps1-dbg xmh libxaw6-dbg xfwp xlibs
xlibosmesa3-dbg xlibmesa3-glu libdps-dev xserver-xfree86-dbg xlibmesa-dev
xserver-xfree86 libdps1 proxymngr xlibmesa3-glu-dbg xfonts-base-transcoded
xlibmesa-gl-dev libxaw6-dev lbxproxy xfonts-cyrillic xlibmesa3-gl-dbg
x-window-system-core xutils xspecs xlibs-pic x-window-system xfree86-common xfs
xlibmesa3 xfonts-base xlibs-dbg libxaw7-dev xnest xfonts-100dpi-transcoded libxaw6
xfonts-100dpi xterm xfonts-75dpi-transcoded xprt xlibosmesa-dev xvfb libxaw7
xlibosmesa3 xdm xlibs-dev
Architecture: source powerpc all
Version: 4.2.1-11
Distribution: unstable
Urgency: medium
Maintainer: Branden Robinson [EMAIL PROTECTED]
Changed-By: Branden Robinson [EMAIL PROTECTED]
Description:
lbxproxy - Low Bandwidth X (LBX) proxy server
libdps-dev - Display PostScript (DPS) client library development files
libdps1- Display PostScript (DPS) client library
libdps1-dbg - Display PostScript (DPS) client library (unstripped)
libxaw6- X Athena widget set library (version 6)
libxaw6-dbg - X Athena widget set library (version 6) (unstripped)
libxaw6-dev - X Athena widget set library development files (version 6)
libxaw7- X Athena widget set library
libxaw7-dbg - X Athena widget set library (unstripped)
libxaw7-dev - X Athena widget set library development files
proxymngr - X proxy services manager
twm- Tab window manager
x-window-system - X Window System
x-window-system-core - X Window System core components
xbase-clients - miscellaneous X clients
xdm- X display manager
xfonts-100dpi - 100 dpi fonts for X
xfonts-100dpi-transcoded - 100 dpi fonts for X (transcoded from ISO 10646-1)
xfonts-75dpi - 75 dpi fonts for X
xfonts-75dpi-transcoded - 75 dpi fonts for X (transcoded from ISO 10646-1)
xfonts-base - standard fonts for X
xfonts-base-transcoded - standard fonts for X (transcoded from ISO 10646-1)
xfonts-cyrillic - Cyrillic fonts for X
xfonts-scalable - scalable fonts for X
xfree86-common - X Window System (XFree86) infrastructure
xfs- X font server
xfwp - X firewall proxy server
xlibmesa-dev - XFree86 Mesa development libraries pseudopackage
xlibmesa-gl-dev - Mesa 3D graphics library development files [XFree86]
xlibmesa-glu-dev - Mesa OpenGL utility library development files [XFree86]
xlibmesa3 - XFree86 Mesa libraries pseudopackage
xlibmesa3-dbg - XFree86 Mesa unstripped libraries pseudopackage
xlibmesa3-gl - Mesa 3D graphics library [XFree86]
xlibmesa3-gl-dbg - Mesa 3D graphics library (unstripped) [XFree86]
xlibmesa3-glu - Mesa OpenGL utility library [XFree86]
xlibmesa3-glu-dbg - Mesa OpenGL utility library (unstripped) [XFree86]
xlibosmesa-dev - Mesa off-screen rendering library development files [XFree86]
xlibosmesa3 - Mesa off-screen rendering library [XFree86]
xlibosmesa3-dbg - Mesa off-screen rendering library (unstripped) [XFree86]
xlibs - X Window System client libraries
xlibs-dbg - X Window System client libraries (unstripped)
xlibs-dev - X Window System client library development files
xlibs-pic - X Window System client extension library PIC archives
xmh- X interface to the MH mail system
xnest - nested X server
xprt - X print server (XFree86 version)
xserver-common - files and utilities common to all X servers
xserver-xfree86 - the XFree86 X server
xserver-xfree86-dbg - the XFree86 X server (static version with debugging symbols)
xspecs - X protocol, extension, and library technical specifications
xterm - X terminal emulator
xutils - X Window System utility programs
xvfb - virtual framebuffer X server
Closes: 172579 204148 206524 206790 206929 206949 206971 207229 207239 207268 207305
Changes:
xfree86 (4.2.1-11) unstable; urgency=medium
.
* urgency set to medium because bug #206790 bites a lot of people (but,
contrary to most submitters' belief, not everyone), and #207305 really
screws people trying to purge xserver-common and xserver-xfree86
.
* debian/control: add gcc's epoch to versioned Build-Conflict on gcc-3.3
(thanks, James Troup)
.
* debian/local/Xsession{,.options}.5: further clarify the X session startup
procedure in the manpages, per suggestion from Frank Murphy
.
* debian/xserver-{common,xfree86}.postinst.in: do not attempt to
create/update configuration file rosters if the path of the auxiliary
directory exists but is not a directory; assume local admin cleverness
.
* Add pt_BR.UTF-8 locale support (as something other than an alias for
en_US.UTF-8) to Xlib; includes Compose file updates from Gustavo
Noronha Silva. (Closes: #204148)
- patch #096: new
- debian/MANIFEST.*: list new files in
Accepted hermes1 1.3.3-4 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 20:22:14 -0700 Source: hermes1 Binary: hermes1-dev hermes1 Architecture: source i386 Version: 1.3.3-4 Distribution: unstable Urgency: low Maintainer: David Schleef [EMAIL PROTECTED] Changed-By: David Schleef [EMAIL PROTECTED] Description: hermes1- The Hermes pixel-format library hermes1-dev - Development libraries for the Hermes pixel-format library Closes: 205467 Changes: hermes1 (1.3.3-4) unstable; urgency=low . * src/HermConf.h: Properly define endian flags for all arches. This bug was causing WindowMaker to go all wonky with the colors on big-endian architectures due to 1.3.3. I really don't understand why, since the code is identical to 1.3.2. Probably a latent bug brought to the surface by other changes. I'm sure there are other problems. (Closes: #205467) Files: f67d3d9140f30392ddee4dcd18755e56 635 libs extra hermes1_1.3.3-4.dsc 83e57339938d35fb2d55ec30e4455258 245182 libs extra hermes1_1.3.3-4.diff.gz 848a51920cab9179076b1298a887015b 58470 libs extra hermes1_1.3.3-4_i386.deb c01318da195b89409472a41b3e8b7670 115224 libdevel extra hermes1-dev_1.3.3-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Ts4m2vJMr9bVSaoRAofpAKCjxrk5wbNU6AHByP75cqP52FQ9fgCgulFh hvS766NiegDBa8E5bZsp/v4= =skmr -END PGP SIGNATURE- Accepted: hermes1-dev_1.3.3-4_i386.deb to pool/main/h/hermes1/hermes1-dev_1.3.3-4_i386.deb hermes1_1.3.3-4.diff.gz to pool/main/h/hermes1/hermes1_1.3.3-4.diff.gz hermes1_1.3.3-4.dsc to pool/main/h/hermes1/hermes1_1.3.3-4.dsc hermes1_1.3.3-4_i386.deb to pool/main/h/hermes1/hermes1_1.3.3-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pantomime 1.1.0-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 28 Aug 2003 22:19:42 +0200 Source: pantomime Binary: pantomime1 pantomime-dev Architecture: source i386 Version: 1.1.0-1 Distribution: unstable Urgency: low Maintainer: Matthias Klose [EMAIL PROTECTED] Changed-By: Matthias Klose [EMAIL PROTECTED] Description: pantomime-dev - Objective-C library for mail handling pantomime1 - Objective-C library for mail handling (development files) Changes: pantomime (1.1.0-1) unstable; urgency=low . * New upstream version. Files: 92d7740e28466f9203852bacdd5bf26f 624 libdevel optional pantomime_1.1.0-1.dsc 8544369508c2a6d54281f30332a4b4f7 395329 libdevel optional pantomime_1.1.0.orig.tar.gz 05b5677fc23052b798bd5500efe78120 2638 libdevel optional pantomime_1.1.0-1.diff.gz 828d372589c7b953e64d3b6f74e285e9 314278 libdevel optional pantomime-dev_1.1.0-1_i386.deb 8557393735e55c77fe15f0d6a87522f6 213998 libs optional pantomime1_1.1.0-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD4DBQE/TmTsStlRaw+TLJwRAk8iAKCNRxAVrif0zJYfT/OoN8XgtfyqaQCYmZql mXlM6qjzAmseGpx80oAl0A== =POuk -END PGP SIGNATURE- Accepted: pantomime-dev_1.1.0-1_i386.deb to pool/main/p/pantomime/pantomime-dev_1.1.0-1_i386.deb pantomime1_1.1.0-1_i386.deb to pool/main/p/pantomime/pantomime1_1.1.0-1_i386.deb pantomime_1.1.0-1.diff.gz to pool/main/p/pantomime/pantomime_1.1.0-1.diff.gz pantomime_1.1.0-1.dsc to pool/main/p/pantomime/pantomime_1.1.0-1.dsc pantomime_1.1.0.orig.tar.gz to pool/main/p/pantomime/pantomime_1.1.0.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted librmail-ruby 0.14-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 15:02:41 +0900 Source: librmail-ruby Binary: librmail-ruby Architecture: source all Version: 0.14-1 Distribution: unstable Urgency: low Maintainer: akira yamada [EMAIL PROTECTED] Changed-By: akira yamada [EMAIL PROTECTED] Description: librmail-ruby - lightweight mail library for Ruby Changes: librmail-ruby (0.14-1) unstable; urgency=low . * new upstream version. Files: b0446e29be64372aa82c4cf879153fdf 592 interpreters optional librmail-ruby_0.14-1.dsc effcc30520108738a98ea71096d84f16 106898 interpreters optional librmail-ruby_0.14.orig.tar.gz a11970b5b33a928fcdf9f0b43229e869 2049 interpreters optional librmail-ruby_0.14-1.diff.gz 28f82b12f8cc520bfaf792e4de7910b0 114204 interpreters optional librmail-ruby_0.14-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Tu5iXzkxpuIT8aARArb8AJ4kquZ/gKvQbn54qSf4Wu832yuwBACdGapV l6nakpSksfcqbZ37xd31tqw= =lP7S -END PGP SIGNATURE- Accepted: librmail-ruby_0.14-1.diff.gz to pool/main/libr/librmail-ruby/librmail-ruby_0.14-1.diff.gz librmail-ruby_0.14-1.dsc to pool/main/libr/librmail-ruby/librmail-ruby_0.14-1.dsc librmail-ruby_0.14-1_all.deb to pool/main/libr/librmail-ruby/librmail-ruby_0.14-1_all.deb librmail-ruby_0.14.orig.tar.gz to pool/main/libr/librmail-ruby/librmail-ruby_0.14.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted dpsyco 1.0.22 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 08:28:16 +0200 Source: dpsyco Binary: dpsyco-doc dpsyco-samba dpsyco-ssh dpsyco dpsyco-cfengine dpsyco-devel dpsyco-sudo dpsyco-base dpsyco-mysql dpsyco-lib dpsyco-skel dpsyco-patch Architecture: source all Version: 1.0.22 Distribution: unstable Urgency: low Maintainer: Ola Lundqvist [EMAIL PROTECTED] Changed-By: Ola Lundqvist [EMAIL PROTECTED] Description: dpsyco - Debian packages of system configurations dpsyco-base - Base package for the debian packages of system configurations dpsyco-cfengine - Automate applying of cfengine configs dpsyco-devel - Tools to create configuration packages dpsyco-doc - Documentation for the debian packages of system configurations dpsyco-lib - Libraries for the debian packages of system configurations dpsyco-mysql - Automate administration of access to mysql dpsyco-patch - Automatically patch the debian file-system dpsyco-samba - Automate administration of access to samba dpsyco-skel - Automatically install a add-on skeleton dpsyco-ssh - Automate administration of access via ssh dpsyco-sudo - Automate administration of sudo privileges Changes: dpsyco (1.0.22) unstable; urgency=low . * Added a check for multiple account information in update-dpsyco- users. Files: db00ee3c095754c07f7fb91172906889 651 admin extra dpsyco_1.0.22.dsc 1ce2c6e5ac234d2f9b117688dd99de0d 45647 admin extra dpsyco_1.0.22.tar.gz 93e37879fc9938fe9ed0e07c683ec1df 10352 admin extra dpsyco_1.0.22_all.deb 31fa70ac9ab505aab35156e332d6314e 24224 admin extra dpsyco-base_1.0.22_all.deb 415f5778c4c2b2f521a15082f6edabd0 18766 admin extra dpsyco-lib_1.0.22_all.deb ed6d5726f664f721e490ec3d20c20c84 6538 doc extra dpsyco-doc_1.0.22_all.deb dc6ffe85e73ce155b38501877685331a 12484 admin extra dpsyco-skel_1.0.22_all.deb cd1f8adee26e96dcb3792deb484f21ad 12180 admin extra dpsyco-patch_1.0.22_all.deb ec6e89abfaa3465a1c92d8c729b67457 44566 admin extra dpsyco-devel_1.0.22_all.deb fce982637a1dfd762fa60a63114047e7 10464 admin extra dpsyco-sudo_1.0.22_all.deb 771801aa56582486fcad6c369d3987b0 9744 admin extra dpsyco-ssh_1.0.22_all.deb ff297ef7c6506bc8266f4d47f8951928 15828 admin extra dpsyco-mysql_1.0.22_all.deb 1b24027e7407fe7231a60604dfbd34f8 14740 admin extra dpsyco-samba_1.0.22_all.deb 7fa3a90cb94bb0bc0ecaf40db8d50883 9068 admin extra dpsyco-cfengine_1.0.22_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TvMGGKGxzw/lPdkRAh6SAJ4kfgnSI4FV1x/soZLlrsq8X9L/EwCgmWn1 N0ys2/z1bYNmKBY+SfSULQE= =+nlL -END PGP SIGNATURE- Accepted: dpsyco-base_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-base_1.0.22_all.deb dpsyco-cfengine_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-cfengine_1.0.22_all.deb dpsyco-devel_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-devel_1.0.22_all.deb dpsyco-doc_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-doc_1.0.22_all.deb dpsyco-lib_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-lib_1.0.22_all.deb dpsyco-mysql_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-mysql_1.0.22_all.deb dpsyco-patch_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-patch_1.0.22_all.deb dpsyco-samba_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-samba_1.0.22_all.deb dpsyco-skel_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-skel_1.0.22_all.deb dpsyco-ssh_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-ssh_1.0.22_all.deb dpsyco-sudo_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco-sudo_1.0.22_all.deb dpsyco_1.0.22.dsc to pool/main/d/dpsyco/dpsyco_1.0.22.dsc dpsyco_1.0.22.tar.gz to pool/main/d/dpsyco/dpsyco_1.0.22.tar.gz dpsyco_1.0.22_all.deb to pool/main/d/dpsyco/dpsyco_1.0.22_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-net-telent-date 1:0.4.1-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 00:54:03 -0600 Source: cl-net-telent-date Binary: cl-net-telent-date Architecture: source all Version: 1:0.4.1-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: cl-net-telent-date - Common Lisp utilities for printing and parsing dates Changes: cl-net-telent-date (1:0.4.1-1) unstable; urgency=low . * New upstream Files: 30feba3fa9acc56c0347ec627c45de23 616 devel optional cl-net-telent-date_0.4.1-1.dsc 0de6847e19f01bdff082fbb52bd87e5e 10681 devel optional cl-net-telent-date_0.4.1.orig.tar.gz 1a0f428d5025200b9c2bc3f73892acc3 2426 devel optional cl-net-telent-date_0.4.1-1.diff.gz 45a4dc90096dec3a72ba6b7c4339b939 12806 devel optional cl-net-telent-date_0.4.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TvkGES7N8sSjgj4RAuciAJ9DYhhy3/IuscLougfsyZ4qh1leSgCbB3/D /fLYjJfSqRJhm2dD1eEhdPQ= =jpgh -END PGP SIGNATURE- Accepted: cl-net-telent-date_0.4.1-1.diff.gz to pool/main/c/cl-net-telent-date/cl-net-telent-date_0.4.1-1.diff.gz cl-net-telent-date_0.4.1-1.dsc to pool/main/c/cl-net-telent-date/cl-net-telent-date_0.4.1-1.dsc cl-net-telent-date_0.4.1-1_all.deb to pool/main/c/cl-net-telent-date/cl-net-telent-date_0.4.1-1_all.deb cl-net-telent-date_0.4.1.orig.tar.gz to pool/main/c/cl-net-telent-date/cl-net-telent-date_0.4.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ctn 3.0.6-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 01:05:50 -0600 Source: ctn Binary: ctn-dev ctn Architecture: source i386 Version: 3.0.6-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: ctn- Runtime files for Central Test Node, a DICOM implementation ctn-dev- Development files for Central Test Node, a DICOM implementation Changes: ctn (3.0.6-1) unstable; urgency=low . * New upstream Files: de851bc7eea186abf145eaaacb1b1901 681 graphics extra ctn_3.0.6-1.dsc bb332398b06517d2755febfc4c05672f 1577960 graphics extra ctn_3.0.6.orig.tar.gz 5f22ebdfae577b2a9d1de195d0c51166 10014 graphics extra ctn_3.0.6-1.diff.gz ef646a4962f92cf9b18c8fe910d509b3 4319452 graphics extra ctn_3.0.6-1_i386.deb aecd239a21e914b7664f3409bbd6598c 366202 devel extra ctn-dev_3.0.6-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TvzxES7N8sSjgj4RAuk7AJ9sfQ+BS1i/m/W2dCiQexx4cVCo7gCfcVjs GqEfoSNu7T8Ubcv3Vdkqy6E= =gXtq -END PGP SIGNATURE- Accepted: ctn-dev_3.0.6-1_i386.deb to pool/main/c/ctn/ctn-dev_3.0.6-1_i386.deb ctn_3.0.6-1.diff.gz to pool/main/c/ctn/ctn_3.0.6-1.diff.gz ctn_3.0.6-1.dsc to pool/main/c/ctn/ctn_3.0.6-1.dsc ctn_3.0.6-1_i386.deb to pool/main/c/ctn/ctn_3.0.6-1_i386.deb ctn_3.0.6.orig.tar.gz to pool/main/c/ctn/ctn_3.0.6.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mailliststat 1.3-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 01:32:39 -0600 Source: mailliststat Binary: mailliststat Architecture: source i386 Version: 1.3-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: mailliststat - Displays statistics about mbox files Changes: mailliststat (1.3-1) unstable; urgency=low . * New upstream Files: f7dcf11831782650d1fc3eed43008b7a 578 mail optional mailliststat_1.3-1.dsc 926baeef8fc7cf41278e535cb5dd4c5e 45484 mail optional mailliststat_1.3.orig.tar.gz c3e01c1efccbc307fd96a1006dc8ae4b 2336 mail optional mailliststat_1.3-1.diff.gz fd4f66512304cbca19636e3c8273dc31 46202 mail optional mailliststat_1.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/TwIYES7N8sSjgj4RArQTAJ90rX9K6LPCgP5elOc9GlsM23ZtDwCeL3vh K79N42rqx07iBRUbpQjAPmw= =EFU3 -END PGP SIGNATURE- Accepted: mailliststat_1.3-1.diff.gz to pool/main/m/mailliststat/mailliststat_1.3-1.diff.gz mailliststat_1.3-1.dsc to pool/main/m/mailliststat/mailliststat_1.3-1.dsc mailliststat_1.3-1_i386.deb to pool/main/m/mailliststat/mailliststat_1.3-1_i386.deb mailliststat_1.3.orig.tar.gz to pool/main/m/mailliststat/mailliststat_1.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted manpages 1.60-2 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 29 Aug 2003 10:22:54 +0200 Source: manpages Binary: manpages manpages-dev Architecture: source all Version: 1.60-2 Distribution: unstable Urgency: low Maintainer: Martin Schulze [EMAIL PROTECTED] Changed-By: Martin Schulze [EMAIL PROTECTED] Description: manpages - Manual pages about using a GNU/Linux system manpages-dev - Manual pages about using GNU/Linux for development Closes: 207331 Changes: manpages (1.60-2) unstable; urgency=low . * Skip getxattr(2), lgetxattr(2) and fgetxattr(2) during installation since exactly the same manpage is in libattr1-dev as well (closes: Bug#207331) * In fact, skipped all xattr manpages that are also present in the libattr1-dev package. Files: e6b0816f5c043519fbf063be45fdfc09 583 doc - manpages_1.60-2.dsc 3c8af323b02b65377cb196bd17515499 47174 doc - manpages_1.60-2.diff.gz 8464c35a00cebfda469362a3b1faad10 365944 doc important manpages_1.60-2_all.deb 5c96c30298da1da6d52d37744c0bc14b 1000568 doc standard manpages-dev_1.60-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Tw7JW5ql+IAeqTIRAkJNAJ4qzi3C2LImLkVLaHvlH87DCFz79ACeNifb rY7Qp3Tdp++EyFM4+Q570+k= =edH3 -END PGP SIGNATURE- Accepted: manpages-dev_1.60-2_all.deb to pool/main/m/manpages/manpages-dev_1.60-2_all.deb manpages_1.60-2.diff.gz to pool/main/m/manpages/manpages_1.60-2.diff.gz manpages_1.60-2.dsc to pool/main/m/manpages/manpages_1.60-2.dsc manpages_1.60-2_all.deb to pool/main/m/manpages/manpages_1.60-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
