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/.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/.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 Makholm"Grisene 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/.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=91653&cid=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 /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 > * 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..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 /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]
I want to modify the gnome panel deb package
Hi, we are working for a distro which is using debian pacakges. By default the gnome panel is having no colour. I want to change the look and feel of the panel, Applications menu backgroud color, Window title background color..,etc. Just to make it look diferent with diffrent colors. I dont want to go with a new theme. can any one please tell me where this panel background colors I can change... I searched the gnome-panel pacakge, where there are some files called panel-applet-enums.c etc, where the PANEL-BACKGROUND id defined as NO BACKGROUND color. Is i the place where I need to modify??? If so how can I do it { I mean syntax of it } HELP PLEASE. Regards Indraveni.K
Why was V. Sehwag warned by the BCCI? Share your knowledge on Yahoo! Answers India
Send instant messages to your online friends - NOW
mdadm 2.4.1-1 ready for tests
Hi all, I have finished mdadm 2.4.1-1 and would like some people to look at it before I upload it, since I made some significant changes (no more mdrun, for instance (but it's not yet deprecated until initramfs-tools syncs)). Here's the changelog: mdadm (2.4.1-1) experimental; urgency=low * The "I'll kill that maintainer... uh, wait, it's me" release. Sorry for the delay, here's the long awaited new upstream release, which closes: Bug#318230, Bug#321751, Bug#337903, Bug#352798, Bug#363592, Bug#356153, Bug#271033 Oh, and we're moving away from that arch nightmare too. Sorry for the confusion. * Experimental release, because I really don't want to be responsible for data loss. Though I am quite sure that the upgrade is painless, I also don't have access to an 18 drive RAID 10 with multipath on s390 or similar arrangements. * We now make the /dev/md* devices in postinst unless /dev/md15 exists (no longer checking for /dev/md0), or unless devfs is in use. If udev is used, /dev/md15 will only exist in complex setups, so the devices will be made in /dev/.static by MAKEDEV, which is not really a concern. I opted against unconditionally calling MAKEDEV until #367407 is fixed so as to preserve custom permissions or owner settings. This also acknowledges the NMU (#299623). closes: Bug#310247, Bug#299623 * Patched some of the code to make mdadm honour /etc/mdadm/mdadm.conf over /etc/mdadm.conf (see NEWS). * /sbin/mdrun has been deprecated and replaced by calls to /sbin/mdadm; a proper deprecation warning is in place (see NEWS). * Fixed a couple of typos in the mdadm(8) manpage; thanks to Reuben Thomas. closes: Bug#345669, Bug#345667 * Updated Debconf translations: - Vietnamese by Clytie Siddall (closes: Bug#323950) - Czech by Miroslav Kure (closes: Bug#360290) - Russian by Yuri Kozlov (closes: Bug#361116) - French by Eric Madesclair (closes: Bug#323988) * Added new Debconf translations: - Swedish by Daniel Nylander (closes: Bug#333486) - Dutch by Frans Pop (closes: Bug#344714) You can download it from incoming.debian.org for the next 11 hours, then from experimental (after a little while): apt-get install -t experimental mdadm http://ftp.debian.org/debian/pool/main/m/mdadm/mdadm*2.4.1-1* Comments welcome. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system the early bird may get the worm, but the second mouse gets the cheese in the trap. signature.asc Description: Digital signature (GPG/PGP)
