Bug#955392: ITP: erlgrind -- Convert Erlang fprof output to callgring output
Package: wnpp Severity: wishlist Owner: Pierre Thierry * Package name: elgrind Version : n/a Upstream Author : Isac Sacchi e Souza * URL : https://github.com/isacssouza/erlgrind * License : BSD-2-Clause Programming Lang: Erlang Description : Convert Erlang fprof output to callgring output This escript makes it possible to use fprof data with the existing cachgrind toolchain (like visualization in kcachegrind…)
Service stopping in prerm considered harmful
For the nth time, I have a package that dpkg is unable to remove because
it tries to stop a service that either is already stopped (I didn't want
it) or couldn't start at all. In the former case, the fix seems simple:
start the service and remove the package. But sometimes starting the
service may have undesirable outcomes on the system, or the stop action
will fail in some way.
In either case, when you can't get a successful stop action for the
service init.d script, the package is impossible to remove without human
action, and not a simple one, because you need to be able to hack the
maintainer scripts or the init.d script.
Shouldn't the maintainer script actually ensure that the service is not
running, instead of just triggering the stop action and checking its
exit code? Something like (it's pseudo-code, because the status action
of init.d scripts prints text, it doesn't seem to give machine-friendly
data):
# if it's running, stop it
if(status(service) == running) {
stop(service);
}
# if now it's still running, something's wrong
if(status(service) == running) {
exit 1;
}
# proceed...
Annoyingly,
Pierre
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
SELinux overhead
Is there available data about the overhead of enforcing various SELinux policies? Quantitatively, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Long-term mass bug filing for crossbuild support
Scribit Neil Williams dies 13/11/2007 hora 17:02: > If you want to build an ARM toolchain to crossbuild for amd64 I'm not > going to stop you but don't expect me to debug it!! But do your tools make it already possible for me to just ask for the build of toolchains for an arbitrary list of target architectures, from an arbitrary host architecture? I can well understand why you don't want the N*N-N packages or sets of packages in the official Debian archive, but it would be great if the tools make it possible to build them. There's also the fact that it could be useful for ports not in the released ones. In any case, thanks to all developers from Embdebian! That's a great project. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Long-term mass bug filing for crossbuild support
Scribit Neil Williams dies 11/11/2007 hora 12:44: > Emdebian supports amd64, i386 and powerpc as --build. Why aren't all architectures supported by Debian supported? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: crossbuild support: help2man considered harmful
Scribit Josselin Mouette dies 09/11/2007 hora 22:53: > BTW, there is another package which does this, and which is likely to > cause you much more trouble: python. The build system compiles the > modules using the generated python binary. This is a classical problem in bootstrapping a language implemented in itself. Providing an automated way to make an arbitrary bootstrap in Debian would be useful. Quickly, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#446971: ITP: zpb-exif -- Common Lisp package to access EXIF metadata
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: zpb-exif Version : 1.0 Upstream Author : Zachary Beane <[EMAIL PROTECTED]> * URL : http://www.xach.com/lisp/zpb-exif/ * License : BSD Programming Lang: Common Lisp Description : Common Lisp package to access EXIF metadata EXIF is a standard for embedding information in an image file created by a digital camera. ZPB-EXIF is a library that makes Exif data accessible to Common Lisp programs. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502, 'stable'), (501, 'unstable'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Testing parallel builds
Scribit Manoj Srivastava dies 09/10/2007 hora 00:04: > It is kinda scary that my typical ./debian/rules has a minimum of 61 > targets, and that is just the base number. But it sure makes for > pretty pictures :) How did you generate those dependency graphs, BTW? I didn't find anything relevant in the reverse dependencies of graphviz... Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Handling of poorly maintained and useless packages
Scribit Michael Biebl dies 12/10/2007 hora 15:06: > > - For packages where orphaning was proposed: 50 days > > - For packages where removal was proposed: 100 days > As sune suggested, 1 and 2 months would be enough imo. As a compromise, the delay to orphan a package could be set to 1 month when there is someone actively wanting to adopt it, 2 months otherwise. The delay for removal shouldn't be less than 3 months. Chronologically, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: wxwidgets 2.8 needs help !
Scribit Roberto C. Sánchez dies 04/10/2007 hora 18:13: > > wxWidgets has been released a long time ago and we're still missing > > it. > Yes, though for a good [1] reason. Sure, wxwidgets has numerous bugs, but is it that surprising for a library package that much used? (i.e. would such a backlog of bugs prevent any other library packager to upload a new upstream into Debian?) > It is not really a question of building or packaging it. That, as you > realize is quite easy. The problem is wxwidgets' dozens of reverse > dependencies. Shouldn't then the package be uploaded to experimental for interactions with the reverse dependencies to be checked? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
Scribit Pierre Habouzit dies 03/10/2007 hora 21:49: > *g* found exists and is versionned, since sth like a year now. if not > two. But is the submitter of the "found" information made easily available? At least it's not shown anywhere in the version graph. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Firefox bugs mass-closed.
Scribit Pierre Habouzit dies 02/10/2007 hora 20:16: > Confirmed is not versionned. The fact that it was confirmed at one > point does not means that the bug is still here. Wouldn't a generic found-by be useful? Then the bug could contain the information about not only the versions where the bug was found, but also by who. For the maintainer, confirming a bug is adding the info that he too found the bug at a current version. Generically, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Packaging a library that requires cross-compiled code
Scribit Josselin Mouette dies 02/10/2007 hora 10:06: > > Because it proves that we are fully self-hosting, and the main > > reason _not_ to do it is the fear that we might _not_ actually be > > self-hosting. Which is something I believe we've promised our > > users, implicitly if not explicitly. > Given that especially autoconf introduces serious incompatibilities > between minor releases, this is simply not feasible because it would > trigger hundreds of FTBFS errors each time a new autoconf version is > uploaded. Shouldn't those bugs just be corrected, and would a similar number of bugs still be triggered with the next version? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#444911: ITP: bordeaux-threads -- Portable shared-state concurrency for Common Lisp
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: bordeaux-threads Version : 0.0.2 Upstream Author : Greg Pfeil * URL : http://common-lisp.net/project/bordeaux-threads/ * License : MIT Programming Lang: Common Lisp Description : Portable shared-state concurrency for Common Lisp BORDEAUX-THREADS is a proposed standard for a minimal MP/Threading interface. It essentially provides a compatibility layer for multi-threading accross multiple CL implementations. Some parts of it's implementation-specific code can also be implemented in a Lisp that does not support multiple threads, so that thread-safe code can be compiled on both multithread and single-thread implementations without need of conditionals. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502, 'stable'), (501, 'unstable'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#444910: ITP: cl-vectors -- Rasterizer and paths manipulation library for Common Lisp
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: cl-vectors Version : 0.1.3 Upstream Author : Frédéric Jolliton <[EMAIL PROTECTED]> * URL : http://projects.tuxee.net/cl-vectors/ * License : LLGPL Programming Lang: Common Lisp Description : Rasterizer and paths manipulation library for Common Lisp This package provides the following libraries: cl-paths is a basic vectorial paths library. Paths can be described by 4 types of interpolations, including Bezier curves of any degree, and Catmull-Rom splitens. Some path transformations are included. There is stroking, dashing and clipping transformations available. But none of these transformation are implemented perfectly, in the sense that algorithms used in the library are rather simples. cl-paths-ttf uses the zpb-ttf library to create paths from glyphs or string from a given TTF font file. cl-aa is an anti-aliasing library. cl-aa-misc is library to render, save, load and display PNM images. cl-vectors includes systems cl-paths and cl-aa, and also provides a function to use the former with the latter. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502, 'stable'), (501, 'unstable'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#444912: ITP: mt19937 -- Common Lisp portable Mersenne Twister random number generator
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: mt19937 Version : 1.1 Upstream Author : Douglas T. Crosher and Raymond Toy * URL : http://www.cliki.net/MT19937 * License : Public Domain Programming Lang: Common Lisp Description : Common Lisp portable Mersenne Twister random number generator MT19937 is a portable Mersenne Twister random number generator. It is mainly a modification of CMUCL's random number generator with all the CMUCL-specific parts taken out. It is faster than the JMT Mersenne Twister implementation, but significantly slower than native random number generators provided by major Common Lisp implementations. For light use this shouldn't be a problem, since it is still very fast. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502, 'stable'), (501, 'unstable'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#444778: ITP: cl-salza-png -- Common Lisp package to write PNG
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: cl-salza-png Version : 1.0 Upstream Author : Zachary Beane <[EMAIL PROTECTED]> * URL : http://www.xach.com/lisp/salza-png.tgz * License : BSD Programming Lang: Common Lisp Description : Common Lisp package to write PNG The salza-png software is a standalone version of the PNG writer from the salza examples directory. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502, 'stable'), (501, 'unstable'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#444729: ITP: vecto -- Simple Vector Drawing with Common Lisp
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: vecto Version : 1.0.1 Upstream Author : Zachary Beane <[EMAIL PROTECTED]> * URL : http://www.xach.com/lisp/vecto/ * License : BSD Programming Lang: Common Lisp Description : Simple Vector Drawing with Common Lisp Vecto is a simplified interface to the powerful CL-VECTORS vector rasterization library. It presents a function-oriented interface similar to CL-PDF, but the results can be saved to a PNG instead of a PDF file. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (502, 'stable'), (501, 'unstable'), (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Use of "Breaks" dependencies
Scribit Ian Jackson dies 29/06/2007 hora 14:28: > I think it's a bug that we try to do upgrades from release A to B > using A's packaging tools. In most case, IME, it worked. In the cases where we know it won't, couldn't the packaging tools be notified of the issue (much like the "requires" file of Mercurial repositories), upgrade themselves and continue operations with the new version? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: rampant offtopic and offensive posts to debian-user
Scribit Greg Folkert dies 18/05/2007 hora 18:42: > > It's so sad that these OT posters are driving away people like you. > > [...] > I guess you'd rather see the OT posters go away. I guess not. It was explicitly acknowledged that killfiling OT posters would prevent reading their useful posts, so the intent here seems clearly to keep everyone and just slow down the pace of OT postings. Calmly, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Feature request for GnuPG crypted Debian packages
Scribit Michelle Konzack dies 25/04/2007 hora 20:44: > > I think you're targetting the wrong layer of the system. If many > > packages contain so much sensitive data, it would be easier to > > encrypt a tarball or part of a FS where packages are read. > The packages are in general on the Server! Could you be more precise? First ISTR you talked about a CD with sensitive data. Now there's a package server. The two scenario are completely different, and call for completely different protection schemes, I'd say. > > As far as D-I is concerned, you could probably easily add a udeb to > > deal with decrypting and unpacking of that senstive part, and leave > > apt and dpkg untouched. > You mean, put the crypred tarball into the DEB? No. I mean you could have an encrypted tarball on the debian installer CD, and that tarball could be unpacked by a compononent of the installer. The debian packages in the tarball would then be reachable by apt and dpkg in a totally normal way (you could either add another source or use some union FS). > > On the other hand, if not all the Debian package is sensitive, you > > better be encrypting data inside it, and have the application or an > > helper decrypt it when needed, maybe in maintainer scripts. > I was trying this too, but Sometimes I get conflicts with Packages > containing the same files. Then your files are probably at the wrong place, and the packages probably aren't FHS compliant. Correct them before "enhancing" dpkg to work around the issue. Quickly, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Feature request for GnuPG crypted Debian packages
Scribit Michelle Konzack dies 24/04/2007 hora 16:40: > I would suggest to add a new header like "Crypted: " and then > crypt the data.tar.gz (in the Debian package). I think you're targetting the wrong layer of the system. If many packages contain so much sensitive data, it would be easier to encrypt a tarball or part of a FS where packages are read. As far as D-I is concerned, you could probably easily add a udeb to deal with decrypting and unpacking of that senstive part, and leave apt and dpkg untouched. On the other hand, if not all the Debian package is sensitive, you better be encrypting data inside it, and have the application or an helper decrypt it when needed, maybe in maintainer scripts. Alternatively, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Mandatory -dbg packages for libraries?
Scribit Daniel Jacobowitz dies 23/04/2007 hora 16:19: > Another possible way to change glibc would be to have libc6-dbg > contain full debug symbols, libc6-dev contain -g1 symbols only, and > have the -dbg divert the -dev. Why not do that for every library? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Draft spec for new dpkg "triggers" feature (v2, repost)
Scribit Ian Jackson dies 10/04/2007 hora 19:27: > If the central package finds problems with the leaf package data it is > usually more correct for only the inidividual leaf package to be > recorded as not properly installed. There is not currently any way to > do this and there are no plans to provide one. As a user, I expect to find it very annoying if one package can easily break havoc for many others. For any trigger that will only deal with files where each file is produced by a single package, maybe we should consider an error reporting protocol by which the trigger can report to dpkg the faulting files (when it is able to do so). With those files, dpkg should be able to figure which packages are properly configured and which are not, WRT this trigger. As I don't have any knowledge of dpkg's internals, I'm not sure what such an error protocol could be. Maybe we could pass a FIFO to the trigger and it could write null-terminated file names in it. Erroneously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: What's needed to integrate backports at full scale
Scribit Raphael Hertzog dies 15/04/2007 hora 14:07: > The automatic dependency are mostly right and they are not a problem > if a simple recompilation replaces them with a dependency that works > within stable. In the cases where this is only a matter of a simple recompilation, maybe we should just make it easier for this recompilation to happen. Maybe we just need to use existing tools in a clearly documented way, and explain to maintainers where the corner cases are. A maintainer could first do as usual, and build the package in sid, with automated dependencies on packages currently in Sid. Then, by incrementing the Debian revision of the package, he could do various rebuilds (or the build daemons could do them), going back in time. In current testing, then in stable, maybe even in oldstable. Maybe the CUT releases could also become interesting targets. > However as you know, there's rarely something like "simple > recompilation" to backport a package because: > (1) the build-dependency require a package which is not in stable > (2) the generated package depends on packages which are not in stable Are there numbers about the ratio of packages that would only need recompilation? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Debian Development environments.
Scribit Andrea Bolognani dies 12/04/2007 hora 18:01: > I think a live CD aimed at developers would be quite useless. But > feel free to correct me. The Université Jussieu (Paris) found it useful. They distribute a live CD based on Knoppix to the students, called Juppix: http://www.pps.jussieu.fr/~jch/software/juppix/ Not every developer knows how to find the packages that would satisfy his needs. We should care about our users if we can help, and having some tasks or meta-packages about programming would be quite useful. Maybe we need something more elaborate for them to choose, with questions like: What environments are you targetting: - GTK+ - Qt - like I care What languages do you want to use: - C - C++ - Perl - Python - Common Lisp - etc. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Mozilla renames: is Debian the only one?
I was wondering, as I did not find any clear info on the subject by Googling: is Debian the only distro that renamed the Mozilla packages? If not, which ones? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Bug#415862: ITP: why -- A software verification tool
Scribit Samuel Mimram dies 22/03/2007 hora 18:10: > * Package name: why That's great! I had begun to play a bit with why, but having it as an official Debian package will make it easier. As I'm beginning to do some packaging, if you ever need it, I'd gladly help (packaging a new upstream, triaging bugs, etc.). Provably Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: many rejects (Re: Second call for votes for the debian project leader election 2007)
Scribit Steve Langasek dies 01/04/2007 hora 13:09: > Hrm, is there really an RFC that specifies encryption before signing? AFAIK, the RFC specifies how to build an encrypted MIME body and a signed body. When you want both, you can either store a signed body in the encrypted one, or an encrypted and signed PGP data as an encrypted body... > That would violate the expectation that people other than the intended > recipient of the mail should not be able to verify the source. Which provides you with repudiability for non-recipients, which can be an expectation too. Differently, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Changelogs for unofficial packages
Scribit Magnus Holmgren dies 31/03/2007 hora 14:34: > Have there been any discussion about adding a field to the Release and/or > Packages files pointing at e.g. changelogs, so that aptitude etc. could > display those for packages from unofficial repositories as well? Maybe it would be worth designing a generic metadata architecture for package repositories. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
EM64T announcement and Linus (was Re: Compiling Debs on AMD vs. Intel and 32bit vs. 64bit)
Scribit Peter Samuelson dies 17/03/2007 hora 03:29: > Linus Torvalds read Intel's announcement and was a bit disgusted that > Intel tried as hard as they could to imply (without actually saying > so) that the architecture was their own invention Would you have any reference to this? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Huge cache dirs in $HOME
Hi, I just discovered today that some packages can store pretty huge cache data in my $HOME, and found that rather problematic. When I backup my home, I don't want to waste backup space or time to do it, because I have to check what eats space and tell if it's cache data. Couldn't such packages, like beagle and tracker, just use the standard directory for that purpose, like specified in XDG's basedir? That would be very helpful, I find. Could it be made mandatory, for packages that produce rather big caches, like indexing tools? Separately, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: debian-private and Gmail
Scribit Andreas Tille dies 06/12/2006 hora 14:09: > > Please ignore paranoid people. > To be honest you have to regard any nonencrypted mail as world > readable and you can be nearly sure that all your mails are recorded > at a place where you have no control over it. I thought that very few ISP have really the will and disk space to record everything that comes from and to their cusotmers. The real problem with Google seems to be that 1) they have all the infrastructure needed to keep and use it 2) they clearly state that they will keep everything. Shouldn't that make a difference? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Automatic bootstrap?
As I just installed an amd64 system, I discovered that the cmucl is not already available for that port. If I'm not mistaken, cmucl needs some manual bootstrapping. Wouldn't it be useful to make it possible for a package needing bootstrap to specify it, so that an unattended bootstrap be possible, e.g. on a buildd? If yes, has it already been tried? Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Processed: Changed address
reassign 206293 mozilla-browser reassign 173206 emacs21 reassign 202620 mozilla-browser reassign 203700 ssh reassign 246678 debtags reassign 248664 bind9 reassign 173494 vim-gtk reassign 199709 mutt reassign 241866 jzip reassign 248501 gman reassign 206374 xml-resume-library reassign 266021 ifupdown reassign 201639 wnpp reassign 204606 wnpp reassign 205024 purity reassign 206931 wnpp reassign 212022 netrik reassign 229715 general reassign 248526 gman reassign 248529 groff reassign 264108 lxr reassign 217899 argouml reassign 206390 libxalan2-java reassign 217878 argouml reassign 224383 vim reassign 192422 wnpp reassign 198826 wnpp reassign 198828 wnpp reassign 198829 wnpp reassign 204472 wnpp reassign 204475 wnpp reassign 212343 wnpp reassign 221795 wnpp reassign 221796 wnpp reassign 221798 wnpp reassign 235729 wnpp reassign 184482 lynx thanks Sorry for the annoyance, I used reassign instead of submitter by mistake. Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
Scribit Josselin Mouette dies 12/11/2005 hora 18:37: > It was already suggested to accept only source+binary uploads, but to > rebuild the binaries on the upload's architecture anyway. Has there been a consensus on rejecting that solution? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
Scribit Manoj Srivastava dies 11/11/2005 hora 22:35: > You gotta start trusting somewhere. Our web of trust starts with the > Developers in the keyring, we trust these people not to muck with the > binaries. You trust them, but not any user of Debian will want to trust them so much. Some will want some degree of confidence that the binaries are clean... Would it cost too much to implement? Doubtfully, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
Scribit Anthony Towns dies 11/11/2005 hora 16:43: > The problem is a technicality, not a moral or practical difference > from the GPL's expectations: you still have the source to OpenSolaris > libc, and you still have permission to modify it, redistribute it, > sell it, etc. Didn't someone ask for the source of some other packages (sunw*) that are not, at the moment, available (and won't in the future, IIUC)? I had understood that the problem is that some of the source needed to compile core packages of Nexenta are not even open source... Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: gnome-swallow_1.2-2_source.changes REJECTED
Scribit Josselin Mouette dies 10/11/2005 hora 22:45: > Le jeudi 10 novembre 2005 à 13:32 -0800, Debian Installer a écrit : > > Rejected: source only uploads are not supported. > I can't see the rationale for rejecting source uploads, and they used > to be accepted in the past. And I see a rationale for allowing them: what prevents a DD to upload binaries that include exploits or some trojan code, along with a clean source? Isn't a buildd compilation more secure WRT this issue? (I don't try to say it's perfectly secure, I think admins of the buildd could do the trick also...) I suspect that is has already been discussed, so could someone give me URIs of messages/web pages on the subject if it is the case? BTW, is there any infrastructure to check against that? Would it be possible, or consume way much of resources (and first CPU of the buildd)? Doubtfully, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Request: Source for parts of GNU/Solaris
Scribit Alex Ross dies 08/11/2005 hora 11:36: > Overnight we actually did remove the downloads. I'm downloading the LiveCD image right now from a link in the download page[1]. Do I have to understand that you corrected the GPL violation problem and that I can find all the sources the GPL gives me the right to get? Doubtfully, Nowhere man [1] http://www.gnusolaris.org/gswiki/Download -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Bug#338058: ITP: markdown -- text-to-HTML conversion tool for web writers
Scribit Pierre THIERRY dies 08/11/2005 hora 01:04: > * Package name: markdown Sorry for that invalid ITP (markdown *is* packaged). It seems reportbug check the archive when doing a RFP, but not an ITP. Maybe on the supposition that when you do an ITP, you know more what you're doing and follow the indications to check yourself before. Oops. Shamely, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Bug#338058: ITP: markdown -- text-to-HTML conversion tool for web writers
Package: wnpp Severity: wishlist Owner: Pierre THIERRY <[EMAIL PROTECTED]> * Package name: markdown Version : 1.0.1 Upstream Author : John Gruber <[EMAIL PROTECTED]> * URL : http://daringfireball.net/projects/markdown/ * License : BSD-style Description : text-to-HTML conversion tool for web writers Markdown is a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML). Thus, "Markdown" is two things: a plain text markup syntax, and a software tool, written in Perl, that converts the plain text markup to HTML. Markdown works both as a Movable Type plug-in and as a standalone Perl script -- which means it can also be used as a text filter in BBEdit (or any other application that supporst filters written in Perl). Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: [Fwd: major problem with gnome-games dependency]
Scribit Kevin Mark dies 13/10/2005 hora 02:26: > I was thinking of a feature that would show 'recommends' but add a > line line explaining what installing package X would add to the > currently selected package. > > [...] > > if this metadata could be added to the package data file it could be > utilized by some program(not sure which or how). I think Debian should develop a general metadata solution for APT. There are already very powerful tools to handle metadata, like the RDF data model, it's serializations (RDF/XML, N3, etc.) and tools associated (Raptor, Rasqal and Redland already packaged in Debian, including sarge). With a generic metadata infrastructure in the APT tools, it wouldn't be a pain anymore to extend APT: debtags could be achieved with it, dependency explanation also. With a separation between the core APT features, like installation end dependency handling, and the metadata addon, it could also be possible to fetch metadata elsewhere: one could have it's own debtags metadata, or some teams of DD or users could publish specific debtags (e.g. for parents that don't want violent games on their system...). Generically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: a few tips on proper use of version tracking in the Debian BTS
Scribit Stefano Zacchiroli dies 19/10/2005 hora 11:06: > 1) once a bug as been closed - erroneously I would say - mailing > [EMAIL PROTECTED] without the "Version:" pseudo header, is > there a way to push the version information to the bts? It seems. I did it for #297927: after sending a 'close 297927' to [EMAIL PROTECTED], the BTS informed me that it was deprecated. I sent another mail to [EMAIL PROTECTED] with 'Version: 0.9.23-1', and it is now in the BTS as ``Fixed in version 0.9.23-1''. Precisely, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Managing SSL certificates
Scribit sean finney dies 16/10/2005 hora 11:00: > also, i think extreme care should be take wrt these ssl certificates. > i don't think they should be blindly purged at package removal (or > probably even package purge) time, without getting permission from the > local admin. I think that this SSL certificates manager package should just have an option that specifies what action(s) should be triggered when a reference count falls down to zero: [ ] send a mail to the admin telling him [ ] do something with the files [ ] move the files [ ] delete the files Optionally, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: experimental and autobuild (was Re: New XTerm package, independent from X.Org, in experimental.)
Scribit Christoph Berg dies 08/10/2005 hora 22:06: > > Quickly, > > Nowhere man > > Using realnames is a matter of politeness on Debian lists. That's partly why my complete address in the From header of my mail is Pierre THIERRY <[EMAIL PROTECTED]> instead of Nowhere man <[EMAIL PROTECTED]> Namely, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
experimental and autobuild (was Re: New XTerm package, independent from X.Org, in experimental.)
Scribit David Martínez Moreno dies 05/10/2005 hora 13:28: > - Oh, yes. My package is only compiled for i386. O:-) For the sake of my curiosity, aren't the packages in experimental taken care of by the autobuilders? Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Re: Packages with unusable documentation
Scribit Alban Browaeys dies 23/04/2005 hora 05:04: > hum this is overkill. Install dwww (need an apache install) that s the > best we have in debian until now. The problem is also that many maintainers don"t register their documentation with doc-base... Are there lintian/linda checks for that ? Documentally, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Right of a maintainer not to respect FHS
Scribit Don Armstrong dies 04/04/2005 hora 01:09: > Otherwise, all you're doing is abusing the BTS, no matter how correct > your actual appraisal of the severity bug is. Downgrading a bug that is a clear violation of the policy just to have a package in the next stable release IS abusing the BTS. Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Right of a maintainer not to respect FHS
Scribit Steve Langasek dies 04/04/2005 hora 00:42: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=14 > > He has the approval of the release team. I didn't notice this mail in the time I was discussing with the maintainer. And it lacks explanation. When I read it recently, I thought it was some sort of error in an automated process. And I told the maintainer I thought he had no right to do a downgrade, and he never informed me that he had this approval: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=30 : > > I insist: you do not have the right, > Feel free to bring it up with tech committee. Simply, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Automatic testing of Debian packages
Scribit Michael Schiansky dies 08/04/2005 hora 11:44: > None of my maintained packages do provide such things. For all of them > any automatic test is impossible as they require user interaction. apt-get install expectk > IMHO it's not worth the efford to implement such an autotest-system > just for a small amount of our packages. IMHO its worth for a vast majority of them. Even complex intreactive programs can have their core functions non-interactively tested for completeness. I don't know which part of the UI can be tested with expectk, though. Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Bug#303667: ITP: cycle -- calendar program for women
Scribit Miriam Ruiz dies 08/04/2005 hora 02:20: > - Calculate days of "safe" sex There are still people to believe that it works?! Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: intend-to-implement: script to obtain Debian Source
Scribit Steve Greenland dies 06/04/2005 hora 17:37: > There's a long history of people relying on explicitly unspecified > behaviour, and then bitching when that behaviour changes. For the sake of my curiosity again, could you point me some precise examples? Historically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: intend-to-implement: script to obtain Debian Source
Scribit Lars Wirzenius dies 06/04/2005 hora 21:34: > > I don't find it very sane to be forced to deliberately trigger > > problems on the user's system to find bugs. > I assume the goal is to make it fail on the developer's system, on > build daemons, whenever random developers unpack the package If it is random, there could be only one or two combinations that fail and dozens (or far more, FWIW) that work well without anyone noticing anything. Remember that when it can go wrong, it will at the worst moment; that is, for us, on the user's system (and for the source point of view, random developers should be considered users). The maintainer and the buildds count only for a bit more than a dozen unpackings, for now, if I understand correctly how buildds work... > The point is to make it as likely as possible to make it break, if it > breaks at all, so that when the user sees the package, it is already > non-broken. That's the very purpose of a test suite! But that one doesn't rely on the randomness of the apparition of a bug, but makes *everything* that is possible to make it visible. -1 random +2 lintian Why use a suboptimal solution when an optimal one is available? Probabilistically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: intend-to-implement: script to obtain Debian Source
Scribit Steve Greenland dies 04/04/2005 hora 07:15: > > - what problems do thsi random order could weed? > Unnoted dependencies that just happen to be fulfilled due to a > consistent (though arbitrary) application order. By applying in a > different order each time, you should trigger an error fairly quickly. I don't find it very sane to be forced to deliberately trigger problems on the user's system to find bugs. Wouldn't it be more appropriate in a package testing tool? Maybe lintian, with a test of all combinations of independant patches (or a more intelligent subset) to see if something fails. When I unpack a source, I don't want it to fail to help a careless maintainer to find the flaws in one's packaging... > > - won't it be more difficult to trakcs bugs if it isn't predictable? > If you get an error during the patching process, it should be fairly > easy to determine that it's an un-marked dependency, and then find it > by hand. That's what you think. I'm not so sure. > You can also impose arbitrary dependencies among your supposedly > "independent" patches until you find the troublesome combination. Urgh. Are you doing computer science or cooking? Couldn't the application write somewhere the order of the patch that it just used?! Easily, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: init.d script dependencies for etch?
Scribit Humberto Massa dies 04/04/2005 hora 10:46: > > Cached? As in queried beforehand? As in two-pass algorithm, once > > iterating init.d with 'depends' as option, then with 'start' ? There are advantages to call the init.d script to poll its dependencies, instead of reading them: - the script can give them according to configuration files or by verifying that something is really needed (e.g. if a service is only accessed by unix sockets, no need for networking), - it doesn't force init.d scripts to be really shell scripts (dunno if this is really desirable, though). Dynamically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: intend-to-implement: script to obtain Debian Source
Scribit Adam Heath dies 01/04/2005 hora 19:10: > Additionally, as a way to weed out other problems, any patches that > are leafs(ie, don't depend on anything) are applied in a random order. For the sake of my curiosity: - what problems do thsi random order could weed? - won't it be more difficult to trakcs bugs if it isn't predictable? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Right of a maintainer not to respect FHS
I have a problem with a bug filed on r-doc-html (#300765). The documentation was entirely in /usr/lib, and it seems that all R packages have all their files under /usr/lib, whatever their type or purpose. I filed a bug with severity serious, as this breaks Policy 9.1.1 (FHS is mandatory). But the maintainer argued that R was packaged like this from the beginning, and that because it must stay in the distribution, the bug had to be downgraded to wishlist. SHouldn't he get the approval of the release team or ftpmasters before doing such an arbitrary downgrade? Surprinsingly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Packages count (was Re: Vancouver meeting - clarifications)
> So looks like "sarge" above should be "woody". Oh, yes. I was wondering why I found so few (!) packages, because last time I installed a fresh sarge, some debconf screen told me I could install something like 14K packages... BTW, is there any other distrib that includes officially so many packages? Increasingly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Vancouver meeting - clarifications
Scribit Anthony Towns dies 23/03/2005 hora 21:52: > Pierre THIERRY wrote: > >- Debian: 11 ports, 9157 packages (sarge) [17593 in sid] > Hrm, where are those numbers from? wc -l (modulo the first lines) of the allpackages.txt file on the website Quickly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Vancouver meeting - clarifications
Scribit Bas Zoetekouw dies 15/03/2005 hora 10:37: > I find it a bit hard to believe that Debian isn't able to support 11 > architectures while for example FreeBSD and NetBSD seem to manage > fine. - FreeBSD: 6 ports, 12646 packages - Debian: 11 ports, 9157 packages (sarge) [17593 in sid] - NetBSD: 55 ports, 5300 packages I think that Debian stands quite well the comparison... And maybe SCC will enable Debian to ``support'' many more architectures, and in a smooth way, instead of a somewhat all-or-nothing. Numerically, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Quick attempt to fix it
tag 296917 +patch
thanks
Hi,
following the discussion about this bug on debian-devel, with some late,
I looked quickly in the code of the debhelper package, and I think I
could understand it very fast (proof that it is written in a very
maintainable way), so I tried to write this patch. I don't make much
Debian packaging yet, so I let others test it.
diff -ur debhelper-4.2.31/Debian/Debhelper/Dh_Getopt.pm
debhelper-4.2.31.new/Debian/Debhelper/Dh_Getopt.pm
--- debhelper-4.2.31/Debian/Debhelper/Dh_Getopt.pm 2004-06-29
01:59:57.0 +0200
+++ debhelper-4.2.31.new/Debian/Debhelper/Dh_Getopt.pm 2005-03-22
20:39:02.0 +0100
@@ -165,6 +165,10 @@
"error-handler=s" => \$options{ERROR_HANDLER},
"<>" => \&NonOption,
+
+ "move=s" => \$options{MOVE},
+
+ "hard-link=s" => \$options{HARD_LINK},
);
if (!$ret) {
diff -ur debhelper-4.2.31/dh_install debhelper-4.2.31.new/dh_install
--- debhelper-4.2.31/dh_install 2004-01-16 04:47:14.0 +0100
+++ debhelper-4.2.31.new/dh_install 2005-03-22 23:01:22.200594648 +0100
@@ -12,7 +12,7 @@
=head1 SYNOPSIS
-B [B<-X>I] [B<--autodest>] [B<--sourcedir=>I]
[S>] [S>]
+B [B<-X>I] [B<--autodest>] [B<--sourcedir=>I]
[B<--move>] [B<--hard-link>] [S>] [S>]
=head1 DESCRIPTION
@@ -96,6 +96,17 @@
approximate dh_movefiles behaviour, except it will copy files instead
of moving them.
+=item B<--move>
+
+Moves the files instead of copying them. B It breaks idempotency!.
Ignored
+when B<--hard-link> is used
+
+=item B<--hard-link>
+
+Copies the files by creating hard links, to perform faster and save disk space.
+B Don't use it if you wan't to be able to modify the source files
+after having installed them.
+
=item I
Lists files (or directories) to install and where to install them to.
@@ -180,7 +191,15 @@
complex_doit("cd $src/.. && find $dir_basename
$exclude \\( -type d -and -empty \\) -exec cp --parents -a {} $pwd/$tmp/$dest/
\\;");
}
else {
- doit("cp", "-a", $src, "$tmp/$dest/");
+ if ($dh{HARD_LINK}) {
+ doit("cp", "-al", $src, "$tmp/$dest/");
+ }
+ elsif ($dh{MOVE}) {
+ doit("mv", "", $src, "$tmp/$dest/");
+ }
+ else {
+ doit("cp", "-a", $src, "$tmp/$dest/");
+ }
}
if ($tmpdest) {
Quickly,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
Re: /var/run and scripts
> If not where should it be? What about /usr/local/ or /var/opt/? The former seems to be the best one, to me... Quickly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgprcp3ynRiSh.pgp Description: PGP signature
Re: Accepted kaffe 1:1.1.1-1 (i386 source)
> > As a submitter, would you feel satisified that you had just gotten > > such a mail? > Yes, I would. I would then know that I could fetch the new release to > see if the problem was really fixed in this release. I must agree with Adam, and IIRC, there has alreadu been said on that list that it is an improper use of the changelog. As a bug sumbitter, I don't want to review source code each time I want to know if a bug is actually corrected. Simply because for some packages, I'm just unable to understand their code (being because of the language used or the complexity...). And the changelog should be something readable by a human being. making it clearer can only be a Good Thing. Explicitly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpBPVY8zsxs0.pgp Description: PGP signature
Bug in gcc/binutils with C++?
Hi, I'm trying to build a small dice roll library in C++, that I'll package next. But I block on an error that seem to be a bug of the toolchain with C++: /usr/bin/ld: hello: hidden symbol `__dso_handle' in /usr/lib/gcc-lib/i386-linux/3.3.1/crtbegin.o is referenced by DSO I didn't find any bug in the BTS, but I can reproduce this error even with a minimalist hello world library. After some search on Google, I didn't understand well it it's a binutils or gcc bug... Can someone enlight me: is it actually a bug or a problem in my C++ code? Dynamically, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpv2Ro1cfINQ.pgp Description: PGP signature
Re: How to locate package uploader?
> Gaetan RYCKEBOER [...] doesn't appear to be listed in the list of NM > applicants. http://nm.debian.org/nmstatus.php?email=gryckeboer%40virtual-net.fr Quickly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgphGvK4vbu4R.pgp Description: PGP signature
Re: Bug#205927: ITP: eggdrop -- Advanced IRC Robot
> As I may take some time to finish the package, I thought of avoiding > duplicated work. You could just tetitle the bug to an ITA, to avoid confusion. Quickly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpQ1PcwXARXS.pgp Description: PGP signature
Bug#206931: ITP: libw3c-logvalidator-perl -- Web server log analysis tool to validate the N most popular documents
Package: wnpp Version: N/A; reported 2003-08-24 Severity: wishlist * Package name: libw3c-logvalidator-perl Version : 0.2 Upstream Author : Olivier Thereaux <[EMAIL PROTECTED]> * URL : http://www.w3.org/QA/Tools/LogValidator/ * License : W3C Software license (BSD-like) Description : Web server log analysis tool to validate the N most popular documents Log Validator is a web server log analysis tool which finds the N most popular documents matching a particular criteria. Thanks to a modular, extensible design, the criteria can be chosen and modified arbitrarily. The Log Validator was first written with Validation (HTML, etc.) in mind : it can thus help web content managers find and fix the most frequently accessed invalid documents on their Web site, acting as a comprehensive, step-by-step validation tool. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux imperatrice.arcanes 2.4.18-686 #1 Sun Apr 14 11:32:47 EST 2002 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpPSh7XnHyLg.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
> How do I configure your script to restart apache when the power button > is pushed? Because it has nothing to do with shutdown, you just change /etc/acpi/events/powerbtn, and modify it to action=invoke-rc.d apache restart Quickly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpffTsYCoLt2.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
>> Tags: patch > You forgot to attach it :-) Shit. And the BTS doesn't seem to have noticed the patch tag... > Event-handling from cardmgr, hotplug, usbmgr, acpid, apmd etc. are > really useful to be able to be customised by power users. I think I'm something like a power user, and I hate having to read and understand a script (being shell, perl or anything else) to customize a package to my needs. And I love a well-documented configuration file, where I just have to change some paramters, without having to understand everything behing it. The power user might want to focus on its work, not on the custimozation of every signle package he installs... > You've assumed they want the power button to *be* a power button, it's > entirely likely that they might want it to (for example) switch the > user into single user mode instead. I didn't assume anything, and my version of the script just need th change ACTION=halt to ACTION=single to achieve this. And if the script is rewritten or modified to be just better, an apt-get upgrade won't erase all the customizations made by the sysadmin, because it is in a configuration file that have little reasons to change... > Shell scripts run by event daemons are the power-user's configuration > files. Leave them be. They are a very bad manner to provide configuration files to the power-user, IMHO... And I still think this bug is an RC one. Technically, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A diff -Nru acpid-1.0.2.old/debian/powerbtn.cfg acpid-1.0.2/debian/powerbtn.cfg --- acpid-1.0.2.old/debian/powerbtn.cfg 1970-01-01 01:00:00.0 +0100 +++ acpid-1.0.2/debian/powerbtn.cfg 2003-08-02 03:34:53.0 +0200 @@ -0,0 +1,11 @@ +# Can be halt, reboot or single +ACTION=halt + +# Time between SIGTERM and SIGKILL, see shutdown(8) +INIT_WAIT= + +# When to shutdown. +TIME=now + +# Message to send to all users. +MESSAGE= diff -Nru acpid-1.0.2.old/debian/powerbtn.sh acpid-1.0.2/debian/powerbtn.sh --- acpid-1.0.2.old/debian/powerbtn.sh 2003-08-02 02:09:02.0 +0200 +++ acpid-1.0.2/debian/powerbtn.sh 2003-08-02 03:40:27.0 +0200 @@ -3,9 +3,40 @@ # Initiates a shutdown when the power putton has been # pressed. +CONFIG=/etc/acpi/powerbtn.cfg +SDPID=/var/run/shutdown.pid +SHUTDOWN=/sbin/shutdown + +if [ -f $SDPID ];then + $SHUTDOWN -c + exit; +fi + +. $CONFIG + if ps -Af | grep -q '[k]desktop' && test -f /usr/bin/dcop then dcop --all-users ksmserver ksmserver logout 0 2 0 && exit 0 fi -/sbin/init 0 + +COMMAND=$SHUTDOWN + +case $ACTION in +halt) + COMMAND="$COMMAND -h";; +reboot) + COMMAND="$COMMAND -r";; +single) + ;; +esac + +case $INIT_WAIT in +"") + COMMAND="$COMMAND -t $INIT_WAIT";; +*) + ;; +esac + +COMMAND="$COMMAND $TIME $MESSAGE" +$COMMAND diff -Nru acpid-1.0.2.old/debian/rules acpid-1.0.2/debian/rules --- acpid-1.0.2.old/debian/rules2003-08-02 02:09:02.0 +0200 +++ acpid-1.0.2/debian/rules2003-08-02 03:31:20.0 +0200 @@ -39,8 +39,11 @@ install -p -o root -g root -m 644 debian/powerbtn \ debian/tmp/etc/acpi/events/powerbtn + install -p -o root -g root -m 644 debian/powerbtn.cfg \ + debian/tmp/etc/acpi/powerbtn.cfg + install -p -o root -g root -m 755 debian/powerbtn.sh \ - debian/tmp/etc/acpi/powerbtn.sh + debian/tmp/usr/sbin/powerbtn.sh install -p -o root -g root -m 644 acpid.8.gz \ debian/tmp/usr/share/man/man8 pgpBPLAGKaghM.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
Tags: patch > I've edited it, and I'd bet I'm not the only one who has a > dog/cat/turtle/etc who keeps knocking the power button, resulting in a > change to scheduling a shutdown in 1 minutes time :) I think a very good coded script should use a config file in /etc. But maybe it's a purist opinion... What do you think of the patch I porvide ? (I did not touch the dcop thing, as I don't understand it very well) And this script could even not be part of acpid, but maybe sysvinit, as it could be useful even without ACPI, just in replacement for halt, with more functionnalities. One could add something for Gnome, as IIRC, DCOP is part of KDE or Qt... Narrow-mindedly, ;-) le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpEQ6WsEoxBn.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
> You think wrong. The user should be able to choose whether the power > button triggers shutdown or suspend to disk, for instance. But one shouldn't have to edit a shell script to do it. It should just be necessary to edit a configuration file. Like modifying the action value to something like /usr/sbin/poweroff or /usr/sbin/suspend-to-disk Surely, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpgqzVk71oL5.pgp Description: PGP signature
Re: Bug#203588: acpid: Shell script has nothing to do in /etc
> I think at least the RCness of this bug is rather dubious, frankly. If > the script is configuration I don't think the script is meant to be edited... So it should be in /usr/sbin. Quickly, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpjHl0gN4jh5.pgp Description: PGP signature
Re: appropriate use of /etc/alternatives
> He doesn't think that it's an appropriate use of alternatives, since > the tools are not compatible. What about having a the ability to parse the original xplot data in your xplot ? Simply, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpOCAxGBQub9.pgp Description: PGP signature
