Bug#569521: ITP: groundcontrol -- Launchpad integration for Nautilus
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: groundcontrol Version : 1.4 Upstream Author : Martin Owens * URL : https://launchpad.net/groundcontrol * License : GPL-3+ Programming Lang: Python Description : Launchpad integration for Nautilus Launchpad Ground Control provides a Nautilus workflow for working with Launchpad and Bazaar and allowing users to collaborate with projects in a much easier and defined way. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569519: ITP: groundcontrol -- Launchpad integration for Nautilus
Package: wnpp Severity: wishlist Owner: Luke Faraone * Package name: groundcontrol Version : 1.4 Upstream Author : Martin Owens * URL : https://launchpad.net/groundcontrol * License : GPL-3+ Programming Lang: Python Description : Launchpad integration for Nautilus Launchpad Ground Control provides a Nautilus workflow for working with Launchpad and Bazaar and allowing users to collaborate with projects in a much easier and defined way. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
initial packages with multiarch paths
While trying to prepare a multiarch version of libdbus I received some
conflicting advice about how much of the multiarch proposal is already
allowed by Policy, so I've prepared a multiarch version of a rather
simpler library (libgfshare) as a starting point.
Does this look OK for upload to experimental, and if not, what changes
are needed?
Regards,
Simon
Source debdiff
==
dpkg-source: warning: extracting unsigned source package
(/home/smcv/src/debian/build-area/libgfshare_1.0.3-2+multiarch.dsc)
diffstat for libgfshare-1.0.3 libgfshare-1.0.3
changelog |9 +
control|1 +
libgfshare-dev.install |6 +++---
libgfshare1.install|2 +-
rules |5 +
5 files changed, 19 insertions(+), 4 deletions(-)
diff -Nru libgfshare-1.0.3/debian/changelog libgfshare-1.0.3/debian/changelog
--- libgfshare-1.0.3/debian/changelog 2010-02-11 22:44:07.0 +
+++ libgfshare-1.0.3/debian/changelog 2010-02-11 22:56:50.0 +
@@ -1,3 +1,12 @@
+libgfshare (1.0.3-2+multiarch) UNRELEASED; urgency=low
+
+ * Install the library to the multiarch path, e.g. /usr/lib/i486-linux-gnu/
+(but move the pkg-config file back to /usr/lib/pkgconfig since pkg-config
+doesn't yet look in multiarch locations)
+ * Set the shared library package to be Multi-Arch: same
+
+ -- Simon McVittie Thu, 11 Feb 2010 22:56:02 +
+
libgfshare (1.0.3-2) unstable; urgency=low
* Migrate to collab-maint git
diff -Nru libgfshare-1.0.3/debian/control libgfshare-1.0.3/debian/control
--- libgfshare-1.0.3/debian/control 2010-02-11 22:44:07.0 +
+++ libgfshare-1.0.3/debian/control 2010-02-11 22:56:50.0 +
@@ -31,6 +31,7 @@
bringing the three computers together.
Package: libgfshare1
+Multi-Arch: same
Architecture: any
Section: libs
Depends: ${shlibs:Depends}, ${misc:Depends}
diff -Nru libgfshare-1.0.3/debian/libgfshare1.install
libgfshare-1.0.3/debian/libgfshare1.install
--- libgfshare-1.0.3/debian/libgfshare1.install 2010-02-11 22:44:07.0
+
+++ libgfshare-1.0.3/debian/libgfshare1.install 2010-02-11 22:56:50.0
+
@@ -1 +1 @@
-debian/tmp/usr/lib/*.so.*
+debian/tmp/usr/lib/*/*.so.*
diff -Nru libgfshare-1.0.3/debian/libgfshare-dev.install
libgfshare-1.0.3/debian/libgfshare-dev.install
--- libgfshare-1.0.3/debian/libgfshare-dev.install 2010-02-11
22:44:07.0 +
+++ libgfshare-1.0.3/debian/libgfshare-dev.install 2010-02-11
22:56:50.0 +
@@ -1,5 +1,5 @@
-debian/tmp/usr/lib/*.so
-debian/tmp/usr/lib/*.a
+debian/tmp/usr/lib/*/*.so
+debian/tmp/usr/lib/*/*.a
debian/tmp/usr/include/libgfshare.h
-debian/tmp/usr/lib/pkgconfig/*.pc
+debian/tmp/usr/lib/*/pkgconfig/*.pc usr/lib/pkgconfig
debian/tmp/usr/share/man/man5/*
diff -Nru libgfshare-1.0.3/debian/rules libgfshare-1.0.3/debian/rules
--- libgfshare-1.0.3/debian/rules 2010-02-11 22:44:07.0 +
+++ libgfshare-1.0.3/debian/rules 2010-02-11 22:56:50.0 +
@@ -1,5 +1,7 @@
#!/usr/bin/make -f
+DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
+
%:
dh $*
@@ -7,6 +9,9 @@
dh_clean
rm -rf pdf html
+override_dh_auto_configure:
+ dh_auto_configure -- --libdir=/usr/lib/$(DEB_HOST_GNU_TYPE)
+
override_dh_auto_build:
dh_auto_build
install -d pdf html
libgfshare.pc
=
# Copyright (c) Daniel Silverstone 2006
prefix=/usr
exec_prefix=${prefix}
libdir=/usr/lib/i486-linux-gnu
includedir=${prefix}/include
Name: libgfshare
Description: Secret Sharing in gf(2^8) library.
Version: 1.0.3
Libs: -L${libdir} -lgfshare
Cflags: -I${includedir}
Binary debdiff
==
Files only in first set of .debs, found in package libgfshare-dbg
-
-rw-r--r-- root/root /usr/lib/debug/usr/lib/libgfshare.so.1.0.3
Files only in first set of .debs, found in package libgfshare-dev
-
-rw-r--r-- root/root /usr/lib/libgfshare.a
lrwxrwxrwx root/root /usr/lib/libgfshare.so -> libgfshare.so.1.0.3
Files only in first set of .debs, found in package libgfshare1
--
-rw-r--r-- root/root /usr/lib/libgfshare.so.1.0.3
lrwxrwxrwx root/root /usr/lib/libgfshare.so.1 -> libgfshare.so.1.0.3
New files in second set of .debs, found in package libgfshare-dbg
-
-rw-r--r-- root/root
/usr/lib/debug/usr/lib/i486-linux-gnu/libgfshare.so.1.0.3
New files in second set of .debs, found in package libgfshare-dev
-
-rw-r--r-- root/root /usr/lib/i486-linux-gnu/libgfshare.a
lrwxrwxrwx root/root /usr/lib/i486-linux-gnu/libgfshare.so ->
libgfshare.so.1.0.3
New files in second set of .debs, found in package libgfshare1
---
Bug#569501: ITP: haskell-happstack -- Haskell web application stack
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: mascell...@poisson.phc.unipi.it Package name: haskell-happstack Version: 0.4.1 Upstream Author: Happstack team URL: http://hackage.haskell.org/package/happstack License: BSD Description: Haskell application server stack Happstack is a web application stack written in Haskell. Application running on Happstack are written in Haskell themselves, and can store data in terms of Haskell structures directly on Happstack, in a database-independent manner. Happstack will be made of several packages. Individual ITPs will be filed for them as soon as other dependencies get packaged. Rationale: is a dependency of gitit (bug #556099). Regards, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Bug#569508: ITP: haskell-hsx -- Haskell support for XML in source code
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org Owner: mascell...@poisson.phc.unipi.it Package name: haskell-hsx Version: 0.6.1 Upstream Author: Niklas Broberg URL: http://hackage.haskell.org/package/hsx License: BSD Description: Haskell support for XML in source code HSX (Haskell Source with XML) allows literal XML syntax to be used in Haskell source code. The trhsx preprocessor translates .hsx source files into ordinary .hs files. Literal XML syntax is translated into function calls for creating XML values of the appropriate forms. trhsx transforms literal XML syntax into a series of function calls. Rationale: is a dependency of happstack (bug #569501). Regards, Giovanni. -- Giovanni Mascellani Pisa, Italy Web: http://poisson.phc.unipi.it/~mascellani Jabber: g.mascell...@jabber.org / giova...@elabor.homelinux.org signature.asc Description: OpenPGP digital signature
Re: debian/rules clean as root or non-root?
Jan Hauke Rahm writes: > On Thu, Feb 11, 2010 at 07:42:37AM +0100, Goswin von Brederlow wrote: >> Sven Joachim writes: >> >> > On 2010-02-10 21:37 +0100, Goswin von Brederlow wrote: >> > >> >> Sven Joachim writes: >> >> >> >>> On 2010-02-10 19:02 +0100, Goswin von Brederlow wrote: >> >>> >> I often see sources where debian/rules clean aborts claiming it needs to >> be run as root. So then I run it with fakeroot. But if the source was >> previously build as root then running fakeroot debian/rules clean might >> not be enough. I think the existing dh_testroot helper is insufficient >> and anoying for the job. >> >>> >> >>> It is both insufficient and unnecessary, I don't use it in my packages. >> >>> Neither does "dh clean", BTW. >> >> >> >> If you build the package as real root and it creates a new directory >> >> (like installing into debian/package/ always does) then you can not >> >> clean without being real root. So the check isn't unnecessary. >> > >> > Yes, and dh_clean will almost certainly fail in such a situation. >> > Unless, maybe, you went to the insanity of running the build target with >> > real root rights. >> >> That is usualy what happens. Haven't yet completly tought my coworkers >> to always build packages as user. > > Well, then do so. :) > >> The extended dh_testroot I suggested would also catch cases where the >> package was build by another user I think. Might need some tuning (chmod >> 770?) to allow building by multiple users in a common group and setgid >> bit set. > > It would catch those cases, BUT working on files that don't belong to > you can always lead to weird behavior, especially if you have a mix of > files owned by you and others. This is not packaging related but an > issue with your rights management (and workflow maybe). I don't think it > makes sense to solve it in debian/rules anyhow. > >> >> If you did run only debian/rules build as root the error might >> >> get ignored and lost in the output. >> > >> > Why would anyone want to run the build target as root? If you do that, >> > even running the clean target as root might not give you a state where >> > you can build the package as a normal user again. >> > >> > Sven >> >> It happens. The important part would be to clearly catch such a case. I >> can then delete the working dir and unpack the source again or check it >> out again. > > debian/rules clean should provide you with exactly the same you had > after unpacking. If the files didn't belong to you then, they don't > belong to you now. There is nothing to catch here. Work in your own > $HOME :) > > Hauke But it doesn't. It fails to delete some files and the error is ignored. Then on build old files will be used or, with luck, the build fails in strange ways. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/rules clean as root or non-root?
Sven Joachim wrote: > Why would anyone want to run the build target as root? If you do that, > even running the clean target as root might not give you a state where > you can build the package as a normal user again. Because there was a time when fakeroot didn't work on some architectures and the buildds used sudo. -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lxc linux image flavour
Hi all I can now announce an "half official" statement from Kir (who is the project manager of openvz) that they are now dedicated to make a openvz. This is what he states: - Hi Ola, guys, Thanks for the info. We have discussed this at length and the resolution is we are all for it. This means we will try hard to do a rebase as soon as possible, and I hope we will succeed. If (or whenever you will) know the exact deadline date (or any close approximation), please let us know, this is important. Also, can you please point us to the location of the git repository of what will become the linux kernel for the next debian release? I checked git.debian.org but where there are too many kernels to look at. If it is not in git then when it is? Regards, Kir. -- So it looks like we are going to have openvz available in squeeze. Best regards, // Ola On Mon, Jan 25, 2010 at 12:46:42AM +0100, maximilian attems wrote: > On Sun, Jan 24, 2010 at 03:17:14PM +0100, Marco d'Itri wrote: > > On Jan 24, maximilian attems wrote: > > > > > the plan as decided in Portland was to go forward with openvz > > > if upstream provides us with a patch in time. as currently this > > > looks quite bad (latest available patch is for 2.6.27, there is > > > no sign of a patch for 2.6.32, nor any schedule like it happened > > > to be for Lenny). > > I expect that it will be released after the first beta of RHEL 6. > > point to an official statement of an openvz dev. > currently it looks like they are waiting too long to be in the squeeze > boat also kernel version should match. > > > -- > To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org > with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org > > -- - Ola Lundqvist --- / o...@debian.org Annebergsslingan 37 \ | o...@inguza.com 654 65 KARLSTAD | | http://inguza.com/ +46 (0)70-332 1551 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / --- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: libqt3-mt-dev: Depends: libjpeg62-dev but it is not going to be installed
On 2010-02-10 18:58 +0100, Bill Allombert wrote: > On Wed, Feb 10, 2010 at 06:14:22PM +0100, Sven Joachim wrote: >> Actually, libjpeg62-dev is needed to build LSB compliant software that use >> libjpeg, so losing that would not be very nice. > > Well, what I suggest: > > I rename the current binary package libjpeg62-dev to libjpeg6b-dev and I > change > libjpeg8-dev to provide libjpeg62-dev. This will probably not make it really possible to actually link software against libjpeg62, because in many cases an additional build-dependency on libgtk2.0-dev and/or libtiff-dev is needed, and if those depend on libjpeg-dev… > But then we are back to the transition the release managers tried to avoid. The alternative is to file many more RC bugs for packages that currently build-depend on libjpeg62-dev. For instance, emacs23 is unbuildable after the latest tiff upload. Sven -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : RE : init script verbosity
On my system VERBOSE=no and I never touch it. and there is plenty of log even with this default. See you Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RE : init script verbosity
On Thu, 11 Feb 2010 13:41:00 +0100, PICCA Frédéric-Emmanuel wrote: > > This would lead to messages from the script to show up during boot > > even when the 'quiet' boot is requested and no error occured, which I > > believe is a bad idea. > ok but for now even with quiet I have plenty of init scripts log during the > start process... /lib/init/vars.sh sources /etc/default/rcS, which sets VERBOSE. On my machine there's | # Set VERBOSE to "no" if you would like a more quiet bootup. | VERBOSE=yes which seems to be the default. Cheers, gregor -- .''`. http://info.comodo.priv.at/ -- GPG Key IDs: 0x00F3CFE4, 0x8649AA06 : :' : Debian GNU/Linux user, admin, & developer - http://www.debian.org/ `. `' Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe `-NP: John Zorn: Abidan (Frisell) signature.asc Description: Digital signature
RE : RE : init script verbosity
thanks > Or setting it in /etc/default/rcS, from `man rcS`: > VERBOSE > Setting this option to no (in lower case) will make the > boot process a bit less verbose. Setting this option > to yes will make the boot process a bit more verbose. so plenty of init script do not follow this rcS default... Is it normal ? Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : init script verbosity
>> so I need to use VERBOSE=yes in my script to override the vars.sh >> values. > This would lead to messages from the script to show up during boot > even when the 'quiet' boot is requested and no error occured, which I > believe is a bad idea. ok but for now even with quiet I have plenty of init scripts log during the start process... See you Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RE : init script verbosity
Hi there! On Thu, 11 Feb 2010 13:03:57 +0100, PICCA Frédéric-Emmanuel wrote: > On Thu, 11 Feb 2010 12:48:48 +0100, Petter Reinholdtsen wrote: >> [PICCA Frédéric-Emmanuel] >>> so what must I do for my init scripts. VERBOSITY / no VERBOSITY ? >> >> Use the VERBOSE to decide when to print informative messages, and >> always report errors no matter the verbosity setting. > > so I need to use VERBOSE=yes in my script to override the vars.sh > values. Or setting it in /etc/default/rcS, from `man rcS`: VERBOSE Setting this option to no (in lower case) will make the boot process a bit less verbose. Setting this option to yes will make the boot process a bit more verbose. Thx, bye, Gismo / Luca pgpZs6hWfUrcJ.pgp Description: PGP signature
Re: init script verbosity
[PICCA Frédéric-Emmanuel] > I know nothing about all this except that it would be nice to see > the messages when started interactively by the user with the > invoke-rc.d command I agree, and I expect it will be fixed for Squeeze. > so I need to use VERBOSE=yes in my script to override the vars.sh > values. This would lead to messages from the script to show up during boot even when the 'quiet' boot is requested and no error occured, which I believe is a bad idea. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RE : init script verbosity
[PICCA Frédéric-Emmanuel] > I am using the /etc/init.d/skeleton (from unstable) file to write my > package init scripts. > but it seems that the lsb-base default behaviour is to have VERBOSE=no > so there is no output. > I believe this is a good default for the boot, and less good for > package installations and when using init.d scripts on the command > line. See http://bugs.debian.org/505468> for a report about > this. Would be nice with feedback on the patch suggested there, as I > hope to have this implemented for Squeeze. I know nothing about all this except that it would be nice to see the messages when started interactively by the user with the invoke-rc.d command > so what must I do for my init scripts. VERBOSITY / no VERBOSITY ? >Use the VERBOSE to decide when to print informative messages, and >always report errors no matter the verbosity setting. so I need to use VERBOSE=yes in my script to override the vars.sh values. See you Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: init script verbosity
[PICCA Frédéric-Emmanuel] > I am using the /etc/init.d/skeleton (from unstable) file to write my > package init scripts. > but it seems that the lsb-base default behaviour is to have VERBOSE=no > so there is no output. I believe this is a good default for the boot, and less good for package installations and when using init.d scripts on the command line. See http://bugs.debian.org/505468> for a report about this. Would be nice with feedback on the patch suggested there, as I hope to have this implemented for Squeeze. > so what must I do for my init scripts. VERBOSITY / no VERBOSITY ? Use the VERBOSE to decide when to print informative messages, and always report errors no matter the verbosity setting. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Relying on glib to publish gettext linker flags
Zitat von Daniel Macks :
Coming here for wider input from gnome bugzilla Bug #606977 (and now
I'm rethinking the much older Bug #500137), which seems to center on
the line in glib-2.0.pc.in:
Libs: -L${libdir} -lglib-2.0 @INTLLIBS@
[...]
This is a real issue for me on OS X, since gettext is not in my system
lib itself nor is the external lib supplied by my os vendor. So I have
several third-party-supplied versions and copies of it and also my
user-land for testing. It's also not sufficient to have glib link
against libintl and then other packages just link against glib.
Darwin's linker does not allow indirect symbol references. I really
need clean control over how/when/where gettext gets linked.
How about putting it into Libs.private?
This should solve your MacOS X problem and also works for static linking.
HS
PS: when referencing bugs from other BTS, please use a link, not just
a bug number.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#569291: ITP: libalgorithm-fuzzycmeans-perl -- perl implementation of Fuzzy c-means clustering
Package: wnpp Severity: wishlist Owner: Bas Zoetekouw * Package name: libalgorithm-fuzzycmeans-perl Version : 0.02 Upstream Author : Mizuki Fujisawa * URL : http://search.cpan.org/~fujisawa/Algorithm-FuzzyCmeans-0.02 * License : same as Perl Programming Lang: perl Description : perl implementation of Fuzzy c-means clustering Algorithm::FuzzyCmeans is a perl implementation of Fuzzy c-means clustering. -- System Information: Debian Release: 5.0.4 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: why are the watchdog drivers blacklisted?
> If you want to test forking ability just enable test-binary test without > giving > it a test-binary or use an empty one. This will make watchdog fork() and react > if not possible. Thinking about this some more, the test for an emtpy test-binary is done *after* the fork, so it should find the forking problem even without a manual test-binary configuration. I do remember testing this feature and it worked. So maybe you had another problem on your system. If you can reproduce this please tell me. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Relying on glib to publish gettext linker flags
On Thu, Feb 11, 2010 at 3:16 PM, Daniel Macks wrote: > I'd love to get this resolved so I know whether to bother filing bugs > when I find "uses gettext but doesn't specify direct link against it" > and if there is a consensus on how other packages should handle it. I read on LWN recently that Fedora is making their runtime linker require linking against libraries that a binary uses symbols from, ie, no more indirect linking: http://lwn.net/Articles/373846/ In addition, packages will fail to build with binutils-gold if they use symbols from a library but they don't link against it. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: debian/rules clean as root or non-root?
On Thu, Feb 11, 2010 at 07:42:37AM +0100, Goswin von Brederlow wrote: > Sven Joachim writes: > > > On 2010-02-10 21:37 +0100, Goswin von Brederlow wrote: > > > >> Sven Joachim writes: > >> > >>> On 2010-02-10 19:02 +0100, Goswin von Brederlow wrote: > >>> > I often see sources where debian/rules clean aborts claiming it needs to > be run as root. So then I run it with fakeroot. But if the source was > previously build as root then running fakeroot debian/rules clean might > not be enough. I think the existing dh_testroot helper is insufficient > and anoying for the job. > >>> > >>> It is both insufficient and unnecessary, I don't use it in my packages. > >>> Neither does "dh clean", BTW. > >> > >> If you build the package as real root and it creates a new directory > >> (like installing into debian/package/ always does) then you can not > >> clean without being real root. So the check isn't unnecessary. > > > > Yes, and dh_clean will almost certainly fail in such a situation. > > Unless, maybe, you went to the insanity of running the build target with > > real root rights. > > That is usualy what happens. Haven't yet completly tought my coworkers > to always build packages as user. Well, then do so. :) > The extended dh_testroot I suggested would also catch cases where the > package was build by another user I think. Might need some tuning (chmod > 770?) to allow building by multiple users in a common group and setgid > bit set. It would catch those cases, BUT working on files that don't belong to you can always lead to weird behavior, especially if you have a mix of files owned by you and others. This is not packaging related but an issue with your rights management (and workflow maybe). I don't think it makes sense to solve it in debian/rules anyhow. > >> If you did run only debian/rules build as root the error might > >> get ignored and lost in the output. > > > > Why would anyone want to run the build target as root? If you do that, > > even running the clean target as root might not give you a state where > > you can build the package as a normal user again. > > > > Sven > > It happens. The important part would be to clearly catch such a case. I > can then delete the working dir and unpack the source again or check it > out again. debian/rules clean should provide you with exactly the same you had after unpacking. If the files didn't belong to you then, they don't belong to you now. There is nothing to catch here. Work in your own $HOME :) Hauke signature.asc Description: Digital signature
