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: 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: 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: 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: 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: 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: 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: 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_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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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?

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: Managing Debian packages with Subversion

Jamin W. Collins wrote: > I prefer an alternate structure where you start with the project as a > top level. This keeps all project (package) related files under one > directory in the project: > >project/ > trunk/ > branches/ > tags/ > vendor/ The only problem wit

Re: Managing Debian packages with Subversion

Fabian Fagerholm wrote: > Thanks to [EMAIL PROTECTED] and [EMAIL PROTECTED] for their > insight into this issue. I will try to summarize everything in this > reply to myself. Nice job writing this up, here are some corrections. > The repository will have the following structure: > > trun

Re: Managing Debian packages with Subversion

Jamin W. Collins wrote: > I was with you up to this point. I don't normally name my working copy > in the form project- as that form is needed for actually making > hte package and for that we need an exported copy of the working copy. Actually, dpkg-buildpackage does not care what you name the b

Re: Managing Debian packages with Subversion

Eduard Bloch wrote: > However, a possible implementation failed completely because of > stupideness of "svn merge". So we have to find an alternative solution > with diff&patch&cp. OTOH it is not possible to keep the version history of > every file. I think you're looking for svn_load_dirs. -- s

Re: Some debconf questions

Frank Küster wrote: > - If a debconf question is manipulated by db_set, does that affect its > "seen" flag? And if it does, does it take effect immediately (i.e., > also for a following db_inut ...), or only in the next run of the > config file? No, you would have to use FSET to manipulate a

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

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: > 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: 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: 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: 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: 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: 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: 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: 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: 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: > > 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: 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: 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: 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: 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: 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: 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: buildinfo.debian mit debhelper ?

Adam P. Harris wrote: > I have. Some packages require specific versions of supporting > packages. Since we don't have source depends, > /usr/doc//buildinfo.Debian files are a useful thing. Buildinfo files are in binaryt packages. What does that have to do with source packages? -- see shy jo

Re: my first package... loads of questions :)

Martin Schulze wrote: > the maintainer. Well, there's just right another, using debhelper > partially prevents the package from being compiled on other > architectures.[1] > > [1] We had this problem with binary-sparc where no new perl package > existed so all packages using debhelper couldn'

Re: buildinfo.debian mit debhelper ?

Matthias Klose Perhaps not everybody wants to rebuild from the debian source package, > but compile a newer upstream version for personal use or installation > into /usr/local. Then the buildinfo in /usr/doc/ would be useful. Why? -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] w

Re: 2 packages using same conffile

Joseph Carter wrote: > What does one do in a situation where two packages both provide the same > conffile? Currently they use different names for the file, but both > packages can (and probably should) use the same file. How should this be > handled, both from a policy and from an implementation

Re: moving confflie to another location

Martin Bialasinski wrote: > I am squashing the bugs in the xisp package. Report 12773 asks to move a > conffile from /etc/options.xisp to /etc/ppp/options.xisp. > > This sounds reasonable. To handle upgrading from an old version, is it enough > to move the file in preinst? Here's what I put in th

Re: debstd trouble with multi-binary package

Adam P. Harris wrote: > Joey Hess, as the maintainer of debhelper, do you see this as a > situation that should change? I think we should eliminate any manuals > suggesting debstd (or put it under a "historic" section), and try to > get someone working on a debhelper

Re: moving confflie to another location

Dan Jacobowitz wrote: > Except, if the user has decided to make it a symlink, wouldn't it make > more sense to just rename the symlink? Otherwise, I'd get really > confused if my /export/configs/X11/xaw-wrappers.conf for example > suddenly got disconnected from /etc/{X11/,}xaw-wrappers.conf . It'

Re: debstd trouble with multi-binary package

Jaldhar H. Vyas wrote: > As the author of one of those documents, (Will Lowe is the other but I > don't know if he is still working on it.) I agree completely. I no longer > use debstd in my own packages and don't recommend it to others. > > Since around February off and on, I've been working on

Re: tempfile <-> IO::Handle::new_tmpfile?

Marcelo E. Magallon wrote: > Hi, > >can I use IO::Handle::new_tmpfile in an Perl script that's run on > postinst? The package has to Predepend on perl, right? Why not just depend on debianutils (>= 1.6) and use the tempfile command? > I'll use this > tempfile to modify a conffile (it *ha

Re: tempfile <-> IO::Handle::new_tmpfile?

Marcelo E. Magallon wrote: > There's nothing wrong with debianutils... this is more a meta > question, I was just wondering if I could use the Perl provided > method... and debianutils is part of the base system, and it's > requiered, so there's no need to depend on it, is there? You have to d

Re: circular depends: problem

Shaleh wrote: > E-themes does not have a Changelog or a Copyright --> it is just pics, > wavs and a text file or three. The docs from E explain what they are If you really don't have a copyright, it cannot go in debian. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subj

Re: How to make only the binary parts

Shaleh wrote: > Now that I have a few packages split into arch-dep and arch-indep, how > do I only build one or the other? If all that changed is the arch-dep > packages, I do not need to re-upload the arch-indep and vice versa. If you changed the version number, you really need to upload the arc

Re: debhelper error -- bug?

Brian Almeida wrote: > The latest release of debhelper(0.99.2) broke my packages. > Is it a bug in it, or my packages? I think it the recent change > to dh_movefiles (see the changelog) did it. Unfortunately I don't > know enough bash to fix it myself. Thanks. > > Here is the error: > -

Re: libmsgcat and sympa : my first packages

Raphael Hertzog wrote: > Why not, but why does debstd provide the possibilitry of modifying : > - /etc/aliases > - /etc/syslog.conf > - /etc/inetd.conf > - /etc/services > - /etc/inittab > - /etc/protocols > - /etc/profile > - /etc/modules > - /etc/X11/window-managers > - probably some others > >

Re: New maintainer's packaging - bewildering variety of information

Matthias Klose wrote: > try to run the helper programs with -v. You get a pretty good insight > what's happening (although this may change, when Joey is switching the > current sh implementation to perl). This will not change. I use perl for the backend now, but it just runs shell commands to do

Re: debhelper

Darren Benham wrote: > To date, I've been using the deb-make packages to handle my packages... After > following a recent conversation, I figured I'd give debhelper a try but I'm > having trouble finding a suitable "Starting place" to aquaint myself with it. > Anybody point me in the right directi

Re: what are the latest debian packaging tools.

Manoj Srivastava wrote: > Hi, > >>"Stephane" == Stephane Bortzmeyer <[EMAIL PROTECTED]> writes: > > Stephane> Just do it... I considered adopting the Packaging HOWTO > Stephane> which seems orphan but it is work and I'm lazy :-} > > The packaging HOWTO is a part of the core Policy documen

Re: changing location of .conf files

tony mancill wrote: > preinst checks to see if it was called with either "install " > or "upgrade ", which case it will copy whatever the user had > for these conffiles into the new locations (and then remove the old > conffiles? Or let dpkg handle this?) I've done this a couple of times, but I c

Re: Packages with shared libraries

Samuel Tardieu wrote: > 1) Man pages and info files > - --- > It looks like the man page is being included in the three > distribution. How can I prevent this? Are you using debhelper and dh_installmanpages to install the man pages automatically? dh_installmanpages has some

  1   2   3   4   5   >