Re: Lintian says "package-contains-ancient-file"

Olе Streicher wrote: > Therefore, the package contains a couple of files which are quite old -- > some help files, sources, documentation etc. date 1983 and 1984. This > leads to the Lintian *error* shown in the subject. Although I think it > is reasonable to overwrite this tag (the files actually

Re: dh --parallel (was: Re: RFS: lebiniou)

Paul Wise wrote: > Completely agreed, please file two bugs against debhelper about this. Only after reading debhelper's bug logs where the decision was researched and made to not --parallel by default, please. -- see shy jo signature.asc Description: Digital signature

Re: Nitpicking: you are doing it wrong

Scott Howard wrote: > From the debhelper manpage > > "Unless otherwise indicated, all debhelper documentation assumes that > you are using the most recent compatibility level, and in most cases > does not indicate if the behavior is different in an earlier > compatibility level, so if you are not

Re: Git and tarballs

Andrey Rahmatullin wrote: > How can I create this delta? The man page says only about creating a delta > for a tarball without a directory. The delta is created for you when you run pristine-tar commit. -- see shy jo signature.asc Description: Digital signature

Re: Git and tarballs

Andrey Rahmatullin wrote: > On Wed, Jul 06, 2011 at 03:12:41PM +0200, Thomas Preud'homme wrote: > > Does pristine-tar work if the upstream branch contains files which have > > been > > removed during repack? > Unfortunately the directory and the tarball must have identical contents. That's not t

Re: RFS: parallel

George Zarkadas wrote: > -- In addition, the "alternatives" mechanism does not force any user to > make any changes to his/her scripts (as a choice to rename one of the > binaries would for the respective user group); they just set their > preference and use their scripts as before. There are alre

Re: RFS: parallel

George Zarkadas wrote: > It builds these binary packages: > parallel - Execute jobs in parallel locally or using remote computers I have not figured out what to do about moreutils containing a /usr/bin/parallel that is not entirely command-line compatable with this one. #597050 -- see shy jo

Re: Init scripts as conffiles

Matt Zagrabelny wrote: > Sure. That doesn't make it correct, optimal, or the best option, just > how things have always been done. > > I understand the difference between remove and purge and the reason to > use both, but removing unmodified conf files seems like a win to me. > Keeps the clutter d

Re: DEP5 and multiple copyrights for same file

Siegfried-Angel Gevatter Pujals (RainCT) wrote: > Hi Jean, > > Something likes this should do: > -- > Files: gtk/core_math2.cc > Copyright: 2004-2010, Thomas Okken > License: GPL-2 > > Files: gtk/core_math2.cc > Copyright: 1993, Sun Microsy

Re: dh 7 broken by design?

Russ Allbery wrote: > I really think this is a bug in make. Probably, but who knows. It could just be a misfeature on which ghod knows what somehow depends. .PHONY: precompiled-binary-we-cannot-regenerate-with-gcc.o > We can change Policy if we have to. Arguably that line complies with > Polic

Re: dh 7 broken by design?

Helmut Grohne wrote: > So will the new minimal example look like the following then? > > #/usr/bin/make -Bf > %: > dh $@ Yes, that's how it's looking now. -- see shy jo signature.asc Description: Digital signature

Re: dh 7 broken by design?

Helmut Grohne wrote: > I recently tried converting my packages to dh 7 and ... failed. > > The simple rule > %: > dh $@ > will fail miserably if there is any file named like a target. Try `touch > build' in your favourite dh-7-package to see it break. > > GNU make users probably know that t

Re: Lintian warning messages

Eduardo M KALINOWSKI wrote: > If the policy suggestion that leads to that lintian warning is so > unreasonable, it might as well be taken off the policy. I'm not aware of any such thing in policy. -- see shy jo signature.asc Description: Digital signature

Re: Lintian warning messages

Eduardo M KALINOWSKI wrote: > If the scripts are not directly executable, you can remove the > #! line from them. That should make the warning go away. > It would be better to talk with upstream so he does that. If I were upstream and was pestered by a distribution to remove the hashbang lines t

Re: RFS: di-netboot-assistant (ITP #489812)

Franklin PIAT wrote: > I am looking for a sponsor for my package "di-netboot-assistant". > (I am CCing debian-boot in case someone has some interest in it) This looks like some nice work. I wonder if it would make sense for it to be maintained inside the d-i project? It's tightly related to d-i,

Re: debconf database and config files

Christoph Biedl wrote: > The given "config" file sources $CONFIGFILE if present but asserts > FOO and BAR are defined there. Is this safe? I'd rather wipe out any > pre-existing values: > > # Load config file, if it exists. > if [ -e $CONFIGFILE ]; then > + FOO= > + BAR= >

Re: dh_install not finding files from orig source

Ben Finney wrote: > Why, then, is it exiting with a "No such file or directory" error > trying to read the file from 'debian/tmp'? Because of implementation details. It's easiest to check if the source is in . , and if not stuff the path in debian/tmp into the list of things to install, which late

Re: dh_install not finding files from orig source (was: Latest upstream versions of files)

Ben Finney wrote: >dh_install > cp: cannot stat `debian/tmp/cmavo.txt': No such file or directory > dh_install: command returned error code 256 > make: *** [install] Error 1 > dpkg-buildpackage: failure: fakeroot debian/rules binary gave error exit > status 2 > bzr: ERROR: The build failed. >

Re: dh_clean and explicit package clean lists

Ben Finney wrote: > I recall recently seeing mention that 'dh_clean' could obey a > 'debian/.clean' file as a list of patterns or files to > clean. > > However, I can't find it with search engines; "package.clean" returns > hits for "package clean", and "dh" returns hits for all the "dh_foo" > com

Re: Efficiency of triggers

Thibaut Paumard wrote: > Indeed, the problem is that per the instructions, I've modified my > update-yorickdoc utility to call dpkg-trigger when invoked from a > package's postinst. dpkg already triggers yorick-doc once after > unpacking the newly installed packages, which is sufficient. Late

Re: ITR: xmlrpc-epi - copyright issues

Neil Williams wrote: > Copyright issues: > 1. The machine-interpretable copyright format is meant to be > hierarchical - Files: * should not appear before any other more specific > matches. i.e. exclude all the awkward files explicitly in turn, then the > last stanza is "everything else". That's n

Re: Bug#465086: RFS: talkfilters

David Paleino wrote: > Is there any chance for filter to provide a "libfilters" library to interface > with? I've packaged talkfilters because it was a possible use of libtranslate > [2] [3], but that's not really necessary. I could try to patch it so that it > uses your "filters" package, but that

Re: RFS: talkfilters

Please see http://kitenet.net/~joey/code/filters/talkfilters-email : | How did you manage to get valspeak, postmodern, pansy, and fudd, whose | authors are unknown to be GPLed? According to the info page, | | While all of these filters have been available in one form or | another in the publ

Re: Copyright question (BSD with advertisement clause)

Riku Voipio wrote: > I think the short term solution to this dilemma is to compile a list > of attributions needed to be included in advertizment material. > Also a list should be compiled attributions needed n documentation > (such as libjpeg's). Obviously most distributors/boob writers will > not

Re: alpine_1.0+dfsg-2_source.changes REJECTED

Bernhard R. Link wrote: > While a minimal chroot is good to test against missing > build-dependencies, a full real-world system is needed to test for > missing build-conflicts or configure switches to disable specific > autodetections. But nothing in the current system ensures that packages are bu

Re: automatically parseable debian/copyright

Bart Martens wrote: > On Wed, 2007-11-28 at 17:44 +0930, Paul Wise wrote: > > I'd suggest that the copyright file > > should be redone and done so it can be parsed automatically: > > > > http://wiki.debian.org/Proposals/CopyrightFormat > > Hi Paul, > > As far as I know, it has not yet been decid

Re: vanity packages (was: mentors.debian.net reloading)

Neil Williams wrote: > > I would consider its popularity low (187 popcon installs with 46 > > votes). > > It's not that low. It looks like quite a few people find it useful, so > that's good. Using absolute popcon numbers as indications of a package's popularity isn't the best idea anyway, since

Re: busybox

K. Richard Pixley wrote: >Ok, sure. But that seems like a hack to me so that busybox can be >installed on regular desktop systems which presumably want coreutils, (and >friends), to be installed as the primary "ls" command. In this context, >busybox is more of a toy, or an evaluat

Re: repository signing and apt-get authentication

Neil Williams wrote: > Seems to me you have two choices: Use what you had without SecureApt. > Use the directory layout and tools that support SecureApt. There is nothing in apt's security checking code that requires any particular repository structure. Example of apt repository that uses a flat

Re: RFS: alienarena2007

Andres Mejia wrote: > License: The game client and dedicated server are under GPL > The game data files are under a CCPL, specifically, the > Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported > License . Therefore the d

Re: Copyright issues GPL-PHP license

David Paleino wrote: > Why? > And a web server written in awk, then? Is that of any real-world use? > I've seen implementations of that on the Internet. I admit that this > is not enough reason to package it though. d-i contains a web server written in shell, fwiw. -- see shy jo signature.asc

Re: Tone-of-voice used by sponsors

Thomas Goirand wrote: > Daniel many times told me that for example, I shouldn't use 2 blank > lines on my debian/rules, don't have empty space a end of line in my > copyright, and things like that. > > I agree it doesn't mater MUCH, but it's still better the way he advise > me to correct. I would

Re: debconf: asking several questions more than once

Patrick Schönfeld wrote: > Hi people, > > as i just finished a current version of mantis got it uploaded by Daniel > (thanks for that!) i have re-started working on smstools. Because the > upstream author and me detected that installation can lead into a > defunct state (because smsd is started, e

Re: RFS: uncrustify

Daniel Baumann wrote: > * ${misc:Depends} is useless here Please don't ask people to remove "useless" misc:Depends lines. At any time a new version of a debhelper command could need to add a new dependency to misc:Depends, and this only works if you keep it in your depends line. -- see shy jo

Re: Packaging automation - separation of 'debian/' directory

Interesting thread. I've never thought about generating the tarball this way, though I do have a lot of native packages that probably shouldn't be. If one general-purpose tool to handle this rises to the top and is usable by many people, it would be a good candidate for addition to devscripts. --

Re: debian/rules::dh_* comments as rejection criteria (Was: Re: A list of common gotchas in Debian packaging)

Jari Aalto wrote: > > See down near the bottom > > near debian/rules. > > This is bad, such micromanagement for few commented lines should not > warrant rejection criteria by the ftp masters. Except the FAQ doesn't say that it's a rejection criteria,

Re: man1 or man8?

Tyler MacDonald wrote: > tarballs, but it's in man8, whereas "defoma-reconfigure", which can only be Ups, I read defoma-reconfigure as dpkg-reconfigure. :-) -- see shy jo signature.asc Description: Digital signature

Re: man1 or man8?

Tyler MacDonald wrote: > I can't find a consistent rule for what should go into man1 vs. man8. For > instance, "apt-get" can be used as an unprivileged user to download source > tarballs, but it's in man8, whereas "defoma-reconfigure", which can only be > run as root, is located in man1. DPKG-RECO

Re: Closing bugs fixed in experimental

Rafael Laboissiere wrote: > Is it acceptable to manually close a bug which is fixed in experimental > but not yet in unstable, especially when there are no plans regarding the > upload of the fixed version to unstable in the foreseeable future? Yes, just be sure to version your close message so th

Re: RFS: stegsnow -- whitespace steganography for text files

Seems highly similar to snowdrop which is already packaged.. Jari Aalto wrote: > > I'm looking for sponsor. > > -- Jari > > Status > > NEW Package, not in Debian > > Availability > > http://sponsors.debian.net/viewpkg.php?id=218 > > Other information > > Lintian clean (unstable

Re: Native package or not?

Bernhard R. Link wrote: > The general suggestion is to not include the debian/ directory in the > release tarball. The reason is that by the format of the Debian source > packages no files can be removed by another person's .diff.gz and some > tools like debhelper act on (non)existance of specific

Re: Extra debian repository

Bas Wijnen wrote: > I think this is because of the signing of packages which happens and is > checked nowadays. If two versions are available, of which only one is > trusted, it chooses the trusted one, no matter what the versions are. AFAIK apt does not use whether a repository is signed to make

Re: RFS: statist - Small and fast terminal-based statistics program

Mario Iseli wrote: > -Depends: ${shlibs:Depends}, ${misc:Depends} > +Depends: ${shlibs:Depends} > (You don't need the second variable, it isn't defined anywhere...) Automatic generation of miscellaneous dependencies. Some debhelper commands may make the generated package need to dep

Re: Proposal for collaborative maintenance of packages

Lars Wirzenius wrote: > I'm going to dip my spoon into this soup, because I dislike soup, and > this one especially irks me. Even ice cream soup? > Reviewing other people's patches in large quantities every day is > something that few people will be happy to do for more than a few > days. After t

Re: RFS: base64, utility for encoding to and decoding from base64

Anders Lennartsson wrote: > This command line application encodes and decodes base64 and can be > used in redirects and pipes etc. Can't you just use uuencode -m and uudecode? -- see shy jo signature.asc Description: Digital signature

Re: Policy documentation on debconf

Manoj Srivastava wrote: > > It would be nicer to have it completely described (and in an updated > > manner) in a definitive reference, of course. > > Sure. Should be in the documentation of debconf itself. debconf-devel(7), anyone? (policy also contains a formal definition of the debcon

Re: Lintian error about missing debconf dependency (which is not missing)

Russ Allbery wrote: > I hate to say this, since actually implementing it is a lot of work in > supporting programs like debhelper, but if the debconf-2.0 pseudopackage > was introduced prior to a new feature in the debconf interface there needs > to be a debconf-2.1 or debconf-3.0 as well. If cdeb

Re: Creating a randomized cron entry

Henrique de Moraes Holschuh wrote: > "at" has a very bad history security-wise, and I really doubt anyone is > seriously maintaining and fixing that thing. Now, if someone would rewrite > from scratch an "at" designed and implemented for security, that would be > very cool indeed. at had one secu

Re: Creating a randomized cron entry

Florian Weimer wrote: > I'm not sure what users would expect from such a service. In the case of debsecan, as an admin I would expect something consistent, so I can, for example, start the day with a coffee and a security report, rather than getting the report at some random time during the day.

Re: python "rpm" module package

Justin Pryzby wrote: > I used packages.d.o to confirm that that file does not exist in (at > least) the unstable suite. You might have to package that, too. The rpm source packge contains python bindings. I don't know if it's the right one. -- see shy jo signature.asc Description: Digital sig

Re: duplicate library code in a package

Andreas Fester wrote: > not necessarily. It must be the original, but it must not be pristine. That's self-contradictory. And wrong. > One reason could be to remove autotools dependencies, another could be > to remove files which would otherwise be removed by the "clean" target > and would end up

Re: RFS: Updated packages for vrms (fwd)

Rogério Brito wrote: > What exactly should I do? I would like to host this somewhere where > others could have access to a svn repository. I think that I can > register a new project on BerliOS, but suggestions are welcome. alioth.debian.org is also an option for team maintenance. -- see shy jo

Re: RFS: Updated packages for vrms (fwd)

Rogério Brito wrote: > I tried to send the message attached two times already, but it seems > that it hasn't reached the list. > > Anyway, if anybody could help, I'd be grateful. I've been following that bug and had been expecting some activity to occur on the vrms mailing list since they redirec

Re: RFS: Plash: a shell and restricted environment for running programs with minimum authority

Mark Seaborn wrote: > LD_PRELOAD isn't good enough. Plash needs to replace *all* uses of > system calls that use filenames, including glibc's internal uses of > those system calls. Back in the day of glibc 2.2.5, you *could* do > this by overriding "__open" and "__libc_open" as well as "open". B

Re: autotools during build

Steve Langasek wrote: > Hmm, I'm not really sure whether that fits with policy's intent regarding > the effects of the debian/clean target. This must undo any effects that the `build' and `binary' targets may have had, except that it should leave alone any output files

Re: autotools during build

Steve Langasek wrote: > If you rerun autoconf/automake/libtool at package build-time, when you don't > need to, what you get are large diffs against upstream every time a new > version of the autotools becomes available. Aside from wasting (a little) > space in the archive, that makes it harder fo

Re: debian/rules: Moving to debhelper or cdbs

Manoj Srivastava wrote: > I prefer to have these command (usually, mv, cp, gzip, etc) > explicitly present, so one does not have to go looking through the > library to guess what is being done. Wow, here it is 2005, a whole 8 years since debhelper was introduced and Manoj still doesn't k

Re: debian/rules: Moving to debhelper or cdbs

Manoj Srivastava wrote: > I appreciate the build system for certain red hat and suse packages not > being arcane and distribution specific when I try and incorporate > changes made in packages on those distributions, and I tend to return > the favour. Grep through the rpm book for all the % co

Re: debian/rules: Moving to debhelper or cdbs

Antti-Juhani Kaijanaho wrote: > Don't do it without the maintainer's go-ahead. The current best > practice is to use whatever (non-evil thing that) works for the > maintainer. This "best practice" fails miserably if the maintainer is not always perfectly responsive. As soon as the maintainer goes

Re: debian/rules: Moving to debhelper or cdbs

Antti-Juhani Kaijanaho wrote: > If I were to receive a bug report, say wishlist severity, containing a > patch that rewrites one of my packages' debian/rules to use debhelper, I > would be very upset: it would feel like an insult toward my style of > packaging. You need to grow a thicker skin. By

Re: Stupid shebang tricks

Ben Finney wrote: > That would be a downside (and kills it for the primary use I had in > mind, '#!/usr/bin/env perl -w'). Of course "#!/usr/bin/env perl\nuse warnings;" is equivilant. -- see shy jo signature.asc Description: Digital signature

Re: checking a NEWS.Debian file with dpkg-parsechangelog

Jereme Corrado wrote: > I just added a NEWS.Debian file to one of my packages and the > Developers Reference, (sec. 6.3.4) suggests that one should check the > formatting with dpkg-parsechangelogs. > > I read the man page for dpkg-parsechangelogs and played around a > little but it's unclear to me

Re: Advice on debconf - locales settings

Brian Sutherland wrote: > I have quite a difficult config file problem to debconfify, and would > like to ask advice. > > The config file can contain a number of lang $locale settings, of which > the first is the requested translation and the rest are backups. > > How best to keep the ordering. M

Re: Advice on debconf - locales settings

Brian Sutherland wrote: > I have quite a difficult config file problem to debconfify, and would > like to ask advice. > > The config file can contain a number of lang $locale settings, of which > the first is the requested translation and the rest are backups. > > How best to keep the ordering. M

Re: Simple Debian Package Creation?

Rene Engelhard wrote: > > any debian rules. > > the foo-0.1 is a convention. if your stuff doesn't follow it it is broken. No, there is no convention and it doesn't matter at all what you name the package's source directory. This has been completly unnecessary for years. > And: You *could* use a

Re: Simple Debian Package Creation?

Rene Engelhard wrote: > > any debian rules. > > the foo-0.1 is a convention. if your stuff doesn't follow it it is broken. No, there is no convention and it doesn't matter at all what you name the package's source directory. This has been completly unnecessary for years. > And: You *could* use a

Re: docs for debconf:db_*

martin f krafft wrote: > I know that debconf-devel(7) lists the debconf protocol and that the > shell and Perl wrappers are basically 1:1. Still, I wonder if there > is any documentation about these (which may be a little more > accessible to new users). Could someone please take a clue stick and >

Re: docs for debconf:db_*

martin f krafft wrote: > I know that debconf-devel(7) lists the debconf protocol and that the > shell and Perl wrappers are basically 1:1. Still, I wonder if there > is any documentation about these (which may be a little more > accessible to new users). Could someone please take a clue stick and >

Re: Debian vs RedHat init script

Adrian 'Dagurashibanipal' von Bidder wrote: > > Thanks for the url. I'm not sure how that solves my problem. As I > > understand you, I need to convince the upstream maintainer to switch > > to LSB style initscript. I can try doing that. The initscript has > > Yes, that was my idea - so everybody

Re: Debian vs RedHat init script

Adrian 'Dagurashibanipal' von Bidder wrote: > > Thanks for the url. I'm not sure how that solves my problem. As I > > understand you, I need to convince the upstream maintainer to switch > > to LSB style initscript. I can try doing that. The initscript has > > Yes, that was my idea - so everybody

Re: mysteries of /etc/default/*

Adrian 'Dagurashibanipal' von Bidder wrote: > On Thursday 15 July 2004 15.15, Martin Dickopp wrote: > > Sebastian Henschel <[EMAIL PROTECTED]> writes: > [/etc/default] > > See Policy 9.3.2. (Disclaimer: IANADD.) > > Which does only say: > | To ensure that vital configurable values are always avai

Re: mysteries of /etc/default/*

Adrian 'Dagurashibanipal' von Bidder wrote: > On Thursday 15 July 2004 15.15, Martin Dickopp wrote: > > Sebastian Henschel <[EMAIL PROTECTED]> writes: > [/etc/default] > > See Policy 9.3.2. (Disclaimer: IANADD.) > > Which does only say: > | To ensure that vital configurable values are always avai

Re: dh_installman

Matthew Palmer wrote: > I was under the impression that dh_installman renamed the file appropriately > according to the .TH line -- at least, that's what the manpage suggests. It uses the .TH line to get the section, but AFAIK there is nothing similar in the content of the man page to work out the

Re: dh_installman

Matthew Palmer wrote: > I was under the impression that dh_installman renamed the file appropriately > according to the .TH line -- at least, that's what the manpage suggests. It uses the .TH line to get the section, but AFAIK there is nothing similar in the content of the man page to work out the

Re: RFS: New version of cvs-autoreleasedeb

Eike zyro Sauer wrote: > Raphael Goulais schrieb: > > - Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since > >the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't > >think you should remove the log files anyway, even on a purge. > > Is this consensus? > I thou

Re: RFS: New version of cvs-autoreleasedeb

Eike zyro Sauer wrote: > Raphael Goulais schrieb: > > - Why do you remove /var/log/cvs-autoreleasedeb.log at postrm, since > >the log files are in /var/log/cvs-autoreleasedeb/ ? Also, I don't > >think you should remove the log files anyway, even on a purge. > > Is this consensus? > I thou

Re: Multi-person sponsorship

Matthew Palmer wrote: > > package I sponsor. I want to know if they are not able to send me a > > package that will build properly. I want to work with them and be > > Since you only get packages for sponsorship which have built in a clean sid > chroot out of my system, you can be fairly sure of t

Re: Multi-person sponsorship

Matthew Palmer wrote: > > package I sponsor. I want to know if they are not able to send me a > > package that will build properly. I want to work with them and be > > Since you only get packages for sponsorship which have built in a clean sid > chroot out of my system, you can be fairly sure of t

Re: Multi-person sponsorship

Matthew Palmer wrote: > So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose package I sponsor. I want to know if they are not able to send me a package

Re: Multi-person sponsorship

Matthew Palmer wrote: > So, comments, brickbats, acclaim, whatever. Throw it at me. Well I don't think that this system as described would be of any use to me. I want to maintain a close relationship with the people whose package I sponsor. I want to know if they are not able to send me a package

Re: Multiple binary source & per-package dh_ options?

Stephen Gran wrote: > dh_installinit -p foo -n > dh_installinit -a dh_installinit -p foo -n dh_installinit -a -N foo -- see shy jo signature.asc Description: Digital signature

Re: Multiple binary source & per-package dh_ options?

Stephen Gran wrote: > dh_installinit -p foo -n > dh_installinit -a dh_installinit -p foo -n dh_installinit -a -N foo -- see shy jo signature.asc Description: Digital signature

Re: po2debconf errors

Stephen Gran wrote: > I am working on a package that uses po files, inherited from the > previous maintainer, and I am getting this during build: > > po2debconf debian/clamav-daemon.templates > > debian/clamav-daemon/DEBIAN/templates > Warning:Outdated PO file: debian/po/fr.po, running > debco

Re: po2debconf errors

Stephen Gran wrote: > I am working on a package that uses po files, inherited from the > previous maintainer, and I am getting this during build: > > po2debconf debian/clamav-daemon.templates > debian/clamav-daemon/DEBIAN/templates > Warning:Outdated PO file: debian/po/fr.po, running > debconf-

Re: wmbatteries

Roberto Cioffi wrote: > Joey Hess wrote: > > > As the author of wmbattery, and a debian developer, I wish you > > could find a new name for your program. I think that having two > > programs that do the own thing have names differing only by > > pluralisation w

Re: wmbatteries

Roberto Cioffi wrote: > I've just uploaded a new package: wmbatterie. > It's a dockapp for windowmaker that shows acpi information read from > proc filesystem. > > It can be reached at: > > http://mentors.debian.net/debian/dists/unstable/ > > or at: > > http://utenti.lycos.it/bigjacob/debian/ >

Re: wmbatteries

Roberto Cioffi wrote: > Joey Hess wrote: > > > As the author of wmbattery, and a debian developer, I wish you > > could find a new name for your program. I think that having two > > programs that do the own thing have names differing only by > > pluralisation w

Re: wmbatteries

Roberto Cioffi wrote: > I've just uploaded a new package: wmbatterie. > It's a dockapp for windowmaker that shows acpi information read from > proc filesystem. > > It can be reached at: > > http://mentors.debian.net/debian/dists/unstable/ > > or at: > > http://utenti.lycos.it/bigjacob/debian/ >

Re: When to unregister unused debconf templates?

Frank Küster wrote: > after changing the configuration scheme considerably, I have a couple of > unused debconf templates left. I guess it's a good idea to unregister > them from the database to keep it as small as possible. > > Where should I do this? Not before the new package is unpacked, but a

Re: When to unregister unused debconf templates?

Frank Küster wrote: > after changing the configuration scheme considerably, I have a couple of > unused debconf templates left. I guess it's a good idea to unregister > them from the database to keep it as small as possible. > > Where should I do this? Not before the new package is unpacked, but a

Re: config.sub and config.guess | .diff.gz bloat

Zenaan Harkness wrote: > > > debhelper puts the following into the "clean" rule in debian/rules: No it didn't. > Should I email this to the debhelper script maintainer? Only if you want me to bounce it to the maintainer of the package that actually put those lines there. -- see shy jo signat

Re: config.sub and config.guess | .diff.gz bloat

Zenaan Harkness wrote: > > > debhelper puts the following into the "clean" rule in debian/rules: No it didn't. > Should I email this to the debhelper script maintainer? Only if you want me to bounce it to the maintainer of the package that actually put those lines there. -- see shy jo signat

Re: RFS: APT-Fu - source building tool for APT

Eric Wong wrote: > Hello, I wrote a new source-building tool for APT and am looking for > somebody to sponsor it. > > Here's an excerpt I wrote for the README file: > > Why APT-Fu? Why not use an existing source-building tool in Debian? I think it's a bad idea to add yet another duplicate

Re: RFS: APT-Fu - source building tool for APT

Eric Wong wrote: > Hello, I wrote a new source-building tool for APT and am looking for > somebody to sponsor it. > > Here's an excerpt I wrote for the README file: > > Why APT-Fu? Why not use an existing source-building tool in Debian? I think it's a bad idea to add yet another duplicate

Re: Debconf problem: Question asked twice

Frank Küster wrote: > It wasn't me ;-) One of the maintainers of tetex brought up a > modification to fix a bug which altered the seen flag, and I wanted to > suggest a somewhat different approach. I agree, however, with Atsuhito > that the question has to be shown again to anybody who has answered

Re: Some debconf questions

Frank Küster wrote: > It isn't, or rather Joey has misunderstood me - he probably knows every > piece of code by heart. Hardly, and obviously not. I'd forgotten about the seen flag cache used in making it easier to do scripts that back up. Besides, it's 30kloc.. ;-) > Seen (after seeing in fact):

Re: Debconf problem: Question asked twice

Frank Küster wrote: > It wasn't me ;-) One of the maintainers of tetex brought up a > modification to fix a bug which altered the seen flag, and I wanted to > suggest a somewhat different approach. I agree, however, with Atsuhito > that the question has to be shown again to anybody who has answered

Re: Some debconf questions

Frank Küster wrote: > It isn't, or rather Joey has misunderstood me - he probably knows every > piece of code by heart. Hardly, and obviously not. I'd forgotten about the seen flag cache used in making it easier to do scripts that back up. Besides, it's 30kloc.. ;-) > Seen (after seeing in fact):

Re: Debconf problem: Question asked twice

Frank Küster wrote: > + db_fset tetex-bin/hyphen seen false > + db_input medium tetex-bin/hyphen || true > +#db_fset tetex-bin/hyphen seen true Please reconsider playing with the seen flag, unless you know *exactly* what you're doing. Since you see the question

Re: Some debconf questions

Frank Küster wrote: > [EMAIL PROTECTED]:~$ debconf-show tetex > Configuration database "frankdb" was not initialized. > > Probably it would be better if you point me to some documentation so > that I don't have to bother the list. There no occurence of "init" in > debconf(7), debconf-devel(7) or d

  1   2   3   4   5   >