Re: Transition from dpkg to GNU install-info
On Fri, 24 Apr 2009, Norbert Preining wrote: > Since that are 67 files and a bit less packages I guess we have to go > thorugh the "mass bug filing" thingy on d-d? Right? In theory yes, but since those are real bugs in the documentation I think nobody will complain if you omit that step (and you're the Debian expert for info files since you maintain texinfo). Up to you. > > And also file bugs against all info-browsers to request their update > > as soon as install-info is in unstable. > > Ok, will check the list of info browsers. But that should be done only > when we have i-i in unstable, not in experimental. But probably we > should file bugs already now? What do you say? Having some advance notice doesn't hurt indeed. So filing them now is fine for me. Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
dpkg-buildpackage vendor hook for environment variable changes?
I'd like to add a vendor hook to dpkg-buildpackage for changing default
environment variables. The Ubuntu diff I'm trying to eradicate is as
follows:
diff -Nru dpkg-1.14.24/scripts/dpkg-buildpackage.pl
dpkg-1.14.24ubuntu1/scripts/dpkg-buildpackage.pl
--- dpkg-1.14.24/scripts/dpkg-buildpackage.pl 2008-12-26 04:49:01.0
+
+++ dpkg-1.14.24ubuntu1/scripts/dpkg-buildpackage.pl2009-01-07
12:10:33.0 +
@@ -261,7 +261,7 @@
CFLAGS => $default_flags,
CXXFLAGS => $default_flags,
FFLAGS => $default_flags,
- LDFLAGS => '',
+ LDFLAGS => '-Wl,-Bsymbolic-functions',
);
foreach my $flag (keys %flags) {
(There is another pile of stuff for hardening-wrapper, but I've just
read #489771 again and have no particular desire to get into that
massive can of worms right now. I very much do not approve of
deprecating the debian/rules interface, but I do think this sort of
thing is a fairly reasonable way for Ubuntu's buildds to set certain
kinds of defaults without having to modify every package in the archive,
and for users to be able to replicate this behaviour reasonably
straightforwardly, until and unless we invent some way for packages to
do this explicitly in debian/rules in a way that's as easy to customise
across the archive.)
How about something like this:
=item default-build-flags ($flags)
The first parameter is a reference to a hash of environment variable
names to their default values. The hook is called by dpkg-buildpackage
immediately before setting default values in the environment.
The hook implementation could then be something like:
my $flags = shift @params;
$flags->{LDFLAGS} = '-Wl,-Bsymbolic-functions';
If this makes sense to people, I can put together a patch.
Thanks,
--
Colin Watson [cjwat...@ubuntu.com]
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
RFC: should there be a dpkg-edit-patch
Hi, I recently converted a few local packages from dpatch to 3.0 (quilt) format. But now I wonder what the equivalent of dpatch-edit-patch foo is. Ok, as quilt user I know I can do QUILT_PATCHES=debian/patches quilt pop/push quilt add file sensible-editor file QUILT_PATCHES=debian/patches quilt refresh But what if the package was unpacked without quilt? Or the user is not familiar with quilt? Having to add files before editing takes getting used to. Wouldn't it be nice to have a dpkg-edit-patch command in dpkg-dev that would work like dpatch-edit-patch and with or without quilt? Additionaly I think it would be nice to be able to rename the debian/patches/debian-changes-version file or merge it into a previous patch. Maybe we could have dpkg-patch --edit name dpkg-patch --rename new_name [old_name] <- default to last patch dpkg-patch --merge [target [source]] <- default to last 2 patches Last how about annotating the debian/patches/debian-changes-version patch when generating it adding infos from DEBFULLNAME, NAME, DEBEMAIL and/or EMAIL just like dch does when generating the changelog? If none of them are set the name/email from the last changelog entry could be used. Comments? MfG Goswin -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: should there be a dpkg-edit-patch
On Tue, 28 Apr 2009, Goswin von Brederlow wrote: > But what if the package was unpacked without quilt? Or the user is not > familiar with quilt? Having to add files before editing takes getting > used to. Well, standardizing is interesting because one has to learn only one system and this system is quilt. So I don't want to replace quilt with dpkg tools. The user should have quilt installed and it will be used. Once the format is standard, I will add a Recommends: quilt to avoid this problem to some extent. > Wouldn't it be nice to have a dpkg-edit-patch command in dpkg-dev that > would work like dpatch-edit-patch and with or without quilt? No. > Additionaly I think it would be nice to be able to rename the > debian/patches/debian-changes-version file or merge it into a previous > patch. Maybe we could have Same answer, it's not really dpkg's businees IMO. > Last how about annotating the debian/patches/debian-changes-version > patch when generating it adding infos from DEBFULLNAME, NAME, DEBEMAIL > and/or EMAIL just like dch does when generating the changelog? If none > of them are set the name/email from the last changelog entry could be > used. Yes, it's in my plans. But I would like us to standardize those meta-informations first so that I can put a useful template. That's why I reserved DEP #3 (Patch Tagging Guidelines). Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
