Re: Creation of custom
On Mon, May 15, 2006 at 10:47:48AM +0200, [EMAIL PROTECTED] wrote: Am 15.05.2006 um 10:32 Uhr haben Sie geschrieben: CFEngine is in Debian, but has some real nasty frustrations. Puppet isn't in Debian, but Jamie is working hard on the packages and I've got some provisional ones built from his sources if you want to try it out. Puppet is fairly new on the scene, but is maturing fast, and has much less irritations. Well, of course I would like to try, that's why I asked ;-) You actually asked about custom packages, and might have rejected my suggestions as not fitting into your desired solution... grin So how can I get my (virtual) fingers on that (puppy) packages? Are they for sarge, otherwiese I will (have to) build some myself. The ones I've got are intended for Ubuntu Breezy (the SOE for the client I'm currently working for), but looking at the dependencies for all of the packages, there's nothing that Sarge wouldn't satisfy. I've put the debs up at http://www.hezmatt.org/~mpalmer/puppet/. Note that there's a new upstream version, but I don't have packages for that yet. What is the URL for puppy? http://reductivelabs.com/projects/puppet/ - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367456: general: text missing in menus and buttons inside window when using utf-8 locale (en_US.utf8)
Package: general Severity: normal I reported an issue with Cinepaint(#365801) and it occurs also with my instance of Dillo. Not the SIGFPE but the font issue. Two instances of the same bug I felt warranted a general report. If I find a third data point, it will really solidify this. If I use 'LC_ALL=en_US.utf8 dillo' I get no menu text and 'google search' button is blank. If I use 'LC_ALL=en_US dillo' it works fine. It maybe related to: X 7.0, gtk 1.2, unicode fonts or locales. That's my guess. Happy bug squashing! Kev -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-1-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
David Goodenough [EMAIL PROTECTED] writes: So are we getting close to the point where you will build gnucash-sql? I think so. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367456: general: text missing in menus and buttons inside window when using utf-8 locale (en_US.utf8)
reassign 367456 libgtk1.2 reassign 365678 libgtk1.2 severity 367456 important severity 365678 important severity 287520 important merge 287520 365649 365678 367456 thanks Kevin Mark [EMAIL PROTECTED] writes: I reported an issue with Cinepaint(#365801) and it occurs also with my instance of Dillo. Not the SIGFPE but the font issue. Two instances of the same bug I felt warranted a general report. If I find a third data point, it will really solidify this. If I use 'LC_ALL=en_US.utf8 dillo' I get no menu text and 'google search' button is blank. If I use 'LC_ALL=en_US dillo' it works fine. It maybe related to: X 7.0, gtk 1.2, unicode fonts or locales. GTK+-1.2 does not work properly in UTF-8 locales; it can't handle the fonts. If you try setting LANG=C and run the applications again, you should find the fonts then display properly. GTK+-1.2 is no longer maintained. These applications should have been ported to GTK+-2.0 several years ago. While not a fix, it's possible that a workaround in libgtk1.2 to set the locale LC_CTYPE to C/POSIX when it's using a UTF-8 codeset would at least make the applications usable, even if it breaks i18n. At this point we're just patching up abandoned code. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpLnhU6VP8R7.pgp Description: PGP signature
Re: gnome 2 gnucash into unstable
On Tuesday 16 May 2006 09:08, Thomas Bushnell BSG wrote: David Goodenough [EMAIL PROTECTED] writes: So are we getting close to the point where you will build gnucash-sql? I think so. Great. If you want someone to test the builds please let me know when they are ready and where I can download them. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creation of custom configured packages?
On Monday 15 May 2006 09:49, [EMAIL PROTECTED] wrote: Hi, in case I am in the wrong list, I beg you pardon, but I asked this already in debian-user without success. I would like to build customized, configured packages (for example additional bash script for the bash package, some default keybindings for screen, some host in /etc/ssh/known_hosts for ssh ... the list is endless), because maitainigs multiple systems becomes frustrating otherwise, if you maintain more than 2 computers (4 in my case). What would be the best (cleanest, most debian-like solution) be? I thought of meta-packages with pre-depends to the real packages and dpkg-divertions for the config files? you've just run into the main problem of CDD's (hence debian-custom would also be a good place to ask for help) Are there other possibilities? usual approaches are as follows (in order of preference): 1) use multilevel/modular config where available: usually in the form of a /etcc/something.d directory (e.g. /etc/apt/conf.d), or stacked config sets (e.g. the major desktop environments, see desktop-profiles package) 2) use debconf preseeding: con: only works before initial installation of whatever package of which you want to customize the configuration 3) use cfengine (or something similar) to customize the configuration: con: can't be automated in a policy compliant manner (though that's likely not a problem for your own use) long-term Debian solution is pushing for 1) -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgpph6AaoTFs3.pgp Description: PGP signature
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
On Tue, May 16, 2006 at 03:16:32AM +0200, Steinar H. Gunderson wrote: verbose and chatty about seemingly normal occasions. In general, I've only seen problems with it; even sendmail seems easier to get to work. With hand-written config file. Written in ed. With or without the Sendmail bible? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing: failure to use invoke-rc.d when required
Hi Lars! You wrote: The usage is mendantory (aka a must clause) but the bugs are not RC? This does not fit. It violates policy, but not in a way enumerated on http://release.debian.org/etch_rc_policy.txt, which means that it isn't release critical, unless I've misunderstood something. AFAIK, vilolating policy always waarent a serious bug: | serious |is a severe violation of Debian policy (roughly, it violates a |must or required directive), or, in the package maintainer's |opinion, makes the package unsuitable for release. [http://www.debian.org/Bugs/Developer#severities] -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#367456: general: text missing in menus and buttons inside window when using utf-8 locale (en_US.utf8)
Processing commands for [EMAIL PROTECTED]: reassign 367456 libgtk1.2 Bug#367456: general: text missing in menus and buttons inside window when using utf-8 locale (en_US.utf8) Bug reassigned from package `general' to `libgtk1.2'. reassign 365678 libgtk1.2 Bug#365678: xmms: Text in all menus and dialogue boxes is blank Bug reassigned from package `xmms' to `libgtk1.2'. severity 367456 important Bug#367456: general: text missing in menus and buttons inside window when using utf-8 locale (en_US.utf8) Severity set to `important' from `normal' severity 365678 important Bug#365678: xmms: Text in all menus and dialogue boxes is blank Severity set to `important' from `important' severity 287520 important Bug#287520: libgtk1.2: Fonts disappear when using LANG different from C Severity set to `important' from `normal' merge 287520 365649 365678 367456 Bug#287520: libgtk1.2: Fonts disappear when using LANG different from C Bug#365649: text doesn't display (e.g., in gtimer, e16keyedit, etc.) Bug#365678: xmms: Text in all menus and dialogue boxes is blank Bug#367456: general: text missing in menus and buttons inside window when using utf-8 locale (en_US.utf8) Merged 287520 365649 365678 367456. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Laptop support: acpi-support
* Raphael Hertzog ([EMAIL PROTECTED]) disait : Hello everybody, snip Since I'm definitely not an expert on this subject, I would welcome co-maintainers for this package and of course testers! I'm willing to help for this, feel free to tell me if I can give a hand Raphael. Best regards, Alexis. -- Alexis Sukrieh [EMAIL PROTECTED] 0x1EE5DD34 Debian http://www.debian.org Backup Manager http://www.backup-manager.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Peter 'p2' De Schrijver wrote: Being able to install multiple versions is some use to multiarch, but could also be used for other things, such if two packages provide the same binary (git for example). Or to install multiple 'version 'numbers' of the same package. The big problem then is when to install multiple versions of a binary? How should the depends decide when that is needed or wanted and when not? Esspecialy when different versions are available per architecture. One way of doing this would be to make a binary a special directory which contains the actual binary files for the architectures the binaries exist. AIX 1.x did this and allowed transparent execution of binaries in a heterogenous cluster. So if you would start a binary on IA32 AIX machine which only existed in a mainframe AIX version, the system would automatically start the binary on one of the mainframe AIX nodes in the cluster. If an IA32 AIX binary was available, it would locally start this binary. The 'binary directory' had the name, the binary would normally have. The actual binary files get the architecture name they implement as the filename. Eg: there would be an /bin/ls directory containing 2 files : i386, ibm370. How would programs or user specifiy what binary to call? How would You could explicitly start /bin/ls/i386 I think (which would fail if you did it on the wrong machine). The obvious problem here: The scheme is incompatible with non-multiarched software. It would at least require a package manager which specialcases /bin directory, a one-time conversion which moves the binaries, and some trickery for alternatives. Plus some more things which don't come to mind immediately, I guess. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creation of custom configured packages?
On Tue, 16 May 2006 10:28:57 +0200, cobaco (aka Bart Cornelis) [EMAIL PROTECTED] wrote: 1) use multilevel/modular config where available: usually in the form of a /etcc/something.d directory (e.g. /etc/apt/conf.d), or stacked config sets (e.g. the major desktop environments, see desktop-profiles package) conf.d directories are problematic when one wants to delete configuration pre-delivered by the Debian package. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Re: Re: screenshot with package description
I mean, all pics are in the same location, but can easyly installed using apt and friends and noone must download the whole tarballs. Even Modem or ISDN-Users would like to see screenshots of some packages/programs and huge tarballs are no sulution. $ apt-cache rdepends libx11-6|wc -l 2237 2237 x 40k = 90MB Some non X11 based application like mutt could have a screenshot too but we won't have 15 000 pixmaps. Tarball is a good solution for people who don't have an Internet connexion but some space on theirs hard drive. The tarballs will be copied from the CD/DVDROMs. If you have a connexion to a pixmap repository you won't have to feed a local cache. A slow connexion is enouch too retrieve 40kb pictures. Regards, Gonéri
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Steinar H. Gunderson [EMAIL PROTECTED] On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: Why not just install some software that can speak SMTP as the chroot's /usr/bin/sendmail? E.g. nullmailer. nullmailer is, in general, broken. Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. That would be accessible to _all_ programs whether they are written in Perl or not. There is a reason for having standardised interfaces. It is that they can be implemented in different ways. -- Henning Makholm En tapper tinsoldat. En dame i spagat. Du er en lykkelig mand ... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
How to detect the active debconf frontend?
Hi, how can I find out in postinst which debconf frontend is active? In case some particular command fails in postinst, we cannot proceed, and let it exit 1. However, to inform the user, we display a debconf error, telling him how to fix their system. But if the frontend is noninteractive, the error message will only be sent by e-mail; and if this happens in a chroot where no mail is configured, there's no chance at all to see that. So what we'd like to do is to check whether the frontend is noninteractive, and additionally output to stderr in that case. Therefore, I'm looking for a way to ask debconf about the frontend - is this possible? The alternative would be to check for $DEBIAN_FRONTEND, and if unset parse debconf-show debconf, but this doesn't look clean. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: multiarch status update
Scripsit Olaf van der Spek [EMAIL PROTECTED] Not true. For example, the kernel could be changed to pick the right Python binary if it sees #!/usr/bin/python. There is already a hook for doing that that in the kernel; no patching is required. See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. -- Henning MakholmGrisene fik gåsehud -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect the active debconf frontend?
Hi, On Tue, May 16, 2006 at 12:47:13PM +0200, Frank Küster wrote: Hi, how can I find out in postinst which debconf frontend is active? debconf-show debconf and some filter meight work. CU, Rudolf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect the active debconf frontend?
Rudolf Weeber [EMAIL PROTECTED] wrote: Hi, On Tue, May 16, 2006 at 12:47:13PM +0200, Frank Küster wrote: Hi, how can I find out in postinst which debconf frontend is active? debconf-show debconf and some filter meight work. You should have read my question to the end: , | Therefore, I'm looking for a way to ask debconf about the frontend - is | this possible? | | The alternative would be to check for $DEBIAN_FRONTEND, and if unset | parse debconf-show debconf, but this doesn't look clean. ` Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: multiarch status update
On 5/16/06, Henning Makholm [EMAIL PROTECTED] wrote: Scripsit Olaf van der Spek [EMAIL PROTECTED] Not true. For example, the kernel could be changed to pick the right Python binary if it sees #!/usr/bin/python. There is already a hook for doing that that in the kernel; no patching is required. See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. That's great. Could you tell me how to use those so that script A uses python 2.3 and script B uses python 2.4 without modifying the scripts?
Re: How to detect the active debconf frontend?
On 5/16/06, Frank Küster [EMAIL PROTECTED] wrote: Hi, how can I find out in postinst which debconf frontend is active? In case some particular command fails in postinst, we cannot proceed, and let it exit 1. However, to inform the user, we display a debconf error, telling him how to fix their system. But if the frontend is noninteractive, the error message will only be sent by e-mail; and if this happens in a chroot where no mail is configured, there's no chance at all to see that. So what we'd like to do is to check whether the frontend is noninteractive, and additionally output to stderr in that case. Therefore, I'm looking for a way to ask debconf about the frontend - is this possible? The alternative would be to check for $DEBIAN_FRONTEND, and if unset parse debconf-show debconf, but this doesn't look clean. Shouldn't a clean solution be done in debconf code and not in your package code?
Re: multiarch status update
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. That's great. Could you tell me how to use those so that script A uses python 2.3 and script B uses python 2.4 without modifying the scripts? Are you seriously proposing adding runtime python version selection to the kernel? /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. That's great. Could you tell me how to use those so that script A uses python 2.3 and script B uses python 2.4 without modifying the scripts? Are you seriously proposing adding runtime python version selection to the kernel? I don't care about the implementation details, but if it requires kernel support, then yes.
Re: multiarch status update
Olaf van der Spek [EMAIL PROTECTED] writes: On 5/16/06, Steinar H. Gunderson [EMAIL PROTECTED] wrote: On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: See the system calls link(2) and symlink(2). The (Essential) coreutils package provides a userspace binary /bin/ln which makes these calls available to shell scripts. That's great. Could you tell me how to use those so that script A uses python 2.3 and script B uses python 2.4 without modifying the scripts? Are you seriously proposing adding runtime python version selection to the kernel? I don't care about the implementation details, but if it requires kernel support, then yes. How should the kernel (or any other implementation) know which script requires which python version without the scripts declaring it? -- ilmari A disappointingly low fraction of the human race is, at any given time, on fire. - Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote: I don't care about the implementation details, but if it requires kernel support, then yes. How should the kernel (or any other implementation) know which script requires which python version without the scripts declaring it? Via configuration / meta data, a bit like package dependencies work now.
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Henning Makholm wrote: Scripsit Steinar H. Gunderson [EMAIL PROTECTED] On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: Why not just install some software that can speak SMTP as the chroot's /usr/bin/sendmail? E.g. nullmailer. nullmailer is, in general, broken. Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. That would be accessible to _all_ programs whether they are written in Perl or not. But I still not get it why not to use Email::Send and choose method there? Email::Send is not another sendmail replacement - it's abstract method for using mailers in way you want to use. There is a reason for having standardised interfaces. It is that they can be implemented in different ways. And each could be used with this module. eloy -- [EMAIL PROTECTED] jak to dobrze, że są oceany - bez nich byłoby jeszcze smutniej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Olaf van der Spek [EMAIL PROTECTED] writes: On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote: I don't care about the implementation details, but if it requires kernel support, then yes. How should the kernel (or any other implementation) know which script requires which python version without the scripts declaring it? Via configuration / meta data, a bit like package dependencies work now. Here's an idea: store the configuration meta data in the file itself, say, in the first line, following a comment starting with an exclamation mark. -- ilmari A disappointingly low fraction of the human race is, at any given time, on fire. - Stig Sandbeck Mathisen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote: Olaf van der Spek [EMAIL PROTECTED] writes: On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote: I don't care about the implementation details, but if it requires kernel support, then yes. How should the kernel (or any other implementation) know which script requires which python version without the scripts declaring it? Via configuration / meta data, a bit like package dependencies work now. Here's an idea: store the configuration meta data in the file itself, say, in the first line, following a comment starting with an exclamation mark. On 5/14/06, Michal Čihař [EMAIL PROTECTED] wrote: This would kill MD5 checksums of changed files...
Re: Creation of custom configured packages?
On Tuesday 16 May 2006 12:10, Marc Haber wrote: On Tue, 16 May 2006 10:28:57 +0200, cobaco (aka Bart Cornelis) [EMAIL PROTECTED] wrote: 1) use multilevel/modular config where available: usually in the form of a /etcc/something.d directory (e.g. /etc/apt/conf.d), or stacked config sets (e.g. the major desktop environments, see desktop-profiles package) conf.d directories are problematic when one wants to delete configuration pre-delivered by the Debian package. How so? As an admin you can always comment out any conf.d file completely if you don't want what is in there. After which dpkg will come with the usual prompt at package upgrade about the conf-file being changed allowing you to keep it that way without any effort. How is this significantly different from any other configuration provided by packages? -- Cheers, cobaco (aka Bart Cornelis) 1. Encrypted mail preferred (GPG KeyID: 0x86624ABB) 2. Plain-text mail recommended since I move html and double format mails to a low priority folder (they're mainly spam) pgp7zysTuFKEG.pgp Description: PGP signature
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
On Tue, 2006-05-16 at 11:04 +0200, Henning Makholm wrote: Scripsit Steinar H. Gunderson [EMAIL PROTECTED] On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: Why not just install some software that can speak SMTP as the chroot's /usr/bin/sendmail? E.g. nullmailer. nullmailer is, in general, broken. Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. Not all people have their systems configured that way. I'd venture to say that most home desktops that POP email from their ISP don't have their MTA set up to relay mail. That would be accessible to _all_ programs whether they are written in Perl or not. On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. There is a reason for having standardised interfaces. It is that they can be implemented in different ways. Yes. The standardized interface is smtp. -- - Ron Johnson, Jr. Jefferson, LA USA Yes, indeed, C isn't 'trendy' enough in the same way gas lighting isn't trendy enough: it's dangerous and it's completely obsolete. http://developers.slashdot.org/comments.pl?sid=91653cid=7893882 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Laptop support: acpi-support
[ Gah, resent with a valid d-devel in the Cc: line ] Buxy writes: Hello everybody, Ubuntu has made some efforts to better support a wide range of laptops and this resulted in some changes that are still not completely integrated in Debian. One of the changes is that they install automatically a package called acpi-support which provides lots of laptop-specific scripts. I asked Matthew Garrett to package it for Debian but he's not interested to maintain it because in his opinion this package is not a long-term solution. He prefers to invest time in pm-utils of freedesktop.org. Since I want Debian etch to work out of the box on most laptops, I uploaded acpi-support to Debian. It's right now in NEW, but the sources are in collab-maint SVN repository: svn+ssh://svn.debian.org/svn/collab-maint/deb-maint/acpi-support/trunk I would like this package to be added in the laptop task of Debian. Since I'm definitely not an expert on this subject, I would welcome co-maintainers for this package and of course testers! Paul Sladen has worked on the acpi support with Matthew for Ubuntu, and has just joined our NM queue to help work on exactly this kind of thing. I've copied him for information... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds signature.asc Description: Digital signature
Bug#367500: ITP: quackle -- graphical Scrabble-like crossword game and analysis tool
Package: wnpp Severity: wishlist Owner: Alec Berryman [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: quackle Version : 0.92 Upstream Authors: Jason Katz-Brown [EMAIL PROTECTED] John O'Laughlin [EMAIL PROTECTED] * URL : http://www.quackle.org/ * License : BSD Programming Lang: C++ Description : graphical Scrabble-like crossword game and analysis tool Quackle is a graphical Scrabble-like crossword game and analysis tool. It includes a computer opponent, move generator, and simulator and may be used with any board layout, alphabet, lexicon, and tile distribution. Screenshot available at http://www.quackle.org/images/quackle-0.92.png. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEadC3Aud/2YgchcQRAsmHAJ0cHMkseRtA1gKbW7056Y98jk7HhgCfcpWl XBLvJGFVGw/lA+UP2krVtLU= =1LeN -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Olaf van der Spek wrote: That depends on the implementation but I don't think it's not solvable. There's a bunch of claims from people who have worked on multiarch-related problems for a few years. You seem to think those claims are bogus, so I suggest you write up a solution which does all you think it should do instead of waving your hands about and saying I think this is solvable. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Buffer Image
I don't know. But it looks like this problem was discussed on the full-disclosure mailing list last year; see http://lists.grok.org.uk/pipermail/full-disclosure/2005-February/031928.html Hamish On Tue, May 16, 2006 at 06:11:10AM +0100, Indraveni wrote: How we can blank the RAM of Video Card. Suggest me please Please help Hamish Moffatt [EMAIL PROTECTED] wrote: On Mon, May 15, 2006 at 06:43:20AM +0100, Indraveni wrote: I am using debian and I am findng a bug in this. Whenever I am rebooting my system an image is being displayed on my screen, which is the last logout screen of the system. At which ever state I am logging out that same image is being displayed before i login my OS. ahy this image is displyed. Can any one tell me from where this Image is coming and how can I resolve it. I think it comes from the RAM on your video card. Basically nothing overwrote the image that was there last time the card was in that mode. Text mode uses a much smaller (and possibly different) section of the RAM. Anybody there who is working on it. Is it a problem? You could blank the RAM somehow if it's important. Hamish -- Hamish Moffatt VK3SB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] - Why was V. Sehwag warned by the BCCI? Share your knowledge on Yahoo! Answers India Send instant messages to your online friends - NOW -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Pierre Habouzit wrote: honnestly, please find *ONE* application where alternatives can't solve your problem, and where upstream design would still allow to have both instances installed. I've though hard enough, and I've found none. You might want to have, say, multiple installations of apache (because the 32 bit version uses PHP and you use a proprietary PHP plugin), while you want to serve DVD images with your 64 bit apache (since apache 2.2 isn't in unstable yet and so you need a 64 bit apache to handle 2GB files on 32 bit platforms). Your point still holds though, applications where coinstallation is needed are rare and in those cases applications can either implement a solution themselves or tell the user to use /usr/local or ~. - tfheen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
On 5/16/06, Tollef Fog Heen [EMAIL PROTECTED] wrote: Olaf van der Spek wrote: That depends on the implementation but I don't think it's not solvable. There's a bunch of claims from people who have worked on multiarch-related problems for a few years. You seem to think those claims are bogus, so I suggest you write up a solution which does all Which claims are you referring too and where did I say those are bogus? you think it should do instead of waving your hands about and saying I think this is solvable.
Re: How to detect the active debconf frontend?
Olaf van der Spek [EMAIL PROTECTED] wrote: The alternative would be to check for $DEBIAN_FRONTEND, and if unset parse debconf-show debconf, but this doesn't look clean. Shouldn't a clean solution be done in debconf code and not in your package code? Yes, #367497 Thanks, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
* Ron Johnson [EMAIL PROTECTED] [060516 15:14]: Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. Not all people have their systems configured that way. I'd venture to say that most home desktops that POP email from their ISP don't have their MTA set up to relay mail. There a trend currently that more and more companies and universities (perhaps also more ISPs in the near future), are blocking outgoing SMTP trafic for everything but their mail server. On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. Yeah. Its a workaround to a common problem (that the local mta is not that easily configurable). That does not mean that it is better to extend the workaround than to solve the problem. There is a reason for having standardised interfaces. It is that they can be implemented in different ways. Yes. The standardized interface is smtp. The standard *NIX way to send mail is the sendmail symlink, the standard for computers to exchange their mails is SMTP. Thats a difference. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
The obvious problem here: The scheme is incompatible with non-multiarched software. It would at least require a package manager which specialcases /bin directory, a one-time conversion which moves the binaries, and some trickery for alternatives. Plus some more things which don't come to mind immediately, I guess. Hmm. I somehow recall that you could also do normal binaries. At least I can't remember that I always made this sort of 'binaries'. I'm not sure how AIX distinguished between both types though. I guess the 'directory binaries' had some magic bit set. L L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: multiarch status update
On Tue, May 16, 2006 at 02:11:08PM +0200, Olaf van der Spek wrote: That's great. Could you tell me how to use those so that script A uses python 2.3 and script B uses python 2.4 without modifying the scripts? That's trivial. Create a wrapper that somehow decides which python version to run and launches the application using the right interpreter. Install the wrapper as /usr/bin/python instead of the current symlink and you're done. No kernel support, no dpkg support, no apt support is needed. However, you can take this idea further: provided you have multiarched binaries, you could create a small file system using FUSE that generates such a wrapper on-the-fly based on the requested file name, and you could mount this file system as /usr/bin. Voila. The _real_ difficulties for supporting multiarched binaries are: - Transitioning every single binary from /usr/bin to /usr/lib/$ARCH/bin. Looking at the current /usr/X11R6 transition this is less than trivial. There may be tricks like moving the old /usr/bin to /usr/lib/fallback_arch/bin before mounting the wrapper filesystem over /usr/bin, and redirect every writes to /usr/bin to /usr/lib/fallback_arch/bin; that may fool dpkg enough so package management continues to work during the transition. - Decide which version/architecture to run if the user requests /usr/bin/blah. With the FUSE approach this can be made a per-user decision if someone dares to go through all the implications of a setuid program seeing a different /usr/bin/foo than a non-setuid program. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#366780: ITP: summain -- compute and verify file checksums
On Fri, May 12, 2006 at 12:41:54AM +0300, Lars Wirzenius wrote: Apart from supporting more file formats, summain differs from the traditional md5sum and sha1sum utilities by providing progress reporting, and via convenience features such as automatic recursion into directories, and looking up files relative to the location of the checksum file, rather than the current working directory. Have you looked at the cfv program, which is already packaged for Debian? There are a huge number of checksum programs out there; it would be nice if there could be fewer with a greater concentration of features - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
On Tue, 16 May 2006, Ron Johnson wrote: On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] Don Armstrong -- I now know how retro SCOs OSes are. Riotous, riotous stuff. How they had the ya-yas to declare Linux an infant OS in need of their IP is beyond me. Upcoming features? PAM. files larger than 2 gigs. NFS over TCP. The 80's called, they want their features back. -- Compactable Dave http://www3.sympatico.ca/dcarpeneto/sco.html http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
Don Armstrong wrote: reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] Except that many ISPs now block outbound port 25 (at least on consumer-level service), except for what is relayed through their mail servers. I guess it is a bit of a catch-22. What about modifying it to work through something like an http POST? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: multiarch status update
On Tuesday 16 May 2006 17:53, Gabor Gombas wrote: However, you can take this idea further: provided you have multiarched binaries, you could create a small file system using FUSE that generates such a wrapper on-the-fly based on the requested file name, and you could mount this file system as /usr/bin. Voila. Hum, mounting FUSE file system at /usr/bin seems a bit weak to me. I love using FUSE as an additional file system, but using it as a core file system seems a bit exagerated for me. Few things that I see: -- FUSE goes throught userland - kernel - Userland so it: ** May be an overhead for all /usr/bin calls. ** May be a potential security leak, like using LD_PRELOAD for a given user and use a custom fuse library for this user, with *any* /usr/bin filesystem you like -- FUSE module is not loaded by default, and some server maintainer would like te reFUSE using it... :-) -- Furthermore, what to do during bootstrap of the root file system? Because this should also be needed for /bin, so again overhead, security and loading at en early stage is not a solution for me... Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
On May 16, Roberto C. Sanchez [EMAIL PROTECTED] wrote: Except that many ISPs now block outbound port 25 (at least on consumer-level service), except for what is relayed through their mail servers. Agreed. It's not reasonable to expect that port 25 connections from large consumer ISPs will work. reportbug should use port 587 instead (see RFC2476 for details). -- ciao, Marco signature.asc Description: Digital signature
Re: gnome 2 gnucash into unstable
David Goodenough [EMAIL PROTECTED] writes: On Tuesday 16 May 2006 09:08, Thomas Bushnell BSG wrote: David Goodenough [EMAIL PROTECTED] writes: So are we getting close to the point where you will build gnucash-sql? I think so. Great. If you want someone to test the builds please let me know when they are ready and where I can download them. Mind you, the mention by someone else of hesitancy because of staleness of the code reminds me that I will ultimately defer to upstream's suggestions on this. I am more-or-less happy to put sql into the main gnucash, but that's dependent on it being more-or-less guaranteed not to hose non-sql users, even if the sql support is a disaster. I am not-too-inclined to do the previous separate packages strategy, unless it is necessitated by the inability of one package to support both sql and non-sql users. Still, my previous statements hold, which are that I'm not going to put sql in until gnucash migrates into testing, and it still hasn't because of a guile-1.6 build bug. Those who want progress on this front, would most advance it by helping to diagnose that bug. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
Bastian Blank [EMAIL PROTECTED] writes: On Sun, May 14, 2006 at 11:11:16PM -0700, Thomas Bushnell BSG wrote: I have just uploaded gnucash 1.9.6, And you should've used pbuilder to check if it is buildable. So I would love to use pbuilder on my fancy fast computer. It runs sarge. So when I try to make a sid chroot on it, it blows chunks because it wants to install a package that no longer exists in sid. I can't even see a way to say don't bother installing package foo, which would presumably be a perfectly sensible workaround. The bug logs are not helpful; they amount to a more-or-less complacent attitude that stable pbuilders will always have problems making unstable chroots. This is a disaster, and the solution for me is *not* to go ahead and run unstable or backported software on a critical server. So, since you have some control over pbuilder and cdebootstrap, is there a long-term solution here? (Perhaps, just perhaps, cdebootstrap might fetch from the archive the list of packages that it should install, rather than a hard-coded list.) But I don't really know, and I had trouble getting a clear impression from the bug logs. Pardon me if I've missed something obvious or misunderstood something. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: Being able to install multiple versions is some use to multiarch, but could also be used for other things, such if two packages provide the same binary (git for example). Or to install multiple 'version 'numbers' of the same package. The big problem then is when to install multiple versions of a binary? How should the depends decide when that is needed or wanted and when not? Esspecialy when different versions are available per architecture. One way of doing this would be to make a binary a special directory which contains the actual binary files for the architectures the binaries exist. AIX 1.x did this and allowed transparent execution of binaries in a heterogenous cluster. So if you would start a binary on IA32 AIX machine which only existed in a mainframe AIX version, the system would automatically start the binary on one of the mainframe AIX nodes in the cluster. If an IA32 AIX binary was available, it would locally start this binary. The 'binary directory' had the name, the binary would normally have. The actual binary files get the architecture name they implement as the filename. Eg: there would be an /bin/ls directory containing 2 files : i386, ibm370. How would programs or user specifiy what binary to call? How would You could explicitly start /bin/ls/i386 I think (which would fail if you did it on the wrong machine). users even know which binary is which if they have the same name and both packages are installed on the system? Just imagine the confusion of a user installing foo (which provides the same binary foo as bar) and calling foo gives him bars foo. That is totaly out of the question. Packages that provide the same (by name) binary (or even just file) MUST conflict. period. I don't think so. I see at least a few possible uses for this : 1) have a shared filesystem between machines of multiple architectures 2) test your programs on architectures you don't have by using qemu It might have its use there but it can't be simply done. The files from two packages must be disjunct. That was my point. Moving binaries into subdirs and calling them by their arch (e.g. /bin/ls/i486) would solve that. But something has to do this change. Either the packaging itself or dpkg when unpacking the deb. Both would mean a major change in what we (and everybody else) currently have. Lets say we do add special dirs for binaries and let dpkg manage them. How would that work with old and new debs mixed together? Should dpkg move all binaries into subdirs on upgrade once? Should it move binaries into subdirs when a second arch gets installed? Also what architecture should be called on x86_64 if both are there? i486 or amd64? Should that be configurable? I imagine that would need kernel support to work for #!/bin/sh and the like which again raises the question of compatibility. Weigh the gain against the work and hopefully you will see that the cost outweigh the gain by a lot. If you want to share a filesystem to i486 and amd64 systems I guess you could use a unionfs for amd64 that has i486 as base and then just adds the 64bit stuff. Thats probably far simpler and better than adding the complexity to dpkg. L L p2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Pardon me if I've missed something obvious or misunderstood something. No solution to the bug, but an easy workaround: Create a sarge chroot tar.gz on your sarge machine, change pbuilderrc to point to sid (I have copies for each distribution), and then update the tar.gz to sid, like this: /usr/sbin/pbuilder update --override-config --configfile /etc/pbuilderrc.sid Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: multiarch status update
I don't think so. I see at least a few possible uses for this : 1) have a shared filesystem between machines of multiple architectures 2) test your programs on architectures you don't have by using qemu It might have its use there but it can't be simply done. The files from two packages must be disjunct. That was my point. Moving binaries into subdirs and calling them by their arch (e.g. /bin/ls/i486) would solve that. But something has to do this change. Either the packaging itself or dpkg when unpacking the deb. Both would mean a major change in what we (and everybody else) currently have. That could just be part of the package. Ie. unpacking the files automatically puts them at the right place. Lets say we do add special dirs for binaries and let dpkg manage them. How would that work with old and new debs mixed together? Should dpkg move all binaries into subdirs on upgrade once? Should it move binaries into subdirs when a second arch gets installed? It is possible to have both 'normal' and 'directory' binaries at the same time. At least AIX managed to do that, although I don't exactly know how it did that. So this problem is probably non existant. Also what architecture should be called on x86_64 if both are there? i486 or amd64? Should that be configurable? What do you mean here ? I imagine that would need kernel support to work for #!/bin/sh and the like which again raises the question of compatibility. No. #!/bin/sh would just execute /bin/sh as usual. Weigh the gain against the work and hopefully you will see that the cost outweigh the gain by a lot. If you want to share a filesystem to i486 and amd64 systems I guess you could use a unionfs for amd64 that has i486 as base and then just adds the 64bit stuff. Thats probably far simpler and better than adding the complexity to dpkg. Well no. Because there is far more use then i486 and amd64. I don't think dpkg needs extra changes beyond being able to install packages for another architecture and doing the dependencies per architecture (which all is necessary for multiarch anyway). L L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
On Tue, 2006-05-16 at 13:20 -0400, Roberto C. Sanchez wrote: Don Armstrong wrote: reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] Except that many ISPs now block outbound port 25 (at least on consumer-level service), except for what is relayed through their mail servers. I guess it is a bit of a catch-22. What about modifying it to work through something like an http POST? That's what popcon does, I think. Remember, though, that reportbug *works*, simply and easily, be- cause it uses the $LANGUAGE smtp library. Why change what works? -- - Ron Johnson, Jr. Jefferson, LA USA You can either have software quality or you can have pointer arithmetic, but you cannot have both at the same time. Bertrand Meyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
David Goodenough [EMAIL PROTECTED] writes: So are we getting close to the point where you will build gnucash-sql? Upstream reports that the SQL subsystem is known not to work. So that means that until it gets to working, I certainly won't be building it for Debian. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
Frank Küster [EMAIL PROTECTED] writes: No solution to the bug, but an easy workaround: Create a sarge chroot tar.gz on your sarge machine, change pbuilderrc to point to sid (I have copies for each distribution), and then update the tar.gz to sid, like this: /usr/sbin/pbuilder update --override-config --configfile /etc/pbuilderrc.sid Splendid; works like a charm. Many thanks for your help. Thomas
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Krzysztof Krzyzaniak [EMAIL PROTECTED] That would be accessible to _all_ programs whether they are written in Perl or not. But I still not get it why not to use Email::Send and choose method there? Because one might not be programming in Perl. Email::Send is not another sendmail replacement - it's abstract method for using mailers in way you want to use. /usr/sbin/sendmail _is_ an abstract method for sending mail through the transport configured by the system administrator. -- Henning Makholm ... a specialist in the breakaway oxidation phenomena of certain nuclear reactors. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
bluez-pin: Crashes when used with --dbus
severity 363425 serious thanks Seems that package which advertises 'Bluetooth PIN helper with D-BUS support' in description should at least don't crash when used with D-BUS, so I think this bug is at least 'serious'. -- JID: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Ron Johnson [EMAIL PROTECTED] On Tue, 2006-05-16 at 11:04 +0200, Henning Makholm wrote: Scripsit Steinar H. Gunderson [EMAIL PROTECTED] On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: Why not just install some software that can speak SMTP as the chroot's /usr/bin/sendmail? E.g. nullmailer. nullmailer is, in general, broken. Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. Not all people have their systems configured that way. The point is that they could if the wanted to. And if they did, it would work for _all_ programs, not just particular perl scripts that happen to use some obscure perl module to send mails. On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. Reportbug may be a special case in that. There is a reason for having standardised interfaces. It is that they can be implemented in different ways. Yes. The standardized interface is smtp. Not according to Debian policy. It is perfectly acceptable to have a way of moving mail to and from the machine that does not use SMTP at all, as long as it provides the standard /usr/sbin/sendmail interface for programs that need to send mail. -- Henning Makholm Science, by its nature, is an uncertain undertaking, and offers plenty of opportunity for failure no matter how you approach it. Yet among the myriad ways to get nowhere, the only fully reliable one is doing and thinking the same as everyone else. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Scripsit Olaf van der Spek [EMAIL PROTECTED] On 5/16/06, Dagfinn Ilmari Mannsåker [EMAIL PROTECTED] wrote: Here's an idea: store the configuration meta data in the file itself, say, in the first line, following a comment starting with an exclamation mark. This would kill MD5 checksums of changed files... No it wouldn't. The metadata that says which version of Python the program is written in is put there by the Debian maintainer and stays content. The metadata the says which binary on the system implements that version of Python is represented by links in the file system. What do you think the problem is? -- Henning Makholm Also, the letters are printed. That makes the task of identifying the handwriting much more difficult. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
Frank Küster [EMAIL PROTECTED] writes: /usr/sbin/pbuilder update --override-config --configfile /etc/pbuilderrc.sid Ok, this gets me a good sid chroot. But I can't build with it. When I try to build, using, say, pbuilder build gnucash_1.9.6-3.dsc, I get seemingly normal pbuilder output, lots of Considering; Trying messages, then the apt run to install them, which reports: WARNING: The following packages cannot be authenticated! and then apt doesn't run, and instead prints: E: There are problems and -y was used without --force-yes Then I gut Trying to fix apt error and the same thing happens, ending with: E: There are problems and -y was used without --force-yes E: Unrecoverable error installing build-dependencies. E: pbuilder-satisfydepends failed. Presumably the problem is that the packages cannot be authenticated. Presumably that's because the key inside the chroot is the old 2005 one? How do I fix that? (Shouldn't this all be automatic? isn't that the point of pbuilder?)
Re: gnome 2 gnucash into unstable
Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Presumably the problem is that the packages cannot be authenticated. Presumably that's because the key inside the chroot is the old 2005 one? How do I fix that? $ grep apt.config /etc/pbuilderrc.sid APTCONFDIR=/etc/pbuilder/apt.config/ $ cat /etc/pbuilder/apt.config/apt.conf.d/allow-unauthenticated APT::Get::AllowUnauthenticated 1; $ I'm not saying this is the right fix; probably this can be done somehow cleanly. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: gnome 2 gnucash into unstable
Frank Küster [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Presumably the problem is that the packages cannot be authenticated. Presumably that's because the key inside the chroot is the old 2005 one? How do I fix that? $ grep apt.config /etc/pbuilderrc.sid APTCONFDIR=/etc/pbuilder/apt.config/ $ cat /etc/pbuilder/apt.config/apt.conf.d/allow-unauthenticated APT::Get::AllowUnauthenticated 1; $ I'm not saying this is the right fix; probably this can be done somehow cleanly. No way to actually *check* the signatures? I mean, I'm going to be signing the results of the build. I tried making a chroot with gnupg in it, but the same error happens. sigh. Bastian, you there?
Re: gnome 2 gnucash into unstable
Frank Küster [EMAIL PROTECTED] writes: Thomas Bushnell BSG [EMAIL PROTECTED] wrote: Presumably the problem is that the packages cannot be authenticated. Presumably that's because the key inside the chroot is the old 2005 one? How do I fix that? $ grep apt.config /etc/pbuilderrc.sid APTCONFDIR=/etc/pbuilder/apt.config/ $ cat /etc/pbuilder/apt.config/apt.conf.d/allow-unauthenticated APT::Get::AllowUnauthenticated 1; $ Doesn't work for me. # grep apt.config /etc/pbuilderrc APTCONFDIR=/etc/pbuilder/apt.config/ # cat /etc/pbuilder/apt.config/apt.conf.d/allow-unauthenticated APT::Get::AllowUnauthenticated 1; but the same errors persist.
Re: gnome 2 gnucash into unstable
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Doesn't work for me. # grep apt.config /etc/pbuilderrc APTCONFDIR=/etc/pbuilder/apt.config/ # cat /etc/pbuilder/apt.config/apt.conf.d/allow-unauthenticated APT::Get::AllowUnauthenticated 1; but the same errors persist. Apparently I also needed to update the chroot after doing this. pbuilder always costs me more time to set up than it could ever save me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
On Tue, 2006-05-16 at 19:18 +0200, Henning Makholm wrote: Scripsit Krzysztof Krzyzaniak [EMAIL PROTECTED] That would be accessible to _all_ programs whether they are written in Perl or not. But I still not get it why not to use Email::Send and choose method there? Because one might not be programming in Perl. So program in C or python or Ruby. Email::Send is not another sendmail replacement - it's abstract method for using mailers in way you want to use. /usr/sbin/sendmail _is_ an abstract method for sending mail through the transport configured by the system administrator. -- - Ron Johnson, Jr. Jefferson, LA USA Power concedes nothing without a demand. It never did and it never will. Frederick Douglass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote: Scripsit Ron Johnson [EMAIL PROTECTED] On Tue, 2006-05-16 at 11:04 +0200, Henning Makholm wrote: Scripsit Steinar H. Gunderson [EMAIL PROTECTED] On Mon, May 15, 2006 at 02:13:46PM +0200, Henning Makholm wrote: [snip] Then something else. One can easily envisage installing as /usr/bin/sendmail something that reads an email, immediately sends it to a smarthost via SMTP and exits with an error if a problem happened. No daemon, no local spool. Not all people have their systems configured that way. The point is that they could if the wanted to. And if they did, it would work for _all_ programs, not just particular perl scripts that happen to use some obscure perl module to send mails. mail-transport-agent postinst config scripts will have to be a lot more clever, then, and explain things like relayhosts to non- sysadmins. -- - Ron Johnson, Jr. Jefferson, LA USA A woman should dress to attract attention. To attract the most attention, a woman should be either nude or wearing something as expensive as getting her nude is going to be. P.J. O'Rourke, satirist -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect the active debconf frontend?
Frank Küster wrote: Olaf van der Spek [EMAIL PROTECTED] wrote: The alternative would be to check for $DEBIAN_FRONTEND, and if unset parse debconf-show debconf, but this doesn't look clean. Shouldn't a clean solution be done in debconf code and not in your package code? Yes, #367497 Your proposed workaround breaks when the bug is fixed.. Also, if you see the current debconf TODO: Noninteractive frontend: * Just because it's noninteractive doesn't mean it can't output to the console. I think it should so so, at least for errors (in addition to mailing them). That way if an error is displayed and the package install fails you don't just see it dying, you immediatly see why. So patches accepted for this bug. As to the actual question, debconf, by intention, does not provide programs a way to know what frontend is being used. Encouraging fronted-specific behavior leads to unncessary complexity and bugs. -- see shy jo signature.asc Description: Digital signature
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
On Tue, 2006-05-16 at 08:44 -0700, Don Armstrong wrote: On Tue, 16 May 2006, Ron Johnson wrote: On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] bugs.d.o is the *destination*, not the journey. -- - Ron Johnson, Jr. Jefferson, LA USA The First Amendment protects speech from being censored by the government; it does not regulate what private parties (such as most employers) do. http://www.eff.org/Privacy/Anonymity/blog-anonymously.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mass bug filing: failure to use invoke-rc.d when required
ti, 2006-05-16 kello 09:53 +0200, Bas Zoetekouw kirjoitti: Hi Lars! You wrote: The usage is mendantory (aka a must clause) but the bugs are not RC? This does not fit. It violates policy, but not in a way enumerated on http://release.debian.org/etch_rc_policy.txt, which means that it isn't release critical, unless I've misunderstood something. AFAIK, vilolating policy always waarent a serious bug: | serious |is a severe violation of Debian policy (roughly, it violates a |must or required directive), or, in the package maintainer's |opinion, makes the package unsuitable for release. [http://www.debian.org/Bugs/Developer#severities] This is not what Steve Langasek tells me (or else I'm seriously misunderstanding). The etch_rc_policy.txt document is what documents what is release critical. As an example (mine, not Steve's), policy mandates that a package must remove its log files when it is purged. Some packages do not. In most cases, this doesn't actually break anything, or reveal any secrets or have other catastrophic problems. The policy mandates it so that all packages do things in the same way, which makes life simpler for system administrators. It would, however, be silly to either delay the release for such a problem, or to remove a perfectly usable package just because it doesn't remove log files when the package is purged. -- Talk is cheap. Whining is actually free. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
On Tuesday 16 May 2006 19:24, Thomas Bushnell BSG wrote: David Goodenough [EMAIL PROTECTED] writes: So are we getting close to the point where you will build gnucash-sql? Upstream reports that the SQL subsystem is known not to work. So that means that until it gets to working, I certainly won't be building it for Debian. Thomas Oh well, I can but dream. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
Scripsit Ron Johnson [EMAIL PROTECTED] On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote: The point is that they could if the wanted to. And if they did, it would work for _all_ programs, not just particular perl scripts that happen to use some obscure perl module to send mails. mail-transport-agent postinst config scripts will have to be a lot more clever, then, and explain things like relayhosts to non- sysadmins. Are you implying that the perl library in question is able to figure out these things without guidance from the sysadmin? In that case the AI code that does it ought to be appropriated and worked into our MTA postinst scripts. -- Henning Makholm Monarki, er ikke noget materielt ... Borger! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
master/murphy downtime
Master and murphy are changing colos. This entails a shutdown, de-rack, move across town(not far, tho), and power back up. Est. time is 2 hours. Nat rules will be installed, so that access can continue at the old addresses. DNS will be updated after the move. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Tollef Fog Heen [EMAIL PROTECTED] writes: Pierre Habouzit wrote: honnestly, please find *ONE* application where alternatives can't solve your problem, and where upstream design would still allow to have both instances installed. I've though hard enough, and I've found none. You might want to have, say, multiple installations of apache (because the 32 bit version uses PHP and you use a proprietary PHP plugin), while you want to serve DVD images with your 64 bit apache (since apache 2.2 isn't in unstable yet and so you need a 64 bit apache to handle 2GB files on 32 bit platforms). Your point still holds though, applications where coinstallation is needed are rare and in those cases applications can either implement a solution themselves or tell the user to use /usr/local or ~. - tfheen But those apaches have to run on different ports or they should switch over seemlessly whenever the php plugin is used. So this needs a certain amount of package adoption already. Lets just add the alternatives there too. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Olaf van der Spek [EMAIL PROTECTED] writes: On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote: Bill Allombert [EMAIL PROTECTED] writes: On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: I so far haven't seen any compelling arguments for multiarchifying the whole archive including all of */bin. Personnally I would favor a new files hierachy that allow every arch-dependend files to be co-installable. Even if we are not able to take full advantage of it at once, it seems saner and more forward-looking than only allowing libraries to be co-installable. This might also make easier to have this new scheme adopted by other OS. Cheers, But would make it totaly incompatible with existing systems. Why do you think there's no compatible solution? Because basicaly all sources assume binaries go to prefix/bin. You want to break that. Also a lot of scripts expect binaries to be where they are and anything setting PATH too. We have thought hard about this over the last 2 years and nobody has come up with a non disruptive way to change binary location that is both upwards and downwards compatible. That certainly isn't a proof but untill someone comes up with a solution I will keep asuming there is none. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Olaf van der Spek [EMAIL PROTECTED] writes: On 5/15/06, Pierre Habouzit [EMAIL PROTECTED] wrote: Le Dim 14 Mai 2006 21:11, Olaf van der Spek a écrit : - Why would you want to have both types installed simultaneously anyway? For libraries the answer is simple, but multiarch applications simply don't seem useful to me. The solution would be to either forbid having Consider for example 32-bit and 64-bit Firefox with some extensions only available for 32-bit and others only for 64-bit. this is a dream. This also need that the application is able to deal with the fact that it has configuration for the 32 and 64 bits version coexisting cleanly. True. Did I say that it would be trivial? Or even a short-term solution? Algorithmicaly it is trivial: /etc/firefox/plugins.x86_64-linux-gnu /etc/firefox/plugins.i486-linux-gnu or /etc/x86_64-linux-gnu/firefox/... given the crap that is firefox configuration, you won't be able to have different lists of plugins for the 32 and 64 bits versions at the same time. Firefox was just an example. But a good one. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Matt Taggart and others [Wed, May 10 2006, 02:00:47AM]: http://wiki.debian.org/multiarch Looking at all that I have a simple question: do we need a such kind of invasive multiarch integration. There only things I have to use which are not available for native amd64. For this things, we could create installer packages which integrate that software and cook the whole dependency chain from i386 Debian packages, by relocating the files and editing the package attributes. This workaround can be created (or is already created) full painless than introducing a whole multiarch system. I agree with people argumenting that sometimes using i386 versions does mean real speedup but I don't believe that this does count. Eduard. What do you mean with invasive? Multiarch is designed to be implemented without disrupting the existing archive or mono-arch systems at any time. Each package can get converted to multiarch by itself and once a substantial number of packages have done so a multiarch dpkg/apt/aptitude can be used. There is some disruption to package sources but a lot of that is enforcing policy compliance, e.g. split binaries and conffiles out of library packages. I've written cross-archive (in the multiarch repository on alioth) to cook amd64 files to be coinstallable with i386 and am using that on a number of cluster system at work for a biarch 32/64 environment. Its predecessor (amd64-archive) is still in use by many people for OOo on amd64. But cooking the packages is not 100% successfull and involves a lot of diversions and alternatives. Every include file gets diverted, every binary in a library gets an alternative. All cooked packages depend on their uncooked other architecture version for pre/postinst/rm scripts, forcing both arch to be installed even if only the cooked one is needed. And still some things won't work without the multiarch dirs being used by any software using dlopen and similar. That includes X locales, gtk-pixmap, pango to start with. It also means the cooking has to patch maintainer scripts on the fly making it fragile with regard to changes in the debs it cooks. It works for a stable release but for unstable the constant stream of changes needed in the cooking script would be very disruptive for users. It also is disruptive to building packages. Build-Depends will only work for the native arch and not for the cooked packages and building for the cooked arch will give precooked Depends (I do cook shlibs files) so they are invalid for uploads. The one big reason for multiarch over biarch (manual or cooked) always has been to preserve Build-Depends and Depends lines in nearly all cases. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Daily built images for i386 include graphical installation option
At Debconf Joey Hess and I have integrated support for the graphical installer into the main build system for d-i. For now the support is for i386 only, but amd64 [1] and powerpc will follow very soon. This means that the daily built images [2] of the installer now include an option to boot the graphical (gtk/directfb based) installer as well as the familiar newt based installer. The following types of images support graphical installation: - businesscard CD - netinst CD - hd-media - gtk-miniiso (mini CD image; install is comparable to netboot installs) To boot the graphical version of the installer, type 'installgui' or 'expertgui' at the boot prompt. By default you will get the newt frontend. Thanks to everyone who has helped us with the udeb shlibs/dependency transition which has made the integration possible. Cheers, Frans Pop [1] Images for amd64 will only actually be available when we can resume daily builds for them; these are currently down as a result of the archive integration. [2] http://www.debian.org/devel/debian-installer/ Note: you need the _daily built_ images, not the Etch Beta2 ones pgpVYY1DVR3sh.pgp Description: PGP signature
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
Ron Johnson [EMAIL PROTECTED] writes: On Tue, 2006-05-16 at 08:44 -0700, Don Armstrong wrote: On Tue, 16 May 2006, Ron Johnson wrote: On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] bugs.d.o is the *destination*, not the journey. Isn't the default that reprotbug asks on the first run whether to use the local fetchmail / ISPs smpt or send to bugs.d.o now? What do you want? Skip the question and default to bugs.d.o? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
Peter 'p2' De Schrijver [EMAIL PROTECTED] writes: Lets say we do add special dirs for binaries and let dpkg manage them. How would that work with old and new debs mixed together? Should dpkg move all binaries into subdirs on upgrade once? Should it move binaries into subdirs when a second arch gets installed? It is possible to have both 'normal' and 'directory' binaries at the same time. At least AIX managed to do that, although I don't exactly know how it did that. So this problem is probably non existant. But say you have the old i486 ls installed in /bin/ls and now you install the new amd64 ls in /bin/ls/x86_64. Wait a second. How do you create the dir when the file already exists? dpkg has to specialy handle this case for every package. Also what architecture should be called on x86_64 if both are there? i486 or amd64? Should that be configurable? What do you mean here ? Say I have /usr/bin/firefox/i486 and /usr/bin/firefox/x86_64. Which one should be the default? Where/how do I set the default? I never use flash so I want the x86_64 default. But userB always uses flash and wants i486. How do you set that up per user? I imagine that would need kernel support to work for #!/bin/sh and the like which again raises the question of compatibility. No. #!/bin/sh would just execute /bin/sh as usual. But /bin/sh then is a directory containing i486 and x86_64. Or just one of them. Or cotaining mips, mipsn32, mips64, mipsel, mipsn32el, mips64el, mips-abi32, mips-abi64, mips-abi32el, mips-abi64el. Weigh the gain against the work and hopefully you will see that the cost outweigh the gain by a lot. If you want to share a filesystem to i486 and amd64 systems I guess you could use a unionfs for amd64 that has i486 as base and then just adds the 64bit stuff. Thats probably far simpler and better than adding the complexity to dpkg. Well no. Because there is far more use then i486 and amd64. I don't think dpkg needs extra changes beyond being able to install packages for another architecture and doing the dependencies per architecture (which all is necessary for multiarch anyway). Multiarch (so far) does not allow the same path/file in 2 packages (with the exception of /usr/share/doc/ files) and all library packages have to move files so they are disjunct. You want more it seems. L L p2. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian and UDEV
Matt Zimmerman [EMAIL PROTECTED] writes: On Mon, May 15, 2006 at 12:14:48PM +0200, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't see it as a general issue either; if you have problems of this type, you should report them to the bug tracking system so that they can be fixed. Debian as an organization can't hope to test all of the hardware available in the market, so we rely on feedback from folks such as yourself to let us know when there is a problem. The most hideous problem of hotplug/udev is the following: You can't wait for an hotplug/udev event to be done processing. That is always done asynchron without any feedback of completion. You don't need to wait for a particular event to be finished processing; instead you should wait for the resource you actually need to become available, e.g. a device node. And how do you detect the resource not becoming available? Say I add a fsck script that runs before the final device node is created for any disk that gets added. That could take way longer than even the 3 minute timeout of the udevsettle. It would be useful to add a simple utility for this to debianutils or similar so that it doesn't need to be reimplemented in so many places. I don't see any way to make this utility without having a race condition as it is. udev has no concept of this rule is finished afaik. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
On Tue, 16 May 2006, Roberto C. Sanchez wrote: Don Armstrong wrote: reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] Except that many ISPs now block outbound port 25 (at least on consumer-level service), except for what is relayed through their mail servers. There's not much that can be done about that besides using 587 or similar. In such a case the user should be prompted for an smtp server which actually works instead of the default. [Indeed, that's what should happen when any smtp server is unreachable.] bugs.debian.org is the only sensible default. Anything else requires user configuration. What about modifying it to work through something like an http POST? I'm personally not too terribly interested in implementing an HTTP access method for the BTS, because it makes it more easy for bug submissions to be sent from people who can not be accessed via e-mail. I don't have a problem with someone else implementing such a service that actually verifies the e-mail address of people, though. [You don't need anything from me at all to do that.] Don Armstrong -- Il semble que la perfection soit atteinte non quand il n'y a plus rien a ajouter, mais quand il n'y a plus rien a retrancher. (Perfection is apparently not achieved when nothing more can be added, but when nothing else can be removed.) -- Antoine de Saint-Exupe'ry, Terres des Hommes http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: reportbug defaults [Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email]
On Wed, 2006-05-17 at 00:24 +0200, Goswin von Brederlow wrote: Ron Johnson [EMAIL PROTECTED] writes: On Tue, 2006-05-16 at 08:44 -0700, Don Armstrong wrote: On Tue, 16 May 2006, Ron Johnson wrote: On the home desktop reportbug uses Python's smtp library to send email directly to the ISP's smtp server. And that's a good thing, because, for a long time, reportbug did not have that feature, and people who don't know how to configure MTAs were not able to send bug reports. reportbug sends mail to wherever it is configured; the default setup should be to send mail to bugs.debian.org, not the ISP's smtp server, since that can't be known in advance. [I don't know if this is the default now, but it should be the default.] bugs.d.o is the *destination*, not the journey. Isn't the default that reprotbug asks on the first run whether to use the local fetchmail / ISPs smpt or send to bugs.d.o now? OK, I'm confused. Isn't the question How does the report gets from the computer to bugs.d.o?? sendmail or smtp library, right? When I first installed rb, it failed to work, because it wanted to use sendmail, and the only way my PC sent mail to the outside world was using my MUA pointing to smtp.myisp.net (because exim was set up for local delivery only). Later on, I tried again, and found that they had added (or made it more clear in reportbug --configure) the ability to use the user's ISP to transport the email. What do you want? Skip the question and default to bugs.d.o? -- - Ron Johnson, Jr. Jefferson, LA USA Peace has its victories no less than war, but it doesn't have as many monuments to unveil. Kin Hubbard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gnome 2 gnucash into unstable
David Goodenough [EMAIL PROTECTED] writes: On Tuesday 16 May 2006 19:24, Thomas Bushnell BSG wrote: David Goodenough [EMAIL PROTECTED] writes: So are we getting close to the point where you will build gnucash-sql? Upstream reports that the SQL subsystem is known not to work. So that means that until it gets to working, I certainly won't be building it for Debian. Oh well, I can but dream. You can also chip in or help recruit people. I believe there is nobody upstream who has a plan to actively work on SQL support. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: multiarch status update
But say you have the old i486 ls installed in /bin/ls and now you install the new amd64 ls in /bin/ls/x86_64. Wait a second. How do you create the dir when the file already exists? dpkg has to specialy handle this case for every package. That's probably a bit of a problem. But that doesn't detract from the usefulness of being able to have multiple binaries with the same path IMO. Also what architecture should be called on x86_64 if both are there? i486 or amd64? Should that be configurable? What do you mean here ? Say I have /usr/bin/firefox/i486 and /usr/bin/firefox/x86_64. Which one should be the default? Where/how do I set the default? The default would then be x86_64. I don't remember if AIX had a per process setting to change this. I never use flash so I want the x86_64 default. But userB always uses flash and wants i486. How do you set that up per user? You could use something like prctl for this. Note that current multiarch doesn't solve this problem either. But /bin/sh then is a directory containing i486 and x86_64. Or just one of them. Or cotaining mips, mipsn32, mips64, mipsel, mipsn32el, mips64el, mips-abi32, mips-abi64, mips-abi32el, mips-abi64el. So ? There is no difference between executing /bin/sh directly and having it done as an interpreter for a script. L L p2. -- goa is a state of mind signature.asc Description: Digital signature
Re: multiarch status update
On Wed, 2006-05-17 at 00:01 +0200, Goswin von Brederlow wrote: Olaf van der Spek [EMAIL PROTECTED] writes: On 5/15/06, Goswin von Brederlow [EMAIL PROTECTED] wrote: Bill Allombert [EMAIL PROTECTED] writes: On Sun, May 14, 2006 at 01:19:14AM +0200, Tollef Fog Heen wrote: I so far haven't seen any compelling arguments for multiarchifying the whole archive including all of */bin. Personnally I would favor a new files hierachy that allow every arch-dependend files to be co-installable. Even if we are not able to take full advantage of it at once, it seems saner and more forward-looking than only allowing libraries to be co-installable. This might also make easier to have this new scheme adopted by other OS. Cheers, But would make it totaly incompatible with existing systems. Why do you think there's no compatible solution? Because basicaly all sources assume binaries go to prefix/bin. You want to break that. Also a lot of scripts expect binaries to be where they are and anything setting PATH too. We have thought hard about this over the last 2 years and nobody has come up with a non disruptive way Is non-disruptive that vital? What about minimally disruptive, or a little disruptive? As a user, I'd put up with some one-time disruption if that means that I could have 64-bit coolness (after all, I'm a home user) while keeping 32-bit goodness like OOo2 w32codecs. to change binary location that is both upwards and downwards compatible. That certainly isn't a proof but untill someone comes up with a solution I will keep asuming there is none. -- - Ron Johnson, Jr. Jefferson, LA USA Politics is not the art of the possible. It consists in choosing between the disastrous and the unpalatable. John Kenneth Galbraith -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#367200: ITP: libemail-send-perl -- Simply Sending Email
On Tue, 2006-05-16 at 22:39 +0200, Henning Makholm wrote: Scripsit Ron Johnson [EMAIL PROTECTED] On Tue, 2006-05-16 at 19:21 +0200, Henning Makholm wrote: The point is that they could if the wanted to. And if they did, it would work for _all_ programs, not just particular perl scripts that happen to use some obscure perl module to send mails. mail-transport-agent postinst config scripts will have to be a lot more clever, then, and explain things like relayhosts to non- sysadmins. Are you implying that the perl library in question is able to figure out these things without guidance from the sysadmin? In that case the AI code that does it ought to be appropriated and worked into our MTA postinst scripts. Of course not. T-bird, Evo, Outlook, etc don't figure it out either. They ask the user, What's the name of your ISP's outgoing mail server? Here's the relevant question from reportbug --config Do you have a mail transport agent (MTA) like Exim, Postfix or SSMTP configured on this computer? [y|N|q|?]? If you take the default N, it asks you: Please enter the name of your SMTP host. Usually it's called something like mail.example.org or smtp.example.org. Just press ENTER if you don't have one or don't know. -- - Ron Johnson, Jr. Jefferson, LA USA Your opinions are bound to affect the stories you choose to broadcast [on TV/radio]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving GFDL documentation to non-free
Hi. I'm just a lowly user with a bandwidth problem. Certainly was a shock to get back from town to find the documentation gone from the debs I brought back. However, I am to make one last trip to town so it's my one shot chance to download the new additional debs where that documentation now lies. I need to know the names of those additional packages though, so I can tell dpkg --set-selections. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gok 1.0.10-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 07:19:08 +0200 Source: gok Binary: gok gok-doc Architecture: source i386 all Version: 1.0.10-1 Distribution: unstable Urgency: low Maintainer: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Changed-By: J.H.M. Dassen (Ray) [EMAIL PROTECTED] Description: gok- GNOME Onscreen Keyboard gok-doc- documentation files for the GNOME Onscreen Keyboard Changes: gok (1.0.10-1) unstable; urgency=low . * New upstream release. * [debian/patches/002_fixes-from-cvs.patch] Removed, upstream has now reverted the changes that broke building against the stable glib. Files: 69c3d4eadc685bce48c2640819921f42 1795 gnome optional gok_1.0.10-1.dsc 7947bc837ec34d3ba52bef3734095abb 1854222 gnome optional gok_1.0.10.orig.tar.gz 4be77fac59777a8a80da51feb9e242e7 103401 gnome optional gok_1.0.10-1.diff.gz d7a1a2618f6bcb5fa49787007a41ebe3 201084 doc optional gok-doc_1.0.10-1_all.deb 79dce9c0dca4e99d623bcf193925907a 1425494 gnome optional gok_1.0.10-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaWnJIwmOUm50p9ERAtXXAKDGr/ICzjK6jUFbpb7kuAxl4Z9U+gCgx/qC 4VA3Los4woxzHgZKpRqFx70= =HGnv -END PGP SIGNATURE- Accepted: gok-doc_1.0.10-1_all.deb to pool/main/g/gok/gok-doc_1.0.10-1_all.deb gok_1.0.10-1.diff.gz to pool/main/g/gok/gok_1.0.10-1.diff.gz gok_1.0.10-1.dsc to pool/main/g/gok/gok_1.0.10-1.dsc gok_1.0.10-1_i386.deb to pool/main/g/gok/gok_1.0.10-1_i386.deb gok_1.0.10.orig.tar.gz to pool/main/g/gok/gok_1.0.10.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted monit 1:4.8-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 07:04:58 +0200 Source: monit Binary: monit Architecture: source i386 Version: 1:4.8-2 Distribution: unstable Urgency: low Maintainer: Stefan Alfredsson [EMAIL PROTECTED] Changed-By: Stefan Alfredsson [EMAIL PROTECTED] Description: monit - A utility for monitoring and managing daemons or similar programs Changes: monit (1:4.8-2) unstable; urgency=low . * Applied patch for AMD64 bug (hopefully solving Bug#367341) Files: c9fc3389099e2d1177257559c410aaf3 593 admin optional monit_4.8-2.dsc f520ccdb702767ae2ce82cc33eb80ddd 9149 admin optional monit_4.8-2.diff.gz dfbcb7be35c101b589b634ce0aa75517 251506 admin optional monit_4.8-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEaXNf7WvuLRx04LcRAljSAJ40a6l1RXyo1rqSiJDu+adRc4HiAwCfVpHr R8wc4F7QWYlk4rhOIwFaO3U= =cacR -END PGP SIGNATURE- Accepted: monit_4.8-2.diff.gz to pool/main/m/monit/monit_4.8-2.diff.gz monit_4.8-2.dsc to pool/main/m/monit/monit_4.8-2.dsc monit_4.8-2_i386.deb to pool/main/m/monit/monit_4.8-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cl-sql 3.6.1-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 15 May 2006 21:07:47 -0600 Source: cl-sql Binary: cl-sql-sqlite3 cl-sql-oracle cl-sql-aodbc cl-sql-postgresql-socket cl-sql-postgresql cl-sql-odbc cl-sql cl-sql-uffi cl-sql-tests cl-sql-sqlite cl-sql-mysql Architecture: source all i386 Version: 3.6.1-1 Distribution: unstable Urgency: low Maintainer: Kevin M. Rosenberg [EMAIL PROTECTED] Changed-By: Kevin M. Rosenberg [EMAIL PROTECTED] Description: cl-sql - SQL Interface for Common Lisp cl-sql-aodbc - CLSQL database backend, AODBC cl-sql-mysql - CLSQL database backend, MySQL cl-sql-odbc - CLSQL database backend, ODBC cl-sql-oracle - CLSQL database backend, Oracle cl-sql-postgresql - CLSQL database backend, PostgreSQL cl-sql-postgresql-socket - CLSQL database backend, PostgreSQL cl-sql-sqlite - CLSQL database backend, SQLite cl-sql-sqlite3 - CLSQL database backend, SQLite3 cl-sql-tests - Testing suite for CLSQL cl-sql-uffi - Common UFFI functions for CLSQL database backends Closes: 352567 Changes: cl-sql (3.6.1-1) unstable; urgency=low . * New upstream, add documentation for db-reader and verified correct operation with symbol-function of symbol (closes: 352567) Files: e0652dce50b3b5961ba5b9d78dade8aa 796 devel extra cl-sql_3.6.1-1.dsc 11757bea68a542c09c076feccb0b0849 706955 devel extra cl-sql_3.6.1.orig.tar.gz 6749c6bdd4728d5788e01b28f35b299b 11478 devel extra cl-sql_3.6.1-1.diff.gz ded5c0ec82476d8c12beb7907273336b 493508 devel extra cl-sql_3.6.1-1_all.deb 3dc18e2efb7a356385f96a058cfe05f2 37234 devel extra cl-sql-aodbc_3.6.1-1_all.deb 8a1062e95e42f179bf986335f13b511c 63674 devel extra cl-sql-odbc_3.6.1-1_all.deb 0685f001a5d131afb3b1965ef6a7f6ef 41904 devel extra cl-sql-postgresql_3.6.1-1_all.deb 6d30732273f187739dc6bbb03e93b643 46052 devel extra cl-sql-postgresql-socket_3.6.1-1_all.deb 83f86085a279df0878c3a98d5d3e35c7 41784 devel extra cl-sql-sqlite_3.6.1-1_all.deb 46d21e749723543fdc5e4faf7abe90b2 42548 devel extra cl-sql-sqlite3_3.6.1-1_all.deb 4be209fae3da2dc4d7858af40d413099 58194 contrib/devel extra cl-sql-oracle_3.6.1-1_all.deb 9672e2e925e00c5694eda76a53db 60586 devel extra cl-sql-tests_3.6.1-1_all.deb 2919255e277859cf7e5f582c4c6d1bf8 40582 devel extra cl-sql-uffi_3.6.1-1_i386.deb 448d1dbbec58ca204471a5c5ecc41eb8 50978 devel extra cl-sql-mysql_3.6.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaXPZES7N8sSjgj4RAhqKAJ9NtNSjq2nue+oJvjuRIfWnAFbOpACffkKj 8XzXQwhFagwVgyeT4V9UrIs= =SfVN -END PGP SIGNATURE- Accepted: cl-sql-aodbc_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-aodbc_3.6.1-1_all.deb cl-sql-mysql_3.6.1-1_i386.deb to pool/main/c/cl-sql/cl-sql-mysql_3.6.1-1_i386.deb cl-sql-odbc_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-odbc_3.6.1-1_all.deb cl-sql-oracle_3.6.1-1_all.deb to pool/contrib/c/cl-sql/cl-sql-oracle_3.6.1-1_all.deb cl-sql-postgresql-socket_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-postgresql-socket_3.6.1-1_all.deb cl-sql-postgresql_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-postgresql_3.6.1-1_all.deb cl-sql-sqlite3_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-sqlite3_3.6.1-1_all.deb cl-sql-sqlite_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-sqlite_3.6.1-1_all.deb cl-sql-tests_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql-tests_3.6.1-1_all.deb cl-sql-uffi_3.6.1-1_i386.deb to pool/main/c/cl-sql/cl-sql-uffi_3.6.1-1_i386.deb cl-sql_3.6.1-1.diff.gz to pool/main/c/cl-sql/cl-sql_3.6.1-1.diff.gz cl-sql_3.6.1-1.dsc to pool/main/c/cl-sql/cl-sql_3.6.1-1.dsc cl-sql_3.6.1-1_all.deb to pool/main/c/cl-sql/cl-sql_3.6.1-1_all.deb cl-sql_3.6.1.orig.tar.gz to pool/main/c/cl-sql/cl-sql_3.6.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted classpath 2:0.91-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 05:35:36 + Source: classpath Binary: classpath-doc classpath-common-unzipped classpath-common classpath jikes-classpath Architecture: source all i386 Version: 2:0.91-2 Distribution: unstable Urgency: low Maintainer: Debian Java Maintainers pkg-java-maintainers@lists.alioth.debian.org Changed-By: Michael Koch [EMAIL PROTECTED] Description: classpath - clean room standard Java libraries classpath-common - architecture independent files classpath-common-unzipped - architecture independent files classpath-doc - free Java API documentation jikes-classpath - wrapper for jikes using classes from Classpath package Changes: classpath (2:0.91-2) unstable; urgency=low . * Set the correct version moc for architecture specific builds too. Files: 438923125873e049ca7b2e8c9063e7d7 1063 libs optional classpath_0.91-2.dsc 875d4faa4e3d435685be05c6eb5746d0 11945 libs optional classpath_0.91-2.diff.gz 938f7ad4e385c15e5f482ca7926d513b 7578294 libs optional classpath-common_0.91-2_all.deb bb5b4b0c50915e196a2334d0c2e09792 5388020 libs optional classpath-common-unzipped_0.91-2_all.deb 4721dff3838ae7bac9969e3a04d0428d 27725464 doc optional classpath-doc_0.91-2_all.deb 8d8d3ab36059df67da32f9c6ba0f526d 145858 libs optional jikes-classpath_0.91-2_all.deb cab0f639ba316212ec08be47a8eb5f86 422376 libs optional classpath_0.91-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaWuYWSOgCCdjSDsRAvZ+AJkBSydZViN71K6Ysniwdn2kGLpjVACfYeIQ oFKZdN3enASqwZmv7g+9sxg= =wEzI -END PGP SIGNATURE- Accepted: classpath-common-unzipped_0.91-2_all.deb to pool/main/c/classpath/classpath-common-unzipped_0.91-2_all.deb classpath-common_0.91-2_all.deb to pool/main/c/classpath/classpath-common_0.91-2_all.deb classpath-doc_0.91-2_all.deb to pool/main/c/classpath/classpath-doc_0.91-2_all.deb classpath_0.91-2.diff.gz to pool/main/c/classpath/classpath_0.91-2.diff.gz classpath_0.91-2.dsc to pool/main/c/classpath/classpath_0.91-2.dsc classpath_0.91-2_i386.deb to pool/main/c/classpath/classpath_0.91-2_i386.deb jikes-classpath_0.91-2_all.deb to pool/main/c/classpath/jikes-classpath_0.91-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted workrave 1.8.3-1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 15 May 2006 15:40:59 +0200 Source: workrave Binary: workrave Architecture: source i386 Version: 1.8.3-1 Distribution: unstable Urgency: low Maintainer: Michael Piefel [EMAIL PROTECTED] Changed-By: Michael Piefel [EMAIL PROTECTED] Description: workrave - RSI prevention tool Closes: 320639 334972 357748 359931 365269 365270 Changes: workrave (1.8.3-1) unstable; urgency=low . * New upstream version - builds with G++ 4.2 (closes: #357748) - breaks cleanly while screen is locked (closes: #334972) - shouldnât crash anymore (or less regularly, closes: #365270) - applet popup menu is now accessible when all timers hidden (closes: #359931) - fixed Czech translation (closes: #365269) * New Brazilian Portuguese translation straight from Workrave issue tracker (closes: #320639 as well, I should hope) Files: 65c2c4a909d36e9ed8fa11b49cc26b69 678 gnome optional workrave_1.8.3-1.dsc e1fe49f6fdf9d725bd21d50e2e0dc20d 1604897 gnome optional workrave_1.8.3.orig.tar.gz 856737caa3d868c943ae74b09a6bf745 6474 gnome optional workrave_1.8.3-1.diff.gz 8e53f12029ea950e6bd80a1627fe2d5b 745678 gnome optional workrave_1.8.3-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaX3L5GwONXmN2VwRAmncAJ90jWzn7bixJa22p/H73lGeWYjCjgCfXJpI Aj+LCH6IbslCPpTRLYfuZCA= =Qbgy -END PGP SIGNATURE- Accepted: workrave_1.8.3-1.diff.gz to pool/main/w/workrave/workrave_1.8.3-1.diff.gz workrave_1.8.3-1.dsc to pool/main/w/workrave/workrave_1.8.3-1.dsc workrave_1.8.3-1_i386.deb to pool/main/w/workrave/workrave_1.8.3-1_i386.deb workrave_1.8.3.orig.tar.gz to pool/main/w/workrave/workrave_1.8.3.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgphoto2 2.1.6-10 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 09:06:33 +0200 Source: libgphoto2 Binary: libgphoto2-port0 libgphoto2-2-dev libgphoto2-2 Architecture: source i386 Version: 2.1.6-10 Distribution: unstable Urgency: low Maintainer: Frederic Peters [EMAIL PROTECTED] Changed-By: Frederic Peters [EMAIL PROTECTED] Description: libgphoto2-2 - gphoto2 digital camera library libgphoto2-2-dev - gphoto2 digital camera library (development files) libgphoto2-port0 - gphoto2 digital camera port library Changes: libgphoto2 (2.1.6-10) unstable; urgency=low . * print-udev-rules.c: fixed according to tip by Marcus Meissner, so it will match newer PTP cameras. Files: 835a6b3ef98921719a7c9a825356ad6c 900 libs optional libgphoto2_2.1.6-10.dsc 6667c571ba245c2f2861647b723b34dc 12066 libs optional libgphoto2_2.1.6-10.diff.gz 1fac47a71b8c07cfc5d0f26a76c0f538 575948 libdevel optional libgphoto2-2-dev_2.1.6-10_i386.deb f7ec09512d9a5c8e66fb35db5761dead 98416 libs optional libgphoto2-port0_2.1.6-10_i386.deb 317a8a7b8a4ac537f2e756d4b72c5b47 963742 libs optional libgphoto2-2_2.1.6-10_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaXv+oR3LsWeD7V4RAgm2AJ9HOe+c9IBhg/0171hfa+aO5tF/jwCfZ2tf 5WXiwSrqy+63jsF5zwdh3Ug= =3jx5 -END PGP SIGNATURE- Accepted: libgphoto2-2-dev_2.1.6-10_i386.deb to pool/main/libg/libgphoto2/libgphoto2-2-dev_2.1.6-10_i386.deb libgphoto2-2_2.1.6-10_i386.deb to pool/main/libg/libgphoto2/libgphoto2-2_2.1.6-10_i386.deb libgphoto2-port0_2.1.6-10_i386.deb to pool/main/libg/libgphoto2/libgphoto2-port0_2.1.6-10_i386.deb libgphoto2_2.1.6-10.diff.gz to pool/main/libg/libgphoto2/libgphoto2_2.1.6-10.diff.gz libgphoto2_2.1.6-10.dsc to pool/main/libg/libgphoto2/libgphoto2_2.1.6-10.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libgphoto2 2.1.99-11 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 09:09:30 +0200 Source: libgphoto2 Binary: libgphoto2-port0 libgphoto2-2-dev libgphoto2-2 Architecture: source i386 Version: 2.1.99-11 Distribution: experimental Urgency: low Maintainer: Frederic Peters [EMAIL PROTECTED] Changed-By: Frederic Peters [EMAIL PROTECTED] Description: libgphoto2-2 - gphoto2 digital camera library libgphoto2-2-dev - gphoto2 digital camera library (development files) libgphoto2-port0 - gphoto2 digital camera port library Changes: libgphoto2 (2.1.99-11) experimental; urgency=low . * print-udev-rules.c: fixed according to tip by Marcus Meissner, so it will match newer PTP cameras. (sync with 2.1.6-10) Files: 17069f2fd438989953d45697ed256363 937 libs optional libgphoto2_2.1.99-11.dsc ddb6d4585ec11b63850d41883d698a25 12353 libs optional libgphoto2_2.1.99-11.diff.gz 608ceb68d95e7e9f0bc0d989faf41c59 1703340 libdevel optional libgphoto2-2-dev_2.1.99-11_i386.deb c30eb1baed722320810f91fdef767c93 109336 libs optional libgphoto2-port0_2.1.99-11_i386.deb 781ad56f66a13ed8611045f366eb1335 971398 libs optional libgphoto2-2_2.1.99-11_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaX2coR3LsWeD7V4RAiprAJ9oQOYQBgWpisptohr/IRnlh+XQDACgmOUO yrtwsBIbqPEaqtP5gjbSlVs= =CqZA -END PGP SIGNATURE- Accepted: libgphoto2-2-dev_2.1.99-11_i386.deb to pool/main/libg/libgphoto2/libgphoto2-2-dev_2.1.99-11_i386.deb libgphoto2-2_2.1.99-11_i386.deb to pool/main/libg/libgphoto2/libgphoto2-2_2.1.99-11_i386.deb libgphoto2-port0_2.1.99-11_i386.deb to pool/main/libg/libgphoto2/libgphoto2-port0_2.1.99-11_i386.deb libgphoto2_2.1.99-11.diff.gz to pool/main/libg/libgphoto2/libgphoto2_2.1.99-11.diff.gz libgphoto2_2.1.99-11.dsc to pool/main/libg/libgphoto2/libgphoto2_2.1.99-11.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted klogic 1.62-7 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Fri, 12 May 2006 15:39:24 +0100 Source: klogic Binary: klogic Architecture: source i386 Version: 1.62-7 Distribution: unstable Urgency: low Maintainer: Chris Boyle [EMAIL PROTECTED] Changed-By: Chris Boyle [EMAIL PROTECTED] Description: klogic - digital circuit editor and simulator for KDE Closes: 360370 364185 Changes: klogic (1.62-7) unstable; urgency=low . * Bumped Standards-Version to 3.7.2.0. * Fixed spelling errors in description (thanks Simon Waters). (closes: #364185) * Installed upstream's example circuit files (thanks Miguel Gea Milvaques). (closes: #360370) Files: bffce6d6a74d6a592a8a4b9f63f423db 641 electronics optional klogic_1.62-7.dsc 577499cffe8925886d33261bcf00ac7e 2 electronics optional klogic_1.62-7.diff.gz d87e52f3b15d1ab29e39b84463dcd02d 312832 electronics optional klogic_1.62-7_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEZKDERi6ArLfYbg8RAm85AJ9t74anWywoFl2Mxbkg53OBpN4dIgCg3C98 wBItU4lG8QqRI+aOZ0wuryQ= =k08i -END PGP SIGNATURE- Accepted: klogic_1.62-7.diff.gz to pool/main/k/klogic/klogic_1.62-7.diff.gz klogic_1.62-7.dsc to pool/main/k/klogic/klogic_1.62-7.dsc klogic_1.62-7_i386.deb to pool/main/k/klogic/klogic_1.62-7_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rafkill 1.2.1-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 01:47:44 -0500 Source: rafkill Binary: rafkill-data rafkill Architecture: source i386 all Version: 1.2.1-1 Distribution: unstable Urgency: low Maintainer: Debian allegro packages maintainers [EMAIL PROTECTED] Changed-By: Sam Hocevar (Debian packages) [EMAIL PROTECTED] Description: rafkill- vertical shoot'em-up similar to Raptor: Call of the Shadows rafkill-data - graphics and audio data for rafkill Closes: 292742 Changes: rafkill (1.2.1-1) unstable; urgency=low . * New upstream release. * Upstream merged many Debian bugfixes and improvements, as well as the new title screen. * debian/control: + Set policy to 3.7.2. + Build-depend on scons that upstream now uses. + Removed build-dependencies on sharutils and bzip2. * Got rid of the rafkill/rafkill-data dependency loop. * Maxout shield is now far more expensive (Closes: #292742). Files: 838ea9884d5d5a61398cc8cde1d8f449 750 games optional rafkill_1.2.1-1.dsc e27a24d5a0c2e92ba13815d8d6638a6b 6209314 games optional rafkill_1.2.1.orig.tar.gz 76f09325022e40694c7f1328f9ab9535 122715 games optional rafkill_1.2.1-1.diff.gz ff788e942b03d5ec398738f4e653f4bb 6045032 games optional rafkill-data_1.2.1-1_all.deb 15d6ec6e5ccea61216ef04a7320582ee 150536 games optional rafkill_1.2.1-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaYm/fPP1rylJn2ERAiryAKCFPxIo/fjMEL2XwB0d+Y1vvzpYrgCePLcO xDpl4fXFfShweUA7CH88u4I= =l/wo -END PGP SIGNATURE- Accepted: rafkill-data_1.2.1-1_all.deb to pool/main/r/rafkill/rafkill-data_1.2.1-1_all.deb rafkill_1.2.1-1.diff.gz to pool/main/r/rafkill/rafkill_1.2.1-1.diff.gz rafkill_1.2.1-1.dsc to pool/main/r/rafkill/rafkill_1.2.1-1.dsc rafkill_1.2.1-1_i386.deb to pool/main/r/rafkill/rafkill_1.2.1-1_i386.deb rafkill_1.2.1.orig.tar.gz to pool/main/r/rafkill/rafkill_1.2.1.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted clamav-data 20060515.105500.1463 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 03:47:08 + Source: clamav-data Binary: clamav-data Architecture: source all Version: 20060515.105500.1463 Distribution: unstable Urgency: low Maintainer: Marc Haber [EMAIL PROTECTED] Changed-By: Marc Haber [EMAIL PROTECTED] Description: clamav-data - clamav data files Changes: clamav-data (20060515.105500.1463) unstable; urgency=low . * Automatically generated by clamav-getfiles. Files: 399080b5a3aa1b32afb11c15f3c64992 552 utils optional clamav-data_20060515.105500.1463.dsc e50ef1e15db6189d2c648c6c8865e888 4588348 utils optional clamav-data_20060515.105500.1463.tar.gz f4377ef13d01c7b0ada4ac4fcdfbaa61 4586684 utils optional clamav-data_20060515.105500.1463_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaY6jgZalRGu6PIQRAkeAAKC1fkPo44JqFaBcNz2AXPKQQKQJDACfXGNW 1Esx2XdZigsumBJce7ewJQU= =JYQs -END PGP SIGNATURE- Accepted: clamav-data_20060515.105500.1463.dsc to pool/main/c/clamav-data/clamav-data_20060515.105500.1463.dsc clamav-data_20060515.105500.1463.tar.gz to pool/main/c/clamav-data/clamav-data_20060515.105500.1463.tar.gz clamav-data_20060515.105500.1463_all.deb to pool/main/c/clamav-data/clamav-data_20060515.105500.1463_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted courier 0.53.1-4 (source i386 all)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Format: 1.7
Date: Tue, 16 May 2006 10:34:19 +0200
Source: courier
Binary: courier-mlm courier-ldap courier-faxmail courier-pcp courier-maildrop
courier-imap courier-mta-ssl courier-pop-ssl courier-base sqwebmail courier-ssl
courier-pop courier-mta courier-webadmin courier-imap-ssl courier-doc
Architecture: source i386 all
Version: 0.53.1-4
Distribution: unstable
Urgency: low
Maintainer: Stefan Hornburg (Racke) [EMAIL PROTECTED]
Changed-By: Stefan Hornburg (Racke) [EMAIL PROTECTED]
Description:
courier-base - Courier Mail Server - Base system
courier-doc - Courier Mail Server - Additional documentation
courier-faxmail - Courier Mail Server - Faxmail gateway
courier-imap - Courier Mail Server - IMAP server
courier-imap-ssl - Courier Mail Server - IMAP over SSL
courier-ldap - Courier Mail Server - LDAP support
courier-maildrop - Courier Mail Server - Mail delivery agent
courier-mlm - Courier Mail Server - Mailing list manager
courier-mta - Courier Mail Server - ESMTP daemon
courier-mta-ssl - Courier Mail Server - ESMTP over SSL
courier-pcp - Courier Mail Server - PCP server
courier-pop - Courier Mail Server - POP3 server
courier-pop-ssl - Courier Mail Server - POP3 over SSL
courier-ssl - Courier Mail Server - SSL/TLS Support
courier-webadmin - Courier Mail Server - Web-based administration frontend
sqwebmail - Courier Mail Server - Webmail server
Closes: 367404 367464
Changes:
courier (0.53.1-4) unstable; urgency=low
.
* add courier-authdaemon dependency to courier-base (Closes: #367464,
thanks to Ed Casas [EMAIL PROTECTED] for the report)
* updated config.{guess,sub} in courier subdirectory also
(Closes: #367404, thanks to Petr Salinger [EMAIL PROTECTED])
Files:
f6dca488c4f18b0859ea4cff77c57209 1196 mail optional courier_0.53.1-4.dsc
9ebfd844f4fbfb979e3b34b757eed28d 115354 mail optional courier_0.53.1-4.diff.gz
3c8401cbde362420cdba3f58716da7c7 350214 doc optional
courier-doc_0.53.1-4_all.deb
de4026a261a58a12859097e245c26439 215890 mail optional
courier-base_0.53.1-4_i386.deb
94fdd0706441b3db0522413f361540db 952122 mail optional
courier-maildrop_0.53.1-4_i386.deb
47a067725267926b56e062eab93204ff 112508 mail optional
courier-mlm_0.53.1-4_i386.deb
b71b55765b008901567e7b57a2ec42be 1354446 mail extra
courier-mta_0.53.1-4_i386.deb
aa5c68be03e7db33122cdcee47710d6a 30166 mail optional
courier-faxmail_0.53.1-4_i386.deb
220577b17567e4dba38f0ea6311f7f39 39842 mail optional
courier-webadmin_0.53.1-4_i386.deb
a022290413bf8b3a1df1823d48d05a3b 804566 mail optional
sqwebmail_0.53.1-4_i386.deb
d8a562401403a2015399d64fb59c6337 61132 mail optional
courier-pcp_0.53.1-4_i386.deb
15e5e04c439784e9450a00514e60efdc 48430 mail extra courier-pop_0.53.1-4_i386.deb
3107a5447a1d6f769747f7eb0a44d9ff 33668 mail optional
courier-ldap_0.53.1-4_i386.deb
6ee4e4eb6faa5b7a1ee39044250eee7e 21 mail optional
courier-ssl_0.53.1-4_i386.deb
e15da4ad86b75f1eda2d99e69ca9cc81 20524 mail extra
courier-mta-ssl_0.53.1-4_i386.deb
e1bbb89de9c55f272c03b0dd4bbff752 21954 mail optional
courier-pop-ssl_0.53.1-4_i386.deb
fa29c312be97386a9f728998647dd9cf 583188 mail extra
courier-imap_4.1.0-4_i386.deb
1f77e7444739c9e47423aeb46aa6e6cd 22238 mail extra
courier-imap-ssl_4.1.0-4_i386.deb
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEaZHVjgVfE5tya3ERAgkFAKDGDW7CGFm5rQ+WkFCEzgV2bBShggCg25r4
uQXVk6XDQ+ewOGkX/H/pqtI=
=27EQ
-END PGP SIGNATURE-
Accepted:
courier-base_0.53.1-4_i386.deb
to pool/main/c/courier/courier-base_0.53.1-4_i386.deb
courier-doc_0.53.1-4_all.deb
to pool/main/c/courier/courier-doc_0.53.1-4_all.deb
courier-faxmail_0.53.1-4_i386.deb
to pool/main/c/courier/courier-faxmail_0.53.1-4_i386.deb
courier-imap-ssl_4.1.0-4_i386.deb
to pool/main/c/courier/courier-imap-ssl_4.1.0-4_i386.deb
courier-imap_4.1.0-4_i386.deb
to pool/main/c/courier/courier-imap_4.1.0-4_i386.deb
courier-ldap_0.53.1-4_i386.deb
to pool/main/c/courier/courier-ldap_0.53.1-4_i386.deb
courier-maildrop_0.53.1-4_i386.deb
to pool/main/c/courier/courier-maildrop_0.53.1-4_i386.deb
courier-mlm_0.53.1-4_i386.deb
to pool/main/c/courier/courier-mlm_0.53.1-4_i386.deb
courier-mta-ssl_0.53.1-4_i386.deb
to pool/main/c/courier/courier-mta-ssl_0.53.1-4_i386.deb
courier-mta_0.53.1-4_i386.deb
to pool/main/c/courier/courier-mta_0.53.1-4_i386.deb
courier-pcp_0.53.1-4_i386.deb
to pool/main/c/courier/courier-pcp_0.53.1-4_i386.deb
courier-pop-ssl_0.53.1-4_i386.deb
to pool/main/c/courier/courier-pop-ssl_0.53.1-4_i386.deb
courier-pop_0.53.1-4_i386.deb
to pool/main/c/courier/courier-pop_0.53.1-4_i386.deb
courier-ssl_0.53.1-4_i386.deb
to pool/main/c/courier/courier-ssl_0.53.1-4_i386.deb
courier-webadmin_0.53.1-4_i386.deb
to pool/main/c/courier/courier-webadmin_0.53.1-4_i386.deb
courier_0.53.1-4.diff.gz
to pool/main/c/courier/courier_0.53.1-4.diff.gz
courier_0.53.1-4.dsc
to pool/main/c/courier/courier_0.53.1-4.dsc
Accepted activeldap 0.7.1-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 12:37:52 +0200 Source: activeldap Binary: libactiveldap-ruby-doc libactiveldap-ruby1.8 libactiveldap-ruby Architecture: source all Version: 0.7.1-1 Distribution: unstable Urgency: low Maintainer: Marc Dequènes (Duck) [EMAIL PROTECTED] Changed-By: Marc Dequènes (Duck) [EMAIL PROTECTED] Description: libactiveldap-ruby - an object-oriented interface to LDAP for Ruby libactiveldap-ruby-doc - an object-oriented interface to LDAP for Ruby libactiveldap-ruby1.8 - an object-oriented interface to LDAP for Ruby Changes: activeldap (0.7.1-1) unstable; urgency=low . * New upstream release. * Fixed Build-Depends/Build-Depends-Indep to ensure having necessary tools for clean rule. * Switched to quilt patch management system. * Refreshed shebang patch. * Ensure no RCS files slip into packages. * Increased Standards-Version to 3.7.2.0 (no changes). Files: 378d77242b06614653242dbfc1a0f949 1248 libs optional activeldap_0.7.1-1.dsc 39caf5fb8f7e54b72cf3eb4bd9566cf4 105810 libs optional activeldap_0.7.1.orig.tar.gz ea738c3082d5675f6013ad1cc7d9ce32 2503 libs optional activeldap_0.7.1-1.diff.gz 2d6483b775e222111f45eeff9689cd3e 8850 libs optional libactiveldap-ruby_0.7.1-1_all.deb 106eb94ce6c1fe9ef597e75728f7 137722 doc optional libactiveldap-ruby-doc_0.7.1-1_all.deb 958db1995cc56f93de7e78091732a7db 36456 libs optional libactiveldap-ruby1.8_0.7.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEaavhsczZcpAmcIYRAoD4AKCXun6S27hfUJeJSYJmMrGKOAcgiwCgiPJC 23qW/qJc/xZjFkAqpP+7gL8= =/H3q -END PGP SIGNATURE- Accepted: activeldap_0.7.1-1.diff.gz to pool/main/a/activeldap/activeldap_0.7.1-1.diff.gz activeldap_0.7.1-1.dsc to pool/main/a/activeldap/activeldap_0.7.1-1.dsc activeldap_0.7.1.orig.tar.gz to pool/main/a/activeldap/activeldap_0.7.1.orig.tar.gz libactiveldap-ruby-doc_0.7.1-1_all.deb to pool/main/a/activeldap/libactiveldap-ruby-doc_0.7.1-1_all.deb libactiveldap-ruby1.8_0.7.1-1_all.deb to pool/main/a/activeldap/libactiveldap-ruby1.8_0.7.1-1_all.deb libactiveldap-ruby_0.7.1-1_all.deb to pool/main/a/activeldap/libactiveldap-ruby_0.7.1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted jed 0.99.18-1 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 12:02:52 +0200 Source: jed Binary: jed jed-common xjed Architecture: source all i386 Version: 0.99.18-1 Distribution: experimental Urgency: low Maintainer: Debian JED Group [EMAIL PROTECTED] Changed-By: Rafael Laboissiere [EMAIL PROTECTED] Description: jed- editor for programmers (textmode version) jed-common - S-Lang runtime files for jed and xjed xjed - editor for programmers (x11 version) Closes: 345268 Changes: jed (0.99.18-1) experimental; urgency=low . * New upstream release . * debian/control: + the kfreebsd-i386 architecture does not have the package libgmpg1-dev; removed it from the Build-Depends list for this architecture (closes: #345268) [JS] . + removed the version condition from debhelper and libgmpg1-dev in Build-Depends, because the packages in stable are newer than this version. [JS] . + added the Uploaders: field [RL] . + removed x-dev as build dependency; this is a transition package [JS] . + added the Homepage pseudo header as the developers reference suggests it in section 6.2.4. [JS] . + decreased the version from the findutils dependency and replaced the -delete option in the compile script in jed-common; this makes backporting of the package easier. [JS] . + splitted the dependency lines to reflect the possible independent build targets. [JS] . + increased the Policy standard version; no changed needed [JS] . * debian/patches/00list: + disabled xrender extension and gpm support on hurd-i386 and kfreebsd-i386 now uniformly by dpatch [JS] . + applied patch from Aurelien Jarno for correct handling xrender and gpm on FreeBSD/Linux; Thanks to him for his help [JS] . * debian/rules: + added a get-orig-source target to [JS] . + splitted the architecture dependent and independent parts; It's now possible to build just one of them. This should decrease the effort to build the package on slower machines (arm, hppa). [JS] . * /usr/share/jed/lib/defaults.sl: + added code to support slang_load_path and doc_path for /usr/share/slsh/ introduced with SLang2 [JS] . + new function debian_startup() that evaluates the files in /etc/jed.d (This function is run by default with every startup, but not if * disabled with the --skip-debian-startup command line argument * jed is called via the `jed-script` symlink If a script needs the standard debian initialization (e.g. for functions in the jed-extra package), it can call debian_startup() explicitely. [GM] . * /usr/share/doc/jed-common/Debian-Jed-Policy.txt: + added a first draft for a policy about packages for Jed [JS] . * debian/jed-common.templates, debian/po/*: + converted to po-debconf [RL] . * debian/jed-common.postrm: + fixed bugged shell code that slipped into version 0.99.16-6 of the package that makes the upgrade from that version fails [RL] . [JS] Jörg Sommer [EMAIL PROTECTED] [GM] Guenter Milde [RL] Rafael Laboissiere [EMAIL PROTECTED] Files: a2731ca6eed3bcc75d5b8db8ca4b5067 790 editors optional jed_0.99.18-1.dsc 2d371046048cc7bd1686ee70c00ad495 971456 editors optional jed_0.99.18.orig.tar.gz 9bf033b2746d40abb4dd3da97fc8adf8 21980 editors optional jed_0.99.18-1.diff.gz 494d369acb69ad91cb9cc791d78726f6 116020 editors optional jed_0.99.18-1_i386.deb 72ae4a3eb2938f79953afa6a2d18ad98 130968 editors optional xjed_0.99.18-1_i386.deb 9fe80cd031cbe5d6d6699d9b23128813 582354 editors optional jed-common_0.99.18-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEabHzk3oga0pdcv4RAm28AKCA9ikNXya55OcBCP/Kdc55oUyZ0ACeJ0p7 TOAhq3BLkbf8hCpIN0uHjLM= =CpvB -END PGP SIGNATURE- Accepted: jed-common_0.99.18-1_all.deb to pool/main/j/jed/jed-common_0.99.18-1_all.deb jed_0.99.18-1.diff.gz to pool/main/j/jed/jed_0.99.18-1.diff.gz jed_0.99.18-1.dsc to pool/main/j/jed/jed_0.99.18-1.dsc jed_0.99.18-1_i386.deb to pool/main/j/jed/jed_0.99.18-1_i386.deb jed_0.99.18.orig.tar.gz to pool/main/j/jed/jed_0.99.18.orig.tar.gz xjed_0.99.18-1_i386.deb to pool/main/j/jed/xjed_0.99.18-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libfile-copy-recursive-perl 0.22-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 12:03:11 +0200 Source: libfile-copy-recursive-perl Binary: libfile-copy-recursive-perl Architecture: source all Version: 0.22-1 Distribution: unstable Urgency: low Maintainer: Debian Catalyst Maintainers [EMAIL PROTECTED] Changed-By: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] Description: libfile-copy-recursive-perl - Perl extension for recursively copying files and directories Changes: libfile-copy-recursive-perl (0.22-1) unstable; urgency=low . * New upstream release * debian/control: - Standards-Version increased to 3.7.2 without additional changes * debian/compat: - Increased to 5 Files: bc68cdcfa0d18fafb41d550f61562d00 777 perl optional libfile-copy-recursive-perl_0.22-1.dsc 553c19021864bf5a9e4aa8371f69971e 8608 perl optional libfile-copy-recursive-perl_0.22.orig.tar.gz 55522ee69bdb178243e27e0b943eefe3 2111 perl optional libfile-copy-recursive-perl_0.22-1.diff.gz 9f0e83bd983cec3f05b711222e295c5a 16542 perl optional libfile-copy-recursive-perl_0.22-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEabH6+NMfSd6w7DERApq/AJ9DI9rD0YNAaaE9iAJ5nDCZ7aRWkwCgrTgX e7E6tHazSHvpqvqQcLViAyQ= =6Nup -END PGP SIGNATURE- Accepted: libfile-copy-recursive-perl_0.22-1.diff.gz to pool/main/libf/libfile-copy-recursive-perl/libfile-copy-recursive-perl_0.22-1.diff.gz libfile-copy-recursive-perl_0.22-1.dsc to pool/main/libf/libfile-copy-recursive-perl/libfile-copy-recursive-perl_0.22-1.dsc libfile-copy-recursive-perl_0.22-1_all.deb to pool/main/libf/libfile-copy-recursive-perl/libfile-copy-recursive-perl_0.22-1_all.deb libfile-copy-recursive-perl_0.22.orig.tar.gz to pool/main/libf/libfile-copy-recursive-perl/libfile-copy-recursive-perl_0.22.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted cddb.bundle 0.2-2.1 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 13:40:26 +0200 Source: cddb.bundle Binary: cddb.bundle Architecture: source i386 Version: 0.2-2.1 Distribution: unstable Urgency: low Maintainer: Gürkan Sengün [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: cddb.bundle - Bundle for CDDB access for GNUstep Closes: 352408 Changes: cddb.bundle (0.2-2.1) unstable; urgency=low . * NMU * Fix build-dependencies (Closes: #352408) * Update FSF address in debian/copyright * Bump standards version Files: a317b5cbf49645c33d8e84dd785e5a37 605 sound optional cddb.bundle_0.2-2.1.dsc 3ccaf734c02e0a5fa4df26bc12b2c98b 2754 sound optional cddb.bundle_0.2-2.1.diff.gz 9318a7b06e2df70d709c06aa96fb2748 21064 sound optional cddb.bundle_0.2-2.1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEabpgpGK1HsL+5c0RAtN4AJ40UnWzNpHpYzevv2o40rn2jTmWhgCfbjxh z5Bkwdk9nH7G3G1fYJVTbao= =lwO5 -END PGP SIGNATURE- Accepted: cddb.bundle_0.2-2.1.diff.gz to pool/main/c/cddb.bundle/cddb.bundle_0.2-2.1.diff.gz cddb.bundle_0.2-2.1.dsc to pool/main/c/cddb.bundle/cddb.bundle_0.2-2.1.dsc cddb.bundle_0.2-2.1_i386.deb to pool/main/c/cddb.bundle/cddb.bundle_0.2-2.1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted lirc 0.8.0-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 May 2006 12:45:59 +0200 Source: lirc Binary: liblircclient-dev liblircclient0 lirc-svga lirc lirc-modules-source lirc-x Architecture: source all i386 Version: 0.8.0-2 Distribution: unstable Urgency: low Maintainer: lirc Maintainer Team [EMAIL PROTECTED] Changed-By: Julien Danjou [EMAIL PROTECTED] Description: liblircclient-dev - development files for LIRC client library liblircclient0 - LIRC client library lirc - Linux Infra-red Remote Control support lirc-modules-source - Linux Infra-red Remote Control support (kernel modules) lirc-svga - Linux Infra-red Remote Control support (svgalib dependent parts) lirc-x - Linux Infra-red Remote Control support (X dependent parts) Closes: 297170 312498 339544 342568 348390 348753 349641 350791 351723 352573 352767 364033 367274 Changes: lirc (0.8.0-2) unstable; urgency=low . [ Julien Danjou ] * Include etc/lirc in lirc-modules-source.dirs (Closes: #342568) * Fix compilation for non-root users (Closes: #297170) . [ Aurelien Jarno ] * Updated German debconf templates translation. Thanks to Franz Pletz (Closes: #367274). * Fixed typos in debconf templates (Closes: #312498). . lirc (0.8.0-1) experimental; urgency=low . [ Hector Garcia ] * New upstream release. (Closes: #349641, #352573) - Added support up to for 2.6.15 kernels. - dvico driver is enabled by default (Closes: #348753) * Removed 02_aclocal.dpatch, not needed anymore. * Ported 04_man_pages to this release. * Ported 01_irxevent.dpatch to this release. * Changed with-drivers to userspace to build only the userspace drivers and keep only the kernel-space on the modules package. * Added 02_Makefile.in.dpatch, to prevent autotools from getting run on every build. * Recompile with driver=userspace (Closes: #352767, #351723, #348390) . [ Julien Danjou ] * Add lirc_dev dependency to it87 * Fix build-depends on libsvga1-dev rather than svgalibg1-dev (Closes: #350791) * Add lircrcd * Add a patch to allow some drivers to compile with linux 2.6.16 * Add patches from Cyril Lacoux [EMAIL PROTECTED] - Compile all modules - Support 2 flavors for it87 (standard/digimatrix) - Improve debconf template - module-assistant works fine - Add missing files for gpio . [ Aurelien Jarno ] * Added Swedish debconf templates translation. Thanks to Daniel Nylander (Closes: #339544) * Added Dutch debconf templates translation. Thanks to Kurt De Bree (Closes: #364033) * Enable lirc-svga on amd64. * Added support for non-Linux architectures: - Don't build-depends on libasound2-dev on hurd-i386, kfreebsd-i386 and kfreebsd-amd64. - Added 05_non_linux.dpatch, to make lirc buildable on non-Linux architectures. - Added 06_libtool_kfreebsd.dpatch, to update libtool for GNU/kFreeBSD. * Changed lirc-modules-source from Arch: any to Arch: all. Files: 7a16e997312c0973669f243052bab485 1004 utils extra lirc_0.8.0-2.dsc 37bc57ba9d9e14bd240bab87d49e6bd1 75509 utils extra lirc_0.8.0-2.diff.gz e7afe347085e76f7923909bddb6b5a31 200224 utils extra lirc-modules-source_0.8.0-2_all.deb 501a1a9fc13687c270dd0a865787aab3 328580 utils extra lirc_0.8.0-2_i386.deb 6800cf6a37f558c539d5cf33818f2189 15358 utils extra lirc-x_0.8.0-2_i386.deb 2b9c24d1dc63674e4a7fd29f7620a3fb 5502 utils extra lirc-svga_0.8.0-2_i386.deb 3b7c22b18c942c3ddd5f5d4119199220 58094 libdevel extra liblircclient-dev_0.8.0-2_i386.deb e4f82c8dfd7dbd6d999760c73718aaac 55392 libs optional liblircclient0_0.8.0-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEabkhpGK1HsL+5c0RAk2pAJ9VQBlXd6sLM9oTYgP/mLn3/1ZXBACgzzZK NNFz4J92ciTW10qiu55NLMY= =mGt1 -END PGP SIGNATURE- Accepted: liblircclient-dev_0.8.0-2_i386.deb to pool/main/l/lirc/liblircclient-dev_0.8.0-2_i386.deb liblircclient0_0.8.0-2_i386.deb to pool/main/l/lirc/liblircclient0_0.8.0-2_i386.deb lirc-modules-source_0.8.0-2_all.deb to pool/main/l/lirc/lirc-modules-source_0.8.0-2_all.deb lirc-svga_0.8.0-2_i386.deb to pool/main/l/lirc/lirc-svga_0.8.0-2_i386.deb lirc-x_0.8.0-2_i386.deb to pool/main/l/lirc/lirc-x_0.8.0-2_i386.deb lirc_0.8.0-2.diff.gz to pool/main/l/lirc/lirc_0.8.0-2.diff.gz lirc_0.8.0-2.dsc to pool/main/l/lirc/lirc_0.8.0-2.dsc lirc_0.8.0-2_i386.deb to pool/main/l/lirc/lirc_0.8.0-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
