Re: searching for a sponsor for vexim
On Fri, Apr 25, 2008 at 06:47:50PM +0200, Daniel Knabl wrote: > after a long while I'm again searching for someone willing to sponsor > and/or upload vexim to Debian. > > you can find the latest files here: http://tirolinux.net/~daniel/vexim/ > * http://tirolinux.net/~daniel/vexim/vexim_2.2.1-5.1.dsc > * http://tirolinux.net/~daniel/vexim/vexim_2.2.1-5.1.tar.gz > * http://tirolinux.net/~daniel/vexim/vexim_2.2.1-5.1_i386.changes After spending like a minute with the postinst script, it is clear that the package is still totally unfit for Debian. The postinst unconditionally chmods the entire contents of /etc/exim4 to 640, ignoring local maintainer changes and messes around with files in in /usr/share/vexim. I fail to understand the dbc_generate_include business at the beginning of the postinst script, it looks to me like all variables are set twice to different values. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: versioned Build-Depends on debhelper
On Wed, Jul 30, 2008 at 02:14:53PM -0700, Russ Allbery wrote: > Stanislav Maslovski <[EMAIL PROTECTED]> writes: > > My sponsor asked me to delete versioned build dependency on debhelper. > > I think this is bad advice. I agree. There are people building Debian packages on older releases, and having a package fail because a known versioned dependency had its version removed it a disservice to those people. I might be missing arguments for removing the version, but I have only been a DD for like seven years. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: versioned Build-Depends on debhelper
On Thu, Jul 31, 2008 at 12:05:21PM +0400, Stanislav Maslovski wrote: > On Wed, Jul 30, 2008 at 11:57:44PM +0200, Marc Haber wrote: > > On Wed, Jul 30, 2008 at 02:14:53PM -0700, Russ Allbery wrote: > > > Stanislav Maslovski <[EMAIL PROTECTED]> writes: > > > > My sponsor asked me to delete versioned build dependency on debhelper. > > > > > > I think this is bad advice. > > > > I agree. There are people building Debian packages on older releases, > > and having a package fail because a known versioned dependency had its > > version removed it a disservice to those people. > > That was my concern also. However, Romain pointed out that Etch > (which will soon become oldstable) has debhelper of ver. > 5 so there > should not be problems with backporting to it. There have been Debian releases before etch. Which is the reason why I wrote "older releases" instead of etch. > > I might be missing arguments for removing the version, but I have only > > been a DD for like seven years. > > Marc, Russ, thank you for your answers. Unfortunately, the package has been > already sponsored and uploaded to NEW. I think that at this stage this change > should be harmless. I will return the versioned dependency back when > preparing the next modification of the package. And please deliver a cluebat to your sponsor and ask him to give better advice to newbies in the future. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ITP vexim
On Sun, 22 Jan 2006 14:44:59 -0500, Justin Pryzby <[EMAIL PROTECTED]> wrote: >You can't just overwrite exim4-config's conffiles. I *think* you can >Provide: exim4-config, but only if you also Conflict: exim4-config. The exim4 maintainer insists that vexim completely replaces exim4-config, so that bug reports against vexim go to the vexim maintainer or can easily be identified as vexim issues if they get filed against exim4. In exim4's README.Debian, it is mentioned how to replace exim4-config, and the exim4 svn has two examples of packages which do this in a greaceful matter. Daniel has been pointed to that README.Debian file multiple times and has obviously not yet bothered to read it. >Do you intend to Depend: exim4? He needs to Depend on exim4-daemon-heavy since vexim is database driven. I recommend that he models his dependencies as closely as possible to exim4-config or the two example packages found in exim4 svn. >How do you deal with the exim4 "conf.d" model vs the exim4.conf model? If he replaces exim4-config, he doesn't need to deal with it. >Your rules file doesn't function at all with dpkg-buildpackage or any >other Debian tools :) > >sed -i -e 's/virtuel/virtual/; s/configuratin/configuration/;' ./debian/control > >Standards-Version: 2.2.rc1 > >That doesn't mean what you think it does :) It is a version of Debian >policy document, not of your package. omg. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: ITP vexim
On Mon, 23 Jan 2006 00:16:25 +0100, Daniel Knabl <[EMAIL PROTECTED]> wrote: >case "$1" in > configure) > db_get vexim/dc_vexim_pass || true > dc_vexim_pass=$RET > db_get vexim/dc_vexim_myip || true > dc_vexim_myip=$RET > db_get vexim/dc_vexim_fdqn || true > dc_vexim_fdqn=$RET > cat /usr/share/doc/vexim/setup/mysql.sql |\ > sed s/@@PASS@@/$dc_vexim_pass/g |\ > sed s/@@MYIP@@/$dc_vexim_myip/g |\ > sed s/@@FDQN@@/$dc_vexim_fdqn/g \ > > /tmp/vexim_mysql.tmp > mysql -u debian-sys-maint \ > < /tmp/vexim_mysql.tmp > rm /tmp/vexim_mysql.tmp I am not sure whether maintainer scripts are allowed to rely on information found in /usr/share/doc. Refer to the policy, please. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: ITP vexim
On Sun, 22 Jan 2006 20:55:09 -0500, Justin Pryzby <[EMAIL PROTECTED]> wrote: >What is exim4-config-2 anyway? We had to change the exim4-config "API" early in the development process, so exim4-config-2 is a "virtual" dependency for the current version of the exim4-config "API" as described in README.Debian. Greeting -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: ITP vexim
On Mon, 23 Jan 2006 16:25:11 +, Stephen Gran <[EMAIL PROTECTED]> wrote: >This one time, at band camp, Daniel Knabl said: >> Am Sun, 22 Jan 2006 14:44:59 -0500 schrieb Justin Pryzby >> > How do you deal with the exim4 "conf.d" model vs the exim4.conf model? >> >> Please look at the previous paragraphs. ;-) > >Why don't you just create an entire seperate conf.d structure and tell >people to use the -d switch in /etc/default/exim? Bad idea for a package. That's what the -config API is for. As exim maintainer, I want to know exactly when a bug reported against exim is actually mine or vexim's. And vexim is exactly that kind of software which attracts a huge bunch of clueless wannabe-mailadmins who generate truckloads of bug reports. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: ITP vexim
On Thu, 26 Jan 2006 14:11:27 +0100, Daniel Knabl <[EMAIL PROTECTED]> wrote: >Einst schrieb Marc 'HE' Brockschmidt <[EMAIL PROTECTED]>: >>* postinst is sometimes called with other values (*not* only >> configure). Though these are perfectly OK, your postinst script will >> fail. > >Could you describe what you exactly think about? (so that I can imagine >what would happen ... and learn from this) How many times have you been pointed to Debian policy? And you are still asking questions that neatly show that you didn't read it? And that also neatly show that you have never looked at other packages? Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: ITP vexim
On Fri, 27 Jan 2006 16:21:47 -0500, [EMAIL PROTECTED] wrote: >On Fri, Jan 27, 2006 at 10:09:56PM +0100, Daniel Knabl wrote: >> Sorry, my mistake. I had to remove CVS dirs from the tarball. Now this >> should be correct. >Thats not a sufficient reason to repack the tarball; it is more >important that it is pristine (if applicable). I think this is a very good place to educate upstream about how to do cvs export for releases instead of releasing a checked out working copy. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: ITP vexim
On Sat, 28 Jan 2006 02:34:47 +0100, Daniel Knabl <[EMAIL PROTECTED]> wrote: >Am Fri, 27 Jan 2006 18:08:38 -0500 schrieb [EMAIL PROTECTED]: >> Nearly all Debian packages should be pristine; if you can do that, you >> should. If upstream *only* exists in CVS, then you can't really, and >> you can run that command before creating your orig tarball. If >> upstream has a real tarball, though, then please use it :) > >The upstream tarball is beeing built daily from CVS, but always >includes CVS dirs. So your Upstream is not doing proper releases and you're merely packaging daily CVS snapshots[1]? Greetings Marc [1] which should be generated with cvs export instead of cvs checkout. -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Some files in /usr/share/doc/foo stay uncompressed, some are compressed
Hi, exim4-doc-html includes the exim FAQ, which is a bunch of HTML files and some configuration examples as .txt, in /usr/share/doc/exim4-doc-html/html. The larger of these .txt files are compressed by the build processs, while the smaller of them stay uncompressed. This is confusing. I am now wondering whether it is acceptable to compress all of the .txt files, or to keep all of them uncompressed. Which would be the lesser evil? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
How to dpatch a file inside a tarball inside an .orig.tar.gz?
Hi, The eximdoc4 source package is built from two upstream tarballs, one with the texinfo docs and one with the html docs. To massage this into Debian source package format, the two upstream .tar.bz2 tarballs are tar.gz'ed together to form eximdoc4_foo.tar.gz. It has now shown to be necessary to apply patches to the upstream docs. I would like to use dpatch for that. Which approach is the most promising and least ugly? (1) Have a 01_unpack.dpatch file which doesn't patch, but unpack the upstream tarballs? (2) Transform the "Debian upstream tarball" (which is locally built anyway to include the two upstream tarballs in unpacked form? The tar.gz will be much bigger then since bz2 compression is rather effective on the text docs. (3) Modify debian/rules to first unpack, second patch, third build? Is there a package which does this and can be taken as a template? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Some files in /usr/share/doc/foo stay uncompressed, some are compressed
On Sun, 12 Feb 2006 17:30:57 -0200, "Nelson A. de Oliveira" <[EMAIL PROTECTED]> wrote: >On 2/12/06, Marc Haber <[EMAIL PROTECTED]> wrote: >> I am now wondering whether it is acceptable to compress all of the >> .txt files, or to keep all of them uncompressed. Which would be the >> lesser evil? > >Less evil is let them all compressed. but not compressing them would remove the need to patch the html files. dh_compress has an option to modify its default behavior. >In general, dh_compress will do the right job for you. In the current situation, it doesn't. Policy allows both approaches as the files _should_ be compressed. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Some files in /usr/share/doc/foo stay uncompressed, some are compressed
On Sun, 12 Feb 2006 14:32:05 -0500, Justin Pryzby <[EMAIL PROTECTED]> wrote: >So it seems that it shouldn't actually be compressing html files; It isn't. The files in question are .txt config file snippets that are linked from the html code. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Some files in /usr/share/doc/foo stay uncompressed, some are compressed
On Sun, 12 Feb 2006 18:01:27 -0200, "Nelson A. de Oliveira" <[EMAIL PROTECTED]> wrote: >You can do this: > >If the .txt files are really important and necessary, you may left >them uncompressed and you won't need to patch the html file. > >If the .txt files aren't very important, you can compress the .txt and >then patch the html file. > >For example, the original html has something like this: >"You can see an example at file.txt." > >On the modified one, you can put: >"You can see an example at file.txt.gz (compressed)." Please, don't treat me as a clueless newbie. The package in question is exim4-doc-html, the documentation for Debian's default MTA. The fact that I maintain that package should show that I have been around the block multiple times. What you outline is exactly what I wrote in my original question. I am pretty well aware of the technical possibilities. I am just pondering which of the two ways to go, and re-iterating the possibilities along with "it's your choice" doesn't help much. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: How to dpatch a file inside a tarball inside an .orig.tar.gz?
On Mon, 13 Feb 2006 01:24:07 -0600, Peter Samuelson <[EMAIL PROTECTED]> wrote: >[Daniel Leidert] >> Am Sonntag, den 12.02.2006, 20:01 +0100 schrieb Marc Haber: >> > It has now shown to be necessary to apply patches to the upstream >> > docs. I would like to use dpatch for that. >> >> Could you also write a bug-report for dpatch? This is a feature I also >> miss and I would of course support such a request. > >Well, note that (1) is already possible and not even all that hard. >That is, to have a .dpatch file whose purpose is to unpack the tarball >on 'patch' and delete the tree on 'unpatch'. dpatch was written with >that sort of flexibility in mind - it seems a shame not to use that >flexibility for one of the few things it's actually good for. (I've >always viewed that flexibility in dpatch to be a serious case of >overengineering, but this is probably a valid use case.) Ok, so, as a member of the dpatch team, I'm going to set a use-case for this ;) Let's see if it can be done as designed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: How to dpatch a file inside a tarball inside an .orig.tar.gz?
On Mon, 13 Feb 2006 11:34:37 +0100, Marc Haber <[EMAIL PROTECTED]> wrote: >Ok, so, as a member of the dpatch team, I'm going to set a use-case >for this ;) Let's see if it can be done as designed. Looks like things have worked out differently and the patch is not necessary any more. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Need help with kernel module building
Hi, I am trying to understand the cooperation of kernel sources, kernel image, kernel-package and module-assistant and am kind of at a loss here. In the debian/ directory of the module sources, I find strange combinations of control, control.in, control.modules and control.modules.in. In one package, I have also found a control.modules.in.in file. In debian/rules, there is usually no code handling the control files. Which component of the build process is supposed to handle the control file generation as I suppose that the module build process actually needs a control and a control.modules file, right? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Need help with kernel module building
On Thu, 14 Sep 2006 20:03:30 +0200, Marcus Better <[EMAIL PROTECTED]> wrote: >Marc Haber wrote: >> Which component of the build process is supposed to handle the control >> file generation > >module-assistant. You will see that debian/rules includes some files >from /usr/share/modass. The documentation for module-assistant has the >details. Unfortunately, I seem to be too stupid for the (sparse) module-assistant documentation. For example, I do not understand the interface between module-assistant and the module sources. I have one (inofficial) module source package which seems to build fine when invoked with debian/rules binary-modules, but fails with module-assistance. Since I do not know how module-assistant invokes the module package debian/rules file, I am at a loss to debug. Is there any documentation I missed? A wiki page with explanations, maybe? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Depending on an essential package
On Mon, 18 Sep 2006 04:33:49 -0700, Steve Langasek <[EMAIL PROTECTED]> wrote: >The error is, if you don't *need* a specific version of the package, you >shouldn't depend on it at /all/. Essential means it's always available, so >there's no reason for you to depend on it. I have never understood the reason for this rule, as it is bound to introduce truckloads of RC bugs whenever a package is moved out of essential. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: Depending on an essential package
On Mon, Oct 30, 2006 at 01:59:05PM +0100, Bas Wijnen wrote: > Packages aren't moved out of essential. So you can guarantee that bash will always be essential? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using the user nobody in my package
On Thu, Nov 16, 2006 at 01:41:30AM +0100, Michael Biebl wrote: > I always use something like this in my postinst scripts > > if ! getent group foo > /dev/null ; then > addgroup --quiet --system foo > fi > > This avoids the warning/error message, if the group/user already exists. With my adduser maintainer hat on, that is not the way adduser is intended to be used. We went to great lengths to make adduser useable without any surrounding bugs^wcode. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using the user nobody in my package
On Fri, Nov 17, 2006 at 08:25:18AM +0100, Michael Biebl wrote: > Marc Haber wrote: > > On Thu, Nov 16, 2006 at 01:41:30AM +0100, Michael Biebl wrote: > >> I always use something like this in my postinst scripts > >> > >> if ! getent group foo > /dev/null ; then > >>addgroup --quiet --system foo > >> fi > >> > >> This avoids the warning/error message, if the group/user already exists. > > > > With my adduser maintainer hat on, that is not the way adduser is > > intended to be used. We went to great lengths to make adduser useable > > without any surrounding bugs^wcode. > > Interesting. But I'd say you failed to advertise this feature of adduser > then. I just checked the postinst scripts in /var/lib/dpkg/info and > basically every package that dealt with user/group creation had a stanza > similar to the one above. So I was mostly documenting current best > practice in my initial email. > If indeed the recommended way nowadays is to use adduser without the > surrounding check, maybe this should be documented somewhere, either the > debian policy or the developers reference. This is ongoing documentation work, see http://wiki.debian.org/AccountHandlingInMaintainerScripts Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Using the user nobody in my package
On Sat, Nov 18, 2006 at 12:59:56PM +0800, Thomas Goirand wrote: > Marc Haber wrote: > > This is ongoing documentation work, see > > http://wiki.debian.org/AccountHandlingInMaintainerScripts > > > > As far as I can see, this doc gives (IHMO) no real directions and says > that it's under discussion on how to get UIDs... Yes, it is an aid to build consensus. > I'm now switching to use the username 'dtc' May I suggest using something that is less likely to clash with local user names, such as "Debian-dtc"? > and I save in my database this username and it's UID Why do you do that? Use getent in your scripts. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to unpack upstream tarball in a dpatch-using package?
Be given a source package with the following layout: foo/ foo/debian foo/debian/rules foo/debian/patches foo/debian/patches/00list foo/debian/patches/01bar foo/upstream/package.tar.bz2 So I want the package build process to unpack foo/upstream/packag.tar.bz2 before trying to apply the patches with dpatch. Is it better to do some makefile magic for this unpacking (as having an unpack-stamp which patch depends on, or would one better have a foo/debian/patches/00unpack dpatch snippet doing the unpacking? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to do input sanitazion in debconf
Hi, #400294 suggests that the Debian exim4 packages go to some way to sanizite input delivered via debconf. I am wondering how to properly do this. One would want to either build a state machine or to loop around all debconf questions until the sanitazion has passed. And one needs debconf templates for all possible error messages. This sounds like being a pain to actually do, but could be eased inside debconf when #400294 is addressed. And to make things worse: One usually writes out debconf information to config files. In the (rather common case) where these config files are postprocessed, once need to do input sanitazion there as well. Doubled bug potential. What is the recommended way to do this? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
When to call debconf-updatepo and when not?
I have a package (exim4) where debian/rules clean calls debconf-updatepo. And still people complain that when they rebuild the package, some po diffs end up in the interdiff. What am I doing wrong? Where do I call debconf-updatepo, and where do I not? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tone-of-voice used by sponsors
On Sun, Jan 14, 2007 at 04:58:13PM +0100, Thijs Kinkhorst wrote: > I often find the lists that Daniel posts to resemble commands "remove > this.", "do not do that", "this is bogus", "that is useless" but lacking > of background or guidance. This might be a language problem. I am also a native speaker of German, and I observe myself to come over a lot more harsh than intended when I write english. I mean, German is the language that makes "I love you" sound like a declaration of war. Misunderstandings like that happen. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Tone-of-voice used by sponsors
On Sun, Jan 14, 2007 at 05:35:02PM +0100, Daniel Baumann wrote: > Thijs Kinkhorst wrote: > > If you take a look at some other sponsors, > > you will see that if they have some criticism on a package, they will > > often include *why* it is a problem, and/or how to solve it. This > > doesn't have to be long. > > this would take me much more time to write the mail. Since you regularly complain about the same things, you could use Textbausteine. Whatever that might be in English ;) Grüße Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Removing self-managed conffiles?
Hi, I have a package with a bunch of configuration files that are managed by my maintainer scripts and not by dpkg. I now need one of them (a.conf) to vanish. How do I do this in a clean way? I am thinking about the following: (1) Let the new package version know about the md5sum of the last version(s) of a.conf that were in the package. (2) If one of the md5sums matches, the file has not been changed, remove it. (3) If none of the md5sums matches, the file has locally been changed, rename it to a.conf.package-old Is that acceptable? Or is there anything easier, more elegant, more policy compliant? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, Jan 19, 2007 at 09:43:04PM +0100, Santiago Vila wrote: > On Fri, 19 Jan 2007, Marc Haber wrote: > > I have a package with a bunch of configuration files that are managed > > by my maintainer scripts and not by dpkg. I now need one of them > > (a.conf) to vanish. > > > > How do I do this in a clean way? I am thinking about the following: > > > > (1) Let the new package version know about the md5sum of the last > > version(s) of a.conf that were in the package. > > (2) If one of the md5sums matches, the file has not been changed, > > remove it. > > (3) If none of the md5sums matches, the file has locally been changed, > > rename it to a.conf.package-old > > Instead of 1,2,3 you could do 1,2,3 only when upgrading from a version > previous than the one not having a.conf anymore, and in case > that (3) happens, keep a.conf untouched, instead of renaming it > (assuming the program will not read a.conf anymore). Yes, that sounds sensible. It is, however, frustrating that there is no method (for example, offered by ucf) to do this without that much coding in maintainer scripts. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Fri, Jan 19, 2007 at 10:26:45PM +0100, Florent Rougon wrote: > Marc Haber <[EMAIL PROTECTED]> wrote: > > Is that acceptable? Or is there anything easier, more elegant, more > > policy compliant? > > I think it's the usual, and correct way (sometimes actually performed by > ucf, but since you're getting rid of the file, there is no point in > putting it under ucf control). The file is under ucf control (I omitted that to lessen complexity), but ucf does not know about the file any more if it is not in the new package and will therefore not handle it. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Fri, Jan 19, 2007 at 10:28:41PM -0500, Justin Pryzby wrote: > You will have to test with both sarge and etch dpkg (until after etch > releases). Colin Watson recently wrote [0] about one of the ssh bugs > and how this was complicated for him. > > You have to include the logic in the preinst, since the prerm is for the old > package, since the postinst happens after the conffile prompts, and since the > postrm happens post rm... This sounds like a horrible mess and a gazillion ways to do things wrong. Is there a reference package that does things completely right? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote: > This is the beauty of fre software. If you find it so > frustrating, write up a generic tool, and contribute it. And that > would follow the grand old UNIX tradition of each command doing one > thing well. The task at hand would mean forking ucf, which would be a bad idea. Additionally, I'd like a functionality of this importance in a better coder's hand than mine. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 11:38:39AM -0600, Manoj Srivastava wrote: > On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber <[EMAIL PROTECTED]> said: > > On Sat, Jan 20, 2007 at 10:31:11AM -0600, Manoj Srivastava wrote: > >> This is the beauty of fre software. If you find it so frustrating, > >> write up a generic tool, and contribute it. And that would follow > >> the grand old UNIX tradition of each command doing one thing well. > > > The task at hand would mean forking ucf, which would be a bad idea. > > Then I am sorry to say you have not learned how free software > works. Your opinion. Agree to disagree? > There is no need to fork ucf to create a command that provides > functionality not in ucf. the intersection between zmct (zugschlus' magical conffiles tool) and ucf would be non-negligible and a lot of routine stuff would need to be present in both packages. > And, arguably, this functionality should be in a different script > anyway, perhaps one that can read the simple ucf cache, which, given > the installed base, is unlikely to change from under you. Where is the documentation of the stable interface to ucf's cache that is reliable not to change between ucf releases? > > Additionally, I'd like a functionality of this importance in a > > better coder's hand than mine. > > Write the code. You might surprise yourself. Or find that > other people can help out. Or you could contribute the code to be > included in ucf. But the first step is "do the work." insufficient time resources. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] svn rollback
On Tue, Jan 23, 2007 at 12:34:08PM +0100, Stefano Zacchiroli wrote: > On Tue, Jan 23, 2007 at 09:01:52PM +1100, Robert Collins wrote: > > Also, in the (rare but can occur) event of a svn rollback, r91 is not > > necessarily accurate after the fact,whereas a datestamp is. > > Uh? Is "rollback" (in the sense of "undoing" a commit) possible with SVN > without manually fiddling in the repository at all? Sure, svn merge. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed conffiles?
On Sat, Jan 20, 2007 at 01:14:59PM -0600, Manoj Srivastava wrote: > On Sat, 20 Jan 2007 18:46:20 +0100, Marc Haber > <[EMAIL PROTECTED]> said: > > On Sat, Jan 20, 2007 at 11:38:39AM -0600, Manoj Srivastava wrote: > >> On Sat, 20 Jan 2007 18:17:27 +0100, Marc Haber > >> <[EMAIL PROTECTED]> said: > >> There is no need to fork ucf to create a command that provides > >> functionality not in ucf. > > > the intersection between zmct (zugschlus' magical conffiles tool) > > and ucf would be non-negligible and a lot of routine stuff would > > need to be present in both packages. > > err, why would there be anything non-negligible beyond a > single grep call in common? I fail to see why there will be mounds > and mounds of common stuff -- as the tetex example already > demonstrates. I haven't thought about this in the necessary depth. To a newbie DD who has only been with Debian for six years it looks like ucf is not completely finished. > >> And, arguably, this functionality should be in a different script > >> anyway, perhaps one that can read the simple ucf cache, which, > >> given the installed base, is unlikely to change from under you. > > > Where is the documentation of the stable interface to ucf's cache > > that is reliable not to change between ucf releases? > > My goodness. Are we so lost in ISO 9000 processes that we need > formal documentation to realize that ucf hash files have a md5sum and > a file path? And to realize that the hashfile exists on user > machines, and changing formats will be a major effort now? ucf could suddenly start to write the hashfile in some other format while still being able to read the old format. If a change like this is not coordinated between the hypothetical zmct and ucf, all packages using zmct will suddenly be RC-buggy. And I remember you scolding me for using an internal kernel-package interface back in 2001. This has nothing to do with ISO900x (which I hate with a passion). It is about stability. > Then it is good for you tat the tetex folks hve written the > (simple) wrapper code for you -- and the complex common part was: > md5sum=$(grep "$file$" /var/lib/ucf/hashfile | cut -f 1 -d ' ') I suspect that there is some wrapper code needed anyway which is the actual hard part (taking care of special cases). Additionally, imagine this code being scattered away to 100 packages and then some obscure bug surfacing. Currently, ucf does a lot less than dpkg does. What ucf does, it does much better than dpkg. But since there are still things that dpkg handles quite well while ucf basically says "well, code it yourself", ucf does not provider conffile like handling as it is advertising in its package description. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Sat, Jan 20, 2007 at 07:03:24PM +0100, Florent Rougon wrote:
> Marc Haber <[EMAIL PROTECTED]> wrote:
> > but ucf does not know about the file any more if it is not in the new
> > package and will therefore not handle it.
>
> Uh, if you don't 'ucf --purge' it, I fear it will remain in the ucf
> cache. There is code doing what you want in tetex-bin (not written by
> me). For instance, in debian/common.functions.in, you can find:
>
> ucf_md5sum(){
> file=$1
> md5sum=$(grep "$file$" /var/lib/ucf/hashfile | cut -f 1 -d ' ')
> if [ -z "$md5sum" ]; then
> get_sarge_md5sum_from_list $file
> fi
> echo $md5sum
> }
>
> [...]
>
> preinst_remove_or_move_ucf(){
> file=/etc/texmf/$1
> newname=$(get_newfilename $1)
> debug $file
> test -f "$file" || return 0
> debug "handled\n"
> oldmd5sum=$(ucf_md5sum $file)
> currmd5sum=$(md5sum $file | cut -d ' ' -f 1)
> if [ "$oldmd5sum" != "$currmd5sum" ]; then
> mv $file $oldstuff_dir/$(basename $file).$PREINST_MOVE_EXT
> else
> rm $file
> if [ -x /usr/bin/ucf ]; then ucf --purge $file; fi
> fi
> }
These are 23 lines of code which have the potential for a lot of bugs.
I do not think it is a good idea to cut&paste this code into a hundred
packages.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Wed, Jan 24, 2007 at 02:37:46PM +0100, Florent Rougon wrote: > Marc Haber <[EMAIL PROTECTED]> wrote: > > These are 23 lines of code which have the potential for a lot of bugs. > > I do not think it is a good idea to cut&paste this code into a hundred > > packages. > > I didn't know you were alone maintaining a hundred of packages that need > this particular removal code. Interesting. You seem to be deliberately misunderstanding me. I'll stop wasting my time. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Removing self-managed configuration files?
On Wed, Jan 24, 2007 at 04:13:24PM +0100, Florent Rougon wrote: > Marc Haber <[EMAIL PROTECTED]> wrote: > >> I didn't know you were alone maintaining a hundred of packages that need > >> this particular removal code. Interesting. > > > > You seem to be deliberately misunderstanding me. I'll stop wasting my > > time. > > I meant that when a maintainer copies code in its maintainer scripts, he > *must* read the code carefully and understand it. Therefore, if a > hundred maintainers do that as you suggest, there is a very high > probability that most, if not all, bugs are found during the process. I doubt this. Additionally, this is a huge waste of maintainer time. Code like this _BELONGS_ into a standardized tool. Following your course of argumentation, why not have debhelper removed from the archive? > And finally, please accept my apologies for having wasted your precious > time correcting your question (where the use of "conffile" was wrong, Mea culpa for writing a wrong subject. Please have my posting privileges to -mentors removed for two years as punishment for this terrible mistake. Millions of innocent bits had to be flipped because I wrote a wrong subject over a correctly worded question. If you find some more efficient punishment, such as force-orphaning all my packages or having me expelled from the project, please go ahead. > and that of ucf not even mentioned), That was a deliberate omission since the challenge is independent of ucf. Actually, the challenge is there _BECAUSE_ ucf was not designed to address this issue (which it actually should) and its maintainer considers this missing feature a feature. > your algorithm (which was missing 'ucf --purge') My algorithm assumed a ucf-less setup as the issue at hand is independent of ucf. ucf doesn't help here. > and extracting the relevant portion of code from tetex-bin that does > what you want. Thanks for doing so. Seeing that code has reconfirmed my opinion that this task is so common and so complicated that there needs to be a standarized tool to handle this issue, and I still feel that the right place to do this is the tool that claims to be able to replace dpkg conffile (sic!) handling, ucf. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VMware Player packages
On Wed, Mar 07, 2007 at 06:46:18PM +0100, Hans Kratz wrote: > Sure. I wasn't aware of that package. AFAICS that package handles only > the VMware kernel modules right now. No, it can build vmware-player .debs as well. I'll fix the wrong description in svn. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VMware Player packages
On Thu, Mar 08, 2007 at 10:14:45AM +0100, Hans Kratz wrote: > >No, it can build vmware-player .debs as well. I'll fix the wrong > > Ah, I see. I will take a look at vmware-package. Do you plan on > supporting VMware Server as well? As it is documented in the package docs, and a bug in the BTS, to support VMware Server, we'll need to build a second vmware-any-any-foo-source package from the same sources, which needs somebody with really serious make knowledge. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: backports.org became really shitty for php5-mysql and mysql-server-5.0
On Sun, Mar 18, 2007 at 05:25:30PM +0800, Thomas Goirand wrote: > P.S: Still, my question remains: who should I contact? Geez, is it so hard to point a browser to backports.org and click on "mailing lists", which points to http://lists.backports.org/mailman/listinfo? Is it so much easier to pester _TWO_ completely unrelated mailing lists instead of doing two seconds of own research? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Symlink conffile?
On Tue, Apr 24, 2007 at 08:26:29PM +0200, Marc Haber wrote: > From: Marc Haber <[EMAIL PROTECTED]> > Subject: Symlink conffile? I apologize for hijacking a thread, I forgot to remove the In-Reply-To:-Header from my outgoing message. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Symlink conffile?
Hi, given the case that a conffile was moved from /etc/conffile to /etc/package/conffile. I would now like to include a transition symlink to my package. When I go the easy way, just including the symlink in the package, debhelper does not mark the link a conffile, and every /etc/conffile that might be present on the local system gets unceremoniously overwritten during package installation, causing blatant data loss. When I flag the symlink manually as a conffile, the package in uninstallable: "dpkg: error processing $PACKAGE (--install): unable to change ownership of new dist ocnffile '/etc/conffile.dpkg-new': No such file or directory. Policy does not mention any issues with symlinks as conffiles, and I didn't find an appropriate bug filed against dpkg. What to do here? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
build two binary packages with different configure parameters
Hi, I have a package which uses debhelper at build time, and is built by a rather simple configure - make - make install triathlon. As it fails badly on xen, the xen people ask to provide a xen-enabled binary package. Thus, I need to build the package once with a normal configure, and a second time with configure --with-extra-libs=foo. The rest of the build process is identical. All packages that I have seen which do this duplicate the entire build process in debian/rules by having configure-foo, configure-bar, build-foo, build-bar, install-foo and install-bar targets along with all stamps explicitly doubled. I hate the idea of having to do this with my package just to have a single different configure call. Is there any more elegant way to do this? If so, which package uses it that I can steal from? Any hints will be appreciated. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build two binary packages with different configure parameters
[I apologize for leaving this for two weeks, I moved house in the mean
time and was not online for a terrible lot of time]
On Sat, May 05, 2007 at 10:44:19AM -0400, Justin Pryzby wrote:
> On Sat, May 05, 2007 at 03:07:53PM +0200, Marc Haber wrote:
> > I have a package which uses debhelper at build time, and is built by a
> > rather simple configure - make - make install triathlon. As it fails
> > badly on xen, the xen people ask to provide a xen-enabled binary
> > package.
> >
> > Thus, I need to build the package once with a normal configure, and a
> > second time with configure --with-extra-libs=foo. The rest of the
> > build process is identical.
> >
> > All packages that I have seen which do this duplicate the entire build
> > process in debian/rules by having configure-foo, configure-bar,
> > build-foo, build-bar, install-foo and install-bar targets along with
> > all stamps explicitly doubled. I hate the idea of having to do this
> > with my package just to have a single different configure call.
> >
> > Is there any more elegant way to do this? If so, which package uses it
> > that I can steal from?
>
> vim is referenced as a prototype for multiple binary packages with
> different compilation variations. It's perhaps not clear from the
> large rules, but it really does handle 10+ such packages, and only
> calls configure once ("configure-stamp-%:", this is quite probably not
> portable make) and this includes a "make clean" to remove the
> earlier-compiled binaries objects and such for compilation of the
> current binary.
I agree that vim's build system is rather elegant. However, I fail to
see how to handle the case where the upstream sources are not in a
dedicated directory which can conveniently be moved away after
building a variant.
I feel that the vim package might be "a number too large" to handle
this.
Any more hints?
> Usually make is supposed to be as parallelized as possible; as such,
> rules that call $(MAKE) again are pretty inelegant. However, for this
> case, you want to avoid parallelizing it: the compilations must be
> serial not concurrent.
Yes. I assume that all packages that build multiple variants of a
package do so sequentially.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build two binary packages with different configure parameters
On Mon, May 21, 2007 at 11:26:02AM +0200, Miriam Ruiz wrote: > I had to do something like that for ultrastar-ng. I created two different > directories, called configure from inside each of them with the proper > different parameters and had to duplicate the make and make install. Dunno > if it's not elegan enough, but I didn't want to make it too complex. You > might want to have a look at it. There's nothing special in it anyway. I finally stole a quite elegant solution from mrxvt. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
remove a debconf template
Hi, where can I read up about what I have to do when I remove a debconf template and question from a package in a new release? I suspect that I need to clean up the debconf database manually. Is there any package where I can steal from? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
How to build flavored package if upstream doesn't grok OOT build
Hi,
I am trying to package the authoritative PowerDNS server in a way that
allows Upstream to use my packaging as well. Additional to the normal
dynamically linked builds, they would like to have a statically linked
binary package as well, which should not be in Debian but only in
their builds.
To ease my work load, I would like to be able to build both the Debian
and the Upstream .debs from the same packaging. The Debian packaging
uses dh, and the canonical way to do multi-flavored builds would be
this, as far as I know:
#!/usr/bin/make -f
PACKAGE = pdns
OOT = --builddirectory=build
backends_dyn := ldap pipe gmysql gpgsql gsqlite gsqlite3 geo lua
backends_sta := pipe gmysql gpgsql gsqlite gsqlite3 geo lua
DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
%:
dh $@ --with autotools_dev,autoreconf --parallel
override_dh_auto_configure:
dh_auto_configure $(OOT)-dyn -- \
--host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr \
--sysconfdir=/etc/powerdns \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--libdir='$${prefix}/lib/powerdns' \
--libexecdir='$${prefix}/lib' \
--with-dynmodules="$(backends)" \
--with-modules="" \
--with-pgsql-includes=`pg_config --includedir` \
--with-mysql-lib=/usr/lib/$(DEB_HOST_MULTIARCH) \
--with-boost=/usr \
--enable-cryptopp \
--disable-recursor
dh_auto_configure $(OOT)-sta -- \
--host=$(DEB_HOST_GNU_TYPE) \
--build=$(DEB_BUILD_GNU_TYPE) \
--prefix=/usr \
--sysconfdir=/etc/powerdns \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--libdir='$${prefix}/lib/powerdns' \
--libexecdir='$${prefix}/lib' \
--with-dynmodules="" \
--with-modules="$(backends)" \
--with-pgsql-includes=`pg_config --includedir` \
--with-mysql-lib=/usr/lib/$(DEB_HOST_MULTIARCH) \
--with-boost=/usr \
--enable-cryptopp \
--disable-recursor \
--enable-static-binaries
override_dh_auto_build:
$(MAKE) -C build-sta
$(MAKE) -C build-dyn
override_dh_auto_install:
$(MAKE) -C build-sta/ install DESTDIR=$(CURDIR)/debian/tmp-sta
$(MAKE) -C build-dyn/ install DESTDIR=$(CURDIR)/debian/tmp-dyn
override_dh_install:
dh_install -p$(PACKAGE)--sourcedir=debian/tmp-dyn
dh_install -p$(PACKAGE)-static --sourcedir=debian/tmp-sta
# pdns-server has a debug package
override_dh_strip:
dh_strip --dbg-package=pdns-server-dbg
Unfortunately, this does not work, as Upstream's build mechanics do
not seem to handle out-of-tree building. I have already asked them to
fix their build mechanics, but in the mean time I would like to
continue as the freeze is approaching.
How can I build two flavors of a program with different configure
parameters if upstream does not properly handle out-of-tree building
and I do not want to ditch dh?
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120623131738.ga16...@torres.zugschlus.de
Re: How to build flavored package if upstream doesn't grok OOT build
On Sat, Jun 23, 2012 at 03:23:03PM +0200, Arno Töll wrote: > On 23.06.2012 15:17, Marc Haber wrote: > > How can I build two flavors of a program with different configure > > parameters if upstream does not properly handle out-of-tree building > > and I do not want to ditch dh? > > You copy the source tree as a preparation and recurse into all flavors > for the configure/build/(install) stages. Take a look at the Apache 2.2 > source package for a (complex) example. Thanks. Thinking about it, it seems obvious. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120623142447.gb16...@torres.zugschlus.de
Moving /home of a package account, and to where?
Hi,
Debian QA decided recently that it is bad to have a system/package
account created with its home directory in /home/package, as it is
adduser --system's default btw. I am therefore faced with having to
change /home to some non-/home place. Unfortunately, policy does not
give any hint about how to do it right.
Where do I put my user's home directory? In this case, the user's home
directory contains a .ssh with known_hosts, authorized_keys and actual
keys and it might additionally accumulate some regular dotfiles.
(1)
Which is the correct place for a user's home dir?
/etc/ or /etc//home
- surprise for a seasoned admin
- might create QA bugs regarding "package does not properly clean up
after itself"
- might create dpkg-conffile hassle for files that are bound to
automatically change during operation, such as known_hosts
/var/lib/
- impossible to use ("users must never need to modify files in
/var/lib to configure a package's operation", FHS)
/var/cache/ / /var/spool
- inapprorpiate via FHS
/var/run
- inappropriate as /var/run is cleared during boot
So, /etc looks like the only feasible way for a package that needs
configuration files in its users' home directory. Is that the case or
am I missing things?
For a package that has never been part of a Debian stable release, it
is ok to just change the home directory in the maintainer script,
causing existing installations (5, regarding to popcon) to still use
the old, "inappropriate" location (with a NEWS.Debian suggesting a
manual change), or do I _really_ need to prompt the user whether he
wants his old data to be moved, forcing me to handle gazillions of
translation and debconf-related bugs?
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120701104448.ge25...@torres.zugschlus.de
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 01:04:17PM +0100, Roger Leigh wrote: > On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote: > > Debian QA decided recently that it is bad to have a system/package > > account created with its home directory in /home/package, as it is > > adduser --system's default btw. I am therefore faced with having to > > change /home to some non-/home place. Unfortunately, policy does not > > give any hint about how to do it right. > > > > Where do I put my user's home directory? In this case, the user's home > > directory contains a .ssh with known_hosts, authorized_keys and actual > > keys and it might additionally accumulate some regular dotfiles. > > I'd go with /var/lib, which is what most packages do. I don't count > the user-specific stuff to be package configuration, in general. .ssh is used to log in to another system running my package, it holds manually created authorized_keys and keys. I'd call that configuration. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701125613.gf25...@torres.zugschlus.de
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 02:53:20PM +0200, Goswin von Brederlow wrote: > If you need configuration files (which the user is supposed to edit as > supposed to calling some config tool) in the users home directory and > also automatically changing files then I'm afraid you will need to use > both /etc and /var/lib and symlinks. sshd won't honor a symlinked authorized_keys, would it? > Maybe think about patching the source so that it reads a system wide > file as well as a users file. sshd??? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701125752.gg25...@torres.zugschlus.de
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 02:29:05PM +0100, Roger Leigh wrote: > On Sun, Jul 01, 2012 at 02:56:13PM +0200, Marc Haber wrote: > > On Sun, Jul 01, 2012 at 01:04:17PM +0100, Roger Leigh wrote: > > > On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote: > > > > Debian QA decided recently that it is bad to have a system/package > > > > account created with its home directory in /home/package, as it is > > > > adduser --system's default btw. I am therefore faced with having to > > > > change /home to some non-/home place. Unfortunately, policy does not > > > > give any hint about how to do it right. > > > > > > > > Where do I put my user's home directory? In this case, the user's home > > > > directory contains a .ssh with known_hosts, authorized_keys and actual > > > > keys and it might additionally accumulate some regular dotfiles. > > > > > > I'd go with /var/lib, which is what most packages do. I don't count > > > the user-specific stuff to be package configuration, in general. > > > > .ssh is used to log in to another system running my package, it holds > > manually created authorized_keys and keys. I'd call that configuration. > > Yes, but it's user configuration not system configuration. A system user's .ssh is user configuration? > If you do want to have that as configuration in /etc, I'd > suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys > (or vice versa), like e.g. postgresql handles cluster configuration. Can you give a more visible example? Should /etc/foo/authorized_keys be a symlink to /var/lib/foo/home/.ssh/authorized_keys? I don't think that circumvents the FHS forbidding configuration in /var/lib just by making it accessible through /etc. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701151308.gj25...@torres.zugschlus.de
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 12:36:41PM -0300, Henrique de Moraes Holschuh wrote: > On Sun, 01 Jul 2012, Marc Haber wrote: > > > Yes, but it's user configuration not system configuration. > > > > A system user's .ssh is user configuration? > > If it is intended to be manipulated by the local admin, yes, and it would > belong in /etc somewhere. I would call that system configuration. > > > If you do want to have that as configuration in /etc, I'd > > > suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys > > > (or vice versa), like e.g. postgresql handles cluster configuration. > > > > Can you give a more visible example? Should /etc/foo/authorized_keys > > be a symlink to /var/lib/foo/home/.ssh/authorized_keys? I don't think > > that circumvents the FHS forbidding configuration in /var/lib just by > > making it accessible through /etc. > > No. The real file goes in /etc, the symlink goes in /var/lib. But you may > need very tight permissions in the directory that hosts these to have sshd > tolerate it, if it will work at all. Does sshd honor symlinks when looking for authorized_keys? I am really really astonished about with which ease we hurl RC bugs at packages without having thought-out alternatives. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701160358.gk25...@torres.zugschlus.de
Re: Moving /home of a package account, and to where?
On Mon, Jul 02, 2012 at 10:03:08PM +1000, Sven Dowideit wrote: > On 02/07/12 02:03, Marc Haber wrote: > >I am really really astonished about with which ease we hurl RC > >bugs at packages without having thought-out alternatives. > Would it not be better to reject the Debian QA 'suggestion' until > such time as its documented thoroughly in the Packaging manual? That will kick the package out of testing and stable. Not desireable. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702081105.gf31...@torres.zugschlus.de
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 07:53:04PM -0700, Russ Allbery wrote: > It would indeed be best if everything possible was documented, but very > few people volunteer to do the work to drive changes to the documentation > through to completion. This is partly because of the kind-of heavy-handed policy editorial process. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120702081214.gg31...@torres.zugschlus.de
Maintainer address for collab-maint team maintained packages
Hi,
I am participating in a team-maintained package which is hosted on
collab-maint. We would like to have the Maintainer: address of that
package to forward to all members of the team, preferably by setting
an address there that forwards to the PTS, having team members and
other interested parties subscribed there.
This seems to be harder to do than I imagined.
@packages.qa.debian.org wants a certain header to be set for
the message to be forwarded.
@packages.debian.org seems to add that header automatically
before forwarding to the PTS, but using that address as Maintainer: is
a lintian _error_ (not even a warning) ("Severity: serious, Certainty:
certain").
There do not seem to be public mailing lists on the collab-maint
Alioth project.
Do we really need to create a dedicated Alioth project just to get a
mailing list which can be used as Maintainer? Or am I missing a
policy-compliant possibility to do this with available resources?
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121119142855.gh28...@torres.zugschlus.de
Re: Maintainer address for collab-maint team maintained packages
On Mon, Nov 19, 2012 at 05:34:58PM +, Bart Martens wrote: > On Mon, Nov 19, 2012 at 03:28:55PM +0100, Marc Haber wrote: > > I am participating in a team-maintained package which is hosted on > > collab-maint. > > Which package ? If that has anything to do with it, it's libopendbx, which has not yet been pushed to collab-maint. > > We would like to have the Maintainer: address of that > > package to forward to all members of the team, > > Why would you want to do that ? I mean, is the package you work on related to > all other maintainers maintaining other packages in collab-maint ? Misunderstanding, either accidental or deliberate. I want the Maintainer address to forward to all people listed in Uploaders: of the respective package, not to all 519 members of the collab-maint Alioth project. I am not out of my mind. > http://wiki.debian.org/Teams/CollabMaint > "not connected to any other teams" I believe that I am working well within the definition of collab-maint, thanks for trying to ask in a very subtle way. > Would modifying lintian be a solution for your problem ? Probably not, since the people behind lintian usually have sound reasons for putting in errors and warnings, especially such with Certainty: certain. > > There do not seem to be public mailing lists on the collab-maint > > Alioth project. > > Does this one not work ? > http://lists.alioth.debian.org/mailman/listinfo/collab-maint-devel > "To post a message to all the list members, send email to > collab-maint-de...@lists.alioth.debian.org." https://alioth.debian.org/projects/collab-maint/ "Mailing Lists (0 public mailing lists)" > > Do we really need to create a dedicated Alioth project just to get a > > mailing list which can be used as Maintainer? Or am I missing a > > policy-compliant possibility to do this with available resources? > > I agree that creating an Alioth project just for the mailing list feels > somewhat uncomfortable. Indeed. Greetings Marc, now tryin to bring blood pressure down again -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121119175108.gk28...@torres.zugschlus.de
Re: Maintainer address for collab-maint team maintained packages
On Mon, Nov 19, 2012 at 06:54:26PM +0100, Arno Töll wrote: > Thing is, you can't use the QA forwarder because it relies on your > source control field to learn about actual forwardings. If you would add > right that address, the result would be an infinite loop because you > would essentially forward mail to @packages.debian.org to > @packages.debian.org. I hope it is clear why this won't work. so @packages.debian.org forwards to all addresses listed in Maintainer: and Uploaders: of the package in question, while @packages.qa.debian.org forwards to all addresses that are subscribed in the PTS and to @packages.debian.org? If that's the case, then the obvious fix would be to have @packages.debian.org not forward to @packages.debian.org and to have the PTS forbid forwardings to @packages.debian.org. That way, it would be possible to use @packages.debian.org in Maintainer:. I don't see anything wrong about this, but maybe I am missing something. In the mean time, I'll request an alioth project. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121127095659.gz28...@torres.zugschlus.de
Re: RFS: jetty6
On Fri, Jun 12, 2009 at 09:32:40PM +0100, Ludovic Claude wrote: > I am looking for a sponsor for my package "jetty6". > > * Package name: jetty6 > Version : 6.1.18-1 > Upstream Author : [fill in name and email of upstream] > * URL : [fill in URL of upstreams web site] > * License : [fill in] > Section : java Is the package as incomplete as the information above? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Please review internal package using a lot of "new" tools
Hi, for an internal package of the Nagios plugin check_multi, I decided to familiarize myself with some new tools (debhelper 7, 3.0 format, quilt, git etc). The package itself is not going to be in Debian since the Nagios team has decided to place check_multi into the existing nagios-plugin package. I would like to have, nevertheless, some feedback whether I have used the "new" tools correctly or whether I can improve things. So far, I like the new approach and will most probably use it for new packages. The package is available for download at http://q.bofh.de/~mh/debian/nagios-plugin-check-multi/, and the git repository can be cloned from http://q.bofh.de/~mh/debian/nagios-plugin-check-multi/git I would appreciate if you could comment. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010051454.ga10...@torres.zugschlus.de
Re: Preventing init script start during package install
On Sun, May 23, 2010 at 06:53:04PM +0300, Zaar Hai wrote: > I have a package that contain init script. When I install it, dpkg > always brings the service up in the end (I'm using Debian Lenny). How > can I prevent him to do so? If you're the package maintainer, adapt your postinst not to start the service. If you're a user, you should have asked the question on debian-user (debian-mentors is the mailing list to discuss packaging issues), and the manpage for invoke-rc.d has your answer in its init script policy section. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100523155907.ge23...@torres.zugschlus.de
Re: Please review internal package using a lot of "new" tools
Hi,
I really appreciate your comments.
On Sun, May 23, 2010 at 11:12:40AM +0800, Paul Wise wrote:
> On Sun, May 23, 2010 at 6:14 AM, Marc Haber
> wrote:
>
> > I would appreciate if you could comment.
>
> dh --with-quilt isn't needed if you're using dpkg-source v3
ok, removed.
> If you call dh_auto_configure -- ... instead of ./configure ... it
> will add --prefix for you.
Done.
> The test parts of override_dh_auto_build should go into
> override_dh_auto_test.
Done.
> In dh_auto_install, does upstream's Makefile not support DESTDIR?
Sadly, incorrectly.
make install DESTDIR=$(CURDIR)/debian/${PACKAGENAME}
places the executeable in
debian/nagios-plugin-check-multi/usr/lib/nagios-plugin-check-multi/check_multi,
ignoring the setting for libexecdir given on the configure command
line.
make install DESTDIR=$(CURDIR)/debian/${PACKAGENAME} \
LIBEXECDIR=/usr/lib/nagios/plugins
seems to do the trick, but I am not too sure whether this is really
better than the way I did things in the demo package.
Is it common that DESTDIR= needs an absolute path ($(CURDIR)
prepended)? If I don't do this, the executeable is not even placed in
the package, but in plugins/debian/nagios-plugin-check-multi/...
> You can use $(CURDIR) instead of $(shell pwd), that will save a few
> process spawnings.
Done.
> I also note that it uses /tmp/check_multi and wonder if that enables
> any symlink attacks.
That is configurable. I could probably create
/var/cache/nagios-plugin-check-multi in postinst and use that as
tmpdir. Better idea?
Thanks again.
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100523182134.gf23...@torres.zugschlus.de
Re: Preventing init script start during package install
On Sun, May 23, 2010 at 10:03:51PM +0300, Zaar Hai wrote: > On Sun, May 23, 2010 at 6:59 PM, Marc Haber > wrote: > > On Sun, May 23, 2010 at 06:53:04PM +0300, Zaar Hai wrote: > >> I have a package that contain init script. When I install it, dpkg > >> always brings the service up in the end (I'm using Debian Lenny). How > >> can I prevent him to do so? > > > > If you're the package maintainer, adapt your postinst not to start the > > service. If you're a user, you should have asked the question on > Yes, I'm the maintainer. The problem is that I do not do anything in > postinst script to start the service. It looks like dpkg just adds > this behaviour automagically. Can you provide any hint? If you have dh_installinit, use --noscripts and have a good reason for not starting the service automatically. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100523191244.gh23...@torres.zugschlus.de
Re: Please review internal package using a lot of "new" tools
Hi,
On Mon, May 24, 2010 at 09:27:29AM +0800, Paul Wise wrote:
> On Mon, May 24, 2010 at 2:21 AM, Marc Haber
> wrote:
> > On Sun, May 23, 2010 at 11:12:40AM +0800, Paul Wise wrote:
> >> In dh_auto_install, does upstream's Makefile not support DESTDIR?
> >
> > Sadly, incorrectly.
> > make install DESTDIR=$(CURDIR)/debian/${PACKAGENAME}
> > places the executeable in
> > debian/nagios-plugin-check-multi/usr/lib/nagios-plugin-check-multi/check_multi,
> > ignoring the setting for libexecdir given on the configure command
> > line.
> > make install DESTDIR=$(CURDIR)/debian/${PACKAGENAME} \
> > LIBEXECDIR=/usr/lib/nagios/plugins
> > seems to do the trick, but I am not too sure whether this is really
> > better than the way I did things in the demo package.
>
> Sounds like a buggy configure.ac or Makefile.am.
I have already reported that upstream and have not yet recived a reply.
> > Is it common that DESTDIR= needs an absolute path ($(CURDIR)
> > prepended)? If I don't do this, the executeable is not even placed in
> > the package, but in plugins/debian/nagios-plugin-check-multi/...
>
> Not really sure to be honest.
I'll take a look at this in other packages and will probably report
this upstream as well.
> >> I also note that it uses /tmp/check_multi and wonder if that enables
> >> any symlink attacks.
> >
> > That is configurable. I could probably create
> > /var/cache/nagios-plugin-check-multi in postinst and use that as
> > tmpdir. Better idea?
>
> Definitely.
I have done this in the package now.
> Getting upstream/nagios3 to use a better default would be good too.
Will be reported once I have established contact with upstream.
I have uploaded a new package to
http://q.bofh.de/~mh/debian/nagios-plugin-check-multi/, and the git
repository can again be cloned from
http://q.bofh.de/~mh/debian/nagios-plugin-check-multi/git
I would like to solicit comments about the contents of the git
repository with regard to branches, upstream etc. I am not yet too
comfortable with git.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100524085354.gi23...@torres.zugschlus.de
Re: Preventing init script start during package install
Hi, On Sun, May 23, 2010 at 10:54:35PM +0300, Zaar Hai wrote: > On Sun, May 23, 2010 at 10:12 PM, Marc Haber > wrote: > > If you have dh_installinit, use --noscripts and have a good reason > > for not starting the service automatically. > Thanks! I'll try that out (looks like I'll need to some CDBS diving :). I guess that CDBS allows you to provide additional parameters for the dh_installinit call. Not having used advanced CDBS in a while, I cannot give more useful advice. > I do not want to start script, since I usually do upgrade right before > making disk 'ghost'. So I have to terminate the service immediately > right after dpkg starts it; but the service starts to process jobs, > which have to be aborted and recovered then. Does it sound like a good > reason? Is that workflow valid for all users of your package? If so, it is a valid approach; if not, you could prevent start of your service locally on your systems by an apporpriate policy-rc.d layer. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100524092610.gm23...@torres.zugschlus.de
Re: Please review internal package using a lot of "new" tools
On Mon, May 24, 2010 at 11:21:17PM +0900, Osamu Aoki wrote: > On Mon, May 24, 2010 at 10:53:54AM +0200, Marc Haber wrote: > > Hi, > > > > On Mon, May 24, 2010 at 09:27:29AM +0800, Paul Wise wrote: > > > On Mon, May 24, 2010 at 2:21 AM, Marc Haber > > > wrote: > > > > On Sun, May 23, 2010 at 11:12:40AM +0800, Paul Wise wrote: > > I have uploaded a new package to > > http://q.bofh.de/~mh/debian/nagios-plugin-check-multi/, and the git > > I see > > override_dh_auto_build: > make all > > > Is not this better to do > > override_dh_auto_build: > dh_auto_build -- all > > Then some extra features offered by dh_auto_build is preserved while > specifying build target. DH_OPTIONS=-v, DH_VERBOSE=1 ... Applied, thanks. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100524152814.ga20...@torres.zugschlus.de
git-buildpackage and multiple source tarballs
Hi, I have a small package which is currently in the process to being converted to 3.0 (quilt) with multiple original tarballs, thanks to upstream's decision to ship the single 31 KB manpage in its own tarball. I maintain the Debian packaging in git and used to use git-buildpackage. Do I see correctly, that git-buildpackage, git-import-orig etc do only have limited support for handling multiple upstream tarballs? Which workflow is recommended to handle this? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100613200823.ge23...@torres.zugschlus.de
debhelper 7 and architecture dependent/independent packages
Hi, I have a package which builds one architecture dependent and one architecture independent binary package and uses dephelper 7. Due to the weird and kind of incomplete upstream build code, I had to override the dh_autoinstall target with an override_dh_auto_install target in my debian/rules. However, when the buildd uses --binary-arch, my override_dh_auto_install fails when it tries to install files into the architecture-independent part of the package, probably due to the directories listed in debian/indep-binary-package.dirs not having been created since we are running with --binary-arch. override_dh_auto_install_indep does not seem to be available. How do I specify "install"-type operations that are only to take place when building architecture (in)dependent packages? If I need to specify my own install-indep and install-arch stanzas in my debian/rules, is there a possibility to jump back into debhelper 7's automatic behavior after doing my local things? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110411134537.gh10...@torres.zugschlus.de
Re: debhelper 7 and architecture dependent/independent packages
On Mon, Apr 11, 2011 at 05:20:32PM +0200, Ansgar Burchardt wrote: > Marc Haber writes: > > I have a package which builds one architecture dependent and one > > architecture independent binary package and uses dephelper 7. Due to > > the weird and kind of incomplete upstream build code, I had to > > override the dh_autoinstall target with an override_dh_auto_install > > target in my debian/rules. > > I had similar problems myself and stopped using override_* targets for > commands that should only run when building the arch-indep packages. > Instead I now use > > --8<---cut here---start->8--- > %: > dh $@ > > binary-indep: > dh --before dh_install $@ > dh_install -i > find debian/btanks-data/ -type f -print0 | xargs -0 chmod 0644 > dh --remaining $@ > > binary: binary-arch binary-indep > --8<---cut here---end--->8--- > > (taken from btanks with the additional override_* targets stripped) Thank you very much, this worked for me. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110412071407.gb1...@torres.zugschlus.de
Re: RFS: taxbird (updated package)
On Sun, Jul 10, 2011 at 10:52:08PM +0100, Michael Tautschnig wrote: > > I am looking for a sponsor for the new version 0.16-0.1 > > of the package "taxbird". > > > > It builds these binary packages: > > taxbird- The first free Elster client (German Tax Declarations) > > > [...] > > Could you please briefly explain why you are NMUing this package? Are you > intending to take over package maintainership? What about the previous > maintainer? I am neither the previous mantainer not the person seeking sponsorship, but I wholeheartedly support an upload of Taxbird. Taxbird is a software that needs to be updated yearly to be usable, and the last upload of taxbird was in February 2002. Taxbird is unuseable to file tax declarations at the moment since it lacks 2011 support. See #619734, which has, however, recently seen Maintainer Activity, where the Maintainer has indicated on May 10 that "uploading to unstable will also be done in a few days." Cc: ing this bug report. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110711070803.gc27...@torres.zugschlus.de
Re: RFS: gentoo (New upstream version: package already in Debian).
On Tue, Sep 13, 2011 at 04:17:12PM +0200, Innocent De Marchi wrote: > I am looking for a sponsor for my package "gentoo". > > * Package name: gentoo >Version : 0.19.11-1 >Upstream Author : Emil Brink > * URL : http://www.obsession.se/gentoo/ > * License : GPL-2+ >Section : x11 > > It builds those binary packages: > > gentoo - Fully GUI-configurable, two-pane X file manager I would strongly suggest choosing a different name, due to the identically named Linux distribution. Greeting Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110913143538.gf22...@torres.zugschlus.de
How to rename a ucf-conffile?
Hi, the PowerDNS packages have shipped configuration in /etc/powerdns/pdns.d/foo, with the pdns.d functionality patched in by Debian. Upstream has recently followed our wishlist request to implement include-dir functionality in PowerDNS proper. However, they require all files in an include-dir directory to be named foo.conf, which we did not do in the past. The PowerDNS packages use ucf to manage their conffiles, and we thus need to rename them. Is this really as easy as if [ -e /etc/powerdns/pdns.d/pdns.local ]; then if [ -e /etc/powerdns/pdns.d/pdns.local.conf ]; then *bomb out* exit 1 fi ucfr --purge pdns-server /etc/powerdns/pdns.d/pdns.local mv /etc/powerdns/pdns.d/pdns.local /etc/powerdns/pdns.d/pdns.local.conf ucf /usr/share/powerdns/pdns.local.conf /etc/powerdns/pdns.d/pdns.local.conf ucfr pdns-server /etc/powerdns/pdns.d/pdns.local.conf fi or will this break in some situations? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130702194211.gc3...@torres.zugschlus.de
Re: How to rename a ucf-conffile?
On Tue, Jul 02, 2013 at 10:38:25PM +0200, Paul Gevers wrote: > On 02-07-13 21:42, Marc Haber wrote: > > Is this really as easy as > > > > if [ -e /etc/powerdns/pdns.d/pdns.local ]; then > > if [ -e /etc/powerdns/pdns.d/pdns.local.conf ]; then > > *bomb out* > > exit 1 > > fi > > ucfr --purge pdns-server /etc/powerdns/pdns.d/pdns.local > > mv /etc/powerdns/pdns.d/pdns.local /etc/powerdns/pdns.d/pdns.local.conf > > ucf /usr/share/powerdns/pdns.local.conf > > /etc/powerdns/pdns.d/pdns.local.conf > > ucfr pdns-server /etc/powerdns/pdns.d/pdns.local.conf > > fi > > > > or will this break in some situations? > > I recently thought about it for cacti. Maybe you can find the answer here: > http://anonscm.debian.org/gitweb/?p=pkg-cacti/cacti.git;a=commit;h=5c8640af6857fb5660d89e5291f84994c730b3da That code was only added in May, with 0.8.8a+dfsg-6, right? Do you feel that it has gotten enough test coverage to snarf it yet? Did you on purpose decide not to bomb out if the new file does already exist? > One point I tried to assure is that maybe the admin has removed the file > and you want to honor that (i.e. let ucf/ucfr know that the file is > removed). Maybe it could be done better, but this seemed to work. Good point. The code you have written will probably ask the user a question about $newfile and then zap the file. Is this intended? Why not ucf --debconf-ok /dev/null $newfile? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130703075824.ga26...@torres.zugschlus.de
Re: How to rename a ucf-conffile?
On Wed, Jul 03, 2013 at 10:26:39AM +0200, Paul Gevers wrote: > On 03-07-13 09:58, Marc Haber wrote: > > Did you on purpose decide not to bomb out if the new file does already > > exist? > > Yes. In my case it would mean that the admin already created a file with > the proposed new name, AND left the old name in place. As these files > are only in the "conf-available" folder, it doesn't hurt there. The > admin seems to know what he is doing. This doesn't mean that it works > for you though. I will probably spew a warning and continue. > > The code you have written will probably ask the user a question about > > $newfile and then zap the file. Is this intended? Why not ucf > > --debconf-ok /dev/null $newfile? > > If I remember correctly, you don't get any question, because ucf > considers the file new and does not need to ask anything. I would expect > that this way (rm -f immediately afterwards) it does not matter what > source you use, and yours might just be clearer at the intension. Could > you test and let me know? I think you're right here. Thanks for explaining. Greetings Ma "need more coffee" rc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130703082924.gb26...@torres.zugschlus.de
How to rename^wremove a ucf-conffile?
Hi, after Paul was so kind to show me some sample code to rename an ucf-conffile, I am now faced with the task of deleting an ucf-conffile with a package update. My first (untested) approach would be: FILENAME="/etc/foo/bar.conf" if [ -e "$FILENAME" ]; then ucf --debconf-ok /dev/null $FILENAME if [ -s "$FILENAME" ]; then rm -f $FILENAME fi fi ucfr --purge $PKGNAME $FILENAME That way, the user would get an ucf prompt to replace the file with an empty file, and if she decides to do this, the file would be entirely removed. If she decides to keep her non-empty file, it would remain on the system. In any case, it would be deregistered from ucf. Did I miss a case? Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130728100012.gb18...@torres.zugschlus.de
lintian W: sharedobject-in-library-directory-not-actually-a-shlib
Hi, for one of my packages, later lintian versions emit a Warning saying: W: snoopy: sharedobject-in-library-directory-not-actually-a-shlib lib/snoopy.so Unfortunately, I am not too clueful about binary libraries, sonames and that stuff and do not even understand the lintian --info output. The Package in question only has a simple lib/snoopy.so without any version numbers in it. That library is meant to be preloaded via ld.so.preload, so there won't be multiple versions available to choose anyway. Can someone please enlighten me or point me to the relevant docs? Thanks! Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: lintian W: sharedobject-in-library-directory-not-actually-a-shlib
On Sat, 26 Jul 2003 14:42:48 +0900, Junichi Uekawa <[EMAIL PROTECTED]> wrote: >> Lintian, however, can't know that this particular library usually is >> preloaded, not linked to. Hence the override. > >If its use is going to be something like that, please don't put it in >/usr/lib. That's what the lintian warning is about. Where should it be put instead? Please notice that this can potentially be preloaded early, hence it is currently in /lib. Greetings Marcc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: creating your own debian package repository
On Wed, 20 Aug 2003 23:51:27 -0400, "Christopher W. Curtis" <[EMAIL PROTECTED]> wrote: >A poor man's version would be: "man dpkg-scanpackages" apt-ftparchive does a better job than dpkg-scanpackages. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
How to include symlinks to conffiles in a package?
Hi, I am currently working on a package that needs to mimic sysvinit's symlink farm. I have a bunch of scripts put into /etc/network/if.d which are in turn symlinked to /etc/network/if-$NAME.d for different values of $NAME. I'd like to have the symlinks in the package as conffiles, but dpkg doesn't seem to like that. The symlinks are not unpacked. After playing with dpkg --unpack and manually configuring the package I suspect the following: - dpkg unpacks conffiles with the file name suffix dpkg-new - It then deletes all stale symlinks - and then renames foo.dpkg-new to foo after resolving conflicts Since the unpacked symlinks point to the unsuffixed file name, they are all considered stale and deleted. Is there a recommended way to handle this? I'd like to avoid shipping a symlink list file and to generate the links in postinst. Any hints will be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Need help: autoreconf breaks library package?
Hi, linux-atm_2.4.9 in unstable builds fine. Upstream uses kind of ancient autotools. I am currently trying to include br2684 from the upstream CVS into my package. To have br2684 built, I need to re-build the makefiles. So I install automake and autoconf, and run autoreconf. After autoreconf, the package still builds without any error message, but the library files are missing the .so suffix. This is b0rken. This can be reproduced on current sid using the procedure described above. Since I don't have too much clue about the autotools, I cannot solve this problem myself. Can anybody help? Thank you very much. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Need help: autoreconf breaks library package?
On Sat, 18 Oct 2003 21:14:39 +0200, Marc Haber <[EMAIL PROTECTED]> wrote: >I am currently trying to include br2684 from the upstream CVS into my >package. To have br2684 built, I need to re-build the makefiles. So I >install automake and autoconf, and run autoreconf. > >After autoreconf, the package still builds without any error message, >but the library files are missing the .so suffix. This is b0rken. The reason for this failure was that upstream built the package with libtool 1.4, and unstable has libtool 1.5. Some remains of libtool 1.4 were still left in the package. I had to autoreconf with -i -f to make the package build OK again. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: recommended sid upgrade method
On Wed, 19 Nov 2003 16:33:08 +, Colin Whittaker <[EMAIL PROTECTED]> wrote: >We do something similar on all of our servers and wrote a very simple >little cronjob for it and have packaged it. > >Package is apticron and is available from http://apt.heanet.ie Did you do more than re-inventing cron-apt? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: How to deal with sql-database structures on upgrade
On Mon, 15 Dec 2003 23:05:12 +0100, Thorsten Sauter <[EMAIL PROTECTED]> wrote: >Cacti use a mysql database to store the configuration values (including >users/password, graphic options, layouts, ...). The new upstream version >(0.8.x) use a completly new designed database structure then the old >version, which is currently already packed for Debian. This sounds like the apache, exim or webrt problem. All three packages have solved that by packaging the new version as $PACKAGE$VERSION (e.g. apache2, exim4). Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: debian/tmp vs. debian/package
On Wed, 19 Nov 2003 15:34:18 -0600, Steve Langasek <[EMAIL PROTECTED]> wrote: >Using debian/tmp has advantages for multi-binary packages, IMHO: it >gives you a way to easily review the contents of that directory after >"./debian/rules binary" to see if upstream has installed anything new >that needs to be added to the file list for one of the packages. If I recall correctly, that was valid for dh_movefiles. Nowadays, this has been replaced by dh_install which does not move but rather copy the files. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Compiling own system
On Mon, 30 Nov 1998 19:54:15 +0100, you wrote: >How important for system's security is having system installed from self >compiled packages? Some time ago a friend asked me, how many of packacges do I >have compiled by me, and he expected I say him "almost all". What do you think >about it? Well, do you check all sources (including the kernel) that you compile for mailicious code? If you don't, then you might have a trojan even from your self-compiled programs. I'd blindly trust all "official" Debian packages since the maintainers are well-known over the net. Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: Compiling own system
On Mon, 30 Nov 1998 15:30:45 -0800, you wrote: >I don't blindly trust pgp or ssh or gnupg, for obvious reasons. Again, do you inspect the pgp sources before compiling them? If not, how do you make sure that the sources are trustworthy? Greetings Marc -- -- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: HOT OPENINGS IN AUSTIN, TEXAS!!!
On Mon, 14 Feb 2000 15:33:50 -0500, you wrote: >if we keep getting spammed at this rate SPI will be able to afford a spot at >half time for the next superbowl. The really frustrating thing is that lists.debian.org removes Received:-Headers from incoming E-Mail so that one can't even complain about the spam! Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: HOT OPENINGS IN AUSTIN, TEXAS!!!
On Tue, 15 Feb 2000 13:30:20 -0500, Ben Collins <[EMAIL PROTECTED]> wrote: >Return-path: <[EMAIL PROTECTED]> >Envelope-to: [EMAIL PROTECTED] >Delivery-date: Tue, 15 Feb 2000 19:42:15 +0100 >Received: from mx7.gmx.net ([194.221.183.87]) > by q.bofh.de with smtp (Exim 3.12 #1) > id 12KmvP-0002CB-00 > for [EMAIL PROTECTED]; Tue, 15 Feb 2000 19:42:15 +0100 >Received: (qmail 2104 invoked by alias); 15 Feb 2000 18:41:44 - >Delivered-To: GMX delivery to [EMAIL PROTECTED] >Received: (qmail 2064 invoked by uid 0); 15 Feb 2000 18:41:43 - >Received: from murphy.debian.org (209.41.108.199) > by mx7.gmx.net with SMTP; 15 Feb 2000 18:41:43 - >Received: (qmail 17905 invoked by uid 38); 15 Feb 2000 18:38:36 - >Resent-Date: 15 Feb 2000 18:38:36 - >Resent-Cc: recipient list not shown: ; >X-Envelope-Sender: [EMAIL PROTECTED] >Date: Tue, 15 Feb 2000 13:30:20 -0500 >From: Ben Collins <[EMAIL PROTECTED]> >To: Marc Haber <[EMAIL PROTECTED]> >Cc: debian-mentors@lists.debian.org >Subject: Re: HOT OPENINGS IN AUSTIN, TEXAS!!! >Message-ID: <[EMAIL PROTECTED]> >References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >User-Agent: Mutt/1.0i >In-Reply-To: <[EMAIL PROTECTED]>; from [EMAIL PROTECTED] on Tue, Feb 15, 2000 >at 06:32:10PM + >Sender: Ben Collins <[EMAIL PROTECTED]> >Resent-Message-ID: <[EMAIL PROTECTED]> >Resent-From: debian-mentors@lists.debian.org >X-Mailing-List: archive/latest/3756 >X-Loop: debian-mentors@lists.debian.org >Precedence: list >Resent-Sender: [EMAIL PROTECTED] >X-Resent-By: Global Message Exchange <[EMAIL PROTECTED]> >X-Resent-For: [EMAIL PROTECTED] >X-Resent-To: [EMAIL PROTECTED] >X-UIDL: 8fc137cdd190b9e40a7f3c7ed7089fbf > >That is a load of crap. So you wrote that message directly on murphy? Please take a look at my e-mail message <[EMAIL PROTECTED]> that also has its first Received:-Header from murphy. I most certainly didn't write that message on murphy. I don't want to be insulting like you were, but I know my way around E-Mail headers. My employer pays my salary because of that fact. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
how to have conf_dirs_ instead of conffiles?
Hi! I am currently working on a package called ipchains-init which is basically a beefed-up ipmasq with a little more restrictive rules. I have a directory /etc/ipchains.init/ which contains my rule sets as a collection of shell scripts that have links to various state levels of the packet filters. This looks suspiciously like the sysvinit scheme of /etc/init.d/
Re: Having ssh support non-US?
On Tue, 12 Dec 2000 18:01:48 -0500, Matt Zimmerman <[EMAIL PROTECTED]> wrote: >On Tue, Dec 12, 2000 at 08:41:55AM -0500, Adam C Powell IV wrote: >> You might look into making it work with kerberos4kth's krsh/krshd for strong >> authentication >> without the encryption overhead. Unless you really need all communication >> to be encrypted >> (doing classified computations on an untrusted network? :-). > >As far as I know, ssh can be configured to use a null cipher on the channel, >and so only be used for strong authentication. As far as I know, the Debian package doesn't have this compiled in. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
INSTALL.gz with generic installation instructions
Bug #79854 says that I should probably remove INSTALL.gz from my package, presumably because it contains only the "Generic Installation Instructions" that other packages like irssi and findutils contain as well. Is it allowed or desired to exclude documentation from binary packages that are in the source? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: INSTALL.gz with generic installation instructions
On Sat, 6 Jan 2001 15:32:17 +0200, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: >On 20010106T135555+0100, Marc Haber wrote: >> Is it allowed or desired to exclude documentation from binary packages >> that are in the source? > >Of course, if done with taste. The INSTALL file almost never should be >installed (it would not do any good for it to be installed, since the user >does the install in a completely different way, ie. using dpkg or apt). > >See Policy manual section 6.3, last sentence. That's what I have been looking for. Thanks. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
dh_suidregisted and potato/sid packages
Hi, in sid packages, dh_suidregister is not allowed to be used any more. However, I need my own packages mainly under potato, so I am quite interested that they build under potato as well. Are there any standard procedures for this, or am I left with some nasty if constructs in my rules files? Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: dh_suidregisted and potato/sid packages
On Sun, 28 Jan 2001 00:46:23 -0800, Joey Hess <[EMAIL PROTECTED]> wrote: >Marc Haber wrote: >> in sid packages, dh_suidregister is not allowed to be used any more. >> However, I need my own packages mainly under potato, so I am quite >> interested that they build under potato as well. Are there any >> standard procedures for this, or am I left with some nasty if >> constructs in my rules files? > >Um, it's not as simple as just not running dh_suidregister -- when it >refuses to do anything in sid and tells you to read the man page, it >really means it. I see. So I need to actually install a chrooted sid to be able to read the manpage. That'll take a few days until I get around doing so... >I think making such a package that could build under either sid or potato >would be pretty complex because you would have to add/remove conflicts >from the control file on the fly depending on which you were building >for. That sounds nasty, and it probably means that backports of other packages from sid|woody to potato are going to be awfully hard in the future. Right? Greetings Marc -- ------ !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
Re: dh_suidregisted and potato/sid packages
On Sun, 28 Jan 2001 03:17:25 -0800, Joey Hess <[EMAIL PROTECTED]> wrote: >Marc Haber wrote: >> I see. So I need to actually install a chrooted sid to be able to read >> the manpage. That'll take a few days until I get around doing so... > >Um, the man page is available in the source package, by cvs, You're right. >on any one >of the debian projects machines that are running unstable, That doesn't help being stuck in the DAM queue. But your post in devel-announce is quite clear. Thanks. >It affects a limited subset of packages: packages with suid binaries >that used to use suidregister. Yes. The libc transition will cause much more headaches. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
revamp of Net::GrpNetworks with unresponsive upstream?
Hi, a few months ago, I tried packaging the perl module Net::GrpNetworks (http://www.cpan.org/authors/id/A/AR/ARVIEGAS/Net-GrpNetworks-1.08.tar.gz, released November 1999) as a Debian package and found that it is missing two features that I need. I contacted the package's author and got no reply back. Last week, I implemented the features I needed. In the course of this implementation, the internal implementation of the module was completely changed, so that only the "API" remained nearly unchanged. Since upstream is not responding, I am now unsure whether to simply bump the upstream version number, or to make it a whole new package, upload it to CPAN and make my Package from "my" perl package (giving proper credit to GrpNetworks' original author of course). If I upload "my" package to CPAN, would it be okay to leave the debian subdirectory in the tarball, and having an empty Debian patch in the Debian source package? Any hints will be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
How do I depend on a specific kernel version?
Hi, I am currently working on a package that provides the framework to build an IP packet filter based on netfilter / iptables. This needs a 2.4.x kernel. How do I depend on a kernel-image-2.4.x? Next project will be a package that needs 802.1q kernel support. This is a kernel patch. I am aware that there is some infrastructure in debian to support kernel patches and works well with kernel-package. Is this infrastructure documented somewhere on the net? How can I make a package depend on a patched kernel? Any hints will be appreciated. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29
