Re: More on icons for packages
On Wed, 26 Jan 2005, Dale C. Scheetz wrote: Thus it might be even better to define a policy the following way: 1. Put all XPMs for the use in Debian-Menu into /usr/share/menu/pixmaps 2. Put all PNGs (and others) into /usr/share/pixmaps if they are intended for applications which follow freedesktop.org specification I don't really see a need for the split. All menu icons should be xpm so any other icons are for some other purpose. Well there could be one reason: If you browse this directory in the worst case you see each icon twice (XPM and PNG) which might be really confusing for users. 3. Put a symlink ln -s /usr/share/menu/pixmaps/.xpm /usr/share/pixmaps if there is no PNG or whatever icon for this application to support both Debian-Menu and freedesktop.org These kinds of solutions lead to extra detail in package management and, of course see above ;-) Sure. If my argument above should be void then forget this item. If my idea (I'm really unsure whether it is good or not) is a real argument try adding this functionality to dh_menu. 4. File bug report or even create automagically via mogrify icons in /usr/share/menu/pixmaps/ if there are icons in /usr/share/pixmaps but the maintainer did not provide a XPM following the menu policy spcification. What package would be responsible for this mogrification? Damn, once there was the exact command line how to call this binary from imagemagick package in /usr/share/doc/menu but I can not find it any more ... Simplify, simplify, simplify ;-) Sure. I was just thinking about kind of arguments which might destroy over simplification. I would definitely go with you if you mean we need a more simple setup. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Wed, 26 Jan 2005 20:18:39 -0500 "Dale C. Scheetz" <[EMAIL PROTECTED]> wrote: > > Thus it might be even better to define a policy the following way: > > > >1. Put all XPMs for the use in Debian-Menu into > > /usr/share/menu/pixmaps > >2. Put all PNGs (and others) into /usr/share/pixmaps if they are > > intended for applications which follow freedesktop.org > > specification > > I don't really see a need for the split. All menu icons should be xpm > so any other icons are for some other purpose. I think the point is we don't want to be stuck we xpm till eternity. Especially because we have window/desktop managers that support better formats like png or svg for example and programs supplying them. grts Tim -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rebooting, non-root raid, udev
On Jan 27, Brian May <[EMAIL PROTECTED]> wrote: > Now I know what happens in practise, what is meant to happen in > theory? The kernel is fixed to provide an additional device which can be used to configure new RAID volumes. Kernel people are aware of this, but I have not seen any progress on this front so don't hold your breath. (Workaround: ditch the initrd and use kernel RAID autostart.) -- ciao, Marco signature.asc Description: Digital signature
Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
Package: wnpp Severity: wishlist @Bernard, I intend to package swsusp2 for Debian, just letting you know... * Package name: kernel-patch-swsusp2 Version : 2.1.5.15 Upstream Author : Bernard Blackham <[EMAIL PROTECTED]> * URL : http://softwaresuspend.berlios.de * License : GPL Description : software suspend 2 for linux kernel patch Software Suspend is most easily described as the Linux equivalent of Windows' hibernate functionality. It saves the contents of memory to disk and powers down. When the computer is started up again, it reloads the contents and the user can continue from where they left off. No documents need to be reloaded or applications reopened and the process is much faster than a normal shutdown and start up. Packages should be available from http://people.debian.org/~madduck/packages/stage/kernel-patch-swsusp2 sometime today. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (600, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10-1-k7 Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Depends: and commands used in maintainer scripts
X-Posting to -policy, because this might be a bug in Policy. I'm not subscribed to -policy, please Cc me unless you keep -devel in. Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Joel Aelwyn <[EMAIL PROTECTED]> writes: > >> On Wed, Jan 26, 2005 at 11:32:19AM +0100, Frank Küster wrote: >>> Hi, >>> >>> what is the reason why in the following sentence in Policy: >>> >>> , >>> | The Depends field should also be used if the postinst, prerm or postrm >>> | scripts require the package to be present in order to run. >>> ` >>> >>> the word "should" is used, not "must"? I'm asking here (not on -policy) >>> because I assume there must be a technical reason for it, but I really >>> can't think of any. [...] > It should still be must so failure to do so is a serious policy > violation (violation of a 'must' or 'required' directive). Do others also think this is an error in policy? Nobody would object if I raise severity of such a bug and address it in an NMU (which I'm going to do for a different RC bug, anyway)? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: advice on a patch set
martin f krafft wrote: > I am trying to package the swsusp2 kernel patch, which comes in > hundred little files. My thought was to simply concat these files > into one large patch for use with kpatches... however, this does not > work because some files are created by early patches and later > modified. Since kpatches first tests the patch with --dry-run, it > will fail when the later patches do not find a file to patch. Have you considered just using Bernard's apply script that is included with the upstream swsusp package? I'm pretty sure it takes care of testing with --dry-run and backing out previous patches if one of them fails. Cameron. signature.asc Description: Digital signature
Re: Depends: and commands used in maintainer scripts
Frank Küster <[EMAIL PROTECTED]> wrote: > Do others also think this is an error in policy? Nobody would object if > I raise severity of such a bug and address it in an NMU (which I'm going > to do for a different RC bug, anyway)? I can answer the second question myself: According to http://release.debian.org/sarge_rc_policy.txt, this is a *must* for sarge, so the severity is RC anyway. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: acpi vs apm
Matthew Garrett wrote: > 1) Dealing with network interfaces and the like sensibly - at the > moment, this will often require unloading and reloading modules pre/post > suspend Yup. The hibernate package helps with this and can do quite a bit automatically by way of a "blacklisted modules" mechanism plus configuration options for bringing network interfaces up and down, killing and restarting programmes, mounting and unmounting filesystems and so on. > 2) Working with video state. The vbetool package makes it possible to > save and restore the graphics card state from userland, which tends to > work much better than the kernel fudges. In the long run, either X or > the framebuffer drivers need to get much better at programming the > video. Oooh, neat. With vbetool my laptop doesn't need any kernel hacks to resume properly and doesn't spit out as many worrying acpi warnings. I'm about to write a hibernate scriptlet for doing this soon. Cheers, Cameron. signature.asc Description: Digital signature
Re: advice on a patch set
also sprach Cameron Patrick <[EMAIL PROTECTED]> [2005.01.27.1045 +0100]: > Have you considered just using Bernard's apply script that is > included with the upstream swsusp package? I'm pretty sure it > takes care of testing with --dry-run and backing out previous > patches if one of them fails. Good idea, I will try this. Right now, my custom solution works. But you are right, stupid me not to have thought of this before... -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
On Thu, Jan 27, 2005 at 10:20:05AM +0100, martin f krafft wrote: > Package: wnpp > Severity: wishlist > > @Bernard, I intend to package swsusp2 for Debian, just letting you > know... > > * Package name: kernel-patch-swsusp2 > Version : 2.1.5.15 > Upstream Author : Bernard Blackham <[EMAIL PROTECTED]> Isn't Nigel Cunningham the primary author? Also, Bernard is in the NM queue, though he's been on hold for quite a while... -- Society is never going to make any progress until we all learn to pretend to like each other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rebooting, non-root raid, udev
* Brian May > 4. /etc/init.d/raid2 attempts to initialise the other RAID > partitions but fails to do so because the /dev/md* entries do not > exist. I believe that if you use mdadm to assemble your arrays, and ensure it is passed the --auto parameter, it should work. -- Tore Anderson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NM queue and groups [Was: NEW queue and ftp-master approval]
On Wed, Jan 26, 2005 at 12:08:27PM -0700, Joel Aelwyn wrote: > In fact, the parts you have chosen to keep, and respond to, are the far > *less* relevant portions of what I wrote. They existed as a demonstration > only of one reason I consider it important for people to have some > agreement on what the usage of "problems" means in our Social Contract Debating the definition of this word remains irrelevant, no matter how much nonsense you write about it. See previous message. Trying to reduce ethical issues to word games is, at best, childish. Grow up. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Depends: and commands used in maintainer scripts
On Wed, Jan 26, 2005 at 11:32:19AM +0100, Frank K?ster wrote: > what is the reason why in the following sentence in Policy: > > , > | The Depends field should also be used if the postinst, prerm or postrm > | scripts require the package to be present in order to run. > ` > > the word "should" is used, not "must"? I'm asking here (not on -policy) > because I assume there must be a technical reason for it, but I really > can't think of any. > > If a package is missing a Depends, and therefore will routinely fail in > prerm or postrm --remove, isn't that a release-critical bug? Failing to remove is a grave bug anyway. Policy doesn't really matter. Not every possible bug is written into policy. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Wed, 26 Jan 2005 08:12:36 -0200, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: >On Wed, 26 Jan 2005, David Pashley wrote: >> > The better fix IS to add an extra line to both incarnations of invoke-rc.d >> > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > >Make that "later". I just noticed one has to run the system's >/usr/sbin/policy-rc.d in preference to all else. Why? 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: NM queue and groups
Andrew Suffield <[EMAIL PROTECTED]> wrote: > On Wed, Jan 26, 2005 at 12:08:27PM -0700, Joel Aelwyn wrote: >> In fact, the parts you have chosen to keep, and respond to, are the far >> *less* relevant portions of what I wrote. They existed as a demonstration >> only of one reason I consider it important for people to have some >> agreement on what the usage of "problems" means in our Social Contract > > Debating the definition of this word remains irrelevant, no matter how > much nonsense you write about it. See previous message. To me, debating the interpretation of the sentence "We will not hide problems" does make sense, and is not irrelevant. The intention behind that debate (namely, to address the question of transparency within the Debian project) seems even more relevant to me. > Trying to reduce ethical issues to word games is, at best, > childish. Grow up. I can't see how he tried to do such a reduction. People *do* have different opinions on transparency in Debian, and they do have different opinions regarding the question whether our Social Contract does say something about transparence in Debian. This is not a word game, although the second part (does the Social contract already say anything about transparency?) surely is connected to different understanding of the word "problems" in that context. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Release update: kde3.3, upload targets, kernels, infrastructure
Re: Henning Makholm in <[EMAIL PROTECTED]> > Huh? I run one machine that is mostly woody but with sarge's libc6 and > a few selected other sarge packages. This seems to work impeccably in > general (I do know where to point my anger at when it doesn't, but in > those casses libc has never been involved). If sarge's libc6 were > *not* backwards compatible, it would have been called libc7. I upgraded a Woody box last week to Sarge's glibc/apt/dpkg/ openoffice.org/perl last week. The result was that Woody's mysql does not work with Sarge's glibc. It complains about missing GLIBC_2.2 symbols. I've then also upgraded mysql and things were fine again. The other thing that is likely to break for partial upgrades is stuff using DB, see for example #196917 on spamassassin breakage when perl is upgraded. Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Wed, 26 Jan 2005 08:12:36 -0200, Henrique de Moraes Holschuh > <[EMAIL PROTECTED]> wrote: > >On Wed, 26 Jan 2005, David Pashley wrote: > >> > The better fix IS to add an extra line to both incarnations of > >> > invoke-rc.d > >> > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > > > >Make that "later". I just noticed one has to run the system's > >/usr/sbin/policy-rc.d in preference to all else. > > Why? Because if any package that is NOT a policy-rc.d package is providing a policy-rc.d in /usr/sbin, it has a damn good reason to do so, and it should take precendence. Examples of damn good reasons are alternative initscript managers such as runit. If a package that is a policy-rc.d package is installed, then the local admin is supposed to take care of things (he should uninstall that package, if he wants to use his own policy-rc.d under /usr/local. Or register his policy-rc.d as an alternative and select that one, etc). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NM queue and groups
On Thu, Jan 27, 2005 at 01:26:15PM +0100, Frank K?ster wrote: > Andrew Suffield <[EMAIL PROTECTED]> wrote: > > > On Wed, Jan 26, 2005 at 12:08:27PM -0700, Joel Aelwyn wrote: > >> In fact, the parts you have chosen to keep, and respond to, are the far > >> *less* relevant portions of what I wrote. They existed as a demonstration > >> only of one reason I consider it important for people to have some > >> agreement on what the usage of "problems" means in our Social Contract > > > > Debating the definition of this word remains irrelevant, no matter how > > much nonsense you write about it. See previous message. > > To me, debating the interpretation of the sentence "We will not hide > problems" does make sense, and is not irrelevant. The intention behind > that debate (namely, to address the question of transparency within the > Debian project) seems even more relevant to me. The definition of 'problems' is not appreciably relevant to this. > > Trying to reduce ethical issues to word games is, at best, > > childish. Grow up. > > I can't see how he tried to do such a reduction. People *do* have > different opinions on transparency in Debian, and they do have different > opinions regarding the question whether our Social Contract does say > something about transparence in Debian. This is not a word game, Playing with the definition of 'problems' is precisely that. There's no ethical justification for it. Treating the sentence as an independent law, and arguing about ambiguities in the way it is phrased as if they were somehow important, is just word games - especially when they're clearly nonsensical in context. All the rational discussion has always been about what constitutes 'hiding', and the rational conclusion has always been the same: actively hiding problems is clearly bad, but failing to go to the trouble of documenting them isn't really, as you probably have better things to do, and it's written into the constitution that developers make their own decisions about what they spend their time on. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, Jan 27, 2005 at 10:37:05AM -0200, Henrique de Moraes Holschuh wrote: > On Thu, 27 Jan 2005, Marc Haber wrote: > > On Wed, 26 Jan 2005 08:12:36 -0200, Henrique de Moraes Holschuh > > <[EMAIL PROTECTED]> wrote: > > >On Wed, 26 Jan 2005, David Pashley wrote: > > >> > The better fix IS to add an extra line to both incarnations of > > >> > invoke-rc.d > > >> > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > > > > > >Make that "later". I just noticed one has to run the system's > > >/usr/sbin/policy-rc.d in preference to all else. > > > > Why? > > Because if any package that is NOT a policy-rc.d package is providing a > policy-rc.d in /usr/sbin, it has a damn good reason to do so, and it should > take precendence. Examples of damn good reasons are alternative initscript > managers such as runit. Packages providing /usr/sbin/policy-rc.d are required to use the alternatives system anyway. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NM queue and groups
* Andrew Suffield ([EMAIL PROTECTED]) [050127 13:55]: > All the rational discussion has always been about what constitutes > 'hiding', and the rational conclusion has always been the same: You mean: you never changed your mind? That's probably true, but that doesn't make you to the master of the interpretation of the SC. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[no subject]
Hi, I don't know, if I'm right, but as I'm a Debian-Fan I'd like to contribute software (I wrote) to other. This software is downloadable at: http://web.uta4you.at/shop/ This programs are: Atto - simple, fast and small Line Editor FreeDoc - mind-mapping-program and a plain-text-documentation software TextDraw - (ascii) drawing of line-, rectangle-, ellipse- and text-objects TextPrint - (ascii-based) chart generator C - scientific RPN-calculator TextSlide - (Ascii-Text)Presentation Program Unfortunately I don't have the time to perfectly maintain this software. If I'm not right at your address - please mail me another. Regards Dieter Schoppitsch (Vienna) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: your mail
Re: Schoppitsch Dieter in <[EMAIL PROTECTED]> > This software is downloadable at: > http://web.uta4you.at/shop/ Hi, if you want to have these programs in Debian, you have to file the proper WNPP wishlist bugs. See [1]. If you want to package them yourself, read the maint-guide [2]. [1] http://www.debian.org/devel/wnpp/ [2] http://www.debian.org/doc/maint-guide/ Christoph -- [EMAIL PROTECTED] | http://www.df7cb.de/ signature.asc Description: Digital signature
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Thu, Jan 27, 2005 at 10:37:05AM -0200, Henrique de Moraes Holschuh wrote: > > On Thu, 27 Jan 2005, Marc Haber wrote: > > > On Wed, 26 Jan 2005 08:12:36 -0200, Henrique de Moraes Holschuh > > > <[EMAIL PROTECTED]> wrote: > > > >On Wed, 26 Jan 2005, David Pashley wrote: > > > >> > The better fix IS to add an extra line to both incarnations of > > > >> > invoke-rc.d > > > >> > (sysv-rc's and file-rc's) to look under /usr/local/sbin first. > > > > > > > >Make that "later". I just noticed one has to run the system's > > > >/usr/sbin/policy-rc.d in preference to all else. > > > > > > Why? > > > > Because if any package that is NOT a policy-rc.d package is providing a > > policy-rc.d in /usr/sbin, it has a damn good reason to do so, and it should > > take precendence. Examples of damn good reasons are alternative initscript > > managers such as runit. > > Packages providing /usr/sbin/policy-rc.d are required to use the > alternatives system anyway. Yes, but they can use diversions when the entire policy-rc.d system has to be disabled, if need be. However, if invoke-rc.d searches /usr/local/sbin/policy-rc.d first, this whole safety net is disabled. So invoke-rc.d could be changed to look under /usr/local/sbin/policy-rc.d as well, but only if it failed to find a runnable policy-rc.d at /usr/sbin/policy-rc.d. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Henrique de Moraes Holschuh wrote: > Yes, but they can use diversions when the entire policy-rc.d system has to > be disabled, if need be. Make it a very high priority alternative. It is probably a bad idea to try our luck with diverting an alternative. Still, the rationale for /usr/local last holds. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NM queue and groups
Andrew Suffield <[EMAIL PROTECTED]> wrote: > All the rational discussion has always been about what constitutes > 'hiding', I have also read discussion about what we promise not to hide (before our users, and before fellow developers). I didn't get the impression that this discussion wasn't rational (although it may have been conducted in a rather emotional way sometimes). Maybe you just missed it. But may I point you to the fact that Joel just tried to start such a discussion (albeit only in a side note to a side note)? You didn't show that this was irrational (except by assertion that it is not possible to rationally discuss the meaning of the word "problems"). Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: NM queue and groups
Andreas Barth wrote: >* Andrew Suffield ([EMAIL PROTECTED]) [050127 13:55]: >> All the rational discussion has always been about what constitutes >> 'hiding', and the rational conclusion has always been the same: > >You mean: you never changed your mind? That's probably true, but that >doesn't make you to the master of the interpretation of the SC. Ssh. The great Suffield has spoken... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
also sprach Brian Nelson <[EMAIL PROTECTED]> [2005.01.27.1301 +0100]: > Isn't Nigel Cunningham the primary author? Apparently. I have had a hard time to find this information on the webpage... therefore I took a guess. I seems that Nigel is the author and Bernard the webmaster. I have written to both. > Also, Bernard is in the NM queue, though he's been on hold for > quite a while... Okay, well, tough luck for him. That said, he can take over the package when he's a DD. I need it now, but I don't insist on maintaining it. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, Jan 27, 2005 at 11:24:01AM -0200, Henrique de Moraes Holschuh wrote: > However, if invoke-rc.d searches /usr/local/sbin/policy-rc.d first, this > whole safety net is disabled. One could argue that the local admin explicitly requested to have that net disabled. > So invoke-rc.d could be changed to look under /usr/local/sbin/policy-rc.d as > well, but only if it failed to find a runnable policy-rc.d at > /usr/sbin/policy-rc.d. So how do I override a non-fitting /usr/sbin/policy-rc.d? Being forced to use a local diversion is not nice. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Thu, Jan 27, 2005 at 11:24:01AM -0200, Henrique de Moraes Holschuh wrote: > > However, if invoke-rc.d searches /usr/local/sbin/policy-rc.d first, this > > whole safety net is disabled. > > One could argue that the local admin explicitly requested to have that > net disabled. > > > So invoke-rc.d could be changed to look under /usr/local/sbin/policy-rc.d as > > well, but only if it failed to find a runnable policy-rc.d at > > /usr/sbin/policy-rc.d. > > So how do I override a non-fitting /usr/sbin/policy-rc.d? Being forced Remove the package providing it. The only two types of pacakge that are to provide policy-rc.d are packages that implement a policy-rc.d system (and if you don't want that, remove the package), AND packages that know they must disable invoke-rc.d for some weird reason (which I am kind of suspicious might be a mistake on the whole reasoning of whomever needs that, but I am playing safe). -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd howto
On Wed, 2005-01-26 at 20:16 +0100, Martin Zobel-Helas wrote: > Hi Soumyadip, > > On Thursday, 27 Jan 2005, Soumyadip Modak <[EMAIL PROTECTED]> wrote: > > However I couldn't find any documentation on how to setup buildds. Can > > anyone please provide pointers > > http://www.debian.org/devel/buildd/ > or > http://people.debian.org/~aba/buildd/ > > Greetings > Martin > -- > The human race never solves any of its problems. It merely outlives them. > -- David Gerrold Thanks to all who've written in. Am going through the details. Will have to present a proposal to the University officials to let me have a couple of permanent IP addresses to set up the buildd. :) Thanks -- Soumyadip Modak [EMAIL PROTECTED] [EMAIL PROTECTED] http://soumyadip.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
martin f krafft <[EMAIL PROTECTED]> wrote: > Okay, well, tough luck for him. That said, he can take over the > package when he's a DD. I need it now, but I don't insist on > maintaining it. I'm curious - what functionality do you need that isn't present in the stock kernel? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd howto
Soumyadip Modak <[EMAIL PROTECTED]> writes: > On Wed, 2005-01-26 at 20:16 +0100, Martin Zobel-Helas wrote: >> Hi Soumyadip, >> >> On Thursday, 27 Jan 2005, Soumyadip Modak <[EMAIL PROTECTED]> wrote: >> > However I couldn't find any documentation on how to setup buildds. Can >> > anyone please provide pointers >> >> http://www.debian.org/devel/buildd/ >> or >> http://people.debian.org/~aba/buildd/ >> >> Greetings >> Martin >> -- >> The human race never solves any of its problems. It merely outlives them. >> -- David Gerrold > > Thanks to all who've written in. Am going through the details. > > Will have to present a proposal to the University officials to let me > have a couple of permanent IP addresses to set up the buildd. :) > > Thanks The only thing you need is a mail account. Running a buildd with a dynamic IP or behind NAT is no problem. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release update: kde3.3, upload targets, kernels, infrastructure
On Thu, Jan 27, 2005 at 01:19:36PM +0100, Christoph Berg wrote: > Re: Henning Makholm in <[EMAIL PROTECTED]> > > Huh? I run one machine that is mostly woody but with sarge's libc6 and > > a few selected other sarge packages. This seems to work impeccably in > > general (I do know where to point my anger at when it doesn't, but in > > those casses libc has never been involved). If sarge's libc6 were > > *not* backwards compatible, it would have been called libc7. > I upgraded a Woody box last week to Sarge's glibc/apt/dpkg/ > openoffice.org/perl last week. The result was that Woody's mysql does > not work with Sarge's glibc. It complains about missing GLIBC_2.2 > symbols. I've then also upgraded mysql and things were fine again. $ ldd -d -r /usr/bin/mysqladmin libstdc++-libc6.2-2.so.3 => /usr/lib/libstdc++-libc6.2-2.so.3 (0x4002a000) libmysqlclient.so.10 => /usr/lib/libmysqlclient.so.10 (0x40073000) libz.so.1 => /usr/lib/libz.so.1 (0x400a9000) libcrypt.so.1 => /lib/tls/libcrypt.so.1 (0x400bb000) libnsl.so.1 => /lib/tls/libnsl.so.1 (0x400e8000) libm.so.6 => /lib/tls/libm.so.6 (0x400fc000) libc.so.6 => /lib/tls/libc.so.6 (0x4011e000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) symbol errno, version GLIBC_2.0 not defined in file libc.so.6 with link time reference (/usr/lib/libmysqlclient.so.10) $ This is a bug in the woody libmysqlclient10 package, which should not have been using errno in this way. It also only occurs when the TLS-enabled glibc is used, which is only the case if you are running a glibc kernel. So, partial upgrades are supported if you don't reboot to a 2.6 kernel prior to also upgrading libmysqlclient10 (or mysql-server). Cc:ed to the glibc folks, so they can consider how this should be handled. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
also sprach Matthew Garrett <[EMAIL PROTECTED]> [2005.01.27.1613 +0100]: > > Okay, well, tough luck for him. That said, he can take over the > > package when he's a DD. I need it now, but I don't insist on > > maintaining it. > > I'm curious - what functionality do you need that isn't present in the > stock kernel? swsusp in the stock kernel is very unstable. I have had better experience with swsusp2. That's all. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
On Thu, Jan 27, 2005 at 02:43:30PM +0100, martin f krafft wrote: > > Also, Bernard is in the NM queue, though he's been on hold for > > quite a while... > > Okay, well, tough luck for him. That said, he can take over the > package when he's a DD. I need it now, but I don't insist on > maintaining it. WRT me in the NM queue, I expected I'd been purged due to my inactivity, but it seems not! If you're not keen on maintaining it forever, I could continue on the NM process and pick it up at some point later. Kind regards, Bernard. -- Bernard Blackham -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292479: ITP: kernel-patch-swsusp2 -- software suspend 2 for linux kernel patch
also sprach Bernard Blackham <[EMAIL PROTECTED]> [2005.01.27.1642 +0100]: > WRT me in the NM queue, I expected I'd been purged due to my > inactivity, but it seems not! If you're not keen on maintaining it > forever, I could continue on the NM process and pick it up at some > point later. You can have it any time if you think you are up to the task. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: apply to NM? ha!
On Tue, 2005-01-25 at 16:02 +1000, Anthony Towns wrote: > Romain Francoise wrote: > > And Debian wouldn't be fun without a few enmities, we wouldn't have great > > posts like http://lists.debian.org/debian-legal/2004/07/msg01308.html or > > http://lists.debian.org/debian-devel-announce/2001/12/msg8.html... > > Huh, and here was me thinking those were perfect examples of the sort of > idiocy that just sucks the fun right out of Debian. I thought it was tongue in cheek myself. Yes, they do suck the "fun" out of Debian. Unfortunately, these are occurring at a regularly tested rate. Let us hope that the steady trend will decline in the near and long future. -- [EMAIL PROTECTED] REMEMBER ED CURRY! http://www.iwethey.org/ed_curry Novell's Directory Services is a competitive product to Microsoft's Active Directory in much the same way that the Saturn V is a competitive product to those dinky little model rockets that kids light off down at the playfield. -- Thane Walkup signature.asc Description: This is a digitally signed message part
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, Jan 27, 2005 at 12:09:11PM -0200, Henrique de Moraes Holschuh wrote: > Remove the package providing it. That might be a non-option. Greetins Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
In article <[EMAIL PROTECTED]> you wrote: >> BTW: I wonder why hwcap decisions are not cached in the ld.so.cache? > > Why don't you check /etc/ld.so.cache? Hint: > "strings /etc/ld.so.cache | grep /lib/tls" on i686. I know it places the libs in the cache, but it is still doing all the stats, why? Gruss Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
> Andreas Metzler <[EMAIL PROTECTED]> - Wed, Jan 26, 2005: > > > It is already linked from deveopers reference. > > It would be nice to have a package for this guide, for example to > request fixes and to make something official out of it. > > The author seems to be Junichi Uekawa, dancer at debian, and is hence a > logical packaging candidate. O:-) > > Junichi, do you have packaging plans for your guide? Should I fill an > RFP on it? I may try to package it; I was kind of waiting for inclusion into the developers reference, but the text format is different. libpkg-guide is written in docbook XML while developers reference is written in DebianDoc SGML. Considering that enough people seem to be feeling the itch for libpkg-guide package, and since I would consider using the BTS etc. for revision management of libpkg-guide, I might go around packaging it as a Debian package. Any objections? regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd howto
On Thu, 2005-01-27 at 16:31 +0100, Goswin von Brederlow wrote: > The only thing you need is a mail account. Running a buildd with a > dynamic IP or behind NAT is no problem. > > MfG > Goswin Hey that's good ! Thanks for the tip. :) -- Soumyadip Modak [EMAIL PROTECTED] [EMAIL PROTECTED] http://soumyadip.blogspot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Looking for a Korean native speaker for a few translation updates
Hello, fellow Debian developers and users, The Korean translation of Debian in general, and especially the Debian Installer, has been made up to now mostly by Changwoo Ryu, one of the few DD's in Korea. I'm however without news from him for several weeks now and we have, for D-I and "related" packages, a few translations which need updates. So, I'm seeking Korean speakers who could just one time look at a few translation files I may send them, and complete them. I will of course help people in case they're not familiar with translation tools and gettext stuff. As the work is quite small, I think this won't be a problem. I estimate the needed work to a few dozens of minutes, not more. Please contact me in private in case you can help. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292535: ITP: haskell-http -- Haskell HTTP client library
Package: wnpp Version: N/A; reported 2005-01-27 Severity: wishlist * Package name: haskell-http Version : 0.4.20041219 Upstream Author : Bjorn Bringert <[EMAIL PROTECTED]> * URL : http://www.bringert.net/haskell-xml-rpc/http.html * License : BSD Description : Haskell HTTP client library -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux urchin 2.4.29-rc2 #1 Wed Jan 12 23:46:31 GMT 2005 i686 Locale: LANG=C, LC_CTYPE=C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > Considering that enough people seem to be feeling the > itch for libpkg-guide package, and since I would > consider using the BTS etc. for revision management > of libpkg-guide, I might go around packaging it as a > Debian package. > > > Any objections? IIRC there were some people who objected to some of the contents of the document. But even for those it is probably better to have a Debian package - if it's important, the discussion will take place in bug reports, instead of not taking place. Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
soft kcuxzfh
McAfee Personal Firewall Plus 2004 v. 5.0 MS Windows 2003 Server Enterprise Edition Symantec Norton Ghost 2003 Linux Redhat 7.3 Adobe InCopy CS Adobe Premiere Pro 1.5 Norton Internet Security Pro 2004 Adobe Photoshop Elements 2.0 Adobe Illustrator CS/11 and more on http://fansoft.info/in.php?aid=57 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292546: ITP: ps2client -- ps2client is a command line interface to intereact with ps2link/ps2netfs on Playstation 2 systems equiped with Network Adaptors. it allows you to manage binaries, upload and run homebrew apps on the Playstation 2, and manage ps2netfs moutning, unmounting, copying from/to devices on the Playstation 2 (ie: memcard). Copyright 2004 Dan Peori , under the BSD License. http://ps2dev.org/kb.x?T=985
Package: wnpp Severity: wishlist Owner: Jose de Paula Eufrasio Junior <[EMAIL PROTECTED]> * Package name: ps2client Version : 2.0.0 Upstream Author : Dan Peori <[EMAIL PROTECTED]> * URL : http://ps2dev.org/kb.x?T=985 * License : BSD Description : ps2client is a command line interface to intereact with ps2link/ps2netfs on Playstation 2 systems equiped with Network Adaptors. it allows you to manage binaries, upload and run homebrew apps on the Playstation 2, and manage ps2netfs moutning, unmounting, copying from/to devices on the Playstation 2 (ie: memcard). Copyright 2004 Dan Peori <[EMAIL PROTECTED]>, under the BSD License. http://ps2dev.org/kb.x?T=985 (Include the long description here.) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.7-1-686-smp Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292183: ITP: gtkpizza -- Pizza takeaway managment program written in gtk
On Wed, Jan 26, 2005 at 09:45:07AM +, David Pashley wrote: > Could it be used to manage items other than pizzas? If so you might want > to mention that it could be adapted for all types of fast food. ...for all types of take-away food. Don't try to call pizza a "fast food". Never, ever again. If you get pizza from a fast food shop, you rightously get digestion problems and lots of pimples! And if there is cheese inside the border, that's not pizza: refuse to pay and move to another restaurant! And "Pizza ai peperoni" is pizza with peppers, not with hot sausage! Ciao, Enrico and the movement of Italians Against Pizza Blasphemes ;) [Cc-ing to debian-curiosa, thread should follow there, where someone can also teach me how to comfortably set mail-followup things in mutt] -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]> signature.asc Description: Digital signature
Bug#292559: ITP: mcelog -- tool to collect and decode Machine Check Exception on x86-64 machines
Package: wnpp
Severity: wishlist
Owner: Julien BLACHE <[EMAIL PROTECTED]>
* Package name: mcelog
Version : 0.3
Upstream Author : Andi Kleen <[EMAIL PROTECTED]>
* URL : ftp://ftp.x86-64.org/pub/linux/tools/mcelog
* License : GPL v2
Description : tool to collect and decode Machine Check Exception on
x86-64 machines
>From the control file:
Package: mcelog
Architecture: i386 amd64
Description: tool to collect and decode Machine Check Exception on x86-64
machines
Starting with version 2.6.4, the Linux kernel no longer decodes and logs
Machine Check Exception events to the kernel log.
.
Instead, the MCE data is kept in a buffer which can be read from userpace via
the /dev/mcelog device node.
.
You need this tool to collect and decode those events; it will log the decoded
MCE events into /var/log/mcelog.
The package is of no use (AFAIK) on non-x86{,-64} machines, thus the Arch: line.
I have a package ready, I should upload it soon.
JB.
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.9
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292183: ITP: gtkpizza -- Pizza takeaway managment program written in gtk
Enrico Zini writes: > And if there is cheese inside the border, that's not pizza: refuse to pay > and move to another restaurant! > And "Pizza ai peperoni" is pizza with peppers, not with hot sausage! Words with similar spelling often have different meanings in different languages. Such is the case here. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#292572: ITP: praat -- program for speech analysis and synthesis
Package: wnpp Severity: wishlist * Package name: praat Version : 4.3 Upstream Author : Paul Boersma and David Weenink * URL : http://www.praat.org/ * License : GPL (with one exception, see below) Description : program for speech analysis and synthesis According to its authors, praat is "doing phonetics by computer". Through its graphical interface, several speech analysis functionalities are available: spectrograms, cochleograms, and pitch and formant extraction. Articulatory synthesis, as well as synthesis from pitch, formant, and intensity are also available. Other features are segmentation, labelling using the phonetic alphabet, and computation of statistics. Praat is configurable and extensible through its own scripting language and has provisions for communicating with other programs. A preliminary version of the package is available at the apt-getable repository http://people.debian.org/~rafael/praat/ If there are no objections, I will upload the package in one week or so. Although the program is released under the GPL, there is a exception for one file. I think I will need to deceide if the term are compatible or not with the DFSG. Its license reads: /* ipaSerifRegularPS.c * * Copyright (C) 1993 Summer Institute of Linguistics * Copyright (C) 1994-2003 Paul Boersma * * This is partly free software; you can redistribute BUT NOT MODIFY * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at * your option) any later version. * *** * * THIS LICENSE IS MORE RESTRICTED THAN THE LICENSE FOR THE OTHER CODE * DISTRIBUTED WITH THE PRAAT PROGRAM. THIS IS BECAUSE THE FONT IS * COPYRIGHTED BY THE SUMMER INSTITUTE OF LINGUISTICS, AND THE PRAAT PROGRAM * DISTRIBUTES IT AS A SUBLICENSEE. THE SUBLICENSE DOES ALLOW REDISTRIBUTION * OF THE INCLUDED FONT IN THE C FORMAT NEEDED FOR PRAAT, * BUT THE SUBLICENSE DOES NOT ALLOW MODIFICATION OF THE INCLUDED FONT, * NOR REVERSE ENGINEERING OF THE FONT ITSELF ON THE BASIS OF THIS C CODE. * * (Reverse engineering is pointless anyway; the font itself can be * downloaded for free from www.sil.org or www.praat.org) * *** -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
my behaviour
i apologise for any offense i made have caused anyone, and i apologise for my behaviour, but i cannot apologise for what i perceive as a problem, that being the unfriendliness to outsiders, and that it's sometimes difficult to get change happening. the latter isn't up to me anyway, all i can do is point it out, albeit i did it too agressively. i reacted out of frustruation, and not thought. it's called outrage, heh. i'm still going to be staying away from debian for a while, but i just wanted to get this out, so i can rest easier, and be my typical obsessive-compulsive over it. eric cÃtÃ/sr -- "Only a brain-damaged operating system would support task switching and not make the simple next step of supporting multitasking." -- George McFry signature.asc Description: Digital signature
Re: Bug#292183: ITP: gtkpizza -- Pizza takeaway managment program written in gtk
On 27-Jan-05, 15:59 (CST), John Hasler <[EMAIL PROTECTED]> wrote: > Enrico Zini writes: > > And if there is cheese inside the border, that's not pizza: refuse to pay > > and move to another restaurant! > > > And "Pizza ai peperoni" is pizza with peppers, not with hot sausage! > > Words with similar spelling often have different meanings in different > languages. Such is the case here. It's true: The word "pizza" in the US doesn't mean the same thing as "pizza" in Italy. Steve, longing for the Pizzeria Cenacola in Siracusa... -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292572: ITP: praat -- program for speech analysis and synthesis
Rafael Laboissiere <[EMAIL PROTECTED]> writes: > * Copyright (C) 1993 Summer Institute of Linguistics You lose; SIL's annoying that way. :-/ I'd suggest trying to sub in a free font. I once mapped the SIL "Sophia" IPA font to Unicode; here's the chart I came up with, which perhaps also applies here. 0 U+25AF # â 1 U+FFFD # ï 2 U+FFFD # ï 3 U+FFFD # ï 4 U+FFFD # ï 5 U+FFFD # ï 6 U+FFFD # ï 7 U+FFFD # ï 8 U+FFFD # ï 9 U+FFFD # ï 10 U+FFFD # ï 11 U+FFFD # ï 12 U+FFFD # ï 13 U+FFFD # ï 14 U+FFFD # ï 15 U+FFFD # ï 16 U+FFFD # ï 17 U+FFFD # ï 18 U+FFFD # ï 19 U+FFFD # ï 20 U+FFFD # ï 21 U+FFFD # ï 22 U+FFFD # ï 23 U+FFFD # ï 24 U+FFFD # ï 25 U+FFFD # ï 26 U+FFFD # ï 27 U+FFFD # ï 28 U+FFFD # ï 29 U+FFFD # ï 30 U+FFFD # ï 31 U+FFFD # ï 32 U+0020 # 33 U+030B # Ì 34 U+0131 # Ä 35 U+0304 # Ì 36 U+0300 # Ì 37 U+030F # Ì 38 U+030C # Ì 39 U+0027 # ' 40 U+0306 # Ì 41 U+0303 # Ì 42 U+030A # Ì 43 U+031F # Ì 44 U+002C # , 45 U+002D # - 'd [-d] 46 U+002E # . neither...nor [ËnaÉÃÉ...ËnÉË] 47 U+0294 # Ê 48 U+0330 # Ì 49 U+0318 # Ì 50 U+0319 # Ì 51 U+031D # Ì 52 U+031E # Ì 53 U+032A # Ì 54 U+033B # Ì 55 U+031C # Ì 56 U+0325 # Ì 57 U+032F # Ì 58 U+02E1 # Ë 59 U+029F # Ê 60 U+207F # â 61 U+0320 # Ì 62 U+02D1 # Ë 63 U+02A1 # Ê 64 U+0301 # Ì 65 U+0251 # Éparsonage [ËpÉËsnÉdÊ] 66 U+03B2 # Î 67 U+00E7 # Ã 68 U+00F0 # Ãtheir [ÃÉÉ] 69 U+025B # Éoverbearing [ËÉuvÉËbÉÉrÉÅ] 70 U+0264 # É 71 U+0262 # É 72 U+02B0 # Ê 73 U+026A # Élimpet [ËlÉmpÉt] 74 U+02B2 # Ê 75 U+029C # Ê 76 U+026E # É 77 U+0271 # É 78 U+014B # ÅCongregationalism [ËkÉÅgrÉËgeÉÊnÉlÉzm] 79 U+00F8 # Ã 80 U+0275 # É 81 U+00E6 # Ãsassafras [ËsÃsÉfrÃs] 82 U+027E # É 83 U+0283 # Êchina-ware [ËtÊaÉnÉwÉÉ] 84 U+03B8 # Îdeath-rate [ËdeÎreÉt] 85 U+028A # Ê 86 U+028B # Ê 87 U+02B7 # Ê 88 U+03C7 # Ï 89 U+028F # Ê 90 U+0292 # Êtoxicology [ËtÉksÉËkÉlÉdÊÉ] 91 U+005B # [ 92 U+005C # \ 93 U+005D # ] 94 U+0302 # Ì 95 U+0308 # Ì 96 U+0329 # Ì 97 U+0061 # a standardize [ËstÃndÉdaÉz] 98 U+0062 # b bibliography [ËbÉblÉËÉgrÉfÉ] 99 U+0063 # c scratch-cat [ËscrÃtÊkÃt] 100 U+0064 # d trilogy [ËtrÉlÉdÊÉ] 101 U+0065 # e taper [ËteÉpÉ] 102 U+0066 # f disaffected [ËdÉsÉËfektÉd] 103 U+0067 # g wiggle [ËwÉgl] 104 U+0068 # h heritor [ËherÉtÉ] 105 U+0069 # i tea-house [ËtiËhaus] 106 U+006A # j maculae [ËmÃkjuliË] 107 U+006B # k fox [fÉks] 108 U+006C # l countervailing duty [ËkauntÉËveÉlÉÅËdjuËtÉ] 109 U+006D # m timber-man [ËtÉmbÉmÉn] 110 U+006E # n indurate [ËÉndjuÉreÉt] 111 U+006F # o triolet [ËtriËoulet] 112 U+0070 # p synoptical [sÉËnÉptÉkÉl] 113 U+0071 # q 114 U+0072 # r planetstruck [ËplÃnÉtstrÊk] 115 U+0073 # s especially [ÉsËpeÊÉlÉ] 116 U+0074 # t presentment [prÉËzentmÉnt] 117 U+0075 # u loop-line [ËluËplaÉn] 118 U+0076 # v unvoiced [ËÊnËvÉÉst] 119 U+0077 # w wolfskin [ËwulfskÉn] 120 U+0078 # x 121 U+0079 # y consanguinity [ËkÉnsÃÅËgwÉnÉty] 122 U+007A # z geophysical [ËdÊiËÉuËfÉzÉkÉl] 123 U+0280 # Ê 124 U+031A # Ì 125 U+027D # É 126 U+033D # Ì 127 U+FFFD # ï 128 U+03BB # Î 129 U+0252 # É 130 U+0188 # Æ 131 U+0361 # Í 132 U+2551 # â 133 U+0059 # Y 134 U+0056 # V 135 U+0298 # Ê 136 U+030B # Ì 137 U+030B # Ì 138 U+02E5 # Ë 139 U+2191 # â 140 U+0250 # É 141 U+0254 # Éminority [maÉËnÉrÉtÉ] 142 U+01C0 # Ç 143 U+0301 # Ì 144 U+0301 # Ì 145 U+02E6 # Ë 146 U+01C1 # Ç 147 U+0304 # Ì 148 U+0304 # Ì 149 U+02E7 # Ë 150 U+2502 # â 151 U+0021 # ! 152 U+0300 # Ì 153 U+0300 # Ì 154 U+02E8 # Ë 155 U+2193 # â 156 U+01C2 # Ç 157 U+030F # Ì 158 U+030F # Ì 159 U+02E9 # Ë 160 U+01AD # Æ 161 U+030A # Ì 162 U+031E # Ì 163 U+031D # Ì 164 U+032C # Ì 165 U+0325 # Ì 166 U+0339 # Ì 167 U+0282 # Ê 168 U+0279 # É 169 U+0260 # É 170 U+0319 # Ì 171 U+0259 # Éhear [hÉÉ] 172 U+0289 # Ê 173 U+0320 # Ì 174 U+0197 # Æ 175 U+0152 # Å 176 U+033A # Ì 177 U+031F # Ì 178 U+0274 # É 179 U+02C1 # Ë 180 U+028E # Ê 181 U+026F # É 182 U+FFFD # ï 183
Re: library packaging doc...
Junichi Uekawa writes, > Considering that enough people seem to be feeling the > itch for libpkg-guide package, and since I would > consider using the BTS etc. for revision management > of libpkg-guide, I might go around packaging it as a > Debian package. I had meant politely to ask you to package libpkg-guide, Junichi, only I have not wanted to push you. The libpkg-guide is a very useful document, a document which skillfully demystifies the practice of library packaging, a document which I really appreciate. (If you feel that the document remains incomplete, this is okay. It may never be 100 percent complete; but it is already complete enough to be very useful, exactly as it is right now.) > Any objections? No. If you feel inclined to do so, please package libpkg-guide and put it in sid now, then let it propagate normally to sarge. If you did this, I for one would install and use the package. -- Thaddeus H. Black 508 Nellie's Cave Road Blacksburg, Virginia 24060, USA +1 540 961 0920, [EMAIL PROTECTED] pgp04yMpoiiol.pgp Description: PGP signature
Re: library packaging doc...
On Thu, Jan 27, 2005 at 07:37:18PM +0100, Frank Küster wrote: > IIRC there were some people who objected to some of the contents of > the document. But even for those it is probably better to have a > Debian package - if it's important, the discussion will take place in > bug reports, instead of not taking place. I haven't read the document in question in a rather long time, so I can't actually object (on some sort of serious basis, I mean), but I would nevertheless request that the document be handed to the -english mailing list for proofreading *before* it's uploaded as a package and that a big "THIS IS A *GUIDE*" banner be stamped on it. The last thing I want is people complaining that libfoo doesn't follow some chapter and verse of said guide under the impression that it is somehow "correct", "standard" or "mandatory". Marcelo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Thu, 27 Jan 2005 09:52:48 +0100 Tim Dijkstra <[EMAIL PROTECTED]> wrote: > On Wed, 26 Jan 2005 20:18:39 -0500 > "Dale C. Scheetz" <[EMAIL PROTECTED]> wrote: > > > > Thus it might be even better to define a policy the following way: > > > > > >1. Put all XPMs for the use in Debian-Menu into > > > /usr/share/menu/pixmaps > > >2. Put all PNGs (and others) into /usr/share/pixmaps if they are > > > intended for applications which follow freedesktop.org > > > specification > > > > I don't really see a need for the split. All menu icons should be xpm > > so any other icons are for some other purpose. > > I think the point is we don't want to be stuck we xpm till eternity. > Especially because we have window/desktop managers that support better > formats like png or svg for example and programs supplying them. > My point was that it doesn't matter that this location is reserved for menu icons. There is no reason not to put other icons there as well, since all menu icons are xpm there should be no confusion. There is nothing in the menu spec that says only menu icons can go in this location. (in any case icons other than xpm in /usr/share/pixmaps is already the case) When and if xpms are no longer used for menus there will still be a need for icons in some format and this has become the defacto location. (I realize that the very name pixmaps implies xpm but as an abreviation for pixel maps it could refer to any mapping of pixels, not just xpm... My complaint was about the many and varied locations in which you might find an icon. Creating multiple locations one for this sort, another for a different sort is exactly the situation that now exists with some packages putting them in /usr/share/package-name/icons and all its variations, some in /usr/share/pixmaps and other locations I have yet to discover. I am assuming that the icons I find in /usr/share/icons are either gnome or KDE graphics elements. (my machines only have gnome icons here as I don't use KDE) Well, this turned out longer than I expected ;-) Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
On Thu, 27 Jan 2005, Marc Haber wrote: > On Thu, Jan 27, 2005 at 12:09:11PM -0200, Henrique de Moraes Holschuh wrote: > > Remove the package providing it. > > That might be a non-option. Only if there is a rather bad bug in the package. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Thu, Jan 27, 2005 at 09:52:48AM +0100, Tim Dijkstra wrote: > I think the point is we don't want to be stuck we xpm till eternity. > Especially because we have window/desktop managers that support better > formats like png or svg for example and programs supplying them. svg icons are already a reality and there is nothing in the documentation on where they should be placed. Note that I am not suggesting that other formats should be dropped, simply that policy include information on their proper location, etc., so that people using something modern, like gnome, will be able to use them. -- James (Jay) Treacy [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
> I haven't read the document in question in a rather long time, so I > can't actually object (on some sort of serious basis, I mean), but I > would nevertheless request that the document be handed to the -english > mailing list for proofreading *before* it's uploaded as a package and > that a big "THIS IS A *GUIDE*" banner be stamped on it. The last thing > I want is people complaining that libfoo doesn't follow some chapter > and verse of said guide under the impression that it is somehow > "correct", "standard" or "mandatory". I think this proofreading has happened some time ago; but will definitely benefit from being proof-read again. This document has been around for more than 2 years now. As for your objection of "correct", "standard" or "mandatory", I would say that this document is a recommendation, and should be followed when there is not a good argument against it. If there is a good reason not to follow this document, in which case I would recommend providing a patch against the libpkg-guide. After all, what this document tried to be is to document current practice, backed with some bugreports resulting from mis-packaging; and tried to document a guideline on which there was no real guideline. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
