Re: Changing of behavior: How to tell the user?
On Thu, Jul 17, 2008 at 06:14:51PM +0300, Eugene V. Lyubimkin wrote:
Andreas Tscharner wrote:
Dear Mentors,
cvslockd is started every time. So I created a configuration file
/etc/defaults/cvsnt where an environment variable defines whether or not
the daemon gets started. I figured that there are probably more client
users than server users and set the default to no longer start cvslockd.
My questions:
1) Is this change of behavior desirable/do-able?
I like that change, as I typically install cvsnt and then
rm -fv /etc/rc?.d/S??cvsnt.
2) Is /etc/default/cvsnt the right place to turn on/off the daemon at all?
I think so.
3) How shall I inform the server users that they know that they have to
configure the file to get the lock daemon started again?
for 3) - may be, Debian.NEWS and/or debconf message in postinst?
Another option is to create (only if it doesn't exist, and after doing
a version number comparison with dpkg --compare-versions to see if
this is a version where it should be created) /etc/defaults/cvsnt as a
non-conffile configuration file, with the value CVSNTD determined by:
. if it's an initial installation, no;
. otherwise, detect if cvslockd is running with s-s-d:
postinst:
f=/etc/defaults/cvsnt
v=2.5.03.2382-3.3
[ ! -e $f ] dpkg --compare-versions $2 le $v {
CVSNTD=no
[ -n $2 ] start-stop-daemon --quiet --stop --test -n cvslockd -x
/usr/bin/cvslockd CVSNTD=yes
echo Creating /etc/defaults/cvsnt with CVSNTD=$CVSNTD 2
echo CVSNTD=$CVSNTD $f
}
Perhaps you could do something a bit more sophisticated, instead of
doing [ ! -e $f ] you could do:
grep '^[[:space:]]*CVSNTD' $f /dev/null || {
dpkg --compare=-versions $2 le $v {
CVSNTD=no
[ -n $2 ] start-stop-daemon --quiet --stop --test -n
cvslockd -x /usr/bin/cvslockd CVSNTD=yes
echo Initializing /etc/defaults/cvsnt with CVSNTD=$CVSNTD 2
echo CVSNTD=$CVSNTD $f
}
}
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to detect an upgrade from an older version of a package
On Tue, Jul 15, 2008 at 03:26:53AM +0800, Thomas Goirand wrote: Patrick Schoenfeld wrote: Additional (might be more to his interest, because he talked about his postinst) it says: postinst configure most-recently-configured-version If a package is upgraded the most-recently-configured-version is usually identical to old-version. It isn't if the configuration of the package already took place but the installation hasn't finished (half-installed state). That is as far as I understand it. Anyways using $2 as oldversion worked for me in every case so far. Regards, Patrick In fact, I was being stupid in my question, so I'm asking again. I think it's best option for me to know from what version I'm upgrading from at the configure stage, so I can prompt a nice debconf dialog and ask: Do you want libapache2-mod-log-sql-mysql to upgrade your apachelogs database tables? I think it's best this way, right? Then, how do I know that I'm upgrading from version 1.101 and that the upgraded is needed ??? Read /var/lib/dpkg/info/dpkg.postinst, which, when called with $1 = configure, also is passed the most-recently configure version, if any, in $2. justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
this bug/#436681- backuppc: Web interface password publicly visible
On Wed, Apr 23, 2008 at 11:22:01PM +0100, sadia jameel wrote: hello dear My name is sadia and i am student of MS(computer science). i want some information relating to bug #436681 that has been fixed now. i am interesting in it and want to know these following questionsabout it: 1- in which subpackage of backuppc this bug was present? The source package backuppc has only one binary package. 2- what was the reason of this password publicaly visible? ISTM that the bug log has all the info on this. 3-in which part of the code u have made changing inorder to fix this bug? 4-what was the major changing that u have to do to resolve this bug? I'd suggest to retrieve the diff.gz files of the version suffering from the bug, and the diff.gz mentioned in the changelog that closes the bug (3.0.0-4), then run interdiff -z ./...1.diff.gz ./...-3.0.0-4.diff.gz. As it's the only change in the changelog, that's precisely what the output should be. On Wed, Apr 16 2008, 2008 at 14:22:51 -0700, BILAL wrote: [...] To get sources, run apt-get source package. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Installing PEAR packages in an idempotent fashion
On Fri, Apr 18, 2008 at 05:13:29PM +0100, Colin Turner wrote:
Hi,
My package needs a Pear package, specifically Pear Log, it has php-pear
in its dependencies.
The big problem is installing the package itself in, I presume, the
postinst script. My early tests were simply:
pear -q install log
but I found that when the package was installed this process would quit
with an error second time around, stopping the script from being
idempotent. At some stage this problem seemed to evaporate (maybe with
lenny).
Has anybody any words of wisdom to offer on how to handle pear module
installations in an idempotent fashion?
You could read the source for pear and figure out under what
conditions it exits with an error, and avoid calling it in that case:
grep 'something' /path/somefile || pear -q install log.
You could also (perhaps) test in postinst the $2 value to see if the
package has been configured before (the earlier solution is better
IMO).
You could also test that, if it fails, it fails for that reason, and
allow that failure.
t=`tempfile`
trap 'rm -fv -- $t' EXIT
pear -q install log 2$tempfile || {
ret=$?
grep -Fx $the_error_message /dev/null $t || {
cat $t
exit $ret
}
}
rm -f -- $t
trap - EXIT
#Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help needed regarding installation
On Mon, Apr 14, 2008 at 06:35:21PM +0100, Neil Williams wrote: On Mon, 2008-04-14 at 17:13 +0500, Zainab Rehman wrote: It should be added that there's no need to apt-get source as a privileged user. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--warn-missing and dh_install?* (Re: Install files with debhelper or make install?)
On Sun, Mar 09, 2008 at 09:03:21PM -0300, Felipe Sateler wrote: But I want to use dh_installman, dh_installexamples and the linke. I don't want to do a big dh_install run. The goal is to use the helper scripts to take the advantage of them. Agreed, per the first paragraph of dh_install(1). Does dh_install run dh_installman for the files in dh_install? I didn't know this. I though dh_install installs only the files in package.install. No. You might get comparable behavior with something like: ( cd debian/tmp find ) | grep -Fvxe $(cd debian/libfoo0 find) \ -e $(cd debian/libfoo-dev find) For --list-missing, add: || [ $? -eq 1 ] For --fail-missing, add: ; [ $? -eq 1 ] Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
list of public usertags?
Does there exist a list of public usertags in use? I'd like to see a big list of these, probably a good use of the wiki. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: maintainer script factorization
On Fri, Feb 22, 2008 at 07:07:54PM +0100, Martin Fuzzey wrote: Hi all, frequently maintainer scripts modify the same files and to avoid duplication of path names etc in all scripts I was wondering if they could be factorized anywhere. The obvious solution of installing something like /usr/share/package/common.sh and sourcing it in the maintainer scripts doesn't work as the package files may already have been removed. Any ideas or is this impossible? You can include some kind of common script and use .in files parsed as with #DEBHELPER# or such. Perhaps use cpp instead of sed for this, or someone will suggest a better way yet. ./debian/maintscript-common: # Begin debian/maintscript-common shell fragment [...] # End maintscript-common ./debian/postinst.in: #! /bin/sh # Postinstallation script for foo #MAINTSCRIPT-COMMON# [...] ./debian/rules: clean: dh_clean debian/postinst debian/preinst debian/postrm debian/prerm binary: [...] set -e; cd debian; for m in postinst preinst postrm prerm; \ do \ f='maintscript-common'; \ [ ! -e $$m.in ] continue; \ exec $$m.in $$m; \ sed -e s/^#MAINTSCRIPT-COMMON#$$//; T; r $$f; \ done [...] dh_installdeb [...] Colin watson wrote about a scenario where he apparently needed to do this: http://lists.debian.org/debian-devel/2006/12/msg00647.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Writing get-orig-source targets to conform with policy
On Sat, Feb 16, 2008 at 11:10:01PM -0500, Andres Mejia wrote:
Second question is regarding a get-orig-source target I have for the package
mediatomb. It goes like:
# Haven't found a way to use this without running it twice
COMPUTED_CHECKSUM = $(shell md5sum $(MEDIATOMB_TARBALL) | cut -d ' ' -f 1)
get-orig-source:
ifeq ($(CORRECT_CHECKSUM),$(COMPUTED_CHECKSUM))
The problem here is that the get-orig-source target has to be run
twice before the checksum passes (unless you happen to have the file
in the current directory already). Is there any way around this?
The reason is that $(shell ...) is evaluated by make before wget creates
the file (I think it happens at the beginning of the rule). Instead I
think you should either use a shell test:
[ $md50 = $md51 ] || { echo $0: error: ... 2; exit 1; }
Or use a 2nd rule which creates the upstream file (using wget), and then
get-orig-source depends on that rule and does md5sum; tar xzf;
manipulate; tar czf.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Exclude config.sub and config.guess from
On Mon, Feb 11, 2008 at 04:42:34PM +0100, David Paleino wrote: Il giorno Mon, 11 Feb 2008 15:19:08 +0100 Daniel Leidert [EMAIL PROTECTED] ha scritto: Copy the config.* scripts after the clean target has been called (e.g. in the config.status target) then they are simply not part of the diff.gz. Of course they would be after a second build run. If you care and if you want to avoid this: preserve the original config.* scripts and put them back in the clean-target. This increases the whole debian/rules file for around 4 lines. This *is* much more easier than any other suggestion I read in this thread. [1] I know that using [ ! test ] || ... is pretty awkward, but it didn't work with [ test ] . Maybe should be escaped somehow? I don't really know. A set -e shell script doesn't terminate if a nonzero return value is a part of a conditional/test. However in a makefile, the exit status of the shell can be nonzero even if it was a due to a test failing, so you have to use [ ! ] || and not the more readable [ ] , since the sh -c '' will still exit 1. For the same reason, you need to explicitly exit 0 at the end of some scripts: for a do [...] [ ] foo done # Necessary due to the test exit 0 Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gnomecatalog
On Wed, Jan 09, 2008 at 07:14:50PM +0100, José L. Redrejo Rodríguez wrote: El mié, 09-01-2008 a las 18:24 +0100, José Sánchez Moreno escribió: On mié, 2008-01-09 at 12:21 +, Neil Williams wrote: On Wed, 2008-01-09 at 12:29 +0100, José Sánchez Moreno wrote: On Tue, Jan 08, 2008 at 08:02:02PM +0100, José Sánchez Moreno wrote: Dear mentors, I am looking for a sponsor for my package gnomecatalog. * Package name: gnomecatalog Version : 0.3.1-1.0 Hi José, just a couple of questions: - Your postinst is maintaining some old debhelper generated code and it should be deleted. In fact, you can test that this is all you need in the file: #!/bin/sh #DEBHELPER# If the postinst can be generated from scratch by debhelper, then just remove it entirely. It's sufficiently intelligent to eg. add set -e in that case (I don't know if that would happen with a shebang+template maintscripts). Justin
Re: [pkg-ntp] - where does /etc/default/ntpdate come from?
On Tue, Dec 18, 2007 at 06:53:39PM +0100, D. Pathirana wrote: Dear mentors! I am new in Debian Package Maintaining. I try to build some packages for my own to get a feeling how everything works. I have read a few docs[1][2] to find a solution for a specific problem that bugs me since days now... I would have asked the pkg-ntp-maintainers list for help but Chapter 10 of the Debian New Maintainers' Guide[3] tells me to ask here first.. I hope it's correct and somebody can help... So here is my problem: I've been trying to figure out how the installation process of the package ntpdate works. After installation the configuration file /etc/default/ntpdate is created. But: I can not find any evidence of it being used throughout the whole debian directory in the source-package. dpkg -L ntpdate |xargs grep -e /etc/default/ntpdate Also (not so useful in this case): find /var/lib/dpkg/info |xargs grep -we etc/default/ntpdate Actually there IS THE file in debian/ntpdate.default but is never refered in the rules file or elsewhere. I believe it has something to do with .default suffix but I was not able to find any docs about what and how it is going on. So where does the magic happen? I just realized that you weren't asking where the file is used at runtime but rather at compile time. Check dh_installinit (debhelper uses lots of these kinds of input files). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: changelog-should-mention-nmu
On Wed, Dec 12, 2007 at 05:52:05PM +0100, chaica wrote: Uploading my package on mentors.debian.net, I got this message: W: yougrabber source: changelog-should-mention-nmu My package is the first debian package for this soft. My debian/changelog is the following: yougrabber (0.29.2-1) unstable; urgency=low * Initial release. -- carl [EMAIL PROTECTED] Thu, 06 Dec 2007 11:42:20 +0100 Any idea what could be wrong? Thx. This is a clue: N: Maybe you didn't intend this upload to be a NMU, in that case, please N: doublecheck that the most recent entry in the changelog is N: byte-for-byte identical to the maintainer or one of the uploaders. What's in debian/control:Maintainer?
Re: Weired problem with apt-get -b source package-name
On Tue, Dec 11, 2007 at 10:10:27PM -0800, iluvlinux wrote: steps i followed 1 apt-get source package-name 2 cd package-version 3 dpkg-buildpackage -rfakeroot above steps builds deb pkg with shared library while using apt-get -b source pkg don't. How does it fail? Are you using dpkg/unstable, which does -rfakeroot automatically? Are you specifying any dpkg build options via apt (-oBuild-Options=-rfakeroot)? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Sun, Nov 25, 2007 at 09:01:50PM -0800, C.J. Adams-Collier wrote:
is there something like a service-common package that provides a helper
script like the following for services to source?
I think the current solution is provide a template with dh_make,
which is somewhat more general since the init.sh might need to be
overhauled to be useful for some given app.
I'm thinking that it would belong somewhere like
/usr/share/service-common/init.sh. I have not tested the following yet, and
I'm a sucky bash programmer.
# Fully qualified paths to required programs
START_STOP_DAEMON=/sbin/start-stop-daemon
CAT=/bin/cat
ECHO=/bin/echo
. /etc/default/$SERVICE_NAME
In general, you'd want to test for the existance and only source it if
it's there.
# Kill me on all errors
set -e
Put this early as possible.
# If the daemon binary does not exist, report the error and exit
if [ ! -f $SERVICE_DAEMON ]; then
fatal( Service daemon, '$SERVICE_DAEMON' does not exist. )
fi
Actually, this is usually:
[ -x $DAEMON ] || exit 0
since the conffiles (such as the initscript) are present after
removing (but not purging) the package, and this keeps them from
spewing noisy errors about the daemon not starting or such.
# Make sure the RUNDIR exists with correct permissions
if [ ! -d $RUNDIR ]; then
Any reason not to include the rundir in the pacakge? Then you don't
have to manually remove it in the initscripts.
# Check whether we were configured to not start the services.
check_for_no_start() {
if [ $SERVICE_DISABLED = yes ]; then
This is probably a good idea to be generally and consistently
supported. OTOH removing the execute bit or renaming the daemon file
already works most (90%) of the time.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. just declare it's interpreter as #!/bin/bash. Generally, you don't need its to do that, but you are allowed to. Do you mean because bash is the default sh? It's still required to declare the interpretter: | If a script requires non-POSIX features from the shell interpreter, | the appropriate shell must be specified in the first line of the | script (e.g., `#!/bin/bash') Justin
Re: interpretted scripts (Re: service helper package)
On Mon, Nov 26, 2007 at 03:53:33PM +, Stephen Gran wrote: This one time, at band camp, Justin Pryzby said: On Mon, Nov 26, 2007 at 02:13:42PM +, Stephen Gran wrote: This one time, at band camp, Jörg Sommer said: Init scripts should not use Bash, they should be Posix Shell scripts! Not strictly true. A script written for use with #!/bin/sh should use the POSIX superset allowed by policy. A script aimed at bsah should By superset of posix I guess you mean posix + echo -n. IIRC policy also allows [ $this -a $that ] and [ $this -o $that ] although I might be confused in thinking those aren't POSIX. -a and -o are XSI which AIUI is an (very common) extension of posix (see standards.7). dash allows them but posh does not. just declare it's interpreter as #!/bin/bash. Generally, you don't need to do that, but you are allowed to. Do you mean because bash is the default sh? No, I mean that bash specific features are not generally necessary in Ah, ok; I didn't think that could be right :) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: service helper package
On Mon, Nov 26, 2007 at 04:51:38PM -0800, C.J. Adams-Collier wrote: On Mon, 2007-11-26 at 12:32 +, Jörg Sommer wrote: C.J. Adams-Collier [EMAIL PROTECTED] wrote: # Fully qualified paths to required programs START_STOP_DAEMON=/sbin/start-stop-daemon CAT=/bin/cat ECHO=/bin/echo Why not use echo and cat? Calling echo this way the shell can't use the builtin echo command and must spawn a new process. Is there a test to determine whether there is a builtin for a given command? If so, we could test for that and use it if it exists. Otherwise, use the fully qualified version There's type and command and which and whatis (see the policy huge long bug about this things) but I don't know why you would use them at runtime (except I guess how debhelper does it with if [ `which ... 2/null` ]; ...) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dynamic users (Re: dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface))
On Fri, Nov 09, 2007 at 02:26:42PM -0500, Andres Mejia wrote:
On Nov 9, 2007 5:24 AM, Michael Biebl [EMAIL PROTECTED] wrote:
Am Donnerstag, den 08.11.2007, 20:31 -0500 schrieb Justin Pryzby:
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote:
On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote:
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
I guess I meant chowning blindly instead of chown.
I do note that a few postinst files in my /var/lib/dpkg/info/ use
dpkg-statoverride rather than chown.
I guess I should reread devref/policy.
Policy mentions this in 10.9.1; it appears that it can be correct to
do either dpkg-statoverride --update or use chown directly, as long as
it's conditional on does dpkg-statoverride -l $f /dev/null.
I note that using chown doesn't add the file to the override data,
which I argue is a good thing due to no ambiguity about who put it
there.
I had the same issue myself, some days ago. I wasn't sure if using chown
or dpkg-statoverride in postinst was the correct way.
You argue for not using dpkg-statoverride, policy seems to recommend it
though. Asking on #debian-devel, the answers I got were, to use
dpkg-statoverride unless I have a very good reason not to.
I think one disadvantage of using chown in postinst is, that you have a
time frame between unpack and postinst, where the binary has the wrong
the permissions. With dpkg-statoverride, dpkg will take care that the
binary has always the correct permissions.
So this is a big advantage of using dpkg-statoverride.
Admittedly it would be nice, if policy was more precise in that matter.
Thanks for the suggestions. I went ahead and made the changes. Here's
the changelog for 0.10.0-5 of this package.
[ Andres Mejia ]
* Using deluser and delgroup commands to remove meditomb user and group.
* Removed dependency on passwd.
* Added --disabled-{login,password} for adduser in preinst.
BTW did you know that adduser --system adds a user *and* a group? For
system users only. {,} is a bashism of course.
Why do you remove the user/group? I think the suggestion is to leave
dynamic system ID's to avoid them being recreated with a different
(system) user which now has access to some stray files leftover from a
different package. If the admin wants to get rid of them, they can do
find / -user $u -o -group $u -ls at their convenience, or look in
obvious places or decide it's not worth the effort.
I think if you do use deluser, it should be in purge and not
remove.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: file encoding and eol marker in orig.tar.gz
On Thu, Nov 08, 2007 at 03:59:44PM +0100, Bas Wijnen wrote: On Thu, Nov 08, 2007 at 08:22:06PM +0530, Kumar Appaiah wrote: On Thu, Nov 08, 2007 at 03:24:40PM +0100, Bas Wijnen wrote: I wouldn't do that. Repackaging is done to make the tarball complient with our standards, not to beautify it. If this conversion is a good idea (and I agree that it is), then that is an upstream issue, and it should be fixed there. Asking them about it is a good idea, changing it in the package is not IMO. I had to do this, because this caused some build failed for some reason (I don't recall, but my mentor asked me to do it). Making changes to make the build work is always good, of course. However, when changes are made for the Debian package, this should be done in a way which doesn't hide them. When a user sees a package where the tarball is repackaged because some files had to be removed, she's not going to expect any changes other than the removal of some files. For other changes, we have a nicely working patch system. In fact devref 6.7.8.2.2 discourages doing anything except removing files when repackaging. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#450608: debhelper: [DH_FIXPERMS] bin/* are updated with v5 too (Re: Executable's execute permission not getting set)
Package: debhelper
Version: 5.0.42
Severity: minor
Tags: patch
File: /usr/bin/dh_fixperms
User: [EMAIL PROTECTED]
Usertag: dh_fixperms
X-Debbugs-Cc: debian-mentors@lists.debian.org
On Thu, Nov 08, 2007 at 04:16:06PM +0100, Bernd Zeimetz wrote:
Arnaud Fontaine wrote:
Bernd == Bernd Zeimetz [EMAIL PROTECTED] writes:
Hello,
Bernd if I understand dh_fixperms manpage correctly it does not
Bernd 'fix' the permissions for bin directories anymore. So you
Bernd just want to add a chmod 755 somewhere.
However, dh_fixperms seems to fix the permissions for bin directories if
compat = 4 according to the manpage (It makes all files in bin/
directories, /usr/games/ and etc/init.d executable (v4 only))
v4 only sounds like compat ==4 imho. If not it should probably updated
to since v4.
You're right:
| # v4 and up
| if (! compat(3)) {
| # Programs in the bin and init.d dirs should be executable..
| for my $dir (qw{usr/bin bin usr/sbin sbin usr/games etc/init.d}) {
--- /usr/bin/dh_fixperms
+++ /tmp/tmp.cCMEZ29704/dh_fixperms 2007-11-08 10:29:23.0 -0500
@@ -24,8 +24,8 @@
the permissions of all man pages to mode 644. It makes all files be owned
by root, and it removes group and other write permission from all files. It
removes execute permissions from any libraries that have it set. It makes
-all files in bin/ directories, /usr/games/ and etc/init.d executable (v4
-only). Finally, it removes the setuid and setgid bits from all files in the
+all files in bin/ directories, /usr/games/ and etc/init.d executable (since
+v4). Finally, it removes the setuid and setgid bits from all files in the
package.
=head1 OPTIONS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface
On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote:
postinst should use dpkg-statoverride instead of chown
Really? I thought this was an administrator's tool, and the postinst
should do something like
getent $u /dev/null ||
adduser --system --group --home /var/... --shell /usr/sbin/nologin \
--disabled-{login,password} $u
dpkg-statoverride --list $f /dev/null ||
chown $u:$u $f
If the statoverride datafile gets filled with all sorts of
maintainer's default package data then it instead requires some
heureustic to try to determine whether the admin did chmod to a
different user/group.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
dpkg-statoverride (Re: RFS: mediatomb -- open source (GPL) UPnP MediaServer with a web interface)
On Fri, Nov 09, 2007 at 10:35:00AM +0930, Paul Wise wrote: On Nov 9, 2007 9:43 AM, Justin Pryzby [EMAIL PROTECTED] wrote: On Fri, Nov 09, 2007 at 09:35:05AM +0930, Paul Wise wrote: postinst should use dpkg-statoverride instead of chown Really? I thought this was an administrator's tool, and the postinst should do something like I guess I meant chowning blindly instead of chown. I do note that a few postinst files in my /var/lib/dpkg/info/ use dpkg-statoverride rather than chown. I guess I should reread devref/policy. Policy mentions this in 10.9.1; it appears that it can be correct to do either dpkg-statoverride --update or use chown directly, as long as it's conditional on does dpkg-statoverride -l $f /dev/null. I note that using chown doesn't add the file to the override data, which I argue is a good thing due to no ambiguity about who put it there. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Mon, Nov 05, 2007 at 06:39:01AM -0800, varun_shrivastava wrote: Justin Pryzby-43 wrote: On Fri, Nov 02, 2007 at 08:13:22AM -0700, varun_shrivastava wrote: You could have libinput0-debug provides:libinput0. However I still think the best way is to compile with debugging symbols and move the symbols to separate files in /usr/lib/debug and separate -dbg package which is *just* the debugging syms. thanks for reply do i have to make changes in Makefile or some thing else please can you provide me some links or documents on how to separate debug symbols from main library I already referenced the source: http://lists.debian.org/debian-mentors/2007/11/msg00012.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Fri, Nov 02, 2007 at 08:13:22AM -0700, varun_shrivastava wrote: Justin Pryzby-43 wrote: Do you mean it adds stuff within a #ifdef to use SDL? Why is it so huge? yes it adds code not so huge under #ifdef SDL_ENABLE ... #endif Can we provide a virtual package libinput-virtual on which the applications will depend and the virtual package can be libinput0 or libinput0-debug depending on what is installed You could have libinput0-debug provides:libinput0. However I still think the best way is to compile with debugging symbols and move the symbols to separate files in /usr/lib/debug and separate -dbg package which is *just* the debugging syms. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 09:42:33PM -0700, varun_shrivastava wrote:
hi
actually the library uses g_log kind of debugging technique ie some #defines
are there, so when log is enabled #defines get replaced by g_log(***), and
when its disabled #defines get replaced by (void)0
But i have a bigger problem thats the library has one more option of
--enable-sdl=yes/no , I checked the source code and enabling it adds a huge
amount of code to standard library.
Do you mean it adds stuff within a #ifdef to use SDL? Why is it so
huge?
Or do you mean it compiles a static copy of SDL? Don't do this; use a
{build,}dep on the shared library package instead.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On Thu, Nov 01, 2007 at 04:27:14PM -0600, Jordi Gutiérrez Hermoso wrote: On 01/11/2007, Justin Pryzby [EMAIL PROTECTED] wrote: On Thu, Nov 01, 2007 at 01:17:26PM -0600, Jordi Gutiérrez Hermoso wrote: Hello, mentors. I'm currently working on Processing (#433270). Now, Processing distributes in its source tarball (well, not really a source tarball at all, since it's necessary to get everything from svn), some Windows .exes and some MacOSX-specific files too. Do these have to be removed from the source package that I make for Debian? I forget if it's policy or devref which prefers *not* removing them unless you're already using a nonpristine sourceball or it would save significant space, It would save 20 megs from the source package. Is that considerable enough for their removal? That part isn't in policy :) Is that 20mb before or after compression? Since it's a source package, there's only one copy (per suite, perhaps with a couple extra copies for a couple days at a time [?], but not per architecture). If you do repackage, make sure to provide an get-orig-source target to retrieve (?), unpack, modify, and repack that (and the top level dir should have .orig appended). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How a package will determine the dependencies
On Thu, Nov 01, 2007 at 08:57:19AM -0700, varun_shrivastava wrote: hi i have a library and want to package it But it has a configuration option as --enable-debug=yes/no So i need to make 2 packages as 1) libinput0 2) libinput0-debug I think the recommended way to do this [0] is to build with debugging symbols then move the debugging symbols to a separate file, and associate the dbg files with the normal runtime files. Justin [0] see the developers' references and at least one bug against such. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing non-Linux files from source tarballs
On Thu, Nov 01, 2007 at 01:17:26PM -0600, Jordi Gutiérrez Hermoso wrote: Hello, mentors. I'm currently working on Processing (#433270). Now, Processing distributes in its source tarball (well, not really a source tarball at all, since it's necessary to get everything from svn), some Windows .exes and some MacOSX-specific files too. Do these have to be removed from the source package that I make for Debian? I forget if it's policy or devref which prefers *not* removing them unless you're already using a nonpristine sourceball or it would save significant space, (with the justification that people might like to use the debian sources for nondebian things) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
On Thu, Oct 11, 2007 at 10:35:30PM -0700, varun_shrivastava wrote: Justin Pryzby-43 wrote: You shouldn't set rpath to /usr/lib since it's in the default search path. I haven't set the path any where in the rules file. but i am trying to What I meant was one should not set rpath to /usr/lib or rpath should not be set to /usr/lib. Is there some arguments to ./configure you can pass to inhibit setting rpath? Otherwise you'll have to munge the upstream build system to get rid of it. Justin Pryzby-43 wrote: You have to supply a ./debian/shlibs file in any package that includes public shared libraries (/usr/lib/*.so.*). It gets installed to /usr/lib/dpkg/info/ and searched by dh_shlibdeps when building packages to find on what package,version to add a dependency for a given objdump -p |grep -we NEEDED line. Do i need to provide package-name.shlibs or shlibs.local file in debian directory. packagename.shlibs is what gets installed to /v/l/d/i. shlibs.local is an additional thing read by dpkg-shlibdeps for cases when someone elses public library package doesn't include packagename.shlibs. In this case dpkg wouldn't otherwise be able to find the library package to add as a dependency. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 12:51:26PM +0200, Daniel Leidert wrote: Am Donnerstag, den 11.10.2007, 10:52 +0900 schrieb Charles Plessy: about non-existing directories, like usr/share/dialign-t. You only need to create the diretories first, if you e.g. use `install' instead of dh_install or of you want to create links there. I guess this is handled too by install -D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Passing variables to a Makefile
On Thu, Oct 11, 2007 at 10:52:03AM +0900, Charles Plessy wrote: Dear mentors, in a package I prepare, there is the following line in a source/Makefile: CPPFLAGS=-O3 -funroll-loops -march=i686 -mfpmath=sse -msse -mmmx CPPFLAGS is for the C PreProcessor. So it's supposed to have things like -Iinclude -DFOO=BAR. CFLAGS is for the C compiler itself, so it's supposed to have things like -O3 -funroll-loops -std=gnu99 -Wall -Wextra. But it only matters if you're using the implicit rules and the binaries are built from multiple source files or are otherwise compiled and linked in separate invocations. BTW there's LDFLAGS too for linker options like -Wl,-soname,libfoo.so.1 -Wl,-O2 (here it's assumed that LD=gcc thus the -Wl, thing). I think that Debian packages shouldn't have subarch-specific options on any arch, since the same binaries may/(have to be able to) be run on variation on that arch. In the case of i386, the binaries have to be able to run on a real 386 [0]. I think all the arch options here will (maybe) cause the binary to fail on such a machine. Justin [0] My understanding is that the packaged kernels don't support 386 but with a software emulation of some math instruction patched in, 386 is advertised as being supported with binary packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: binary-or-shlib-defines-rpath error message
On Thu, Oct 11, 2007 at 06:17:06AM -0700, varun_shrivastava wrote: hi i am a newbee in packaging and trying out how to package some already available source packages i am trying to pack jpeg62_6b, the package builds successfully but running Is this the same package that caused dh_strip errors? lintian shows binary-or-shlib-defines-rpath ./usr/bin/cjpeg /usr/lib the message is same for all binaries in /usr/bin You shouldn't set rpath to /usr/lib since it's in the default search path. can some one please explain the reason for this message? Debian considereds rpath to be inflexible. Also while building the same package a warning message is being displayed by dh_shlibdeps here is the message:: dpkg-shlibdeps -Tdebian/libjpeg62-utils.substvars debian/libjpeg62-utils/usr/bin/cjpeg debian/libjpeg62-utils/usr/bin/djpeg debian/libjpeg62-utils/usr/bin/rdjpgcom debian/libjpeg62-utils/usr/bin/wrjpgcom debian/libjpeg62-utils/usr/bin/jpegtran dpkg-shlibdeps: warning: could not find path for libjpeg.so.62 You have to supply a ./debian/shlibs file in any package that includes public shared libraries (/usr/lib/*.so.*). It gets installed to /usr/lib/dpkg/info/ and searched by dh_shlibdeps when building packages to find on what package,version to add a dependency for a given objdump -p |grep -we NEEDED line. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unable to strip using dh_strip
On Tue, Oct 09, 2007 at 10:30:21PM -0700, varun_shrivastava wrote: hi i am trying to build a package using debhelper scripts, but it gives an error message dh_installdirs -a dh_install -a dh_link -a dh_compress -a dh_strip -a dh_fixperms -a dh_makeshlibs -plibfreetype6 -V'libfreetype6 ( 6.3.10)' dh_shlibdeps -a dh_installdeb -a /scratchbox/tools/bin/install: `debian/libfreetype6/DEBIAN' exists but is not a directory dh_installdeb: command returned error code 256 make: *** [binary-arch] Error 1 I m using scratchbox in order to build package, currently i am not cross compiling. Now when i remove dh_strip -a command from the rules file , the package builds successfully. But running lintian shows unstripped binary error message. Can you set DH_DEBUG like at the head of the rulesfile and rerun? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Unable to strip using dh_strip
On Wed, Oct 10, 2007 at 05:33:48AM -0700, varun_shrivastava wrote: Justin Pryzby-43 wrote: Can you set DH_DEBUG like at the head of the rulesfile and rerun? i added line export DH_DEBUG=1 on top of rules file but o/p is same (no debug kind of o/p displayed) then i uncommented a line which says export DH_VERBOSE=1 the o/p is as shown Yeah that. chmod 644 debian/libfreetype6/DEBIAN/shlibs chown 0:0 debian/libfreetype6/DEBIAN/shlibs dh_shlibdeps -a dpkg-shlibdeps -Tdebian/libfreetype6.substvars debian/libfreetype6/usr/local/lib/libfreetype.so.6.3.10 dh_installdeb -a install -o 0 -g 0 -d debian/libfreetype6-dev/DEBIAN install -o 0 -g 0 -d debian/libfreetype6/DEBIAN /scratchbox/tools/bin/install: `debian/libfreetype6/DEBIAN' exists but is not a directory dh_installdeb: command returned error code 256 make: *** [binary-arch] Error 1 Well 2 things come to mind. Is scratchbox install compatibile with debhelper? Also ls -la debian/libfreetype6/DEBIAN Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Reason for Failed build on some arch only
On Wed, Oct 03, 2007 at 06:52:43PM +0530, Kartik Mistry wrote: Hi, My package Xosview is failed to build on (atleast) two arch with same reason. Following are links from buildd. mipsel: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mipsel;stamp=1190303855 mips: http://buildd.debian.org/fetch.cgi?pkg=xosview;ver=1.8.3%2Bdebian-2;arch=mips;stamp=1190807389 Can anyone please look at guide me to some point? No bug reported, but it is safer to fix it before that :P I think this documents your options: /usr/share/doc/autotools-dev/README.Debian.gz Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Same source package, differents targets
On Mon, Oct 01, 2007 at 04:02:32PM +0200, Leopold Palomo-Avellaneda wrote: Hi, I'm sorry if the question is a bit silly, but I have a conceptual doubt. I would like to package a soft that with the _same_ source, provides different packages but, this packages have different build dependencies and incompatibles. I think you mean that you have multiple binary package, and the build deps for one of them conflict with the build deps of the other. Neat! Can you give specific detail of the package and dependencies? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autoconfigurable package: how to build two configurations?
On Sun, Sep 23, 2007 at 06:50:02PM -0500, Steve M. Robbins wrote: Hello, Are there any examples of a package that builds two binary packages, each from a distinct run of configure? My specific case is soqt, which provides a Qt interface to Coin (OpenInventor). There is a sentiment [1] that I provide packages for Qt3 as well as packages for Qt4. I believe that I need to run the autoconf-generated configure script twice and build each configuration in its own build directory. I'd like to see a package that does this already. Preferably, one that uses cdbs. The dev-ref (still) uses vim as an example afaik. A good goal would be to reduce duplication of code within the rules file. Justin References [0] http://lists.debian.org./debian-mentors/2007/05/msg00069.html
Re: Removing transition stuff in debhelper scripts after which time?
On Tue, Sep 25, 2007 at 04:46:43AM +0200, Daniel Leidert wrote: Hi, Today I stumbled over the question: After which time should transition stuff be removed from the debhelper scripts. In this special case I'm talking about install-sgmlcatalog calls in (e.g.) postinst scripts. Adam Di Carlo announced the depreciation of install-sgmlcatalogs in 2001. However, almost all related docbook* packages still contain this stuff. So I'm wondering, how long one should wait before such obsolete stuff can be removed? I mean, there is no requirement to support updates from e.g. Woody to Lenny, right? I checked the Debian Social Contract and the Policy manuals, but didn't find an information related to this topic. Maybe I overlooked it? You can drop such things in uploads to unstable after they're included in a stable release. Upgrades across releases are not tested and are officially not supported though AFAIK the reasons are largely undocumented. I think it's roughly the same situation as for downgrades: . maintainer scripts may not support things; this is basically so maintainers are allowed to drop support for ancient things and not have unmanagably large and difficult to test, unmaintanble cruft; . Package control file; including in particular the dependency fields: Conflicts, Depends, Provides (?), Pre-Depend plus Replaces. Dependencies on versions earlier than [old]stable are often dropped. It's only unfortunate that control files afaik still don't support comments to document why the versions and things were there with which to being. . The package itself; eg. it might contain logic to upgrade the format of its datafiles but not for every historic version and bugs therein. Justin References [0] http://lists.debian.org/debian-mentors/2007/01/msg00241.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Extraeyes needed - Conflicts, Provides, Replaces don't seem to work
On Wed, Sep 19, 2007 at 10:18:24AM +0200, Turbo Fredriksson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could someone take an ehey on this, I'm not seeing the problem... Laptop2/SARGE# apt-get install libglib-dev Reading Package Lists... Done Building Dependency Tree... Done Note, selecting libglib1.2-dev instead of libglib-dev You might want to run `apt-get -f install' to correct these: The following packages have unmet dependencies: util-linux: PreDepends: slang1a-utf8 ( 1.4.9dbs-4) E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution). I guess it's because *versioned* dependencies on virtual packages are never satisfied. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Tue, Sep 18, 2007 at 11:19:04AM +0200, Jan Beyer wrote: On 09/10/2007 06:40 PM, Justin Pryzby wrote : Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using =. Are you, Justin, willing to sponsor this package then, or should I retry with an updated RFS? Sorry, not a DD, so I can't sponsor you. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#443063: net-tools: configure-stamp does nothing
Package: net-tools Version: 1.60-17 Tags: patch Debbugs-Cc: debian-mentors@lists.debian.org X-Debbugs-Cc: debian-mentors@lists.debian.org X-Why: multipipe RFS had the same problem (template?) User: [EMAIL PROTECTED] Usertags: debian-specific configure: configure-stamp configure-stamp: dh_testdir touch configure-stamp ./debian/rules configure-stamp creates a file but otherwise does nothing. The utility of the stampfile is to avoid rerunning slow commands, so at best this fails to avoid a slow command. diff -u net-tools-1.60/debian/changelog net-tools-1.60/debian/changelog --- net-tools-1.60/debian/changelog +++ net-tools-1.60/debian/changelog @@ -1,3 +1,10 @@ +net-tools (1.60-17.1) unstable; urgency=low + + * Non-maintainer upload. + * ./debian/rules: Remove useless configure-stamp target. + + -- Justin Pryzby [EMAIL PROTECTED] Tue, 18 Sep 2007 07:22:04 -0400 + net-tools (1.60-17) unstable; urgency=medium * arp.c: bus error on sparc64 with latest gcc fixed. (Closes: Bug#340384) diff -u net-tools-1.60/debian/rules net-tools-1.60/debian/rules --- net-tools-1.60/debian/rules +++ net-tools-1.60/debian/rules @@ -8,12 +8,7 @@ # This is the debhelper compatability version to use. export DH_COMPAT=1 -configure: configure-stamp -configure-stamp: - dh_testdir - touch configure-stamp - -build: configure-stamp build-stamp +build: build-stamp build-stamp: dh_testdir cp debian/config.h config.h @@ -24,7 +19,7 @@ clean: dh_testdir dh_testroot - rm -f build-stamp configure-stamp + rm -f build-stamp -$(MAKE) clobber dh_clean diff -u net-tools-1.60/debian/changelog net-tools-1.60/debian/changelog --- net-tools-1.60/debian/changelog +++ net-tools-1.60/debian/changelog @@ -1,3 +1,10 @@ +net-tools (1.60-17.1) unstable; urgency=low + + * Non-maintainer upload. + * ./debian/rules: Remove useless configure-stamp target. + + -- Justin Pryzby [EMAIL PROTECTED] Tue, 18 Sep 2007 07:22:04 -0400 + net-tools (1.60-17) unstable; urgency=medium * arp.c: bus error on sparc64 with latest gcc fixed. (Closes: Bug#340384) diff -u net-tools-1.60/debian/rules net-tools-1.60/debian/rules --- net-tools-1.60/debian/rules +++ net-tools-1.60/debian/rules @@ -8,12 +8,7 @@ # This is the debhelper compatability version to use. export DH_COMPAT=1 -configure: configure-stamp -configure-stamp: - dh_testdir - touch configure-stamp - -build: configure-stamp build-stamp +build: build-stamp build-stamp: dh_testdir cp debian/config.h config.h @@ -24,7 +19,7 @@ clean: dh_testdir dh_testroot - rm -f build-stamp configure-stamp + rm -f build-stamp -$(MAKE) clobber dh_clean
Re: Sponsor for multipipe
On Sun, Sep 16, 2007 at 04:32:13PM +0200, Christopher Zimmermann wrote: Hi! I just packaged the small multipipe tool from http://sourceforge.net/projects/multipipe. It can send its stdin to several other commands like this: cat blub |multipipe 'cat /dev/null' 'less' 'wc' Neat. You can do something similar using bashisms: echo foo |tee (sed s/^/x/) (sed s/^/y/) (sed s/^/z/) I find this little tool very handy in many cases. Something like this should be available in Debian. I have to agree :) You can download the source package from ftp://madroach.dyndns.org/multipipe/ Some comments: Your copyright file is incomplete (I think you know this). Ideally, debian/dirs:usr/bin isn't necessary since the upstream makefile should handle this. *some* debian/rules comments should go away. But you should also understand what eg. DH_VERBOSE, docbook-to-man, # dh_*, and the manpage macro comments do and try the relevant things once before getting rid of them. Your configure-stamp target seems to do nothing. You should understand why it was in the template and ultimately get rid of it. BTW tell your upstream that libc6 unistd.h already defines STDIN_FILENO and such, so main.c essentially just duplicates this. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: daemon stop and start during upgrade
On Tue, Sep 11, 2007 at 08:06:42PM +0200, Patrick Schoenfeld wrote: Adeodato Simó schrieb: Your init.d script should *not* exit with status non-zero if the daemon was already stopped. You can do that either by passing --oknodo to start-stop-daemon, or by checking by hand if the return status is 1. *Not*, in any case, by appending || true, since that would hide the case when a real errors occurs and the daemon can't be stopped. Hm. If i think about this topic it appears to make sense to let invoke-rc.d not fail (I actually do it like this), but I'm asking myself the question why this is not formalized in the policy? It would be a pro to take this into the policy, wouldn't it? It is 9.3.2: |The `init.d' scripts must ensure that they will behave sensibly if |invoked with `start' when the service is already running, or with |`stop' when it isn't, and that they don't kill unfortunately-named |user processes. The best way to achieve this is usually to use |`start-stop-daemon'. It's a very interesting question whether packages should inhibit starting a daemon that wasn't running when it would otherwise have been stopped. I guess the current state of affairs is that a manually-stopped daemon which is started at postinst time will cause a message to be printed and the admin can stop it again if he wants. I think the ideal situation is that a manually-stopped daemon would cause a message to be printed: Not starting food: not stopped at preinst time in the same style of messages that are shown with increasing consistency when things are not enabled in etc/default. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Are soname bumps required when library upgrades break compatibility?
On Tue, Sep 11, 2007 at 06:27:11PM -0700, Brandon wrote: Thanks for your explanations guys. I get it now. A crash is serious, whether or not the reason is documented in policy. If the crash is the fault of the library, the library gets the RC bug. The statement was that a crash due to changes in a dependency is a severity:serious bug in that dependency. A crash is always a bug, but many are just severity:normal for non-core functionality or important for things that don't totally inhibit the package's utility. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Sat, Sep 08, 2007 at 08:24:19PM +0200, Jan Beyer wrote: Justin Pryzby schrieb am 07.09.2007 17:46 Uhr: On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Then I'll use libxxxy-z (=a.b), which should be inserted by the -V option. -V should be using =. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lintian .packlist warning and debian/rules modification
On Sun, Sep 09, 2007 at 07:40:28PM +0200, Jeremiah Foster wrote: I ran debuilder with lintian and received this output (amongst other messages) E: libhtml-treebuilder-xpath-perl: package-installs-packlist usr/lib/perl5/auto/HTML/TreeBuilder/XPath/.packlist N: N: Packages built using the perl MakeMaker package will have a file named N: .packlist in them. Those files are useless, and (in some cases) have N: the additional problem of creating an architecture-specific directory N: name in an architecture-independent package. N: N: They can be suppressed by adding the following to debian/rules: N: N: find debian/tmp -type f -name .packlist | xargs rm -f N: N: -find debian/tmp/usr/lib/perl5 -type d -empty | xargs rmdir -p N: N: Or by telling MakeMaker to use vendor install dirs; consult a recent N: version of perl policy. Perl 5.6.0-12 or higher supports this. Below is an example of the output I would receive: snip find debian/tmp -type f -name .packlist | xargs -r rm -f find: debian/tmp: No such file or directory find debian/tmp -type d -empty | xargs -r rmdir -p find: debian/tmp: No such file or directory snip What I did to finally get rid of this error was to change the command to this: # remove .packlist files inserted by MakeMaker find . -type f -name .packlist | xargs -r rm -f I changed the directories find looks in because of the error message from find saying: No such file or directory even though the .packlist file existed. (I think that the directory debian/tmp was not being created.) Hi, The debhelper tools (dh_install) used to use debian/tmp but now (depending on DH_COMPAT) use debian/$package. So this is a small-ish lintian bug. You should probably do find ./debian/ instead of find . to avoid removing files from ./ except from ./debian/.. since a strict reading of policy requires that after the clean rule is run you have to end up in the same state as immediately after dpkg -x $dsc. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: ario
On Mon, Sep 10, 2007 at 10:27:08AM +0900, Michal Čihař wrote: Hi On Sun, 9 Sep 2007 23:35:40 +0200 Marc Pavot [EMAIL PROTECTED] wrote: I am looking for a sponsor for my package ario. [...] I would be glad if someone uploaded this package for me. Please fix following issues: - there is no point of including empty README and NEWS as documentation But actually debhelper makes an exception and doesn't include empty docs in the binary package. I forget who/when/where this was pointed out to me, but the maintainer wanted their source package to DWTW even if upstream filled in the originally-empty docs files. Also you specify -pario to all the debhelper calls, but they all act by default on the first binary package anyway. Justin
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: Dear mentors, I am looking for a sponsor for my package gwyddion. * Package name: gwyddion Version : 2.8-1 Upstream Author : David Nečas (Yeti) [EMAIL PROTECTED], Petr Klapetek [EMAIL PROTECTED] * URL : http://gwyddion.net/ * License : GPL-v2+, and parts PD Section : science It builds these binary packages: gwyddion- Scanning Probe Microscopy (SPM) analysis software Neat :) (Long) Annotations (=Request for Help/Comment/Explanation): Furthermore there are lintian warnings, which I did not quieten. They are about the libgwyddion2 package which contains several libraries and thus doesn't match the SONAMES of them. What is current practice? Allow the warning? Override it? Split the package (This seems useless to me)? Policy has this to say: |If you have several shared libraries built from the same source tree |you may lump them all together into a single shared library package, |provided that you change all of their sonames at once (so that you |don't get filename clashes if you try to install different versions of |the combined shared libraries package). The goal is that debs compiled/depending against any libgwyddion* libraries are always installable (well, the other goal is that there are only 2 versions of a library in the active archive at once). So you have to avoid the situation where libgwyddion2 includes: libxyza.so.1 and libxyzb.so.1, and the as-of-yet hypothetical libgwyddion3 includes libxyza.so.1 and libxyzb.so.2 (thus the new package name). In this case lib3 is required to Conflict on lib2 (or the other way around) since they're not actually co-installable. But then every package compiled against lib2 will end up effectively conflicting with every package compiled against lib3 since it's impossible to satisfy the packages of any 2 such packages. So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gwyddion - Scanning Probe Microscopy analysis software
On Fri, Sep 07, 2007 at 05:20:56PM +0200, Jan Beyer wrote: Many thanks for the quick response! On 09/07/2007 01:55 PM, Justin Pryzby wrote : On Fri, Sep 07, 2007 at 11:54:18AM +0200, Jan Beyer wrote: Furthermore there are lintian warnings, which I did not quieten. They are about the libgwyddion2 package which contains several libraries and thus doesn't match the SONAMES of them. What is current practice? Allow the snip So I think the libraries should only be in the same package if they have the same soname. (Or, you can put them into a subdirectory of /usr/lib/ if they're not linked against directly and it's no problem). The point is, at least as upstream explained to me, that these libraries are not particularly well split with regard to their contents. So no one will link against just one or some of them. In fact, one often needs some modules (which are in the gwyddion package) to build something reasonable. That's why I/we (we=upstream+me) decided to put them together. Concerning putting them into subdirectories: This would mean creating a subdirectory for each library and putting it in there? Could I then keep them all in one package? The directory would be named after the package. /usr/lib/libgwyddion2/* and either the public libraries or final binaries would need rpath to find them. (It still seems a grey area whether to add a soname and install the lib to /usr/lib or to use rpath for some things). And finally there is a duplicate depends of gwyddion on libgwyddion2, one added by the debhelper scripts and one by me - should I override this, or take away my hand-written dependency? I think you should drop the manually-added one since the automatic one will always be working with ELF dependency output. Should I force a versioned automatic dependency via dh_makeshlibs -V or dh_makeshlibs -V 'libgwyddion2 (=2.8)'? I think you have to bump the shlibs version whenever upstream adds a symbol. Unless you can show (by reading the diff) that a new upstream *doesn't* do this (or make incompatible changes), it's prolly safe to increment this at every new upstream. Otherwise an object compiled against a recent libgwyddion2 with new symbol would end up in a package with Depends: libgwyddion2 (=X) where version X doesn't actually provide the symbol, and an app will crash whenever the symbol lookup is attempted. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed copyright format
On Thu, Sep 06, 2007 at 01:58:31PM +0200, Manuel Prinz wrote: Dear mentors, there has been some discussion going some time ago on about making the copyright file machine-interpretable. I really like the idea and read the proposal [1]. The new format looks clearer to me and I wonder whether it's reasonable to already use it. There don't seem to be any tools using it right now, and it's not policy. On the other hand, I really don't see any reason not to use it, knowing that some adjustments have to be made if the format changes. What are your thoughts on that? Is anyone using the new format already? Seems like a best-practice to me. Using the proposed format too is perhaps the only good way of finding problems or potential improvements. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help with -dbg packages for a library
On Fri, Aug 31, 2007 at 10:57:55AM -0400, Justin Pryzby wrote: On Thu, Aug 30, 2007 at 09:29:45AM +0530, Kumar Appaiah wrote: Dear Debian Mentors, I have a specific question with regard to -dbg packages for libraries. My understanding of generating -dbg libraries is like this: 1. We build the package with CFLAGS or CXXFLAGS = -g -O2 (for optimization). 2. We call dh_strip while exluding the dbg package, to ensure that debugging sumbols are present there. I think the suggestion is for all libraries to use dh_strip --dbg-package or -k. BTW this is in bug #420540. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFC: irrlicht
On Thu, Sep 06, 2007 at 10:15:28AM -0700, Brandon wrote: I'm not sure how to actually handle replacing the files. Is it ok to put them into the orig.tar.gz? I'm sure the answer is in the policy manual somewhere. The orig.tar.gz can't have any files introduced relative to upstream. * lintian complaining about missing soname I noticed that too. Not from lintian, but using executables compiled against your library require the symlink that is only included in the development library. I bet the fix is easy, but I don't really know what it is. I bet it is a gcc option. -Wl,-soname,libfoo.so.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problem with --purge and reinstalling
On Wed, Sep 05, 2007 at 09:58:32PM +0200, Thibaut Paumard wrote: Dear mentors, I'm maintaining the yorick-* packages. The source package is split into yorick, yorick-data and yorick-dev. The conffiles are in the -data package. However, yorick.postrm removes these files upon --purge. I guess I must have been slightly offset from my head when I did this, but that's the situation in Etch. conffiles shouldn't ever be modified, created, moved, or removed by any package except dpkg. I just noticed a problem if a user does: aptitude install yorick (installs yorick and yorick-data) aptitude remove yorick (removes yorick and yorick-data) dpkg --purge yorick (deletes /etc/yorick/*, which actually belongs to yorick-data) aptitude install yorick (installs yorick and yorick-data) When reinstalling yorick the conffiles are not installed! One needs to purge y-data for these conffiles to get reinstalled. They're probably in etch's dpkg's obsolete state; use dpkg -s on those pacakges. I can clearly see that there is a bug in my packages in that yorick.postrm should certainly not remove files owned by yorick-data, but I don't understand why the files are not reinstalled. That's the (obsolete) thing. Removal of conffiles is supposed to be preserved. I also wonder how to fix this issue best: I guess /etc/yorick files should belong in the package yorick, not yorick-data, but can I simply switch the files from one package to the other? No. You have to remove the files in preinst if their md5sum matches the md5sum in dpkg's status database. Actually it's more complicated if you support dpkg rollbacks. You have to rename them in preinst (if they're unmodified), remove them in postinst (in the normal scenario when everything works), but rename them back to their original name in postrm abort-upgrade. All conditional on their existence, version checks, and md5sum checks. [0] Technically that might not be necessary if the files to be moved are identical between etch and lenny. Justin References [0] http://justinpryzby.com/debian/dpkg/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: In-Program documentation
On Tue, Sep 04, 2007 at 10:37:21PM +0200, Patrick Schoenfeld wrote: Hi there, I'am currently in progress of packaging password-gorilla, which is a tcl/tk application. Well everything is fine so far, except that the application contains menu items LICENSE and HELP which rely on files in the source distribution, which I currently install with dh_installdocs. So basically I need to make these files available to the tcl/tk scripts. But how should I do this properly? 1) Variant 1: I could install the files to /usr/share/doc, but not with dh_installdocs so that they don't get compressed and then link them to the target directory (/usr/share/password-gorilla). 2) Variant 2: Install them to /usr/share/doc AND to the target directory. 3) Variant 3: Install them only to the target directory. It seems to me as if variant 1 would be the only that makes sense. But is this okay? Is there another way to do it? What would you recommend? It's a little known requirement that packages continue to work after /u/s/doc is removed. So it's not allowed to install required files there. You could do (2) or (3) with links *from* u/s/d though. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: In-Program documentation
On Tue, Sep 04, 2007 at 11:49:33PM +, Jörg Sommer wrote: Hi Justin, Justin Pryzby [EMAIL PROTECTED] wrote: It's a little known requirement that packages continue to work after /u/s/doc is removed. So it's not allowed to install required files there. You could do (2) or (3) with links *from* u/s/d though. Where's this written? In the policy? All the packaging requirements and well-accepted recommendations are in policy or otherwise should be :) This one is 12.3: |Packages must not require the existence of any files in |`/usr/share/doc/' in order to function [1]. Any files that are |referenced by programs but are also useful as stand alone |documentation should be installed under `/usr/share/package/' with |symbolic links from `/usr/share/doc/package'. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Advocate needs
On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: Hi all! I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? Hi Alexander, Where are the debian sources? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
review: qstardict (Re: Advocate needs)
On Mon, Sep 03, 2007 at 07:12:18PM +0400, Alexander Rodin wrote: В Пнд, 03/09/2007 в 10:19 -0400, Justin Pryzby пишет: On Mon, Sep 03, 2007 at 06:15:24PM +0400, Alexander Rodin wrote: Hi all! I have develop program (http://qstardict.ylsoftware.com) and maintain Debian package for them. Now I want to put them to Debian. Can anyone to be my advocate? Hi Alexander, Where are the debian sources? Hi, Justin! There is a Debian sources: http://qstardict.ylsoftware.com/files/qstardict-0.07-debian-sources.tar.bz2 . But this have some problem: written by me manpage qstardict.1 don't installs... Some comments. You're the upstream author; why don't you include the manpage upstream instead of in the .diff.gz? I realize that manpages for graphical programs are difficult to write well. Does your program accept keystrokes? Does it have any other help file? Is debian/dirs really necessary? It's probably best if this is handled by upstream install scripts, and debian foo used only as a fallback. Your changelog has two Initial release entries. The second should (by convention) instead read New upstream release.. Since you're the upstream author you can include sub-bullets with the major changes for that release. The copyright file should specify under which versions of the GPL the content is licensed and ideally include the full GPL header (but not the full GPL). doc-base isn't for listing manpage; see dh_installman for how to fix that. Section: universe/devel doesn't make sense for Debian. At least the manpage and rules files should probably have some of their comments removed. Perhaps not all of them though. The only advantage to not removing comments is to easily be able to diff to new templates... +install: build +binary-arch: build install I really wish the redundant dependancy on build was either not specified in the template or that someone would explain to me what purpose it serves. But I already reported it as bug #358722 and apparently knowbody nos. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help with -dbg packages for a library
On Thu, Aug 30, 2007 at 09:29:45AM +0530, Kumar Appaiah wrote: Dear Debian Mentors, I have a specific question with regard to -dbg packages for libraries. My understanding of generating -dbg libraries is like this: 1. We build the package with CFLAGS or CXXFLAGS = -g -O2 (for optimization). 2. We call dh_strip while exluding the dbg package, to ensure that debugging sumbols are present there. I think the suggestion is for all libraries to use dh_strip --dbg-package or -k. Now, my situation is that upstream generates special pkg_debug packages by sending ./configure --enable-debug. While I achieve the desired result with the CFLAGS mentioned above, upstream fears that generating the library with debugging symbols first and then stripping them may result in a slightly reduced performance (it's a numerical computation library). While I am going to run some tests myself to verify this, I just wanted to ask the mentors here about their knowledge of this issue. My *understanding* is that the debug information is in a separate ELF section in the executable. See the strip manpage for details, but you can move the debug sections to a separate file, and distribute such files as separate Debian packages. So people who use the library as just a dependency of some other package (and don't have problems so don't need to debug it) just get the lib, and people who develop with it get lib-dev, and also lib-dbg. So I think there should be no performance difference between running with the libraries compiled without -g, compiled with -g, compiled with -g and stripped, and compiled with -g and debug symbols/sections moved to a separate file. It would be neat if you could compare the ELF files using binutils tools. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: custom boot CD
On Fri, Aug 31, 2007 at 01:09:21AM +0200, Ondrej Certik wrote: Hi, I often have problems installing Debian using the official installer, What remains is my own custom boot CD, with the newest kernel. Since I have already used my code several times by now, I decided to share it with you (you'll also find there a wiki how to install using Deboostrap and Grub in a very short way): http://code.google.com/p/debianiso/ Thanks for sharing. Do you know the debian-live project? Your CD scripts were interesting since they're very compact (~130 lines) whereas d-l is much larger (~11k lines). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package question, disappearing /etc/xinetd.d config file
On Wed, Aug 29, 2007 at 01:12:58PM -0600, Chris Thompson wrote: Hello. I am trying to create a set of debian packages. Everything is going well except that I am trying to add a file into /etc/xinet.d so that the server is started automatically. When I run dpkg -i packagename.deb, I see that it creates a file called quasard.dpkg-new in /etc/xinet.d but by the time the installation is That's the behavior of dpkg for conffiles; at configuration time it looks for .dpkg-new and does the tests for whether to replace or update the conffile, or prompt (only iff both the maintainer and admin updated it, and to different content). complete, this file is removed. That's not expected though.. Strangely, if I set user and group to root, the file is not removed at the end of the install and everything works. Note that I am using /opt/quasar for my directory tree. I set the ownership of this directory to quasar:quasar in my postinst file. I create the user and group quasar in my preinst file. Why in preinst? BTW do you know about the maintainer script rollback actions? http://justinpryzby.com./debian/dpkg/ They're not strictly necessary to implement, but you have to at least check the arguments to make sure you're not doing forwards things in a backwards path (although in many cases this is the right thing to do, I guess that's by deliberate design decision). What am I doing incorrectly? Can you link to your diff.gz? I'm in particular interested in seeing your maintainer scripts. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] stunnel4 (updated package, adoption, RFS repost)
On Sat, Aug 25, 2007 at 11:11:05AM +0530, Kapil Hari Paranjape wrote: Hello, On Thu, 23 Aug 2007, Kapil Hari Paranjape wrote: Package looks fine. I'm currently updating my local pbuilder base and will upload when that is done. Unfortunately, I just realised that there are a few more changes that I think you should make! While looking through your debian/rules I found under the install rules: cd src; $(MAKE) install prefix=$(CURDIR)/debian/stunnel4/usr cd doc; $(MAKE) install prefix=$(CURDIR)/debian/stunnel4/usr 1. I think it is better to use $(MAKE) -C src and $(MAKE) -C doc instead of the cd src; $(MAKE) and cd doc; $(MAKE) constructs. Agreed, but only because you use cd ; make instead of cd make. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package requiring a customised version of another package
On Thu, Aug 23, 2007 at 08:56:50PM +0100, David Given wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Please can you give the details of why this is necessary? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Package requiring a customised version of another package
On Thu, Aug 23, 2007 at 10:26:35PM +0100, David Given wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Pryzby wrote: [...] I have an application I'd like to package --- plasticfs. Unfortunately, due to glibc weirdnesses, it needs a copy of glibc built using custom (non-standard) options. Is this doable, or is it likely to be a lost cause? Please can you give the details of why this is necessary? It's an LD_PRELOAD hack. When glibc calls itself --- for example when fopen() calls open() --- it does so using a hidden private interface, Right, aliases are used when public functions are called internally (I'm not sure the rationale). which means the preloader library doesn't get a chance to override it. plasticfs wants a glibc compiled with --disable-hidden-plt to expose this interface. I still don't understand why? Or so the plasticfs docs say --- I'm sure this can be worked around, since fakeroot and fakechroot fakeroot is just an LD_PRELOAD.. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: cellwriter
On Wed, Aug 22, 2007 at 12:12:46AM +0100, Jonny Lamb wrote: On Tue, 2007-08-21 at 17:37 -0500, Michael Levin wrote: On Tue, 2007-08-21 at 22:38 +0100, Jonny Lamb wrote: * debian/control has a format for homepage URLs, which is *two* spaces then Homepage: http://www.example.com/; I can't find mention of this in either the Policy or the New Maintainer's guide, how is that supposed to look? Does that go in the description or is that one of the control lines (if so, why two spaces in front of it..?) Mm, I've tried to find the mailing list post *I* first read it in lots of times, but have always failed. It's not policy, but I think most do Well it may have been me (perhaps earlier than these). http://lists.debian.org/debian-mentors/2005/12/msg00059.html http://lists.debian.org/debian-mentors/2005/12/msg00084.html Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: How to deliver an binary file
On Sun, Aug 19, 2007 at 12:26:21PM +0200, Christian Welzel wrote: Am Sonntag, 19. August 2007 12:10 schrieb Vincent Bernat: To be able to include it in diff.gz, you need to encode it. You can use But is it such a good idea to put a 120kb encoded file into the diff? I believe i read somewhere this is not a good practise... The encoded filesize will be not less than 4/3 larger anyway. Were you thinking of you mustn't include in the repacked orig.tar.gz any file not distributed upstream or modified by you? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: License issues with md5deep
On Sun, Aug 19, 2007 at 07:06:13PM +0200, Giovanni Mascellani wrote: Hi all! These days I am trying to package md5deep for Debian[1]. Although it is my first compiled package (the other was in Python), I'm not having any technical problem. I have just a bunch of question for you about the license. I don't know if you should write to debian-legal, or you can help me directly. In most (all those I won't discuss in this email) of the sources file there is a notice like this: /* MD5DEEP - algorithms.h * * By Jesse Kornblum * * This is a work of the US Government. In accordance with 17 USC 105, * copyright protection is not available for any work of the US Government. As far as I know, this means that I can safely Debianize this program, simply writing in debian/copyright that it is dropped to the public domain. Yes Anyway, some files are different headings. md5.c reports: /* * This code implements the MD5 message-digest algorithm. * The algorithm was written by Ron Rivest. This code was * written by Colin Plumb in 1993, our understanding is * that no copyright is claimed and that * this code is in the public domain. This writing talks about our understanding. Can I trust this understanding and mark also this file as left in the public domain in debian/copyright? I think there are probably many copies of this md5.c floating around. In fact Debian probably already has them. In fact I suspect that you can find one in in dpkg.. But try to retain the Upstream author for each file as well as copyright holder (if applicable) and license. sha256.c has: /* * FIPS-180-2 compliant SHA-256 implementation * written by Christophe Devine * * This code has been distributed as PUBLIC DOMAIN. * * Although normally licensed under the GPL on the author's web site, * he has given me permission to distribute it as public domain as * part of md5deep. THANK YOU! Software authors are encouraged to * use the GPL'ed version of this code available at: * http://www.cr0.net:8040/code/crypto/sha256/ whenever possible. */ Is it correct to write in debian/copyright that also this file is in the public domain? Yes. For this file also keep the GPL Preferred note. tiger.c looks like a bit more difficult: /* MD5DEEP - tiger.c * * By Jesse Kornblum * *SPECIAL COPYRIGHT NOTICE FOR THIS FILE * (and this file only) * * This code was adapted from GnuPG and is licensed under the * GNU General Public License as published by the Free Software Foundation; * either version 2 of the license, or (at your option) any later version. * * Some functions have been changed or removed from the GnuPG version. * See comments for details. * * This program is distributed in the hope that it will be useful, but * WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. * */ This file is surely GPL and not in the public domain. Isn't illegal to link GPL object code with other non-GPL object code and don't distribute it as GPL? In other words, because of only this GPL file, all the package should be GPL licensed, isn't it? To repeat what Russ said: the majority of your souce package is PD. The resulting binary package (if it links with this file) must be GPL. You should say this in /copyright. In Debianizinig this program, I own a piece of copyright on the final work. Isn't this in contrast with the Lawyer to English clause? I think that the GPL doesn't put restrictions on makesystems. Or are you also modifying some code (nontrivially)? Even so obvious licenses choices for the Debian packaging are GPL and PD which allow you to distribute the binary package as gpl. Thanks, Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: multiget
On Sun, Aug 19, 2007 at 06:20:19PM +0200, Julian Andres Klode wrote: Am Sonntag, den 19.08.2007, 22:55 +0800 schrieb LI Daobing: On 8/16/07, Julian Andres Klode [EMAIL PROTECTED] wrote: Am Mittwoch, den 15.08.2007, 23:50 +0800 schrieb LI Daobing: Dear mentors, I am looking for a sponsor for my package multiget. * Package name: multiget Version : 1.1.4-1 Upstream Author : liubin [EMAIL PROTECTED] * URL : http://multiget.sourceforge.net/ * License : GPL Section : net It builds these binary packages: multiget - graphical download manager The package appears to be lintian clean. The upload would fix these bugs: 388427 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/m/multiget - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/m/multiget/multiget_1.1.4-1.dsc I would be glad if someone uploaded this package for me. Kind regards LI Daobing I am no DD, which means I can not upload it, but I took a look at the package. few things can be improved: - Remove changelog.txt from debian/docs, you install it with dh_installchangelogs - Delete the lines you commented out, this makes it easier to read. - Use Priority: optional Hello, an updated version in mentors.debian.net (fix all above issues), need I repost the RFS? Simply answer to this message with Re: RFS: multiget (still need sponsor) or similar. I attached a diff with a few improvements and a man page. (debdiff.diff.gz) --- multiget-1.1.4/debian/copyright +++ multiget-1.1.4/debian/copyright -Upstream Author: - -liubin [EMAIL PROTECTED] - -Copyright: - -Copyright (C) 2006 liubin - License: +Copyright (C) 2006 liubin [EMAIL PROTECTED] I don't like this change. luibin isn't a license, and it loses the information about the original upstream author (which can differ from the copyright holder). Justin References [0] http://lists.debian.org/debian-mentors/2005/02/msg00371.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: unable to build gdb from source
On Wed, Aug 15, 2007 at 10:46:29AM -0400, Kamaraju S Kusumanchi wrote: Can some one tell me what I am doing wrong here? I am unable to build gdb from source on a machine running sid. I did $apt-get source gdb $cd gdb-6.6.dfsg/ $ dpkg-buildpackage -us -uc -rfakeroot The build log is attached in this email. What puzzles me is that, according to http://buildd.debian.org/fetch.cgi?pkg=gdbver=6.6.dfsg-1arch=i386stamp=1170205364file=log it built just fine. However it does not build on my machine. This machine does not have pbuilder installed so can't check if things improve when I build with it. Any ideas on why this is happening? Should I file a bug? You're apparently trying to build in downloaded packages source/. It contains a space which the make build system didn't handle. IMHO it's a bug, but I suspect many package have similar problems. I supose somebody wants to rebuild the archive and find out? Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tango package
On Tue, Aug 14, 2007 at 03:38:25PM +0200, picca wrote: On Tue, 7 Aug 2007 14:25:13 +0200 PICCA Frédéric-Emmanuel [EMAIL PROTECTED] wrote: Dear mentors, I am looking for a feedback on my tango package, it is not yet finished but as it use a mysql database and this is my second package, I asked here for critical views on it. It builds 2 libraries liblog4tango4 ans libtango5 and tango-db install the tango-ds service. It builds these binary packages: liblog4tango4 - C++ library for tango logging (runtime) liblog4tango4-dev - C++ library for tango logging (runtime) libtango5 - C++ library of the TANGO distributed control system (runtime) libtango5-dev - C++ library of the TANGO distributed control system tango-db - The Tango Database device - URL: http://mentors.debian.net/debian/pool/main/t/tango I need a working Mysql server to install the tango-db package. Must I put a pre-dep on mysql ? Probably not the right solution. Pre-dependencies should be rare. Also you should support the general case where the SQL server is on a remote host (not local). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: tango package
On Tue, Aug 14, 2007 at 05:54:38PM +0200, picca wrote: On Tue, 14 Aug 2007 09:48:21 -0400 Justin Pryzby [EMAIL PROTECTED] wrote: u should support the general case where the SQL server is on a remote host (not local). Yes when writing the post I tell to miself but if I want to use a mysql server on a remote host. Do you have exemple of package doing this ? I guess dbconfig-common is the framework so apt-cache rdepends that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: force-overwrite in pdebuild
On Sun, Aug 05, 2007 at 06:48:49PM +0200, Gudjon I. Gudjonsson wrote: Hi I was trying to rebuild my packages against a new version of library but there is a bug in the libraries that one file is in two packages. Is there any way of letting pdebuild force and overwrite of files? You can either run dpkg --force-overwrite while installing it (preferrably with only one package for finer-grained control of when the force is in effect). Or add Replaces: foo to the package to be installed, which will cause the file to be removed from the already-installed packages file list (/v/l/dpkg/info). If you remove the 2nd package before the 1st package though, the file will be gone (and the copy from the 1st package will not be put back into place). I note that Conflicts+Replaces is a special overloaded case that means cause that package to be completely removed. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Replacing aclocal.m4
On Mon, Aug 06, 2007 at 12:17:26PM +0100, David Given wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm current packaging ufiformat, a USB floppy disk formatter (#436134). It's nearly at the stage of looking for a sponsor, but before that happens I'd like to sound people out about something. I needed to change Makefile.am to tell it to install the binary in the right place. When rebuilding, autotools whinged about aclocal.m4 being too old and that I should regenerate it, which I did. Now the (compressed) patch file is 80+kB, only slightly smaller than the source code itself, and is almost entirely comprised of the new aclocal.m4. Is this acceptable, or does it need addressing? If so, how? It's acceptable and preferred by some. Otherwise you can depend on autotools-dev and run them at build time, and remove the generated files at clean time to get a small diff. autotools-dev/README.DEBIAN discusses such. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: open-invaders
On Tue, Jul 31, 2007 at 03:33:40PM +0200, Siegfried-Angel wrote: Hi, Thanks for looking at it Alexander, and sorry that I did not answer before but I wasn't subscribed to this list and so did not see your reply before. I fixed everything you said (it's online on mentors.deban.net [1]) except point 3, that one about the architecture independent stuff. You mean that the data should be in a separate binary package (open-invaders-data)? If so, could you appoint me to a tutorial on how to do that? (I looked at the contents of the Debian New Maintainer's Guide but it doesn't look like there's anything related to that). Also, currently the game is only building on i386 (upstream author promised to fix that, but it may still need some time), so is this necessary now? Maybe this will help? http://lists.debian.org/debian-mentors/2005/11/msg00042.html Or check some multiple-binary packages [0], or just the ./debian/control output of dh_make m. The architecture problems are kind of disappointing.. Justin [0] Ones for which there are multiple Binary packages listed for the given source Package in apt-cache showsrc output. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sponsor Checklist
On Tue, Jul 31, 2007 at 05:53:49PM +0100, Neil Williams wrote: On Mon, 30 Jul 2007 21:40:26 -0500 Manoj Srivastava [EMAIL PROTECTED] wrote: Hmm. Since the DD/sponsor is the one who creates the uploaded packages, they do not have to insis; they can just make it so. I hope DD's do the actual tend build/clean/rebuild/piuparts-run personally. I can never run piuparts - it just takes far too long over my crippled internet connection. Isn't there some way of getting piuparts to use the cached archives like pbuilder does? Perhaps apt-cacher? It uses /var/cache/apt-cacher/ though perhaps it could use .../apt/ I don't know if this would pull in things downloaded by apt and not -cacher.. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On Fri, Jul 20, 2007 at 03:36:56PM +0200, François Févotte wrote:
Hello,
On 7/20/07, Carl Fürstenberg [EMAIL PROTECTED] wrote:
lintian spits out warnings about -x flag on the py-files, as they all
has a shebang, also the setup.py generates a cgpdfpng that only will
work under OSX, but I don't know a good way to fix that.
to remove unneeded shebang lines, I usually use a small perl script
called at the end of debian/rules. I find this much more flexible than
maintaining a set of patches.
Or sed -i -re '1{/^#!/d}'
I note that sed -n -i is a dangerous combination..
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plastex
On Tue, Jul 24, 2007 at 11:01:06PM +0200, Carl Fürstenberg wrote:
On 7/24/07, Justin Pryzby [EMAIL PROTECTED] wrote:
Or sed -i -re '1{/^#!/d}'
I note that sed -n -i is a dangerous combination..
How do you handle clean target then?
Do you mean how can you reverse the change to satisfy the policy
requirement that the sources, after clean, are indistinguishable from
the sources before? Well, you can simply run the sed on only the
./debian/$package/{,usr/}{,s}bin/* since the whole installation
tree[s] are removed anyway. I think any build-time munging of scripts
consistent with strict interpretation of this section of the policy
will have to act on ./debian/$package/ only or do something much less
elegant.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: command-not-found
On Sun, Jul 01, 2007 at 10:08:47PM +0200, Julian Andres Klode wrote: Dear mentors, I am looking for a sponsor for my package command-not-found. * Package name: command-not-found Version : 0.2.4+debian-1 Upstream Author : Zygmunt Krynicki [EMAIL PROTECTED] Michael Vogt [EMAIL PROTECTED] * URL : https://launchpad.net/command-not-found * License : GPL Section : admin It builds these binary packages: command-not-found - Suggest installation of packages in interactive bash sessions How does it compare with auto-apt? This a shell-only implementation whereas auto-apt will find things which are accessed otherwise (perhaps not bad). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: shared libraries and _REENTRANT
On Fri, Jun 22, 2007 at 02:11:25PM -0400, Felipe Sateler wrote: Policy 10.2 says we must compile shared libraries with -D_REENTRANT: You must specify the gcc option -D_REENTRANT when building a library (either static or shared) to make the library compatible with LinuxThreads. However, LinuxThreads has been superseeded by NPTL. Is this still necessary? I think Michael Kerrisk of man-pages upstream may have wondered the same thing? Also, when a library ships a .pc file, should it include the option in its CPPFLAGS? It's only necessary for compilation of libraries since they might be linked to apps or other libraries which are threaded. So it should probably not be specified in .pc which would make all apps/libs use it. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Converting a config file into a conffile
On Tue, Jun 19, 2007 at 02:37:14PM +0200, Stefan Fritsch wrote:
Hi,
I have a package with a config file that is created by postinst, and I
would like to convert this file into a conffile that is handled by dpkg.
Is there a way to achieve this in a way so that dpkg will silently replace
the postinst-created default version with the new conffile? I expect that
normally it will ask the user what to do if I just start shipping a
conffile.
I anticipate that you copied the config file into place from /u/share/
(not /u/s/doc/) if it doesn't exist, and if dpkg lists some relevent
version.
In this case, you can remove it in preinst if its MD5sum matches the
value of the initially copied file. Don't touch it if it doesn't
match; this will cause the user to be prompted, as intended for a
conffile modified by both the admin and the maintainer.
You should then implement rollbacks in postrm to unremove the file
in case there's an error. Actually the preinst should just mv
foo{,.old} then the postrm abort-upgrade mv foo{.old,} and the
postinst configure rm -f foo.old.
Further reading:
http://justinpryzby.com/debian/dpkg/
http://wiki.debian.org/DpkgConffileHandling
I believe UCF will also handle this (but I've never used it).
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: mantis (updated package w/ security fix)
On Tue, Jun 19, 2007 at 10:12:47PM -0400, Kevin Coyner wrote: I am looking for a sponsor for the new version 1.73-4 of my package libphp-phpmailer. My normal sponsor for this package seems unavailable presently and this upload is rather important in that it fixes a security hole. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429179 regarding CVE-2007-3215. It builds this binary package: libphp-phpmailer - full featured email transfer class for PHP I believe I've prepared this appropriately. In debian/changelog I set urgency to 'high'. I know this will get it into unstable on an expedited basis, but am unsure how to get the fix into stable. You meant: testing, not unstable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: kicad (updated package)
On Fri, Jun 15, 2007 at 10:31:01AM +0100, Richard A Burton wrote: On 15/06/07, Paul Wise [EMAIL PROTECTED] wrote: A drive-by diff review: Do I need to increment the Debian part of the version number to upload to the mentors site? I'd assume it'd be happy with another upload of -1 since it's not been released, and it seems silly to keep incrementing it while testing things out with a mentor, plus above -1 it won't want to upload the orig source. dpkg-buildpackage -sa overrides that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where does /usr/bin/rename come from ?
On Thu, Jun 14, 2007 at 01:35:50PM +0900, Charles Plessy wrote: Dear mentors, I wanted to use /usr/bin/rename in a rules files, and wondered if it would be present in minimal installs and chroots. To my surprise, although this program is available on my computer running Etch from a fresh install, no Debian package contains rename anymore (it was provided by perl in Sarge). Can I use it safely for building a package since I can not build-depend on it and it does not seem to be contained in an essential package ? I think this says it all? $ dpkg -S $(readlink -f `which rename`) perl: /usr/bin/prename -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some help with watch files again
On Wed, Jun 06, 2007 at 01:24:11AM +0200, Daniel Leidert wrote: Hi, I'm again stuck with a debian/watch file. In this special case I try to write watch files for garlic and garlic-doc. The sources can be found at: http://garlic.mefos.hr/sources/ So I tried the following: version=3 http://garlic.mefos.hr/sources/garlic-([\d\.]+)/garlic-([\d\.]+).tar.gz I don't know if there's a better way: |version=3 |opts=downloadurlmangle=s:\./([^/]+)$:$1/$1.tar.gz: \ | http://garlic.mefos.hr/sources/ \ | ./garlic-([\d.]+) Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need some help with watch files again
On Tue, Jun 05, 2007 at 10:25:25PM -0400, Justin Pryzby wrote: On Wed, Jun 06, 2007 at 01:24:11AM +0200, Daniel Leidert wrote: Hi, I'm again stuck with a debian/watch file. In this special case I try to write watch files for garlic and garlic-doc. The sources can be found at: http://garlic.mefos.hr/sources/ So I tried the following: version=3 http://garlic.mefos.hr/sources/garlic-([\d\.]+)/garlic-([\d\.]+).tar.gz I don't know if there's a better way: |version=3 |opts=downloadurlmangle=s:\./([^/]+)$:$1/$1.tar.gz: \ | http://garlic.mefos.hr/sources/ \ | ./garlic-([\d.]+) Well, I don't know if this is better, but: |version=3 | http://garlic.mefos.hr/sources/([^-]*-[^-]*)/ \ | ./garlic-([\d.]*).tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Prompt to install missing software?
On Sun, May 27, 2007 at 02:17:15PM +1000, John Pye wrote: Hi all, I have a PyGTK-based program that has an optional dependency on the package python-matplotlib. Is there any way under Debian (and hopefully also Ubuntu) that I can trigger gtk-debi or something like that when the user requests to use the part of my program that depends on stuff they haven't installed yet? a la auto-apt? Note: doesn't play well with bash_completion -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of configuration files not shipped with a newer package version
On Sat, May 26, 2007 at 03:00:31PM +0200, Daniel Leidert wrote: Am Samstag, den 26.05.2007, 00:36 -0400 schrieb Justin Pryzby: On Sat, May 26, 2007 at 04:08:32AM +0200, Daniel Leidert wrote: , purging docbook-xml will not purge all configuration directories anymore: dpkg - warning: while removing docbook-xml, directory `/etc/xml' not empty so not removed. I think this should work with etch dpkg? Tested in an Etch pbuilder chroot. It produces the warnings I posted. dpkg -L does list /etc/sgml/docbook-xml/3.1.7/dbgenent.ent as part of docbook-xml after update, but it doesn't list /etc/sgml/docbook-xml/3.1.7 anymore. A mis-behaviour of dpkg? I think the logic is supposed to be that dpkg doesn't warn until after postrm purge phase, since the maintscripts are supposed to act as a kind of dpkg module and the user shouldn't be bugged just because there's a config file which is not a conffile. Also added I think was that dpkg would keep reattempting removal of dirs at relevant times after the first attempt after the conffiles in that dir were removed. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Handling of configuration files not shipped with a newer package version
On Sat, May 26, 2007 at 04:08:32AM +0200, Daniel Leidert wrote: Hi, The docbook-xml package 4.4 shipped a really old version 3.1.7, that was dropped with package version 4.5. The package itself ships a configuration file for every released version: [ Note: Is it a conffile. ] [..] /etc /etc/sgml /etc/sgml/docbook-xml /etc/sgml/docbook-xml/3.1.7 /etc/sgml/docbook-xml/3.1.7/dbgenent.ent [..] Now what is the best/recommended way to handle the removal of the 3.1.7 version? A normal upgrade tries to remove the directory /etc/sgml/docbook-xml/3.1.7, which is impossible, because /etc/sgml/docbook-xml/3.1.7/dbgenent.ent still exists. Although dpkg still knows, that the file belongs to docbook-xml You can check the page that used to be at dpkg.org regarding removal of an obsolete conffile. Basically you check: [ -e $f ] dpkg --compare-version [ `md5sum $f |sed -e 's/ .*//` = $oldmd5 ] rm -iv $f or such. http://wiki.debian.org/DpkgConffileHandling , purging docbook-xml will not purge all configuration directories anymore: dpkg - warning: while removing docbook-xml, directory `/etc/xml' not empty so not removed. I think this should work with etch dpkg? because it doesn't try to remove /etc/sgml/docbook-xml/3.1.7 anymore. How is such a situation handled best? I guess, I must add at least some code to postrm to make sure these directories are removed too, if /etc/sgml/docbook-xml/3.1.7 still exists. But should I try to remove this obsolete directory already during upgrade? Conditional on the above .. conditions, yes. Should I ask the user via debconf? This would be considered an overuse of debconf. Justin -- 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 Sat, May 05, 2007 at 03:07:53PM +0200, Marc Haber wrote: 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? 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. 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. In fact the template debian/rules created by dhmake does this: |binary-common: [... dh foo ...] |# Build architecture independant packages using the common target. |binary-indep: build-indep install-indep |$(MAKE) -f debian/rules DH_OPTIONS=-i binary-common | |# Build architecture dependant packages using the common target. |binary-arch: build-arch install-arch |$(MAKE) -f debian/rules DH_OPTIONS=-s binary-common The debhelper commands look at the DH_OPTIONS from the environment so the arch/indep targets do different things and build different packages. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Removing an obsolete symlink
On Tue, Apr 24, 2007 at 10:10:29AM +, Sam Morris wrote: On Tue, 24 Apr 2007 11:38:04 +0200, Thijs Kinkhorst wrote: My question is how to deal with this legacy symlink. I can just rm it on upgrade, but the admin might have put a different symlink there, or depends on the symlink to keep phpmyadmin configured. Remove it on upgrade if it still points to the same place (check with readlink) and document the change in NEWS.Debian? And echo Removing link: $l = $m 2 in postinst -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Wrapper script
On Tue, Apr 24, 2007 at 11:33:15AM +0200, Manuel Prinz wrote: Hi everyone, I ITP a package that provides a single binary that expects its input file named in a special way, and writes two files with fixed names. One of those is only temporary and not really usefull, so one usually deletes it. I thought of writing a wrapper script, so the user can give the input and output filename, the renaming would be done by the script, as well as taking care of not overriding files if they already exist. Okay, it would be good to provide an option to inhibit deletion of the file, and it would be good if the renames would be guaranteed to be on the same filesystem and thus atomic. Also be sure to use exec if this is a shells script, so you don't have a needless bash process which is hanging around just going to do wait(); exit(); Are there any guideline how this is done? I've seen packages using foo.bin for the original binary and foo for the wrapper script, or some using a different location such as /usr/lib/foo/bin for the binary. Or should one leave the binary as foo to provide the know behavior and use foo-wrapper for the script? These are all possibilities from which to choose depending on your goals. Another possibility is to make source changes to support --input, --output, --[no-]remove. I'd also be glad if you could point me out to some good source of how to use /tmp in a secure way in scripts; The important thing is that (at a low level) you open files with O_CREAT|O_EXCL. If you do this, it is safe: you won't clobber any existing file. If you don't, it is unsafe. See also this manpages bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368501 I'd like to run the binary there because I'm not a fan of joking around in the filesystem. Check if TMPDIR is set, and use it instead. Any advise would be very welcome! The Debian tools to create tempfiles are tmpfile and mktemp. These will use /tmp by default, and handle TMPDIR. Or, if you put the tempfiles in the same dir as the final pathnames, then you can do mv and it will be atomic. Or, you can use mkdtemp -d to make a directory directly below the final pathname (also guaranteed to be on the same FS). Since it's a new dir, you can assume it's empty. If ther user modifies things in it you can assume they know what they're doing. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Creating a source tarball for repackaged source using dpkg-source -b
On Thu, Mar 15, 2007 at 12:22:12PM +, Ben Hutchings wrote: On Fri, 2007-03-09 at 23:50 +, James Westby wrote: snip 4. Run tar czf package_upstream-version.dfsg.orig.tar.gz \ package-upstream-version.orig/ (adjusting paths appropriately) I have never checked that tar czf actually produces gzip -9 files, so you might need to form a pipeline if not. snip It doesn't. The pipeline would be: tar cf - $source_dir | gzip -c9 $tarball Or set GZIP=-9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Claiming a binary name used in Sarge but not in Etch.
On Sun, Mar 18, 2007 at 09:50:16AM +0900, Charles Plessy wrote:
Le Sat, Mar 17, 2007 at 01:02:46PM -0400, Justin Pryzby a écrit :
On Sat, Mar 17, 2007 at 08:12:47PM +0900, Charles Plessy wrote:
Le Sat, Mar 17, 2007 at 12:00:20PM +0100, Florent Rougon a écrit :
Charles Plessy [EMAIL PROTECTED] wrote:
#!/bin/sh
echo -e AMAP is now available under /usr/bin/amap.\nThis wrapper
(/usr/bin/amap-align) will be removed in the future.
exec /usr/bin/amap $@
'echo -e' is not specified by POSIX. If you want to use escapes such as
\n, you'd better use printf instead of echo.
Thanks a lot, I will use one echo per line.
set -e
{
echo first line
echo second line
} 2
Oh, this is something I did not think about. But what is the set -e
doing?
It's essentially required for all scripts to be able to detect errors.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debian/prerm is executed on *reconfigure*?
On Fri, Mar 16, 2007 at 03:52:18PM +0100, schönfeld / in-medias-res.com wrote: Hi mentors, hi Dpkg developers, i could need some help with a bug that has been reported to be in one of my packages. According to #408823 my package removes a configuration file when dpkg-reconfigure is invoked. I'm really wondering about this, because that means that dpkg invokes my prerm script if it is called with dpkg-reconfigure. Is this behaviour of dpkg correct? This is the documented interface and intentional behavior. dpkg prerm is invoked before the removal of an *instance* of a package. It can be called with arguments including (but not limited to): remove, deconfigure, and upgrade. If it is. What do i need to do, so that my prerm script does not cause harm, when called during this stage? You probably don't want to remove config files during the upgrade, and you should really handle all the cases individually unless you know that they should be the same. Justin References [0] http://justinpryzby.com/debian/dpkg/ [1] new dpkg maintscripts file:///var/lib/dpkg/info/dpkg.p* [2] old debian-policy maintscripts [3] debian-polciy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need help packaging
On Tue, Mar 13, 2007 at 05:38:41PM -0400, Jean-Sebastien Pilon wrote: Hello, Can someone spend a few minutes explain how to create a debian package from binary files ? I have read the documentation on debian.org and many howto on the web, it is too advanced for what I am trying to achieve, and a little help would be appreciated. I had an rpm, converted to .deb using alien. Extracted files off the package using dpkg --contents, since I want to add some more files to the package. ( actually merge things together and add default configuration that suits us ) I extracted the control files as well... And I have this control md5sums postinst postrm prerm shlibs From here I am not sure what I should do... Should I put everything together, add my files and then do a dpkg --build off the root of the packaging directory ? Binary packages are not considered to be particularly useful unless they're derived from a source package. You won't be able to get a binary only package uploaded. But, if that's what you want, then you can use dpkg -b. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Claiming a binary name used in Sarge but not in Etch.
On Sat, Mar 10, 2007 at 12:32:29PM +0900, Charles Plessy wrote: Dear mentors, When I created the package amap-align (bioinformatics), there was a already a program called amap in Debian. Therefore, I renamed the binary program of my package. However, the old amap package has been removed from Etch, so I would like to know if it is possible to provide our users the bioinformatical program amap under its real name, and not amap-align as it is the case for the moment. Also removed from unstable: RoM; non-free. So it seems unlikely to return (that's important). http://ftp-master.debian.org / removals What is the policy of Debian for pacakges which are not released anymore? Can I Conflict:amap with my package amap-align, and request the upgraded package to be hinted in Etch ? Importantly, there is little overlap between the field of usage of amap and amap-align, so I think that the conflict is unikely to happen in real life. (can popcon be mined for this kind of data ?). The popcon interface can't, but if you mail the popcon group, they might be willing to check for hosts with both installed, and of those with recent access times. Also, I think that I should inform users that the name has changed, can I use NEWS for this ? Lastly, do I have to support the old /usr/bin/amap-align for some moment, as it was never released in a stable distribution ? For instance, I can provide a wrapper which issues a warning. http://packages.qa.debian.org/a/amap.html http://packages.qa.debian.org/a/amap-align.html A NEWS entry isn't unreasonable. Supporting the old binary might be nice; a wrapper with a warning rather than a symlink is extra friendly. Be sure to use exec as the last line of a wrapper script to remove unnecessary memory footprint. Cheers Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repost: RFC and preliminary RFS: prayer webmail
On Sat, Mar 10, 2007 at 08:05:55PM +0100, Magnus Holmgren wrote: Something I've been thinking about: If two packages share a /var/(lib|run|log) subdirectory, how do you know when to remove it? I reckon that it should be removed when the last of the packages has been purged. Both packages place files there at runtime, so dpkg won't remove it since it's nonempty. But you can't just remove it in postrm if it's empty. Do you: a) leave it alone; let root delete it manually when it's no longer needed b) use dpkg -S to see if it's still in use c) use dpkg -l to see if the other package is still installed d) avoid sharing directories under /var e) do something else? The easy thing to do is to include it in the package, rather than creating it in maintainer scripts. Then dpkg leaves it alone if another package also includes (and in recent releases may even succeed in not warning you). I think there are cases where it is advantageous not to include it, but they don't occur to me presently.. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Repost: RFC and preliminary RFS: prayer webmail
On Sat, Mar 10, 2007 at 10:19:57PM +0100, Magnus Holmgren wrote: On Saturday 10 March 2007 21:37, Justin Pryzby wrote: On Sat, Mar 10, 2007 at 08:05:55PM +0100, Magnus Holmgren wrote: Something I've been thinking about: If two packages share a /var/(lib|run|log) subdirectory, how do you know when to remove it? I reckon that it should be removed when the last of the packages has been purged. Both packages place files there at runtime, so dpkg won't remove it since it's nonempty. But you can't just remove it in postrm if it's empty. Do you: a) leave it alone; let root delete it manually when it's no longer needed b) use dpkg -S to see if it's still in use c) use dpkg -l to see if the other package is still installed d) avoid sharing directories under /var e) do something else? The easy thing to do is to include it in the package, rather than creating it in maintainer scripts. Then dpkg leaves it alone if another package also includes (and in recent releases may even succeed in not warning you). I think there are cases where it is advantageous not to include it, but they don't occur to me presently.. The directory is included in the packages, that's why I wrote that dpkg won't remove it. The problem is that postrm purge is called after dpkg removes the last of a package's files. Thus we have to delete not only the files, but also the directories, that are not deleted already in postrm remove. dpkg will remove it, if it's included in the package, if there are no conffiles (this [should] only happen[s] when it's in /etc) or other dpkg files, and (naturally) if it's empty. I think the recent change for etch was to retry removal of non-shared directories for which removal failed during remove during purge and only warn if they failed both times. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where to mention, when several tarballs are merged into one .orig.tar.gz
On Sun, Mar 04, 2007 at 02:22:02AM +0100, Daniel Leidert wrote: Hello, For docbook-xsl I merge two tarballs together docbook-xsl-x.y.z.tar.gz and docbook-xsl-doc-x.y.z.tar.gz. Where should I mention this? debian/README.Debian or better debian/copyright? copyright for sure, perhaps also README.Debian if it exists for other things too. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Versionned dependancies on build-essential packages. (was: Re: Where did Bacula 1.38.11-7+b1 come from?)
On Sat, Feb 24, 2007 at 04:35:44PM +0900, Charles Plessy wrote:
Le Fri, Feb 23, 2007 at 07:30:38PM +0100, Andreas Metzler a ?crit :
Build-Depends: dpkg-dev (=1.13.19)
Package: foo
Architecture: all
Depends: foo-binary (= ${source:Version}), foo-binary (
${source:Version}.1~), foo-doc (= ${source:Version})
Package: foo-binary
Architecture: any
Depends: foo-data (= ${source:Version})
Package: foo-doc
Architecture: all
[Thread from -devel diverted to -mentors.]
Hi,
I was just wondering the reason why the build-dependancy on dpkg-dev is
necessary. Dpkg-dev is build-essential and is 1.13.19 in unstable and
testing anyway. Couldn't this be safely omitted when uploading for
unstable ?
For unstable, yes. For backports perhaps or self-documentation. I
would guess that it uses the likes of ${Source:Version}.
Justin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
