Re: More on icons for packages
|--==> Paul Brossier writes: PB> On Sun, 2005-01-23 at 19:35 -0500, Dale C. Scheetz wrote: >>With regards to GNOME panel icons. The "add to panel" option now no >>longer offers "launcher from menu" so now with the "custom launcer" >>you have to hunt for your icon. PB> well yes, here it does at least. also you can drag and drop it from your PB> menu. PB> On Tue, 2005-01-25 at 18:17 -0500, Dale C. Scheetz wrote: >>It might be better to reserve /usr/share/pixmaps specifically for menu >>icons in xpm format and create /usr/share/icons for png gif and jpeg >>icon images. PB> i don't think this is the right way to go. gnome and kde use the PB> freedesktop standard and look for their icons in /usr/share/pixmaps. PB> other applications using icons should seriously consider looking in PB> there if they want to find any. clever ones could prune redundant PB> icons according to their file format preference. PB> you don't really want to use jpeg in a menu do you? >>Is it worth while trying to get some general icon policy established >>or am I straigning at gnats? PB> another manual does not seem required. but mentionning the use PB> of .desktop would be a worth addition to the menu manual. PB> see http://standards.freedesktop.org/desktop-entry-spec/latest/ PB> here is a minimal .desktop example: PB> $ cat /usr/share/applications/freewheeling.desktop PB> [Desktop Entry] PB> Name=FreeWheeling PB> Comment=live looping instrument PB> Exec=fweelin PB> Terminal=0 PB> Icon=freewheeling.xpm PB> Type=Application PB> Categories=Application;AudioVideo; PB> .desktop go in /usr/share/applications and icons in /usr/share/pixmaps PB> (or full path). both png and xpm are ok. PB> there could actually be some lintian/linda rules that checks if both PB> menu and .desktop entries are there and that the icons are installed at PB> the correct location. I do agree with all these observations. Let me add that issues related to the menu systems are becoming even more important now that Custom Debian Distributions are entering the scene. Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: try to keep a watch file into your package
|--==> bluefuture writes: b> The dehs system now is regular running again every two days on alioth b> (and so also on the info feed to developer.php on qa). b> Looking at no_watch page[1] there are: b> Total source packages without watch file: 6324 b> Total source packages: 8285 b> %: 76,33% b> But seems also that there are: b> 1621 packages that had no watch filel had a dehs automatic generated b> watch file that had passed uscan test. b> If every developer could download, check and if necessary fix the b> automatic generated watch file and the put the file in his package b> source we could fix the info in developers.php and the status on dehs b> for some of the 6324 packages without watch file. b> Every developer could find his automatic generated watch file going on b> his dehs own maintainer/package page from dehs homepage[2] on alioth. Thanks for this effort. Would it make sense to support queries of dehs by maintainer email address? This ways it would be easier for people to check the status of their own packages. Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PostgreSQL-Problem and Problem on Alioth
Hi!
sean finney [2005-01-25 18:38 -0500]:
> On Tue, Jan 25, 2005 at 10:38:37AM +0100, Martin Pitt wrote:
> > There are two common ways to achieve that:
> >
> > - Connect as "www-data". For this you need an appropriate PostgreSQL
> > user ("createuser www-data" as user postgres). Then you either make
> > www-data the owner of the database ("createdb -O www-data mydb") or
> > you set the owner to some application-specific PostgreSQL user and
> > only GRANT the necessary permissions to www-data (usually you need
> > table creation etc. only for package installation and can restrict
> > www-data permissions to SELECT/UPDATE).
>
> if i'm understanding correctly, a security drawback of both these
> methods is that any web application would effectively have r/w privileges
> to every web app's database, right?
It does not make a difference whether you use the "owned by www-data"
approach or use different owners with passwords. The webserver can
read all scripts (_including_ the passwords) anyway, so regardless of
how you do it, all your databases will be fair game to your web
server.
> > This solution has the advantage that you don't need to modify
> > pg_hba.conf (since you can use "ident sameuser" authentication).
>
> which is certainly not to be overlooked. i think maybe a disclaimer
> like "if you run multiple applications, this may present a security
> risk" might be in order, but it should definitely be an option.
See above :-) I still think owning the database by an
application-specific user and granting the necessary permissions to
www-data is an easy method, and it gives you the maximum amount of
security you can expect from this use case (least privilege).
> > - Connect as $dbc_dbuser and use "password" authentication. ident
> > makes not much sense since the database user has not necessarily
> > a system user counterpart (if it has, then this would of course
> > work). But if it hasn't, you need a pg_hba.conf entry.
Well, this is not _exactly_ right since you can map system users to
database users in pg_ident.conf, but that would mean yet another
conffile to touch.
> also, it looks like pg_hba.conf and pg_ident.conf both have some
> kind of @include functionality, which might make messing with either
> of the files moot. i'll have to look more into these details...
I think pg_hba.conf does not have this feature. However, if that would
help and some kind of pg_hba.d/ structure would solve problems, I
think it would not be that hard to add that feature for Debian.
However, the general approach to these web applications wrt
databases should be discussed, and a generally working solution should
be found before I start hacking. :-)
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developerhttp://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: try to keep a watch file into your package
On Tue, 25 Jan 2005 13:28:16 +0100, Bluefuture <[EMAIL PROTECTED]> wrote: >Native packages are already not included in the dehs system. What do you do with packages that have uncooperative upstream and thus a watch file is not possible? apg's web host, for example, doesn't support directory listings, so I had to resort on checking the fingerprint of the download web page to find out whether there is a new release. 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: policy-rc.d confusion (was: not starting packages at boot)
On Tue, 25 Jan 2005 11:03:16 -0200, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote: >On Tue, 25 Jan 2005, Marc Haber wrote: >> So policy-rc.d needs to be in /usr/local, or we have a FHS violation. > >Please request that we enhance invoke-rc.d to look on /usr/local first, >then (through a wishlist bug). Looks like a good idea at first glance. invoke-rc.d is part of at least two packages, so the "search path infrastructure" fits best into its own package containing an alternative for /usr/sbin/policy-rc.d. That shouldn't be hard to do, and I filed an ITP for an appropriate 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: scripts to download porn in Debian?
Ron Johnson <[EMAIL PROTECTED]> wrote: > Following fortune's model, this is what I'm thinking: > dosage > dosage-comics > dosage-comics-off > > See there's no censorship here... No, just st^W. What do you gain as a parent? Instead of having to look at one package (dosage) and deciding "No, not that", you have to check at least two of them (dosage and dosage-comics). You know, the maintai- ner might have a put something into -comics that he didn't think anybo- dy would find offensive, but you do. By the way, what would be the difference between dosage and dosage-comics? Can the package also download different stuff than comic strips? Regards, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Bug#292299: ITP: policyrcd -- policy-compliant interface from invoke-rc.d to local config files
Package: wnpp Severity: wishlist Owner: Marc Haber <[EMAIL PROTECTED]> * Package name: policyrcd Version : 0.1 Upstream Author : Marc Haber <[EMAIL PROTECTED]> * URL : http://wiki.debian.net/index.cgi?ZugSchlus * License : GPL Description : policy-compliant interface from invoke-rc.d to local config files contains a script which is linked via the alternatives subsystem to /usr/sbin/update-rc.d. This script looks for a local policy-rc.d script in /usr/local an /etc, providing a policy- and FHS-compliant way to interface invoke-rc.d with a local script. Without this package, a local admin wanting to cleanly interface with invoke-rc.d is forced to drop a local binary to /usr/sbin and/or manually interface with the alternatives system. Both ways of doing this are clumsy and error-prone, so this package offers a clean way of interfacing with sysvrc and file-rc. Since there are at least two packages containing their own version of invoke-rc.d, having a search path policy for policy-rc.d can be messy and is prone to be unstructured and uncoordinated. Hence, having a dedicated package is the clean way of doing things. Greetings Marc -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.9-zgserver Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PostgreSQL-Problem and Problem on Alioth
On Wed, 26 Jan 2005, Martin Pitt wrote: Well, this is not _exactly_ right since you can map system users to database users in pg_ident.conf, but that would mean yet another conffile to touch. ... which should probably be avoided. Moreover I had bad experiences while trying that some years ago. I think pg_hba.conf does not have this feature. However, if that would help and some kind of pg_hba.d/ structure would solve problems, I think it would not be that hard to add that feature for Debian. IMHO this would be really great. Currently I prepend the following lines in pg_hba.conf: ### DO NOT REMOVE THIS LINE: GNUMED_SERVER_CONFIG_DONE ### Next lines inserted by gnumed-server install # ## Enable bootstraping the GnuMed-Server # # Enables socket authentification to template1 for users mentioned in # file $PGDATA/gmTemplate1User.list (=gm-dbowner) with PASSWORD authentication # to enable creating gnumed database and users localtemplate1 @gmTemplate1User.list password # # Enables socket authentification to gnumed-test for users mentioned in # file $PGDATA/gmTemplate1User.list (=gm-dbowner) with authentication TRUST # to pupulate database with data. Unfortunately the current bootstraping method # requires TRUST. :-( localgnumed-test@gmTemplate1User.list trust # ## Enable client connections to the GnuMed-Server # # Enables socket authentification to gnumed-test for users mentioned in # file $PGDATA/gmGnumedUser.list with PASSWORD authentication # The file $PGDATA/gmGnumedUser.list should be regarded as config file # and thus it is a symlink to /etc/gnumed/gmGnumedUser.list local gnumed-test @gmGnumedUser.list password # # Uncomment this to enable remote users connecting to the GnuMed server # You have to provide and # = 0.0.0.0 and = 255.255.255.255 # means connection from all hosts is allowed # # hostgnumed-test @gmGnumedUser.list md5 # hostssl gnumed-test @gmGnumedUser.list md5 ### End gnumed-server install ### DO NOT REMOVE THIS LINE: GNUMED_SERVER_CONFIG_END I know that gforge maintainers do similar things. This could be much cleaner be done with pg_hba.d/50_gnumed pg_hba.d/50_gforge ... whatever and I would greatly appreciate this. However, the general approach to these web applications wrt databases should be discussed, and a generally working solution should be found before I start hacking. :-) Sure. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/25/2005 09:46 PM, Goswin von Brederlow wrote: >>And yes, I've already thought of that. However, I'd rather some >>things (URLs, in this case) not be dropped my children's laps, >>even though they could be blocked further upstream. >> >>When they start to get curious about such things, let 'em learn >>about porn the old fashioned way... ;) > > > Try it out and get pregnant? well, what about good old fashioned sex education. Oh wait no, deny the problem is not there is so much better, it solves all the problems. Sure, let them die stupid and pregnant with 15. - -- [ Clemens Schwaighofer -=:~ ] [ TBWA\ && TEQUILA\ Japan IT Group ] [6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ] [ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ] [ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB92NbjBz/yQjBxz8RAisJAJ40A6hD/gOBboTfmsR51gGVaLF/1QCfR//Z JAtOtTqzpbXWMf6f+KeaYDE= =t6Ku -END PGP SIGNATURE- -- 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 Jan 25, 2005 at 16:08, Guglielmo Dapavo praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Guglielmo Dapavo <[EMAIL PROTECTED]> > > * Package name: gtkpizza > > Version : 0.1.0 > Upstream Author : Guglielmo Dapavo <[EMAIL PROTECTED]> > * URL : http://www.dapavo.it/ > * License : (GPL) > Description : Pizza takeaway managment program written in gtk > > You can manage orders, external/internal customers, pizza types. It also > has reports. > Is it really neccessary to say it uses gtk? 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. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- 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 Jan 26, 2005 at 08:26, Marc Haber praised the llamas by saying: > Package: wnpp > Severity: wishlist > Owner: Marc Haber <[EMAIL PROTECTED]> > > * Package name: policyrcd > Version : 0.1 > Upstream Author : Marc Haber <[EMAIL PROTECTED]> > * URL : http://wiki.debian.net/index.cgi?ZugSchlus > * License : GPL > Description : policy-compliant interface from invoke-rc.d to local > config files > > contains a script which is linked via the alternatives subsystem to > /usr/sbin/update-rc.d. This script looks for a local policy-rc.d > script in /usr/local an /etc, providing a policy- and FHS-compliant > way to interface invoke-rc.d with a local script. > > Without this package, a local admin wanting to cleanly interface with > invoke-rc.d is forced to drop a local binary to /usr/sbin and/or > manually interface with the alternatives system. Both ways of doing > this are clumsy and error-prone, so this package offers a clean way of > interfacing with sysvrc and file-rc. > > Since there are at least two packages containing their own version of > invoke-rc.d, having a search path policy for policy-rc.d can be > messy and is prone to be unstructured and uncoordinated. > > Hence, having a dedicated package is the clean way of doing things. > It seems a bit excessive having a package for just one script. Is there not another package this could go in instead? -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- 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 Wed, 26 Jan 2005, David Pashley wrote: > > Since there are at least two packages containing their own version of > > invoke-rc.d, having a search path policy for policy-rc.d can be > > messy and is prone to be unstructured and uncoordinated. No, it is not. invoke-rc.d *HAS* to be coordinated, and implemented by every initscript system. The maintainers of these packages are well aware of that fact. 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. > It seems a bit excessive having a package for just one script. Is there > not another package this could go in instead? No. Either it has to go on a package of its own, or it has to have the functionality folded into file-rc and sysv-rc. -- "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 Jan 26, 2005 at 09:59, Henrique de Moraes Holschuh praised the llamas by saying: > On Wed, 26 Jan 2005, David Pashley wrote: > > > Since there are at least two packages containing their own version of > > > invoke-rc.d, having a search path policy for policy-rc.d can be > > > messy and is prone to be unstructured and uncoordinated. > > No, it is not. invoke-rc.d *HAS* to be coordinated, and implemented by every > initscript system. The maintainers of these packages are well aware of > that fact. > > 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. > > > It seems a bit excessive having a package for just one script. Is there > > not another package this could go in instead? > > No. Either it has to go on a package of its own, or it has to have the > functionality folded into file-rc and sysv-rc. > Then I suggest a patch is submitted to both file-rc and sysv-rc. -- David Pashley [EMAIL PROTECTED] Nihil curo de ista tua stulta superstitione. -- 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 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. If it does not exist, then /usr/local/sbin/policy-rc.d can be checked for. > Then I suggest a patch is submitted to both file-rc and sysv-rc. So do i. -- "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 Wed, Jan 26, 2005 at 09:48:54AM +, David Pashley wrote: > On Jan 26, 2005 at 08:26, Marc Haber praised the llamas by saying: > > Since there are at least two packages containing their own version of > > invoke-rc.d, having a search path policy for policy-rc.d can be > > messy and is prone to be unstructured and uncoordinated. > > > > Hence, having a dedicated package is the clean way of doing things. > > > It seems a bit excessive having a package for just one script. Is there > not another package this could go in instead? Please see the two quoted paragraphs. 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 [Was: NEW queue and ftp-master approval]
On Tue, Jan 25, 2005 at 06:01:26PM -0700, Joel Aelwyn wrote: > On Wed, Jan 26, 2005 at 12:06:06AM +, Andrew Suffield wrote: > > On Tue, Jan 25, 2005 at 10:52:48AM -0700, Joel Aelwyn wrote: > > > [1] Which is a separate rant, and frankly, I think Debian needs to be > > > clear about what we really mean by "We won't hide probles" in our Social > > > Contract > > > > It's a literal statement. We won't hide them. As always with the > > social contract, do not attempt to assume the inverse is true. Just > > because we won't hide them does not mean we're committed to going out > > of our way to make them well-known and easy to understand. It is not a > > commitment to some higher notion of transparency, but rather merely to > > avoid *obstructing* transparency. > > > > Complaining that you didn't know what the issues with the NM process > > were is precisely equivalent to complaining that you didn't know about > > some random bug which nobody had filed. Nobody was hiding anything, > > it's just that nobody bothered to document the problem; they're very > > different things. > > I notice that you conveniently trimmed the portion of my statement that > went into detail about what I consider the core issue to be: what is meant > by "problems". It's irrelevant. > One could argue that failing to acknowledge, or do anything about, an > utter lack of transparency in our basic processes is, in fact, hiding > problems, by tacit acceptance and omission rather than deliberate > obfuscation. One could, but it would be stupid pointless word games. You might as well make similar complaints about tagging bugs as wontfix and closing them. I already told you once that this is *not* what it means. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Depends: and commands used in maintainer scripts
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. If a package is missing a Depends, and therefore will routinely fail in prerm or postrm --remove, isn't that a release-critical bug? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
Re: Debian MIA structure
Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Jeroen van Wolffelaar <[EMAIL PROTECTED]> [2005-01-23 01:31]: >> > And finally, are there plans to update the Developer's Reference to >> > reflect this change in standard procedure? >> >> Yes, while this procedure hasn't really been discussed much, it's now >> just de-facto how it happens. > > There's some information in the README of the MIA scripts at > http://cvs.debian.org/mia/README?cvsroot=qa and in my paper about > inactive maintainers at > http://www.cyrius.com/publications/michlmayr-mia.html I have read both, but it is still unclear to me what I should do as somebody not involved in QA who just wants to know about a particular maintainer. Should I send mail to him, and a copy to mia-@qa.d.o, or should I just send a question to [EMAIL PROTECTED] And what is going to happen - is the event just logged in your mia database, or is some human being going to answer me "We don't know anything about him", "Others have asked, too; he's probably MIA" or "No, how come you think? He's very active with package a and b, and on IRC"? Furthermore, what is the proposed action if I know (from the LDAP database) that the maintainer in question has shown some action, but I still think that he has lost interest in a particular package (and, of course, doesn't answer mail about it)? TIA, Frank -- Frank Küster Inst. f. Biochemie der Univ. Zürich Debian Developer
library packaging doc...
Hi everyone, i would point to this link : http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html which i think would fit very nicely in debian official documentation after maybe a few modifications if necessary... not sure where to propose this so i write here... thanks :) Pierre Ancelot. pgp0WzHwiwyuI.pgp Description: PGP signature
Re: scripts to download porn in Debian?
* Tristan Seligmann | Where do you draw the line, though? Easy, maintainer's perogative, as usual. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
On 2005-01-26 Pierre Ancelot <[EMAIL PROTECTED]> wrote: > Hi everyone, i would point to this link : > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html [...] It is already linked from deveopers reference. cu andreas PS: It is pretty useless to sign messages without making the public key available, please upload it to the keyservers, especially subkeys.pgp.net. -- "See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf, fuhggvat qbja gur juveyvat tha. Neal Stephenson in "Snow Crash" http://downhill.aus.cc/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: acpi vs apm
Cameron Patrick <[EMAIL PROTECTED]> wrote: > What kind of userland support do you see as being missing? I use the > hibernate package for ACPI sleep and it works pretty well. Most of > the problems that I've seen with ACPI have been kernel or BIOS issues > (e.g. the screen not being switched on when resuming unless you give > particular kernel options). The ACPI spec makes it the OS's responsibility to reinitialise the video hardware, not the BIOS's. The kernel is (for the most part) incapable of doing so - there are some cases where you can get it to bring it back, but there's a huge range of hardware where those options crash the machine on resume. The main things that need doing are: 1) Dealing with network interfaces and the like sensibly - at the moment, this will often require unloading and reloading modules pre/post suspend 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. 3) Decent integration into user configuration. In a lot of cases, you want PM policy to be definable by the person carrying the computer around, even if they don't have administrative access. I've got some amount of code for doing most of these things, but it's very heavily a post-Sarge thing - it involves touching a lot of packages. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292322: emacspeak: might be non-free
Hi,
It seems to me that the maintainer of emacspeak is not very much
interested in this package currently, or at least didn't have time for a
couple of months. Therefore I forward this bug report to -devel and
-emacsen, in the hope to find somebody who is more interested.
Personally, I only came across the issue because I reported #291970, and
thought about NMU'ing it. I have no further interest in emacspeak except
that it doesn't break auctex, which is the result of that bug.
I don't even know why I looked at the copyright file..., but once I did I
couldn't let this go unnoticed.
Regards, Frank
Frank Küster <[EMAIL PROTECTED]> schrieb:
> Package: emacspeak
> Version: 17.0-1
> Severity: severity
>
> The copyright of emacspeak is confusing, and the package is possibly non-free:
>
> debian/copyright claims two contradicting licenses for the
> packages. The first seems to be present in some source files:
>
> ,
> | Copyright:
> |
> | Source files contain this copyright notice:
> | --
> | ;;{{{ Copyright:
> |
> | ;;;Copyright (C) 1995, 1996, 1997 T. V. Raman Adobe Systems Incorporated
> | ;;; Copyright (c) 1996 by T. V. Raman
> | ;;; All Rights Reserved.
> | ;;;
> | ;;; This file is not part of GNU Emacs, but the same permissions apply.
> | ;;;
> | ;;; GNU Emacs is free software; you can redistribute it and/or modify
> | ;;; it under the terms of the GNU General Public License as published by
> | ;;; the Free Software Foundation; either version 2, or (at your option)
> | ;;; any later version.
> | ;;;
> | [...]
> `
>
> On the other hand, there is a file etc/COPYRIGHT which seems to be a
> copyright file for the whole package. The license therein is non-free
> because it does not explicitly allow modifcation:
>
> ,
> | ;;
> | ;;; Author: T. V. Raman, <[EMAIL PROTECTED]>
> | ;;;Copyright (C) 1995 -- 2002, T. V. Raman
> | ;;; All Rights Reserved
> | ;;; Author: T. V. Raman, Digital Equipment Corporation. <[EMAIL PROTECTED]>
> | ;;; Copyright 1994, 1995 by Digital Equipment Corporation, Maynard, MA.
> | ;;; All Rights Reserved
> | ;;; $Id: COPYRIGHT,v 17.0 2002/11/23 01:29:08 raman Exp $
> | ;;;Permission to use, copy, and distribute this software and its
> documentation
> | ;;;for any purpose and without fee is hereby granted, provided that the
> above
> | ;;;copyright notice appears in all copies and that both that copyright
> notice
> | ;;;and this permission notice, including the disclaimers below, appear in
> | ;;;supporting documentation, and that the name of Adobe and Digital not be
> | ;;;used in advertising or publicity pertaining to distribution of the
> software
> | ;;;without specific, written prior permission.
> |
> | Digital Equipment Corporation, and T.V. Raman
> | ;;;DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL
> IMPLIED
> | ;;;WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL Digital
> | ;;;Equipment Corporation, or T.V. Raman BE LIABLE
> | ;;;FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> | ;;;WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> | ;;;ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION OR ANY ACTION OF
> | ;;;ANY OTHER KIND WHATSOEVER, ARISING OUT OF OR IN CONNECTION WITH THE USE
> OR
> | ;;;PERFORMANCE OF THIS SOFTWARE.
> | ;;; Permission to use, copy, and distribute this software and its
> | ;;; documentation for any purpose and without fee is hereby granted,
> provided
> | ;;; that the above copyright notice appear in all copies and that both that
> | ;;; copyright notice and this permission notice appear in supporting
> | ;;; documentation, and that the name of Adobe Systems not be used in
> | ;;; advertising or publicity pertaining to distribution of the software
> without
> | ;;; specific, written prior permission.
> `
>
> (this is repeated for Adobe, and the disclaimer once more for DEC)
>
> This file is still present in the current upstream version.
>
> Additionally, the source contains a lot of sound files without
> specific copyright notice. Some are probably just sounds needed to
> synthesize speech, and may not be copyrightable, or be spoken and
> copyright by Mr. Raman. But files like
>
> emacspeak-17.0/realaudio/radio/bbc-world-service.ram
> emacspeak-17.0/realaudio/radio/science-in-action-bbc.ram
> emacspeak-17.0/realaudio/radio/cnn-biz.ram
> emacspeak-17.0/realaudio/radio/cnn-si.ram
> emacspeak-17.0/realaudio/radio/cnn-cnn.ram
> emacspeak-17.0/realaudio/radio/cnn-sports.ram
> emacspeak-17.0/realaudio/radio/cnn-es.ram
> emacspeak-17.0/realaudio/radio/cnn-top-stories.ram
> emacspeak-17.0/realaudio/radio/cnn-hn.ram
>
> Do sound like somebody else had a copyright on them.
>
> Minor issues with the copyright file:
>
> ,
Re: Debian MIA structure
* Frank Küster <[EMAIL PROTECTED]> [2005-01-26 12:10]: > Should I send mail to him, and a copy to mia-@qa.d.o, or should I > just send a question to [EMAIL PROTECTED] Just send a mail to [EMAIL PROTECTED] > And what is going to happen - is the event just logged in your mia > database, or is some human being going to answer me "We don't know > anything about him", "Others have asked, too; he's probably MIA" or > "No, how come you think? He's very active with package a and b, and > on IRC"? [EMAIL PROTECTED] (i.e Jeroen van Wolffelaar) will respond to you with the information he has already and take action depending on the circumstances. > Furthermore, what is the proposed action if I know (from the LDAP > database) that the maintainer in question has shown some action, but I > still think that he has lost interest in a particular package (and, of > course, doesn't answer mail about it)? Tell [EMAIL PROTECTED] -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libxml2 and libxslt uploads to sid, soon
Hi fellow developpers, I just want you to make you aware that I'm planning to upload new upstream versions of libxml2 and libxslt into sid soon. Since the number of reverse dependencies on them are quite significant, and since shlibs are going to be bumped, I'm posting this warning on -release and -devel. Both versions that will be uploaded into sid are targetted for sarge, and will actually be the ones currently in experimental (or maybe latest upstream for libxml2 if the change-set is not too significant comparing to the one in experimental). I'm planning the upload for early february (I'd say on the 1st or the 2nd). If you have any comment or need some delay for some reason, feel free to answer this message. Just don't forget that these uploads mean that all reverse depending packages, and some more indirect reverse dependencies, will be stuck in sid the time for the packages to migrate into sarge, which will be 10 days (urgency: low, except if someone has an objection). Thanks for listening. Mike -- 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 03:20:34 +, Paul Brossier <[EMAIL PROTECTED]> wrote: > On Sun, 2005-01-23 at 19:35 -0500, Dale C. Scheetz wrote: > > With regards to GNOME panel icons. The "add to panel" option now no > > longer offers "launcher from menu" so now with the "custom launcer" > > you have to hunt for your icon. > > well yes, here it does at least. you can also drag and drop it from your > menu. Yes, that works here too, but doesn't that use the icon displayed in the menu entry? For Spider I conformed to the menu spec and made the icon 32x32 pixels in xpm format. The icon I would prefer to use on the desktop/panel is 114x154 pixels and gives a smoother lookeing icon. I'll have to experiment with violating the menu spec and seeing how it works... > > On Tue, 2005-01-25 at 18:17 -0500, Dale C. Scheetz wrote: > > It might be better to reserve /usr/share/pixmaps specifically for menu > > icons in xpm format and create /usr/share/icons for png gif and jpeg > > icon images. > > i don't think this is the right way to go. gnome and kde use the > freedesktop standard and look for their icons in /usr/share/pixmaps. I see your point. I was not aware of the other "specifications". One single location for icons makes great sense. > other applications using icons should seriously consider looking in > there if they want to find any icon. clever ones could prune redundant > icon according to their file format preference. > > you don't really want to use jpeg in a menu do you? > Naaah, I just included it for completeness, png is a much better format ;-) > > Is it worth while trying to get some general icon policy established or > > am I straigning at gnats? > > another manual does not seem required. but mentionning the use > of .desktop would be a worth addition to the menu manual. > Except that it has little to do with the menu specification. For those like me who went searching for "icon" in the docs it would be nice to have a section with that title that points at the menu spec and the desktop spec and any other useful help with icon managment. > see http://standards.freedesktop.org/desktop-entry-spec/latest/ > This is very useful. Thank you! BTW, DSL (Damn Small Linux, a Debian based live cd distro) uses its own desktop icon format in a .lnk file in the .xdesktop directory for that user. I'm still left with a question: How do I, as a package maintainer, provide these .desktop files so the user either automatically or by some simple choice gets the icon on their desktop? Waiting is, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
advice on a patch set
Hi all, 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. What can I do? Is there a tool that can merge multiple patches into a single patch in a "recursive" manner (i.e. to produce the smallest patch that has the same result)? combinediff looks promising, but the approach I tried... 1 + 2 -> A A + 3 -> B B + 4 -> C ... did not work (it can only merge pairs). Thanks for any help. -- 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#292150: ITP: phpauction -- PHP based auction site, you can submit and make offers for auctions
Hello On Tue, Jan 25, 2005 at 01:00:22PM +0100, Guglielmo Dapavo wrote: > * Package name: phpauctionGPL > Version : 2.5.0 > Upstream Author : Name <[EMAIL PROTECTED]> > * URL : http://www.phpauction.org/ > * License : (GPL) > Description : PHP based auction site, you can submit and make > offers for auctions Just checked out the homepage: --- snip --- Minimal server requirements are as follows: - Apache web server - PHP 4.0.6 or later (see below) with safe_mode=Off - register_globals=on - no open_basedir restriction - MySQL Database --- snap --- This definately does not sound like a perfect idea given the needed requirements out of a security point of view. Is the product worth inclusion anyway, has the code been audited? MfG/Regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on a patch set
martin f krafft <[EMAIL PROTECTED]> writes: > 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. > > What can I do? Is there a tool that can merge multiple patches into > a single patch in a "recursive" manner (i.e. to produce the smallest > patch that has the same result)? Any reason you can't just make a copy of the unpatched source, apply all the patches, and then diff -urN the original with the patched version to create a fresh patch? Test by applying the newly created patch with the original to make sure that your patch and the original patch set produce the same result. -- Jay Berkenbilt <[EMAIL PROTECTED]> http://www.ql.org/q/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on a patch set
Il giorno mer, 26-01-2005 alle 17:17 +0100, martin f krafft ha scritto: > Hi all, > > I am trying to package the swsusp2 kernel patch, which comes in > hundred little files. Hi Martin, why don't you apply all the patches to a clean kernel source tree, and then diff that source tree from the original one? -- Fabio Tranchitella http://www.kobold.it Studio Tranchitella Assoc. Professionale http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata
Re: advice on a patch set
also sprach Jay Berkenbilt <[EMAIL PROTECTED]> [2005.01.26.1724 +0100]: > Any reason you can't just make a copy of the unpatched source, apply > all the patches, and then diff -urN the original with the patched > version to create a fresh patch? Test by applying the newly created > patch with the original to make sure that your patch and the original > patch set produce the same result. also sprach Fabio Tranchitella <[EMAIL PROTECTED]> [2005.01.26.1730 +0100]: > Hi Martin, why don't you apply all the patches to a clean kernel source > tree, and then diff that source tree from the original one? Obviously this is an option. However, I would prefer to ship the original patch within the source package, rather than a patch I created specifically for Debian. Also, it's much less work in the future if I can just drop in new versions of the patch without having to go through the process of patching and diffing the kernel source. -- 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: advice on a patch set
martin f krafft <[EMAIL PROTECTED]> writes: > Hi all, > > 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. > > What can I do? Is there a tool that can merge multiple patches into > a single patch in a "recursive" manner (i.e. to produce the smallest > patch that has the same result)? > > combinediff looks promising, but the approach I tried... > 1 + 2 -> A > A + 3 -> B > B + 4 -> C > ... > did not work (it can only merge pairs). > > Thanks for any help. Why not just put all the patches into /usr/src/kernel-patches/swsusp2 and apply them in order? Nothing wrong with having many files. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on a patch set
also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.01.26.1754 +0100]: > Why not just put all the patches into > /usr/src/kernel-patches/swsusp2 and apply them in order? Because I like reusing wheels (as in: dh-kpatches) and it does not really allow multiple patches, surely not one hundred of them. Sure, I can make a custom kernel patch package without kpatches, but then I'd have to write apply and unapply scripts too. Why bother when kpatches does so already? -- 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: scripts to download porn in Debian?
On Wed, Jan 26, 2005 at 09:52:13 +0100, Frank KÃster wrote: > By the way, what would be the difference between dosage and > dosage-comics? Can the package also download different stuff than comic > strips? Presumably 'dosage' would contain everything except the actual modules that download the various webcomics, while 'dosage-comics' would just contain the comic modules. I have no intention of splitting the package up like that, however. -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature
Buildd howto
Hello, I'm part of a team that is seeking to build a desktop oriented distro to support and showcase L10N efforts in the Indic languages, based on Componentized Linux. We think it is probably better if we setup a system based on Debian buildd, to receive source packages from uploaders, and then building the Debian package automatically. However I couldn't find any documentation on how to setup buildds. Can anyone please provide pointers Thank you -- 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: NM queue and groups [Was: NEW queue and ftp-master approval]
On Wed, Jan 26, 2005 at 10:30:01AM +, Andrew Suffield wrote: > On Tue, Jan 25, 2005 at 06:01:26PM -0700, Joel Aelwyn wrote: > > On Wed, Jan 26, 2005 at 12:06:06AM +, Andrew Suffield wrote: > > > On Tue, Jan 25, 2005 at 10:52:48AM -0700, Joel Aelwyn wrote: > > > > [1] Which is a separate rant, and frankly, I think Debian needs to be > > > > clear about what we really mean by "We won't hide probles" in our Social > > > > Contract > > > > > > It's a literal statement. We won't hide them. As always with the > > > social contract, do not attempt to assume the inverse is true. Just > > > because we won't hide them does not mean we're committed to going out > > > of our way to make them well-known and easy to understand. It is not a > > > commitment to some higher notion of transparency, but rather merely to > > > avoid *obstructing* transparency. > > > > > > Complaining that you didn't know what the issues with the NM process > > > were is precisely equivalent to complaining that you didn't know about > > > some random bug which nobody had filed. Nobody was hiding anything, > > > it's just that nobody bothered to document the problem; they're very > > > different things. > > > > I notice that you conveniently trimmed the portion of my statement that > > went into detail about what I consider the core issue to be: what is meant > > by "problems". > > It's irrelevant. That's funny. I like that. I really do. You should do stand-up. Or maybe a mind-reading show, since you seem to know, better than I do, what the topic of my message was. > > One could argue that failing to acknowledge, or do anything about, an > > utter lack of transparency in our basic processes is, in fact, hiding > > problems, by tacit acceptance and omission rather than deliberate > > obfuscation. > > One could, but it would be stupid pointless word games. You might as > well make similar complaints about tagging bugs as wontfix and closing > them. I already told you once that this is *not* what it means. 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 - so that it can be decided whether those are *relevant* topics at all. Nothing more. Let's try this one more time: 1) I have seen people assert that "We won't hide problems" means "Our bug database will be open", *and nothing more* - that the following phrase is a delineation of exactly what that means, rather than an example of a minimum expectation. 2) I have also seen people assert that this same phrase means we won't hide any problems, real or perceived, that do not have an immediate and overwhelming reason to be *temporarily* non-public (such as security announcements where we would simply be cut off from any future announcement if we publicized it too early). (There have also been views that it should demand no hiding of security issues either, but I find that an impractical and fairly useless suggestion given the reality of security fixes today.) These statements are plain facts. *I have seen both things asserted*. Some set of other questions, which I will not repeat here because you'll probably just trim the rest of the message again and argue about them pointlessly if I do, depend on answering which of these two assertions is, in fact, a correct summation of the project's stance on the topic. They are mutually exclusive; it is not possible for both to be correct statements of a single entity's stance simultaneously (it is possible that neither of them is correct, in which case someone should propose an alternative interpretation). Perhaps fundamental and significant disagreements over what an entire clause of our Social Contract means aren't important to you; for my part, *I* would like to know what people believe they are agreeing with when they agree to abide by the SC. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- 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: > 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. > > If a package is missing a Depends, and therefore will routinely fail in > prerm or postrm --remove, isn't that a release-critical bug? Because policy, unlike RFCs, does not use normative declarations such as SHOULD and MUST (note the reason for uppercasing them in RFCs - to indicate that they are, in fact, normative). -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: Buildd howto
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Buildd howto
On Thu, Jan 27, 2005 at 12:20:35AM +0530, Soumyadip Modak wrote: > However I couldn't find any documentation on how to setup buildds. Can > anyone please provide pointers http://www.de.debian.org/devel/buildd/ Gruesse, -- Frank Lichtenheld <[EMAIL PROTECTED]> www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: library packaging doc...
Hi, 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? Bye, -- Loïc Minier <[EMAIL PROTECTED]> "Neutral President: I have no strong feelings one way or the other." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: and commands used in maintainer scripts
Joel Aelwyn writes: > Because policy, unlike RFCs, does not use normative declarations such as > SHOULD and MUST... >From debian-policy: In the normative part of this manual, the words must, should and may, and the adjectives required, recommended and optional, are used to distinguish the significance of the various guidelines in this policy document. Packages that do not conform to the guidelines denoted by must (or required) will generally not be considered acceptable for the Debian distribution. Non-conformance with guidelines denoted by should (or recommended) will generally be considered a bug, but will not necessarily render a package unsuitable for distribution. Guidelines denoted by may (or optional) are truly optional and adherence is left to the maintainer's discretion. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: and commands used in maintainer scripts
On Wed, Jan 26, 2005 at 01:21:38PM -0600, John Hasler wrote: > Joel Aelwyn writes: > > Because policy, unlike RFCs, does not use normative declarations such as > > SHOULD and MUST... > > From debian-policy: >In the normative part of this manual, the words must, should and may, and >the adjectives required, recommended and optional, are used to >distinguish the significance of the various guidelines in this policy >document. Packages that do not conform to the guidelines denoted by must >(or required) will generally not be considered acceptable for the Debian >distribution. Non-conformance with guidelines denoted by should (or >recommended) will generally be considered a bug, but will not >necessarily render a package unsuitable for distribution. Guidelines >denoted by may (or optional) are truly optional and adherence is left to >the maintainer's discretion. As an additional note to this, the 'generally not be considered acceptable for the Debian distribution' is for as far Sarge is concerned, canonically defined at [1]. --Jeroen [1] http://release.debian.org/sarge_rc_policy.txt -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on a patch set
martin f krafft <[EMAIL PROTECTED]> writes: > also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.01.26.1754 +0100]: >> Why not just put all the patches into >> /usr/src/kernel-patches/swsusp2 and apply them in order? > > Because I like reusing wheels (as in: dh-kpatches) and it does not > really allow multiple patches, surely not one hundred of them. > > Sure, I can make a custom kernel patch package without kpatches, but > then I'd have to write apply and unapply scripts too. Why bother > when kpatches does so already? Improve kpatches to cope with multiple patches. Just think of the hassle you have on updates when one of the hundred files change and you have to remake the full patchfile each time. It's a lot easier to follow if you have the original upstream sources to work with directly. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: advice on a patch set
also sprach Goswin von Brederlow <[EMAIL PROTECTED]> [2005.01.26.2054 +0100]: > Improve kpatches to cope with multiple patches. Uh, yeah. When I get a free minute. > Just think of the hassle you have on updates when one of the > hundred files change and you have to remake the full patchfile > each time. cat does so for me automatically as part of the package's build target. > It's a lot easier to follow if you have the original upstream > sources to work with directly. Right, which is what I am trying to do. -- 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: Buildd howto
Martin Zobel-Helas <[EMAIL PROTECTED]> writes: > 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 Aba's url is a very good pointer. Read it carefully. There is also http://debian-amd64.alioth.debian.org/tools/sourcerer.conf http://debian-amd64.alioth.debian.org/tools/sourcerer-chroot that I use to setup buildd chroots for amd64. As for the actual buildd and wanna-build try: # for sbuild, buildd, etc... deb http://db.debian.org/ debian-admin/ #deb-src http://db.debian.org/ debian-admin/ MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: and commands used in maintainer scripts
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. >> >> If a package is missing a Depends, and therefore will routinely fail in >> prerm or postrm --remove, isn't that a release-critical bug? > > Because policy, unlike RFCs, does not use normative declarations such as > SHOULD and MUST (note the reason for uppercasing them in RFCs - to indicate > that they are, in fact, normative). > -- > Joel Aelwyn <[EMAIL PROTECTED]> ,''`. It should still be must so failure to do so is a serious policy violation (violation of a 'must' or 'required' directive). Just my 2c, Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: and commands used in maintainer scripts
On Wed, Jan 26, 2005 at 01:21:38PM -0600, John Hasler wrote: > Joel Aelwyn writes: > > Because policy, unlike RFCs, does not use normative declarations such as > > SHOULD and MUST... > > >From debian-policy: >In the normative part of this manual, the words must, should and may, and >the adjectives required, recommended and optional, are used to >distinguish the significance of the various guidelines in this policy >document. Packages that do not conform to the guidelines denoted by must >(or required) will generally not be considered acceptable for the Debian >distribution. Non-conformance with guidelines denoted by should (or >recommended) will generally be considered a bug, but will not >necessarily render a package unsuitable for distribution. Guidelines >denoted by may (or optional) are truly optional and adherence is left to >the maintainer's discretion. Hmmm. That contradicts what I got told the last time I filed a wishlist bug asking for the policy to clearly indicate the normative usages. Oh well, either times change or someone was mistaken. I *like* normative usages. I just also like them to be obvious. -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: scripts to download porn in Debian?
On Tue, Jan 25, 2005 at 10:32:13PM -0600, Ron Johnson wrote: > On Wed, 2005-01-26 at 03:38 +0100, Uwe A. P. Wuerdinger wrote: > > Ron Johnson schrieb: > > > On Tue, 2005-01-25 at 12:34 +0200, Kalle Kivimaa wrote: > > > > [-snip-] > > > > > And yes, I've already thought of that. However, I'd rather some > > > things (URLs, in this case) not be dropped my children's laps, > > > even though they could be blocked further upstream. > > > > > > When they start to get curious about such things, let 'em learn > > > about porn the old fashioned way... ;) > > > > Looks like an other round of underestimating children and censorship is > > coming up. > > Parents are *supposed* to censor what their children see. Says who (well, except you)? > They are also supposed to educate their children. Can't disagree with this one though. But there's always the saying: "Do as I say, not as I do". And it's always a mistake... [snip] Regards: David Weinehall -- /) David Weinehall <[EMAIL PROTECTED]> /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More on icons for packages
On Wed, 2005-01-26 at 09:41 -0500, Dale Scheetz wrote: > The icon I would prefer to use on the desktop/panel is 114x154 pixels > and gives a smoother lookeing icon. I'll have to experiment with violating > the menu spec and seeing how it works... i would say that could sound too large for an icon. png icons in /usr/share/pixmaps are 48x48. the other images are splash screen or alike and should go to /usr/share/. > > another manual does not seem required. but mentionning the use > > of .desktop would be a worth addition to the menu manual. > > > Except that it has little to do with the menu specification. oh yeah! it makes the freedesktop compliant menus. have a look in /usr/share/applications. > For those like me who went searching for "icon" in the docs it would > be nice to have a section with that title that points at the menu spec > and the desktop spec and any other useful help with icon managment. agreed. 9.3 in the policy could contains the word icon. and the menu manual could advise to have a look at the freedesktop specifications. > I'm still left with a question: How do I, as a package maintainer, > provide these .desktop files so the user either automatically or by > some simple choice gets the icon on their desktop? put it in the menu, drag and drop on the desktop works there too. there is no entry to specify different icon sizes, so you could also craft one more myapp.desktop linking to the bigger icon and tell your users where to copy it from to install it. but i would not like at all having a program that automatically adds icons to my desktop. it's messy enough as it is :) ciao, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Slightly Off Topic: Laptops for Debian
On Tue, Jan 25, 2005 at 08:32:18PM -0600, Jacob S said > pcmcia. For that matter though, I can't see that much difference in a > wireless usb stick and a pcmcia when the usb and iBook are both used > without modification. Having something flimsy stick two inches out the side of the iBook is very very noticable. -rob -- Words of the day: CBNRC Dateline attack SAFE Serbian Telex beanpole gamma -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#292105: ITP: libmusepack -- Musepack (MPC) format decoder library
On Mon, Jan 24, 2005 at 11:16:08PM -0600, Joe Wreschnig said > Package: wnpp > Severity: wishlist > > * Package name: libmusepack > Version : 1.1 > Upstream Author : The Musepack Development Team > * URL : http://www.musepack.net > * License : 3-clause BSD > Description : Musepack (MPC) format decoder library > > libmusepack allows you to decode files in the Musepack audio format, > which usually use the 'mpc' extension. MPC is a lossy compression format > like MP3 or Ogg Vorbis. It is based on the MPEG-1 Layer-2 / MP2 algorithms, > but has vastly improved. This sounds interesting, but perhaps you could elaborate on how it is vastly improved? Better quality for the same bitrate? Less distortion? Lower bitrate/same quality? etc. -rob -- Words of the day:Kh-11 cryptographic e-cash Cocaine ANC eternity server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: hwcap supporting architectures?
At Sun, 23 Jan 2005 18:38:59 +0100, Bernd Eckenfels wrote: > On Mon, Jan 24, 2005 at 01:16:12AM +0900, Junichi Uekawa wrote: > > Looking at the rate of hardware changes, we will ideally be wanting > > to add a new hwcap entry just about every year; > > which results roughly in x10 time penalty every 3 years. > > 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. Note that there are LD_LIBRARY_PATH, DT_RPATH and DT_RUNPATH. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
rebooting, non-root raid, udev
Hello, How is the boot process of RAID (using a Debian supplied kernel that doesn't have RAID autodetect compiled in) meant to work with udev? What seems to happen (at least with recent testing/sarge based system): 1. initrd script starts RAID for swap and /. No problems here. The initrd script does the right thing (after I renamed devfs names to non-devfs names in /etc/raidtab that is). 2. kernel boots and transfers control to userland. 3. udev, I believe (not checked) starts early in the boot process. It creates /dev/md entries for the activated RAID partitions (swap and /), but nothing else (since the RAID hasn't been initialised for these devices yet). 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. As I hacked solution, I have added to the very start of my /etc/init.d/raid2 (not tested yet in automatic boot, but worked when I run it manually): for i in 12 14 20 30 32 do mknod /dev/md/$i b 9 $i ln -s md/$i /dev/md$i done I think this will solve the problem. Now I know what happens in practise, what is meant to happen in theory? I haven't observed anything like this behaviour with devfs, so I suspect this is udev specific. -- Brian May <[EMAIL PROTECTED]> -- 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 08:15:38 +0100 (CET) Andreas Tille <[EMAIL PROTECTED]> wrote: > On Tue, 25 Jan 2005, Dale C. Scheetz wrote: > > > It might be better to reserve /usr/share/pixmaps specifically for menu > > icons in xpm format and create /usr/share/icons for png gif and jpeg > > icon images. > Why not putting all icons (xpm, png, ...) into /usr/share/pixmaps and just > use the XPMs for menu and the other for anything else? > At least I think that we are bound to /usr/share/pixmaps at least to > support fredesktop.org standards for the Gnome / KDE icons. If the maintainer > does not provide any PNG but has created an xpm it wold definitely not > hurt in this location. Perhaps a problem for the user would be if there > would be two icons with a similar look (XPM and PNG). > When I looked briefly at the freedesktop standard for Gnome and KDE icons I thought it specified /usr/share/icons and, sure enough there be icons here. There is a lot more stucture here to. /usr/share/icons/Default and others that I looked at have subdirectories ranging from 12x12 up to 192x192 but the contents seems to be specialized to gnome pieces-parts. (the more I look the more complicated it gets...) > 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. >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 ;-) >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? > > Is it worth while trying to get some general icon policy established or > > am I straigning at gnats? > Would the skecth of a policy above make sense to you? > Simplify, simplify, simplify ;-) Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: scripts to download porn in Debian?
On Wed, 2005-01-26 at 22:31 +0100, David Weinehall wrote: > On Tue, Jan 25, 2005 at 10:32:13PM -0600, Ron Johnson wrote: > > On Wed, 2005-01-26 at 03:38 +0100, Uwe A. P. Wuerdinger wrote: > > > Ron Johnson schrieb: > > > > On Tue, 2005-01-25 at 12:34 +0200, Kalle Kivimaa wrote: > > > > > > [-snip-] [snip] > > Parents are *supposed* to censor what their children see. > > Says who (well, except you)? *Your* parents. And, to take an extreme example, the parents of every 5 yo who won't let him go see some hyper-violent R-rated(*) movie. (*) In the USA, an R (Restricted) movie says that children under age 17 are not allowed in without an adult. > > They are also supposed to educate their children. > > Can't disagree with this one though. But there's always the saying: > "Do as I say, not as I do". And it's always a mistake... Bull. Happens all the time. Quick example: I cross the street by myself all the time. My children, however, can't. -- - Ron Johnson, Jr. Jefferson, LA USA PGP Key ID 8834C06B I prefer encrypted mail. GGLX : Gnome GNU Linux X.Org signature.asc Description: This is a digitally signed message part
Re: NPTL support in 2.4 kernel series?
At Fri, 21 Jan 2005 19:51:22 +0100, Martin Kittel wrote: > Recently upstream has converted the database kernel from > linuxthread-style threading to NPTL. While -at least for i386- > linuxthreads is still supported in MaxDB at this time, it will go away > in one of the next releases. > As far as I know there is no NPTL support in 2.4 debian kernels (as for > example in some RedHat 2.4 kernels). Is that correct? > In that case I will have to add a dependency on kernel-image-2.6 or does > anyone know of a better way to express a dependency on NPTL style threading? I don't read these threads entirely, so some opinions may be duplicated in other messages. (1) The correct way to detect NPTL availability is: check the result value of "getconf GNU_LIBPTHREAD_VERSION": [EMAIL PROTECTED]:~> uname -a Linux celesta 2.6.8-1-686-smp #1 SMP Mon Sep 13 23:02:39 EDT 2004 i686 GNU/Linux [EMAIL PROTECTED]:~> getconf GNU_LIBPTHREAD_VERSION NPTL 0.60 [EMAIL PROTECTED]:~> env LD_ASSUME_KERNEL=2.4.1 getconf GNU_LIBPTHREAD_VERSION linuxthreads-0.10 You can check it in your wrapper script. If your wrapper script detects NPTL unavailability, you can put warning message. One problem is old libc6 does not include /usr/bin/getconf (until 2.3.2.ds1-13, it was included in libc6-dev). So your package should depend on at least 2.3.2.ds1-14 if this method is used (because the current libc6 shlib deps is 2.3.2.ds1-4). (2) Most architectures do not support NPTL currently. Debian glibc-2.3.2.ds1-20 supports NPTL on i386, amd64, ia64 and s390. So your package is available on only four architectures. (We have plan to add NPTL support for alpha, ppc and ppc64 in the next glibc update. However, currently NPTL is not supported even in upstream cvs on arm (EABI update), mips (tls register discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is everytime big problem in computer history). It's sure that hurd and *bsd are out of scope with NPTL.) (3) NPTL is POSIX thread library - I wonder why your package has to depend on NPTL. It's sure there're a lot of incapability to handle the whole POSIX threading requirement with linuxthreads - but it has basic features to use pthread. Depending on the specific implementation is not good idea, IMHO. Martin, I would like to know why such requirement is needed. (4) In general, depending on the specific kernel package causes various problems as other mails are already mentioned. MaxDB should not use check kernel version because it's related with threading system, not kernel version. However some packages really needs kernel version checking - one example is glibc package. It detects old kernel version using "uname" in libc6.preinst. If old kernel version is detected, preinst warns with messages and just exits. (Note that I'll add "uname detection" not only in preinst but also in /etc/init.d in future, though. I notice that we can possibly put a generic kernel version detection mechanism for this kind of purpose.) Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NPTL support in 2.4 kernel series?
[ Not ignoring point 1 or 4, just nothing to say about them. ] On Thu, Jan 27, 2005 at 10:37:34AM +0900, GOTO Masanori wrote: > > (2) Most architectures do not support NPTL currently. Debian > glibc-2.3.2.ds1-20 supports NPTL on i386, amd64, ia64 and s390. > So your package is available on only four architectures. > > (We have plan to add NPTL support for alpha, ppc and ppc64 in the > next glibc update. However, currently NPTL is not supported even > in upstream cvs on arm (EABI update), mips (tls register > discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is > everytime big problem in computer history). It's sure that hurd > and *bsd are out of scope with NPTL.) Regarding the BSD ports and NPTL: absolutely out of scope, but also mostly irrelevant; the threading libraries on all variants I know of are more or less fully POSIX compliant (as NPTL is, and LinuxThreads is not) and capable of handling N threads for values of N that scale well (again, which NPTL can do, and LinuxThreads cannot). Or, in other words, any package that builds on a BSD and uses POSIX threading (which means 'uses threading at all' on a BSD, generally) will be just fine, despite the absence of NPTL. Or, in short, the sane way to write POSIX threading is to #ifdef the LinuxThreads as a special case (that you'd generally like to get rid of :), not to special-case NPTL. This does not, of course, change the necessity of supporting and detecting LinuxThreads vs. NPTL on the 11 released Debian ports, since they're all Linux and only some of them have NPTL (as you bring up above). Of course, it's fairly simple to check uname on those and skip the check as irrelevant on known-sane BSD systems (I can't comment on Hurd threading, having never touched it). > (3) NPTL is POSIX thread library - I wonder why your package has to > depend on NPTL. It's sure there're a lot of incapability to > handle the whole POSIX threading requirement with linuxthreads - > but it has basic features to use pthread. Depending on the > specific implementation is not good idea, IMHO. Martin, I would > like to know why such requirement is needed. Speaking from direct experience (as in, writing applications running hundreds of threads handling thousands of transactions per second 24/7): any 'serious' (high load, high thread count environment) attempt to use POSIX threading semantics on LinuxThreads, or to rely on certain fundamental points of POSIX threading (like, say, signal handling) is prone to fundamental breakage. Not just incidental, but "melt down your system with processor load" levels. Databases, for various reasons involving certain design patterns that work well for them when you can count on sane threading, tend to be extremely good at triggering this... -- Joel Aelwyn <[EMAIL PROTECTED]> ,''`. : :' : `. `' `- signature.asc Description: Digital signature
Re: NPTL support in 2.4 kernel series?
On Thu, Jan 27, 2005 at 10:37:34AM +0900, GOTO Masanori wrote: > (We have plan to add NPTL support for alpha, ppc and ppc64 in the > next glibc update. However, currently NPTL is not supported even > in upstream cvs on arm (EABI update), mips (tls register > discussion), hppa (Hurrah Carlos O'Donell), m68k (slow speed is > everytime big problem in computer history). It's sure that hurd > and *bsd are out of scope with NPTL.) By the time we actually do this, I hope to have both ARM and MIPS support pushed out. It's all been written, and we're starting the submission process over the next couple of weeks, I hope. -- Daniel Jacobowitz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Arabic Linguist
Amir resume.wpd Description: Binary data
