Re: Deleting files from .orig on unpack?
* Jonathan Niehof [100408 01:56]: > I'm working with a package where upstream uses a flat Makefile and the > Debian package has been converted to automake. This means the Makefile > from the .orig.tar.gz gets clobbered in the build process, and then > removed entirely on clean. So build; clean isn't a no-op. I see > several ways to deal with this: > 1) Ignore it and be happy, but since clean doesn't actually restore > the tree isn't this a policy violation? If there was a policy against it, then the policy would be buggy because it would neither document current practise nor would there be any reasons for such a requirement. The only sentence in this direction I can find is "This must undo any effects that the build and binary targets may have had", which only says what it should do (undo the changes), not how. Practically you want to make sure that build - clean - dpkg-source -b works and produces the same results (except dpkg warning you a file vanished so it assumes you removed that deliverately) and that build clean - build build - clean - build clean - build - clean - build all produce the same result. > 3) Add a bunch of rules logic to back up the shipped makefile on bulid > and restore it on clean Now that is ugly, though there is some example of people doing it because of problems with their vcs workflow. I'd suggest to just remove it in clean and make sure it does not break your build if it is still there. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408090705.ga31...@pcpool00.mathematik.uni-freiburg.de
Re: flow of things rules/debhelper (still confused)
Hi, On Wed, Apr 07, 2010 at 04:19:33PM +0200, jmroth+...@iip.lu wrote: > Guys, > I am still confused about my initial question when which binary-* > target in debian/rules is called. > > This also concerns: > - http://www.debian.org/doc/maint-guide/ch-dreq.en.html#s-rules > - http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules > which seem to be out of sync. The policy e.g. still refers to the > patch target whereas in the NMG it is not mentioned. Maybe one should > remove that section from NMG altogether and just leave the reference > to the policy manual (it had better be in one place only and should be > up-to-date). I do not know which part made you think so. Currently on web and SVN: * clean target: to clean all compiled, generated, and useless files in the build-tree. (required) * build target: to build the source into compiled programs and formatted documents in the build-tree. (required) * binary target: to create all binary packages (effectively combination of binary-arch and binary-indep targets). (required)[12] * binary-arch target: to create arch-dependent (Architecture: any) binary packages in the parent directory. (required)[13] * binary-indep target: to create arch-independent (Architecture: all) binary packages in the parent directory. (required)[14] * get-orig-source target: to obtain the most recent version of the original source package from upstream archive site. (optional) * install target: to install files into a file tree for each binary package under the debian directory. If defined, binary* targets effectively depend on this target. (optional) I see one problem here. The order is not optimal. I will move up install to remove confusion. > > > While reading the NMG I see > "build: ... pre-build configuration" ??? I do not see it. > "binary: ... all that is necessary for the user to build the binary > package(s) ..." ??? > When I translate this to the usual things to be done for getting a > software installed, we have > build <-> ./configure OOps. let me spell out for you. ./configure and make install <-> make install binary <-> roling into *.deb etc. I think following text to 4.4.2's later half shoul have made it clear. > Why not give this as an example? > Talking about "building" everywhere and not showing what this means > just confuses the beginner. (Or maybe I'm looking at the wrong > documentations.) > > > > But back to topic: my main motivation here is to find out about the > binary, binary-arch, binary-indep targets, when they are called, and > where this is documented. binary is documented in: http://www.debian.org/doc/maint-guide/ch-build.en.html#s-completebuild binary-arch will be mentioned soon. I do not know active use of binary-indep by itself. Anyone knows? (I know some makefile has binary: binary-indep binary-arch.) Osamu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408132431.gb14...@osamu.debian.net
Re: flow of things rules/debhelper (still confused)
On Wed, Apr 07, 2010 at 06:48:26PM +0200, Jan Hauke Rahm wrote: > Well, this is just wrong. As you can find in Debian Policy, the binary > target has to depend on binary-arch and -indep which is not provided > here. There isn't much to document. It's standard Makefile behavior. Excuse me. I can not find this assertion. Could you elabarate where you find this? I find following in 4.9 Main building script: debian/rules: > binary, binary-arch, binary-indep > > The binary target must be all that is necessary for the user to build the > binary package(s) produced from this source package. It is split into two > parts: binary-arch builds the binary packages which are specific to a > particular architecture, and binary-indep builds those which are not. Although pedantic, "It is split into" is not "It depends on". dh synatx realize this without using make rule dependency, as I understand. How this binary target functionality is split is not dictated by the Policy. > As a matter of fact, I find the dh7 syntax very confusing for beginners > (espacially for those unfamiliar with Makefiles). The NMG should cover a > more detailed debian/rules to explain how it works. The dh7 stuff is > just sugar code on top of it *after* understanding how the build process > really works. But I admit I never really cared about that guide. Actually, Polycy has been improved but still confusing too. http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps In this: 7.7 Relationships between source ... > The dependencies and conflicts they define must be satisfied (as defined > earlier for binary packages) in order to invoke the targets in debian/rules, > as > follows:[43] > > Build-Depends, Build-Conflicts > > The Build-Depends and Build-Conflicts fields must be satisfied when any of > the following targets is invoked: build, clean, binary, binary-arch, > build-arch, build-indep and binary-indep. > > Build-Depends-Indep, Build-Conflicts-Indep > > The Build-Depends-Indep and Build-Conflicts-Indep fields must be satisfied > when any of the following targets is invoked: build, build-indep, binary and > binary-indep. It does not tell us Build-Depends-Indep does not need to list ones listed in Build-Depends (although this is waht we expects and seems to be true by reading dpkg-buildpackage and dpkg-checkbuilddeps, without this exclusion rule, Build-Depends-Indep becomes very long one.) We really need to read dpkg-buildpackage and dpkg-checkbuilddepsto understand what exactly is going on. Anyway, these are De Facto standard which we can rely better than Policy. Any improvement suggestion on maint-guide are welcome. Please file bugs :-) Osamu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408134810.gc14...@osamu.debian.net
Re: flow of things rules/debhelper (still confused)
On Wed, Apr 07, 2010 at 11:23:02AM -0700, Russ Allbery wrote: ... > In general, I find mixing explicit target definitions and wildcard rules > really confusing. Yes, indeed. I will steal this phrase into maint-guide as footnote :-) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408135038.gd14...@osamu.debian.net
Re: flow of things rules/debhelper (still confused)
Le jeudi 08 avril 2010, Osamu Aoki a écrit : > I do not know active use of binary-indep by itself. Anyone knows? > (I know some makefile has binary: binary-indep binary-arch.) I do not know what you mean by “active use”, but I do have a package which debian/rules contains a featured binary-indep: and an empty binary-arch:. This is the dokuwiki package, a PHP-interpreted website content manager. I considered switching to the new managed rules syntax, but when I discovered that it would have the effect of losing the information that most of the work is arch-independent, I decided to keep my old rules. -- Tanguy Ortolo signature.asc Description: Digital signature
Re: GPG Signature
On Monday 22 March 2010, Paul Tagliamonte wrote: > On Mon, Mar 22, 2010 at 1:14 AM, Paul Wise wrote: > > On Mon, Mar 22, 2010 at 9:38 AM, Paul Tagliamonte wrote: > >> I added myself as requesting a GPG signature in the Cleveland area > >> from a DD ( the only thing holding me back from starting the new > >> maintainer process ) and really felt that I gave it due discourse ( > >> the wiki, front desk and a few hours searching for DDs in the > >> Cleveland area have all proven fruitless ). > > > > There don't appear to be an DDs listing Cleveland in their LDAP > > information. > > > >> Any ideas on next steps? > > > > You can apply without having your key signed and then get it signed > > before you finish the process. > > Did not know that. Thank you! > > > It is not too far to NYC, you could come to the keysigning at DebConf10. > > Aye. I will have to see if I can make it out that way. Even better, you can help us out with DC10 and stop by NYC a few months earlier :-) :-) There are plenty of DDs in the New York metro area. For opportunities to volunteer take a look at http://wiki.debconf.org/wiki/DebConf10 or just stop by #debconf-nyc at IRC. Cheers, Pablo signature.asc Description: This is a digitally signed message part.
Re: GPG Signature
On Thu, Apr 8, 2010 at 7:05 PM, Pablo Duboue wrote: > On Monday 22 March 2010, Paul Tagliamonte wrote: >> On Mon, Mar 22, 2010 at 1:14 AM, Paul Wise wrote: >> > On Mon, Mar 22, 2010 at 9:38 AM, Paul Tagliamonte > wrote: >> >> I added myself as requesting a GPG signature in the Cleveland area >> >> from a DD ( the only thing holding me back from starting the new >> >> maintainer process ) and really felt that I gave it due discourse ( >> >> the wiki, front desk and a few hours searching for DDs in the >> >> Cleveland area have all proven fruitless ). >> > >> > There don't appear to be an DDs listing Cleveland in their LDAP >> > information. >> > >> >> Any ideas on next steps? >> > >> > You can apply without having your key signed and then get it signed >> > before you finish the process. >> >> Did not know that. Thank you! >> >> > It is not too far to NYC, you could come to the keysigning at DebConf10. >> >> Aye. I will have to see if I can make it out that way. > > Even better, you can help us out with DC10 and stop by NYC a few months > earlier :-) :-) > > There are plenty of DDs in the New York metro area. > > For opportunities to volunteer take a look at > > http://wiki.debconf.org/wiki/DebConf10 > > or just stop by #debconf-nyc at IRC. > > Cheers, > > Pablo > I'll try my best Pablo! I hear Debconf is a blast! I did get this all set, there were three DDs in Boston nice enough to sign my key while I was on Vacation :) All the best, Paul Tagliamonte -- #define sizeof(x) rand() :wq -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/o2ubc5805c31004081619y5373848auba0a6a22eb7b3...@mail.gmail.com
RFS: emerillon
Dear mentors, I am looking for a sponsor for my package "emerillon". * Package name: emerillon Version : 0.1.1-1 Upstream Author : Novopia Solutions Inc. * URL : http://www.novopia.com/emerillon/ * License : GPL Section : utils It builds these binary packages: emerillon - map viewer for the GNOME desktop The package appears to be lintian clean. The upload would fix these bugs: 550912 My motivation for maintaining this package is: it is a package I use, which interests me, and I believe I already have a good relationship with the upstream maintainers. Keeping in mind the (off-topic) discussion on bug 575384, the rationale for having this retrieved from git is that it simplifies (at least for me) maintaining and regularly building the package, if nothing else because I am already using the same or very similar recipes in other packages, including in helping maintaining NetworkManager in Ubuntu. I'm very interested to get more input on this. Thanks to Andreas Henriksson for the advice already given, which I will clearly take into account. I've additionally CC'd the pkg-gnome team, since this is obviously a very gnome-centric package :) The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/e/emerillon - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/e/emerillon/emerillon_0.1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards Mathieu Trudel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/h2i79123a661004081910wad0ab252j9ae587cc2e36d...@mail.gmail.com
RFS: libgstreamerjava (Java bindings for Gstreamer, LGPLv3)
Hi, I need a sponsor/mentor for the libgstreamerjava package, Java bindings for the Gstreamer Multimedia Framework. Short information: - Programming Language: Java - ITP Bug: #576984 - Homepage: http://code.google.com/p/gstreamer-java/ - Version: 1.3 - Upstream Authors: Andres Colubri, Levente Farkas, Tal Shalif, Wayne Meissner and Others - License: LGPL v3 My packages are available at mentors.debian.net, at http://mentors.debian.net/debian/pool/main/l/libgstreamerjava I have changed the upstream source only to remove some binary files (jar) shipped by upstream. The script to perform this operation is at debian/upstream-remove-binaries.sh. Thank you, - Samuel -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l2x5754264b1004082004id65b5736q8dc13a95a6fbc...@mail.gmail.com
Re: RFS: emerillon
On tor, 2010-04-08 at 22:10 -0400, Mathieu Trudel-Lapierre wrote: [...] > Keeping in mind the (off-topic) discussion on bug 575384, the > rationale for having this retrieved from git is that it simplifies (at > least for me) maintaining and regularly building the package, if > nothing else because I am already using the same or very similar > recipes in other packages, including in helping maintaining > NetworkManager in Ubuntu. [...] I suggested that you look at gnome-pkg-tools "get-orig-source" rules. Did you? That target normally fetches the real orig tarballs but can also be used to fetch from git as far as I could see when quickly looking at the cdbs script (by just setting DEB_UPSTREAM_GIT_REV). I do understand that you might want to easily be able to build local test versions straight from git for your testing, but these should IMHO not be uploaded as official Debian packages. I don't understand what advantage your "never fetch the real orig tarball" rules has over gnome-pkg-tools, please explain. (As I see it, with gnome-pkg-tools you get the best of both. Easy building from git and fetching of real tarballs for official uploads.) (I don't see that you're doing this for all *your* packages in *ubuntu* as an explanation and strong reason to go with your way over already established ways of handling this used by *many* maintainers inside *debian*.) -- Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270793843.9289.100.ca...@amd64.fatal.se
