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
Re: Terminé
Scribit ciol dies 27/10/2007 hora 22:27: Donc ne m'attendez pas. Ouf, on peut recommencer à travailler. Productivement, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Accepted bordeaux-threads 0.0.2-1 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 01 Oct 2007 21:23:55 +0200 Source: bordeaux-threads Binary: cl-bordeaux-threads Architecture: source all Version: 0.0.2-1 Distribution: unstable Urgency: low Maintainer: Pierre THIERRY [EMAIL PROTECTED] Changed-By: Pierre THIERRY [EMAIL PROTECTED] Description: cl-bordeaux-threads - Portable shared-state concurrency for Common Lisp Closes: 444911 Changes: bordeaux-threads (0.0.2-1) unstable; urgency=low . * New upstream release. (Closes: #444911) Files: 51cfa6e3e89fc6b2e77ca819bd82217e 642 libs optional bordeaux-threads_0.0.2-1.dsc 211be1ec2970e67791b62cdc1609f071 11842 libs optional bordeaux-threads_0.0.2.orig.tar.gz 6cbde27418d182a171e918de85c3f782 1351 libs optional bordeaux-threads_0.0.2-1.diff.gz 8ebbab2390bf9d90a0e8ffc7167ceee0 13834 libs optional cl-bordeaux-threads_0.0.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHG2F3XrnnKiKKOuQRAhgTAKDAH0DdlI9T49Vlf4ysVe1/VN5MZQCePmsg HB6e/OxjoGTHRhaGeF9cDr0= =97Oq -END PGP SIGNATURE- Accepted: bordeaux-threads_0.0.2-1.diff.gz to pool/main/b/bordeaux-threads/bordeaux-threads_0.0.2-1.diff.gz bordeaux-threads_0.0.2-1.dsc to pool/main/b/bordeaux-threads/bordeaux-threads_0.0.2-1.dsc bordeaux-threads_0.0.2.orig.tar.gz to pool/main/b/bordeaux-threads/bordeaux-threads_0.0.2.orig.tar.gz cl-bordeaux-threads_0.0.2-1_all.deb to pool/main/b/bordeaux-threads/cl-bordeaux-threads_0.0.2-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: 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: 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: 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 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: 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: 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#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#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#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#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
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
Re: Gestion du développemen t des package Debian
Scribit Raphael Hertzog dies 06/07/2007 hora 14:11: Malheureusement, il n'est pas clair que le travail d'empaquetage des logiciels se découpe d'une quelconque manière. Je vois bien un certain nombre d'activités séparables : - l'adaptation du paquet upstream en paquet Debian, - le suivi d'upstream et la mise à jour du paquet Debian, - la correction des bugs du paquet upstream vis-à-vis des critères de Debian (ex.: FHS, manpages), - l'intégration upstream des corrections venant de Debian (ou l'intégration des spécificités Debian, accessibles conditionnellement), - la traduction, - le triage des bugs, - la recherche et la sollication de personnes compétentes sur les bugs, - la correction des bugs. Il y en a probablement au moins encore une ou deux. À toutes celles-ci s'ajoute le travail de coordination : communication sur le ou les paquets, motivation des troupes, formation des nouveaux, coordination du travail sur les groupes de paquets, etc. Tout cela peut amplement bénéficier d'outils automatisés de gestion. Le devrait, dirais-je, si on est vraiment malins. Diversement, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: invitation de Debian aux JRES 2007
Scribit Sam Hocevar dies 03/07/2007 hora 01:56: Si ça intéresse quelqu'un de représenter le projet là-bas, faites-le moi savoir. Étant déjà sur place, ça me tente. Je ne devrais pas avoir de mal à bloquer une journée pour ça. Par contre, je n'ai pas de matos pour un stand... Localement, Pierre -- [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: 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: 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: gpg_key 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
Accepted zpb-ttf 0.7-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 11 Mar 2007 21:52:30 +0100 Source: zpb-ttf Binary: cl-zpb-ttf Architecture: source all Version: 0.7-2 Distribution: unstable Urgency: low Maintainer: Pierre THIERRY [EMAIL PROTECTED] Changed-By: Pierre THIERRY [EMAIL PROTECTED] Description: cl-zpb-ttf - TTF parser Changes: zpb-ttf (0.7-2) unstable; urgency=low . * Corrected debhelper dependency Files: dfd25e1f750bd2b8d632435bb207a940 600 libs optional zpb-ttf_0.7-2.dsc 6eea38e0207eb56b688725f03b726c7e 47022 libs optional zpb-ttf_0.7.orig.tar.gz e21dddcd22dd5ef9e1c2b7e2eb544423 1811 libs optional zpb-ttf_0.7-2.diff.gz 9eadf919016120b7b0e4abd1c5dde2ac 48862 libs optional cl-zpb-ttf_0.7-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGANV411ldN0tyliURAg+SAKC3divlAsKOCYYnJC72PJXLOEDhYACfQwz8 tJJjT1Uy3bP2IIczyOR/iZ8= =g4z0 -END PGP SIGNATURE- Accepted: cl-zpb-ttf_0.7-2_all.deb to pool/main/z/zpb-ttf/cl-zpb-ttf_0.7-2_all.deb zpb-ttf_0.7-2.diff.gz to pool/main/z/zpb-ttf/zpb-ttf_0.7-2.diff.gz zpb-ttf_0.7-2.dsc to pool/main/z/zpb-ttf/zpb-ttf_0.7-2.dsc zpb-ttf_0.7.orig.tar.gz to pool/main/z/zpb-ttf/zpb-ttf_0.7.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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: 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
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: 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
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: Rappel pour les traduct ions gérées par les maintainers
Scribit Thomas Huriaux dies 22/05/2006 hora 01:03: nous avons au fil du temps établi une série de choix (qu'il serait trop long de documenter) La l10n serait-elle de la magie noire ? Depuis quand la complexité d'un sujet justifie-t-elle de ne pas le documenter ?! J'ai toujours pensé qu'il en allait justement tout autrement : plus c'est complexe, plus on a intérêt à proprement et rigoureusement documenter... S'il en était de même partout dans Debian, ce serait proprement ingérable. Et si un mainteneur veut rédiger tout seul son français, pourquoi ne pourrait-il pas, au même titre qu'il n'a pas à faire relire obligatoirement son code, ses Makefiles ou quoi que ce soit d'autre ? Étonnamment, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Encore une question sur les transitions de libs
Scribit Steve Langasek dies 23/01/2006 hora 01:33: Dans quelle sense sont-ils paquets de transition? Si j'ai bien compris, une fois la transition terminée, des paquets entreront l'archive sans le suffixe, non ? J'en viens d'ailleurs à une question que j'aurais du poser depuis longtemps : existe-t-il une documentation sur les méthodes de transitions de bilbiothèques dans Debian ? S'il n'y en a pas, j'aimerais beaucoup aider à la rédiger. Et il est déjà assez difficile de réaliser une telle transition sans faire des corrections aux descriptions de paquet au même temps. Ne faut-il pas déjà modifier le fichier control pour changer les dépendances ? Cela couterait-il vraiment beaucoup de rajouter une ligne dans le champ Description ? Quelque chose du genre : Package: kdelibs4c2a Version: 4:3.4.3-2 Description: core libraries for all KDE applications This package contains all the shared libraries used by all KDE applications. You need these libraries to run KDE applications. . This package is part of KDE, and a component of the KDE libraries module. See the 'kde' and 'kdelibs' packages for more information. . This is the kdelibs4 package for the C++ new allocator transition. Peut-être avec une URI où est la transition est expliquée en détails : This is the kdelibs4 package for the C++ new allocator transition. See http://www.debian.org/devel/transitions/c2a for more informations. Tenez compte que pour ceux qui installent etch, la transition n'a rien à voir; ils sont simplement les versions courrants des bibliothèques... Oui, mais la présence de paquets qui ne sont pas encore passés aux dépendences de la transition rend soit les nouveaux soit les anciens impossibles à installer (puisque kdelibs4c2a est en conflit avec kdelibs4 et kdelibsc2). Pendant les deux dernières transitions, aptitude, lorsque je lançais un upgrade ou installait certains nouveaux paquets, me proposait de supprimer une énorme partie de mes paquets installés, à cause de cela. J'étais forcé, pour mettre quand même à jour ma machine, de mettre à jour les paquets un à un, manuellement, pour ne mettre à jour que ceux qui ne causaient pas de conflit. Laborieusement, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Encore une question sur les transitions de libs
Avant de comprendre puis de me tenir au courant des transitions, je ne captais jamais pourquoi apparaissaient des paquets avec un c102 ou ce genre de suffixe. Étant donné que ce sera également le cas de 99,99% des utilisateurs qui tomberont sur un upgrade qui foire, je ne comprends pas pourquoi ces paquets de transition de mentionnent pas qu'ils le soient dans la description du paquet... Curieusement, Nowhere man -- [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 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: 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 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 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: 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
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
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: Transitions problémat iques
Scribit Frédéric Bothamy dies 12/10/2005 hora 13:15: Normalement, ces rapports de bogue existent déjà. Sur mon système, je n'ai plus aucun paquet dépendant de libgmp3 d'après apt-cache rdepends libgmp3¹ (et 93 dépendant de libgmp3c2) et ce paquet n'existe plus dans unstable. J'en avais autant qui dépendent de libgmp3, mais vérification faite sur l'un d'eux, c'est dans testing... Je n'ai pas vu dans la manpage de apt-rdepends comment restreindre à une source ou release... Imprécisément, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Transitions problémat iques
Scribit Thomas Clavier dies 09/10/2005 hora 10:14: Le fait de déclancher cette désinstallation permet de rédiger un rapport de bug sur le paquet qui n'a pas été compilé avec la bonne librairie. OK, là du coup, je pige. Bon, ben ça me fait des bugs à rapporter, ça, donc... Brièvement, 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: 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
Transitions problématique s
Je me pose une question sur le fonctionnement de Debian : quelles solutions ont déjà été proposées (et éventuellement rejetées) pour éviter les problèmes de transition (e.g. de bibliothèques, de compilateur). Je pense en particulier au fait que lors de certaines transitions, il est impossible de faire une mise à jour sans perdre de paquets. Exemple : - les paquets foo (0.1-1) et bar (0.2-1) dépendent de libbaz, - on introduit libbazc102 qui est en conflit avec libbaz, - foo (0.1-2) est mis à jour pour dépendre de libbazc102, - si je mets à jour foo, je perds bar, qui dépend encore d'une bibliothèque qui dégage. En particulier, est-ce que des solutions ont été proposées pour que des paquets de même nom et de versions différentes puissent coexister dans l'archive Debian ? J'ai un peu STFW, mais les mot-clefs qui me viennent à l'esprit sont trop généraux pour avoir quelque chose... Curieusement, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
[résolu] Re: [HS] Re: Un bug dans la STL ?
Scribit Guillaume Morin dies 28/04/2005 hora 23:26:
Tu dois retourner une *référence* sur ton Dice pas un nouvel objet. En
effet, tu vas créer des objets temporaires (un par appel a ) qui
référencent le même vecteur.
Non, car ayant surdéfini l'opérateur =, il n'y a pas de copie
superficielle. Néanmoins, merci de la remarque, c'est corrigé. Le
problème venait probablement du fait que mon constructeur de recopie ne
créait pas le vecteur, en fait. C'est corrigé, et cette partie du code
fonctionne désormais, semble-t-il.
Par contre, je suis tombé sur troisième bug dans mon code, et je suis
effaré que le compilo soit passé outre :
templateclass T Dice operator =(const T )
{
m_rollable_scalars-clear();
this-append(value);
return *this;
}
value aurait du être l'identifiant de l'argument, mais j'avais oublié,
une fois que j'ai décidé d'en faire une fonction template définie dans
le fichier d'en-tête, de le rajouter dans ce qui était le prototype.
C'est un bug dans GCC, ou c'est parce que c'était une fonction
template ?
Si tu avais conçu ta classe correctement, tu aurais repérer le prb
tout de suite. Les versions de l'opérateur= et du constructeur par
recopie générés par le compilateur ne sont pas correctes pour l'objet
Dice. Tu dois donc les écrire toi même si tu veux autoriser la copie
d'objet Dice.
C'était déjà fait.
Merci d'avoir pris le temps d'étudier mon problème.
Finalement,
Nowhere man
--
[EMAIL PROTECTED]
OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
Re: Un bug dans la STL ?
Scribit Vera Mickael dies 27/04/2005 hora 19:29: Tu as dû faire une erreur de programmation. Peut-être, mais même avec valgrind, impossible de comprendre où est mon erreur. Je sais précisément où ça merde dans mon programme. Plus précisément, ça merde au final dans la STL (à cause de moi ou d'un bug en elle-même...), et je sais où est l'appel dans mon source (dans la méthode clear() de la classe Dice). Mais je ne vois pas quoi corriger. Si je décommente l'instruction qui, avant de supprimer le pointeur du conteneur, désalloue l'objet pointé, alors, avec un conteneur vector, on a plus la taille qui passe de 1 à un nombre astronomique, mais à 104, puis segfault... Infructueusement, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Un bug dans la STL ?
Hello, je suis en train de me mettre à écrire une bibliothèques de classes en C++, qui me servira ensuite pour des logiciels de jeu (principalement du jeu de rôle). Je commence par les dés, et je suis tombé sur un os : une de mes classes comprend un méthode qui est censée désallouer des objets dont les pointeurs sont stockés dans un conteneur de la STL, qui est un membre privé de la classe, et vider celui-ci au passage. Avec trois types différents, j'obtiens trois bugs différents, l'un très grave. Si c'est un vectorMonType*, impossible de vider. un pop_back() quand size() renvoit 1 fait passer à un état où size() renvoit 33635908 (2^25+81476, je trouvais que c'est étrangement « proche » d'une puissance de 2), Si c'est un dequeMonType*, au bout de quelques secondes, la machine plante lamentablement, impossible de passer sur une console texte ou de tuer le serveur X. Seule possibilité, les Magic Keys du kernel, SIUB. Et lorsque la machine redémarre, kernel panic. Un redémarrage supplémentaire et elle démarre comme une fleur. Si c'est un listMonType*, le programme segfaulte après ou pendant la suppression du dernier élément. Je recommande de lancer la version deque ainsi : ./test sleep 4 ; kill %+ Est-ce que quelqu'un saurait me dire ce qui se passe, ou au moins me filer des pistes sur la façon de le découvrir ? Au passage, est-ce que ce n'est pas un bug gravissime dans le noyau (probablement dans l'ordonnancement) qu'un plantage pareil puisse arriver ? Problématiquement, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A dice.tar.gz Description: Binary data 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 dont 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: 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: 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=300765msg=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=300765msg=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: 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: 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 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: 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: 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 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
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
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
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
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
-Bdh_install [B-XIitem] [B--autodest] [B--sourcedir=Idir]
[SIdebhelper options] [SIfile [...] dest]
+Bdh_install [B-XIitem] [B--autodest] [B--sourcedir=Idir]
[B--move] [B--hard-link] [SIdebhelper options] [SIfile [...] dest]
=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. BCaution! 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.
+BCaution! Don't use it if you wan't to be able to modify the source files
+after having installed them.
+
=item Ifile [...] dest
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: 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
Switcher massivement vers trunk (was Re: nouvelles)
Ce que nous faissons c'est d'avoir une archive SVN, [...] chaque package maintenu [...] a ou sous repertoire. Chaque package a un sous repertoire trunk Je viens justement de faire un svn co de plusieurs dépôts disponibles sur svn.d.o (dont pkg-ocaml, justement), et comme il y a tout un paquet de répertoires trunk, je me suis rapidement écrit un script dont le but est de switcher massivement tous les répertoires paquets vers trunk (comme décrit dans le SVN-Book). Comme j'ai des dépôts où les noms de répertoires sont en français (tronc, étiquettes et branches), le script accepte un argument s'il doit utiliser autre chose que trunk. Je poste ici pour savoir si ça vous semble valoir le coup d'être proposé au mainteneur de subversion-tools. Curieusement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpqCd5OF1luf.pgp Description: PGP signature
Re: /var/run and scripts
If not where should it be? What about /usr/local/package or /var/opt/package? 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
Re: Aide pour comprension du BTS et paquet wnpp
j'essaye de comprendre comment marche les rapports de bugs dans le paquet wnpp pour l'adoption de paquet. Tu envoies un mail à [EMAIL PROTECTED] pour dire que tu veux adopter le paquet, et tu envoies un mail contenant dans le corps retitle numero-du-bug ITA: nom-du-paquet Brièvement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpuWBuO6x5bA.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
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#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
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: Signature de cle en Alsace (was: Re: Bug#198987: Is something planned for this bug?)
A confirmer pour le moment et l'heure encore cependant. Rendez-vous aujourd'hui (le 20...) à 15h devant la cathédrale. J'essairai d'être un minimum geek vestimentairement ; si ce n'est pas un T-Shirt «Linux Soft Revolution», je me rabatterai sur une casquette Star Trek ou un T-Sirt «Kid Paddle» ;-). Mais pour ceux qui ne pourront pas venir (l'annonce 13h avant, c'est un peu short), ça ne devrait pas être bien difficile de réitérer. Notez que ce soir se tiendra l'Appel À Mousser mensuel de la Flammekueche Connection (le LUG) : 20h30 à la Hache, 11 rue de la Douane... Teutoniquement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpilmfnnuUvI.pgp Description: PGP signature
Re: Signature de cle en Alsace (was: Re: Bug#198987: Is something planned for this bug?)
Y aurait-il une concentration de DD en Alsace ? Le manger y est copieux et succulent, le boire agréable à flotssouhait, et le temps incite plus rester devant sa machine qu'à aller ouvrir ses doigts de pied en éventail... ;-) Orientalement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgp9BbDoXJjS1.pgp Description: PGP signature
docbook-to-man(1) et la policy
Je viens de voir que docbook-to-man ne permet pas de modifier son comportement autrement que par une variable d'environnement, pour ce qui est d'appeler instant(1) avec ou sans l'option -d. Comme je ne suis pas du tout familier avec instant, je ne me demande à quel point ça contrevient ou pas avec la section 9.9 de la policy (3.6.0)... Brièvement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgp06AvxJgBH0.pgp Description: PGP signature
Re: SCO license for Debian distrib
Licence SCO : http://www.sco.com/scosource/linuxlicensefaq.html En Allemagne, le LinuxTag a fait sommer par la jsutice allemande SCO de fermer sa gueule ou d'avancer des preuves formelles. C'était il y a plusieurs semaines, et ils ont décidé de la fermer. Conclusion : SCO n'a fait que monter un FUD, pour discréditer Linux, notamment auprès des décideurs informatiques en entreprise. Brièvement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpXV7pNORyti.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
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: 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
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
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: KEY SIGNING PARTY vendredi prochain a Paris?
Les personnes intéressées peuvent se manifester (rapidement) pour voir si la réunion est possible. Je vais essayer d'être là, mais je ne suis pas certain. Je serais là le 18, à l'ADAE, je vais essayer de rester sur Paris. http://www.biglumber.com/x/web?ev=59904 Brièvement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpEwhZEvdGUC.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
Re: Recherche d'un sponsor pour adopter distributed-net
Essaie debian-mentors... Simplement, le Moine Fou -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpnVHJLR1VD4.pgp Description: PGP signature
Re: ethique Debian
Sans le nom, pornview est un lecteur d'image comme tout autre. Mais la question reste intéressante : si un logiciel inclue des images pornos, sera-ce un prétexte suffisant pour le refuser dans l'archive officielle ? C'est du troll, mais ça nous donnerait le statut de «communauté bien-pensante collaborative» ! Il y a pourtant dans Debian des paquets nettement plus litigieux que du porno, comme airsnort, dont on ne peux nier qu'ils sont conçu autant comme outils d'intrusion que d'audit de sécurité... Mais la liberté des LL réside aussi dans la liberté de ne pas s'en servir. Chastement, le Moine Fou -- mailto:[EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpPvLoIq79db.pgp Description: PGP signature
Re: Developper une application pour KDE 3
comme j'utilise KDE en général, je pensais developper mon appli pour KDE Regarde déjà du côté de KDevelop, c'est un peu son but... Simplement, le Moine Fou -- mailto:[EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpnBkX9xoGqE.pgp Description: PGP signature
Re: Questions de policy
A la purge, je ne vire évidemment pas ces bases (je me ferais crucifier par lesutilisateurs!) N'est-ce pas pourtant un des buts possibles de la purge : tout retirer du système. De fait, certains paquets, comme sympa ou mysql, demandent à l'install si le purge doit comporter la suppression des données... et il faut bien que leur groupe soit toujours défini dans /etc/group. Pas forcément... Pourquoi ne pas les refiler à root ? Innocemment, le Moine Fou -- mailto:[EMAIL PROTECTED] OpenPGP 0xD9D50D8A pgpTsArhpYWme.pgp Description: PGP signature
