RFS: k3dsurf (maths+3d=fun)
Hi, I'd be glad if someone could check and possibly upload the following source package for me: http://alioth.debian.org/~kibi-guest/k3dsurf/k3dsurf_0.6.2-2.dsc It's mostly a maintenance release, see the changelog entry: ,--- | k3dsurf (0.6.2-2) unstable; urgency=low | | * Add Vcs-Git and Vcs-Browser since the packaging is now hosted on | git.debian.org. | * Rework a bit the long description. | * Add back the patch to fix FTBFS with newer gcc (it was probably dropped | due to a misuse of debuild options), using quilt (Closes: #454843): | - Add debian/patches/10_gcc4.3_includes | * Drop trailing spaces in debian/rules at the same time. | * Bump Standards-Version from 3.7.2 to 3.7.3 (no change needed). | | -- Cyril Brulebois <[EMAIL PROTECTED]> Thu, 20 Dec 2007 02:49:18 +0100 `--- About k3dsurf (http://k3dsurf.sourceforge.net/): ,--- | K3DSurf is a program to visualize and manipulate multidimensional | surfaces by using mathematical equations. It's also a modeler for | POV-Ray in the area of parametric surfaces. `--- cowbuilder & lintian seem happy with it. Thanks in advance. Cheers, -- Cyril Brulebois pgpeWhJeLH74i.pgp Description: PGP signature
Re: RFS: yougrabber
On 22/12/2007, chaica wrote: > Thanks for your leads, I'm close to solve these different issues but > arch field in debian/control is unclear for me. I tested my package > under i386 machines so I'm sure they work for i386. What should I put > in this field? i386? any? If it contains only architecture-independant data: “all”. “any” otherwise, unless it is supposed to only run on this and that architecture, in which case you put “Architecture: this that” there. In most cases, you're going to use either “all” or “any”. Cheers, -- Cyril Brulebois pgpw65qglxDud.pgp Description: PGP signature
Re: RFS: k3dsurf (maths+3d=fun)
On 20/12/2007, Cyril Brulebois wrote: > I'd be glad if someone could check and possibly upload the following > source package for me: > > http://alioth.debian.org/~kibi-guest/k3dsurf/k3dsurf_0.6.2-2.dsc Still the same location, with the attached additional commit, which takes care of extra linking. Cheers, -- Cyril Brulebois commit c674b4d21d2a0116a8beb3b67f7dc3f79b93e8c8 Author: Cyril Brulebois <[EMAIL PROTECTED]> Date: Wed Dec 26 16:23:11 2007 +0100 Avoid extra linking using -Wl,--as-needed diff --git a/debian/changelog b/debian/changelog index 85c6ce5..fd39696 100644 --- a/debian/changelog +++ b/debian/changelog @@ -8,8 +8,12 @@ k3dsurf (0.6.2-2) unstable; urgency=low - Add debian/patches/10_gcc4.3_includes * Drop trailing spaces in debian/rules at the same time. * Bump Standards-Version from 3.7.2 to 3.7.3 (no change needed). + * Pass “LFLAGS="-Wl,-z,defs -Wl,--as-needed"” to the “$(MAKE)” call: + - The latter avoids extra linking. + - The former ensures there's no undefined reference in the temporary + objects, although there is none at the moment. - -- Cyril Brulebois <[EMAIL PROTECTED]> Thu, 20 Dec 2007 02:49:18 +0100 + -- Cyril Brulebois <[EMAIL PROTECTED]> Wed, 26 Dec 2007 16:22:49 +0100 k3dsurf (0.6.2-1) unstable; urgency=low diff --git a/debian/rules b/debian/rules index ddeb5ce..ee94280 100755 --- a/debian/rules +++ b/debian/rules @@ -23,7 +23,7 @@ build: build-stamp debian/k3dsurf.xpm build-stamp: configure-stamp dh_testdir - $(MAKE) + $(MAKE) LFLAGS="-Wl,-z,defs -Wl,--as-needed" touch build-stamp clean: clean-patched unpatch pgpiNG1lJc5Bl.pgp Description: PGP signature
Re: RFS: k3dsurf (maths+3d=fun)
On 26/12/2007, Cyril Brulebois wrote: > Still the same location, with the attached additional commit, which > takes care of extra linking. Uploaded by ana. Cheers, -- Cyril Brulebois pgpTPDGdq87D2.pgp Description: PGP signature
Re: RFS: blimp
Hi. On 05/01/2008, Knut Arild Erstad wrote: > I am looking for a sponsor for my package "blimp". Blimp is a photo > editor which offers a unique workflow for photographers. Some of the > features are: I would understand if you were asking for a review instead of a sponsor because… > The package currently depends on Sun's java6. I will probably create > gcj-based packages as well at some point. Yes, it is written in Java, > but don't let that discourage you from trying it out. :-) … this means that the following isn't correct: Section: graphics Build-Depends: …, sun-java6-jdk, … Depends: …, sun-java6-jre, … Check for contrib and non-free in the policy. Hopefully it's buildable and usable with gcj, as you stated. > The package appears to be lintian clean. Checking the source package: W: blimp source: binary-arch-rules-but-pkg-is-arch-indep W: blimp source: out-of-date-standards-version 3.7.2 (current is 3.7.3) I: blimp source: build-depends-without-arch-dep ant I: blimp source: build-depends-without-arch-dep sun-java6-jdk I: blimp source: build-depends-without-arch-dep libswt3.2-gtk-java I: blimp source: build-depends-without-arch-dep imagemagick I: blimp source: build-depends-without-arch-dep fakeroot Check: you're running the latest lintian, and be sure to use -i/-I so as to spot as many issues as possible. If you're running debuild or so with -b, be sure to run lintian on the source package (.dsc) as well. > I would be glad if someone uploaded this package for me. I didn't dig it much more, but I might help a bit with the gcj stuff. You might have a look at the pkg-phototools group, more information on the website[1]. 1. http://pkg-phototools.alioth.debian.org/ Cheers, -- Cyril Brulebois pgpQ5XePFFhCg.pgp Description: PGP signature
Re: RFS: ttf-summersby (updated package)
On 08/01/2008, Mauro wrote: > Dear mentors, > > I am looking for a sponsor for the new version 1.007-3 > of my package "ttf-summersby". Hi, do you know the pkg-fonts group? You might want to join it and maintain your packages there. More on http://pkg-fonts.alioth.debian.org/ Cheers, -- Cyril Brulebois pgpZrZKLGTqss.pgp Description: PGP signature
Re: Re: RFS: nettee
On 09/01/2008, Joel Franco wrote: > I do not understand what means "serverstats or webissues in > lenny/sid". Where can i read about it? apt-get source one or the other, then look at debian/copyright. Cheers, -- Cyril Brulebois pgpm5YasILFHh.pgp Description: PGP signature
Re: RFS: zynaddsubfx
On 09/01/2008, Robert Vogel wrote: > Couldn't find this link...Is it ok ? Uploaded already: | Subject: Accepted zynaddsubfx 2.2.1-4.1 (source i386) Keeping only lists in To:, list policy blah blah. -- Cyril Brulebois pgphWMwN0nEPx.pgp Description: PGP signature
Re: libcwd: one or two packages?
On 09/01/2008, Carlo Wood wrote: > My mail, posted to this list on Jan 8, is ALSO lost... The subject > was "libcwd: one or two packages?". The Message-ID was > [EMAIL PROTECTED] (I'm "replying" to a local CC now). > Can someone tell me what is going on? Why did both posts that I mailed > to this list not appear on the list? http://lists.debian.org/debian-project/2008/01/msg00011.html http://lists.debian.org/debian-project/2008/01/msg00013.html Note that you can request to be whitelisted. See “whitelist” on http://www.debian.org/MailingLists/subscribe > This is tiresome - on one hand this list generates like 90% of all > spam that I get, and on the other hand my mails are /dev/null-ed :/. > May I suggest to just refuse all mails from non-subscribers, and > always allow all posts by subscribers? Hopefully things will get better. Hard moderations rules are quite inconvenient anyway (like you have one or two questions to ask on a list, and have to temporary subscribe, instead of setting Reply-To/asking people to keep you in Cc in their replies). Cheers, -- Cyril Brulebois pgpc4q4RCZ8xf.pgp Description: PGP signature
Re: FTBFS due to upgrade/bug in build-dependency
On 10/01/2008, Frank Terbeck wrote: > I could work around that problem quite simply. However, I think it > would be preferable, if 'tdb.h' would be fixed. Sure. > My question is, if it would be the right thing to do is to reassign > the bug to tdb-dev and add a comment about signal.h to it? Or should I > rather create a new bug against tdb-dev about the problem? Simply reassigning is IMHO OK, but if someone else sees this FTBFS, and sees no one reported against your package, that someone could open a bug against your package, w/o checking that its root is in another one. What I usually do in this case is the following: clone + reassign + retitle + block the old one with the new one. (block is just a documentation marker.) Cheers, -- Cyril Brulebois pgpuQePccvWb1.pgp Description: PGP signature
Re: RFS: openjpeg
On 11/01/2008, Robin Cornelius wrote: > Openjpeg is a JPEG2000 library and associated tools for the > encoding/decoding of jpegs that use the JPEG2000 format. It is a > required component of the secondlife viewer (#406335) but also has a > wider general use for image processing. Hi. Do you know about pkg-phototools? It looks to me that openjpeg is quite a good candidate for inclusion there, so you might want to read more on http://pkg-phototools.alioth.debian.org/. Note that Bernd Zeimetz is a member of this team as well, and might be interested to review your package within the team, since he needs it for a gimp plugin. Cheers, -- Cyril Brulebois pgprDW6xB3Ky6.pgp Description: PGP signature
Re: FTBFS due to upgrade/bug in build-dependency
On 11/01/2008, Frank Terbeck wrote: > Okay, I'm not sure if I understand the relevant passages in bts(1), > for these subcommands. So I guess, I better ask in more detail, so I > don't screw up my first manual interaction with the bts. :-) In case you incidentally screw up, everything can be undone anyway, don't be afraid. > What confuses me, is the 'new IDs' argument. My guess is this: > > % bts clone 456871 -1 > > So that I can use '-1' instead of waiting for the new number the > cloned bug get assigned. Exactly. > The version argument is to tell the bts that a special version > introduced the bug in question, right? So, I would do: > > % bts reassign 456871 tdb-dev '1.1.1~svn26294-1' Looks fine, nice to know the version number of the faulty package. > However, this does not mean, that my bug will be closed once the > cloned bug will be closed by the maintainer of tdb-dev, will it? Once cloned, bugs are totally independent. > If not, what would be an appropriate close message to send once the > bug in tdb-dev is closed? You could use a versioned Build-Depends: package (>= fixed-version) and state so when closing that bug. If your package gets uploaded after your build dependency, it'll be put in Dep-Wait rather than failing. A Dep-Wait would be something like: “Dep-Wait: $package >= $version” and would be displayed on: http://buildd.debian.org/~jeroen/status/package.php?p=$PACKAGE > To wrap it up, I would issue these commands, one after another: > > % bts clone 456871 -1 > % bts reassign -1 tdb-dev '1.1.1~svn26294-1' > % bts retitle -1 "usr/include/tdb.h uses sig_atomic_t without\ > including signal.h" > % bts block 456871 by -1 > > Correct, or did I screw up already? Quite correct, but how does the BTS know what -1 refers to if you issue your commands one after the other? Either you use a *single* bts command, using delimiters (see the manpage), or you put all these commands the body of a mail you send to [EMAIL PROTECTED] Cheers, -- Cyril Brulebois pgpfcPIgH105l.pgp Description: PGP signature
Re: RFS: openjpeg
On 11/01/2008, Robin Cornelius wrote: > I'm quite happy for the package to enter the pkg-phototools version > control system if that is what the group would like and finalise any > changes there. I should have made it clear: that was a proposition. :) > Currently I am hosting the package on my own (publicly accessible) svn > server, but it makes more sense for these packages to move to alioth > as they start to be finalised for/enter Debian. Do you want me to take care of creating the git repository and injecting your revisions there? According to a quick search on alioth, I guess you're robinc-guest (so that I add you to the group). > PS: I am not currently subscribed to pkg-phototools so please CC me or > ensure a reply goes to debian-mentors (which i am subscribed). Let me know once you're subscribed, we'll take care of everything on the -devel list. Cheers, -- Cyril Brulebois pgplf2QsOCHnb.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Asheesh Laroia wrote: > I'm a Debian Maintainer now and am uploading a new release of my > package alpine, for which I successfully uploaded 1.0+dfsg-1 to the > archive. Indeed, check[1]. 1. http://packages.qa.debian.org/a/alpine/news/20080105T014704Z.html > I noticed that according to > http://buildd.debian.org/build.php?pkg=alpine , the Debian archive > never builds i386 packages. To my surprise, it accepts the binary > .debs I upload with the source package. It accepts any binary package you upload together with the source package. If you upload from amd64, it then won't build an amd64 package, but use the one you uploaded instead. > >Rejected: source only uploads are not supported. That's exactly the point: at the moment, source-only uploads are REJECTED. You have to provide at least the binaries for one architecture. > Is it possible to ask the buildds to rebuild my package on all > architectures as part of an upload? No. If you want to *rebuild* a package using the very same source already in the archive, you can read about binNMUs. But that only happens for good reasons (e.g. transitions). That's not a workaround so that source-only uploads can happen. -- Cyril Brulebois pgpxmwUAMfK76.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
Please use list-reply. No need to Cc people if they didn't request it, see the Debian lists policy. On 12/01/2008, Asheesh Laroia wrote: > Interesting. Is there a reason for this policy, or is it just > historical? ISTR it was intended to ensure the package at least builds fine in the developer's environment, to reduce FTBFSes. I wasn't there at that time though, but I've been told several times that I'll be an old DD before it gets a chance to be changed. I guess you can call it historical. > Got it, now I understand the way things work. I still have the above > question about why they work that way. Check for “source only uploads” in the list archives, and maybe in the DWN. First shot gives [1,2]. 1. http://lists.debian.org/debian-devel/2003/10/msg01226.html 2. http://lists.debian.org/debian-devel/2003/10/msg01227.html -- Cyril Brulebois pgpUswW5Yoe2R.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Colin Tuckley wrote: > It's a bit of a historical thing, left over from the days when > everybody used i386 boxes. There is only one i386 buildd (which was > down recently). > > The idea is that since you should be test building your package in a > clean sid chroot anyway you might as well upload the results (after > signing it of course) to save time on Debian resources. But nothing ensures it is built in a chroot, which might occasion disparities between uploaded binaries and built-on-the-buildd-network binaries. And no log is available for that build. Not to mention the disparities between (build-)dependencies' versions in case the package stays in NEW for some time. I find it a shame to rely on everyone to upload binaries to save time on Debian resources, rather than having a comprehensive and reliable buildd network. About the above: it's not like i386 is a rare architecture and it isn't possible to find some machines that could act as build daemons. Remember Vancouver? Cheers, -- Cyril Brulebois pgpLkzjSjU08F.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Bernhard R. Link wrote: > While a minimal chroot is good to test against missing > build-dependencies, a full real-world system is needed to test for > missing build-conflicts or configure switches to disable specific > autodetections. Sure. > So when you get disparities between a package build in a pure unstable > environment and on a buildd or a minimal chroot, that is not a bug in > the process but a bug in the package, which would not be catched when > only using buildds. Well, no. A “pure unstable environment” on a development box can have various configuration tweaks, differing from the defaults shipped with the packages, and that can impact the built binaries. > > disparities between (build-)dependencies' versions in case the > > package stays in NEW for some time. > > disparities can also happen with differently fast buildds or just by > the differences of the different architectures. Things should be able > to work with this. Maybe trying to limit these disparities might be interesting… > and then arguing how stupid those reasons are. And for source only > uploads please take a look at Ubuntu. I really hope we do not want to > go that path and up with totally unuseable packages (in the sense of > can't possibly ever do the single thing that package is there for) > ending up in stable releases. I don't see how requesting to have a binary along the source package ensures it has been tested, that upgrades and transitions are OK, etc. > > About the above: it's not like i386 is a rare architecture and it > > isn't possible to find some machines that could act as build > > daemons. > > There is a i386 buildd. Quite some people are uploading amd64 > packages. I personally usually only upload sparc binaries with my > sources. Sometimes the i386 buildd makes problems, sometimes another > buildd. Nothing specific with i386 here. Having a single point of failure is i386-specific as far as I can tell. Testing migration suffered from that. Are you saying that redundancy is totally useless and that one should just not care about it? -- Cyril Brulebois pgprjHEnD5CA3.pgp Description: PGP signature
Re: alpine_1.0+dfsg-2_source.changes REJECTED
On 12/01/2008, Asheesh Laroia wrote: > I realize that the "arch: all" packages would need technical attention > before the policy can be realized in practice, and there may be other > small technical issues to work out, but I imagine there are solutions > to those issues. I guess some packages might be exceptions to such a rule, like compilers or other packages needing bootstrap at some point. Cheers, -- Cyril Brulebois pgpzU2yrXnby0.pgp Description: PGP signature
Re: RFS: gthumb (updated and adopted package)
On 13/01/2008, David Paleino wrote: > > Could you please make the yelp dependency a Recommends? > > May I ask why? So that it gets pulled in by default. But so that one can still choose not to install yelp at all, e.g. because one isn't interested at all by documentation (e.g. because online helps will be sufficient, if ever needed). Cheers, -- Cyril Brulebois pgplbIdro2s7S.pgp Description: PGP signature
Re: RFS: gnomecatalog (uploaded)
On 08/01/2008, José Sánchez Moreno wrote: > I am looking for a sponsor for my package "gnomecatalog". FWIW, 0.3.3-3 just landed in NEW. -- Cyril Brulebois pgpYxby5Z4A1Z.pgp Description: PGP signature
Re: RFS: libhugetlbfs
On 13/01/2008, Mel Gorman wrote: > Dear mentors, Maw, > It builds these binary packages: > libhugetlbfs - helper to back malloc(), text and data with hugepages > libhugetlbfs-dev - libhugetlbfs Development library and Header Files > > The package appears to be lintian clean. No: W: libhugetlbfs source: out-of-date-standards-version 3.7.2 (current is 3.7.3) Be sure you're running latest lintian, and not only on your binary, but also on the source. Running it on the .changes is a way to do so (if you didn't specify -b when building, otherwise you can feed both _source.changes and _$arch.changes to lintian, if you build with -S and then -b). Ah. Actually it's not even source vs binary: W: libhugetlbfs-dev: new-package-should-close-itp-bug E: libhugetlbfs-dev: bad-version-in-relation depends: libhugetlbfs (= 1.2-1}) W: libhugetlbfs: shlib-with-executable-stack usr/lib/libhugetlbfs.so E: libhugetlbfs: shlib-missing-in-control-file libhugetlbfs.so for usr/lib/libhugetlbfs.so W: libhugetlbfs: unused-shlib-entry-in-control-file libhugetlbfs 1.2 W: libhugetlbfs: shlibs-declares-dependency-on-other-package ( >= 1:1.2) W: libhugetlbfs: new-package-should-close-itp-bug Of course -i -I to lintian will help you figure out what's happening. ITP bug is quite trivial. The bad-version-in-relation… is only a typo in debian/control. > At this starting stage, I would be glad if someone would review the > package. I know that starting packaging with a library is generally > frowned upon and no doubt mistakes will mean it is not quite ready for > upload. I'm quite surprized by your shlibs.local file. Did you read libpkg-guide? As far as I can tell, you don't need such a file. different reason. And you don't need to ensure that you are >= foo, << bar, because if you make some incompatible change, you have to bump the SONAME and rename the binary package. You probably want to version your library, using a 0 or 1 SONAME, so that upgrades are then possible when new incompatible versions are released. > I wrote up the experiences while building the package at > http://www.csn.ul.ie/~mel/docs/debianstart/ in case it's useful to > anyone. Thanks. Cheers, -- Cyril Brulebois pgpNFUE5BpZYQ.pgp Description: PGP signature
Re: packaging advice and eventually RFS: osmo
Hi. On 13/01/2008, Eike Nicklas wrote: > The package appears to be lintian clean and builds fine in pbuilder. Actually, no for the lintian part: W: osmo source: desktop-file-but-no-dh_desktop-call but that's nothing too dramatic, just read about it (-I option of lintian), it's quite trivial to fix. > Since this is my first package, it probably still contains many errors > and it would be great if one of you could have a look at it and provide > feedback, so that I can improve both the package and my skills. Once > you believe the package is in a good shape, it would be great if someone > could sponsor an upload for me. > You are already using LDFLAGS to pass -no-undefined. I'm wondering whether you see the (relatively new) dpkg-shlibdeps warning, stating that you're linking against things you shouldn't (because you're not using any symbol of those libs)? You could try to play with -Wl,--as-needed (together with the current flag) to see whether that helps. That's a nice occasion to learn a bit about the following: objdump -x debian/osmo/usr/bin/osmo | grep NEEDED You can also check how your Depends: line evolve, when this flag is passed or not. libpthread remains, but that's AFAICT harmless and it's quite a particular problem (talked about with dpkg-dev developers IIRC). About the --host and --build options passed to ./configure, I'd suggest reading autotools-dev's README.Debian. Depending on whether you're crosscompiling, you have to use the correct options. All details are there IIRC. Instead of mkdir -p + install, you might just want to use “dh_install file location”. > One comment: > The upstream Makefile does not have a clean or distclean target and I > currently do the cleaning 'by hand' in the rules file. I contacted > upstream about adding a clean targed and they consider doing so when > time permits. I'm able to “make clean”, which cleans “po”, “src”, and “.”, and even to “make distclean”. They might be doing an insufficient work but that's better than nothing. I'm happy to see you've already reported that upstream. > Thanks a lot for your help, That was a *very* quick review to help you find some stuff to work on/learn from. Hope it'll keep you busy some moment. ;-) Cheers, -- Cyril Brulebois pgpfqXUT9sJli.pgp Description: PGP signature
Re: RFS: mg (updated package)
On 14/01/2008, Trent W. Buck wrote: > I am looking for a sponsor for the new version 20070918-1 > of my package "mg". Some quick comments: - debian/changelog, line 11: wrong indentation? - You B-D on debhelper >= 5, and still use compat 4 (debian/compat). Any reason to do so? - You don't use any VCS to maintain your packaging? > The package appears to be lintian clean. Being a bit picky: I: mg: hyphen-used-as-minus-sign usr/share/man/man1/mg.1.gz:30 I: mg: hyphen-used-as-minus-sign usr/share/man/man1/mg.1.gz:31 Quite easy to fix, though. Cheers, -- Cyril Brulebois pgpBAfUChUSGx.pgp Description: PGP signature
Re: python-osd (adopted package)
On 14/01/2008, Mauro Lizaur wrote: > Hello there, 'lo. > I recently adopted the python module python-osd, i could say that i've > already finished the work needed but i have a couple of question > though: First, I'd like to point you to the DPMT[1,2], which might act like a mentor with specific knowledge of python-specific troubles. 1. http://python-modules.alioth.debian.org/ 2. http://wiki.debian.org/Teams/PythonModulesTeam > 2) > -- > python-osd: arch-independent-package-contains-binary-or-object > /usr/lib/python-support/python-osd/python2.4/_pyosd.so > The package contains a binary or object file but is tagged > 'Architecture: all'. > -- > > With the 2nd lintian warning, i had to fix some mistakes i found on > the debian/control file, such as 'Architecture: any' i changed that to > all, (the prev version didn't had this error because the arch wasn't > "all") So again, what should i do with this? How was that an error? Why do you think that “Architecture: all” is more appropriate. I guess you should be able to say for yourself after having double-checked Policy 5.6.8. > the previous version used python 2.3 and python 2.4, but now i just > use 'current' which is python 2.4. Should i use python 2.4 and 2.5, > leave with 2.3 and 2.4 or just use 2.4? If possible, you should build modules for all supported versions, see “pyversions -s” output. That works fine in most cases AFAICT. > Any recomendations is welcome :) Double-checking what the Architecture field is for should be #1 on your priorities list. ;) Cheers, -- Cyril Brulebois pgp68rSx9LNEk.pgp Description: PGP signature
Re: RFS: falcon package (ITP:Bug#460591); source package
On 14/01/2008, Giancarlo Niccolai wrote: > It is a sightly modified version of the package I am preparing for > Ubuntu, and it should generate correctly the libraries, the binaries, > the -dev and -dbg packages related to the basic contents of the Falcon > Language. Some quick remarks (this is not a complete review): - You need to target unstable rathen than sid. - Your Standards-Version is outdated. - You don't need the g++ B-D. - What is debian/copyfiles? Don't dh_install do the job already? - I think the ldconfig call will be added automatically by debhelper, to check. Same thing for the symlink. - No need to chown/chmod debian/tmp, dh_fixperms will do. - Looks to me that debian/rules could be really simplified if you were using dh_* commands. > I think there's something wrong with the watch file. Also, I need a > spin for what concerns the checksum files. All the rest should be > pretty complete. You might want to use the download page[1] although it doesn't contain any link to .7 currently. 1. http://www.falconpl.org/?page_id=downloads Cheers, -- Cyril Brulebois pgphbCbljJ9xs.pgp Description: PGP signature
Re: RFS: falcon package (ITP:Bug#460591); source package
On 14/01/2008, Giancarlo Niccolai wrote: > Yes, they could; but the build process is quite customized. Source > comes from three sub-projects that are kept separate for > administrative reasons, but are integrated at operating level. I read > in the debhelper and related manual that it may have some trouble in > detecting modules which need particular stripping rules, and a very > important part of the base library (which is supposed to support > application embedding scripts) relies on loadable binary modules, as > the RTL. You can always use parameters to exclude this or that files, using “dh_strip -Xfoo -Xbar”, which might help you target exactly what you want. > If that has to be done manually, then using some automated tools and > not other may mess up things; if not now, they may be in future if new > dependencies are drawn between dh_* tools. OK, thanks for considering. > And anyhow, I may use anything if it simplifies the process and works, > but I'd need assistance, as using such automated (and > documented-through-examples) tools can be problematic when having > custom builds and not a clear picture on how they infer things. I see, I'm not sure I'll find the time to help you do so, sorry. But if you run into troubles trying to, just ask here and see whether someone has a clue. > Oh... so the watch file can refer even an http page linking the packages? -- > where can I find some example? > However, shouldn't it work also on i.e. the http tree at Yes, that's documented in the manpage. The following should do: | http://www.falconpl.org/?page_id=downloads \ |/downloads/([0-9.]+)/Falcon-[0-9.]+.tar.gz Indeed: | [EMAIL PROTECTED]:/tmp/falcon-0.8.7$ uscan --report-status | Processing watchfile line for package falcon... | Newest version on remote site is 0.8.6, local version is 0.8.7 | falcon: remote site does not even have current version Cheers, -- Cyril Brulebois pgpY6aIlBpB0v.pgp Description: PGP signature
Re: RFS: libhugetlbfs
warn) about their deletion, and they won't appear in the source diff anymore. Looking at them: - libhugetlbfs-1.2/libhugetlbfs_write_dirs_installs might just go under debian, that'd be cleaner. - Makefile might deserve a dpatch/quilt patch. - strace.out might just disappear. - version.h could go along Makefile (in the same patch). I know you're still struggling with the build system, so that might be a burden to handle a patch management system. But in the long run, once you've sorted out versioning and stack troubles with upstream, switching to a patch management system will help you. Maybe not in the few next days or weeks, but you'll see for yourself. ;-) Cheers, -- Cyril Brulebois pgpKeSFYVNFLm.pgp Description: PGP signature
Re: packaging advice and eventually RFS: osmo
On 15/01/2008, Eike Nicklas wrote: > Ah, I did not check the source package. Now I actually noticed that > 'lintian .changes' checks both source and binary packages... Note that it depends on the options you possibly passed to debuild: -S -> source only, *_source.changes, -b -> binary only, *_$arch.changes, -> source & binary, *_$arch.changes, but including both. > Thanks for the reading hint, now the package should only be > crosscompiled if necessary. By the way, I only used DEB_HOST > (BUILD)_GNU_TYPE because these lines were autogenerated by dh_make. Is > crosscomiling support actually necessary or common? Some persons are actively working on embedding Debian, and crosscompiling. I guess it's just nice to try and not break cross compilation, and not to enter crosscompilation mode when not needed. It's just about doing the Right Thing©®™ (IMHO). > Indeed, I tried to run 'make distclean' before the Makefile was > created :-) , i.e. on the first compilation, when the rules clean > target is called. I included a workaround that first checks whether > the Makefile exists and if so, calls 'make distclean'. Is that ok? > What is the recommended procedure here? The templates (and usual practices) lead to: -$(MAKE) clean (or the same with distclean) But that meant ignoring errors that could happen during (dist)clean, and it is now reported by lintian, which also suggests the following idiom: [ ! -f Makefile ] || $(MAKE) clean > One more general question on closing bugs? Would a hypothetical upload > of the new revision close the ITP-bug or are only the very latest > Changelog entries considered when bugs are closed automatically on an > upload? It's a bit of a hot topic (successive revisions uploaded to mentors), but a point on which most agree is that one upload to the archive = one changelog entry, so you would either keep on working on the same single revision (and mentors.d.n should do/provide with whatever is needed to ensure mentors can look at the diffs between successive revisions), or work on several ones, merging the changelog entries afterwards. Anyway, you want to read about the -v option of dpkg-buildpackage, which help including the appropriate changelog entries when it's not just the last one (the default). You could also have a look at backports.org, which contain detail instructions on how to provide with backports, to see why such an option can be needed. > Thanks for your feedback, You're welcome. Cheers, -- Cyril Brulebois pgpGK1jQTKMM0.pgp Description: PGP signature
Re: RFS: libsetproctitle
On 16/01/2008, Max Lapan wrote: > It builds these binary packages: > libsetproctitle0 - A setproctitle implementation > libsetproctitle0-dev - A setproctitle implementation development files Do you think you'll have to manage libsetproctitleX-dev and libsetproctitleY-dev at the very same time? If you won't, just call it libsetproctitle-dev. Cheers, -- Cyril Brulebois pgpK5CYNxZKvN.pgp Description: PGP signature
Re: RFS: gitstats: statistics generator for git repositories
On 16/01/2008, Ansgar Burchardt wrote: > The package can be found at http://43-1.org/~ansgar/gitstats/. > > This is my first package, any feedback is welcome. Please install lintian (and make sure it is the latest version), and run it against both source and binary packages. Some work to do before going any further: Source: --- W: gitstats source: binary-arch-rules-but-pkg-is-arch-indep W: gitstats source: out-of-date-standards-version 3.7.2 (current is3.7.3) E: gitstats source: missing-build-dependency python-support Binary: --- E: gitstats: manpage-not-compressed usr/share/man/man1/gitstats.1 W: gitstats: copyright-lists-upstream-authors-with-dh_make-boilerplate W: gitstats: changelog-file-not-compressed changelog.Debian (You want to run lintian with -i and -I.) Cheers, -- Cyril Brulebois pgpRGYtUG9YbG.pgp Description: PGP signature
Re: SONAME vs illegal package name
On 17/01/2008, Tim Brown wrote: > two libraries, libopenvas and libopenvas_hg and I was getting > complaints that libopenvas didn't match the SONAME (for > libopenvas_hg.so) FWIW, it is thought about removing this lintian check (I had a quick discussion with Russ Allbery in #459851[1]). 1. http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=459851 > so I broke it down into one package per library (and a dev package for > each) - libopenvas and libopenvas_hg. However I'm now getting > complaints that the package name of libopenvas_hg is illegal. It's not needed, especially if they are supposed to be updated altogether (unlike if they were libfoo and libar, with no relation at all between them). And indeed, you can't have any “_” in package name, see the Debian Policy 5.6.7. I'd suggest you let the lintian info/warning as it is for now, no need to override it AFAICT. Cheers, -- Cyril Brulebois pgpzSXC4lWtxb.pgp Description: PGP signature
Re: RFS: terminator
On 18/01/2008, Nicolas Valcárcel wrote: > > Had a quick look, the following are improvement suggestions: > > - the package is not lintian clean: > > W: terminator: package-contains-empty-directory usr/lib/ > > This is a bug in python-central IIRC, i have tried to fix it for hours > but someone point me at a bug that makes this empty usr/lib/ FTR: #452227. > > Moreover, I would be happy to sponsor it but I've a personal rule: I > > want packages to be on some collaborative maintenance repository. So > > go find one (add the proper Vcs-* fields to debian/control) and I'll > > be happy to sponsor terminator; if no one fits more precisely your > > package go for collab-maint. > > I'm not sure about you are talking about, we have collaborative bzr > repositories on launchpad, but i can't find information about the > Vcs-* fields, can you point me to them please? http://article.gmane.org/gmane.linux.debian.devel.announce/1143 Cheers, -- Cyril Brulebois pgp0v7DnYlSP5.pgp Description: PGP signature
Re: RFS: rafb
On 20/01/2008, Moe Smith wrote: > I just uploaded a fixed version 1.0-6, my lintian (from lenny) doesn't > complain about that one anymore. Please let me know if there are still > problems. Please always use the latest one. Since it's a Perl-based package, it shouldn't cause any problem to fetch the unstable package and install it on your lenny (through “dpkg -i”, for example). > Well, I'd hope packages are judged by their usefulness, not by their > size. :-) > rafb is a one-trick-pony. I created it because I found nothing similar > in debian. I unfortunately missed 'pastebinit' by David Paleino in my > search because my first contact with mentors was when I sought a way > to upload my newly created package... > > Anyways, what is the general debian policy about one trick ponies? > Can multiple alternatives go in or should only one be chosen? Alternatives aren't an issue. Small (1-script-with-a-single-purpose falls in the “small” category) packages are usually frowned upon. Especially if that pastebinit does its job right and supports multiple hosts. Cheers, -- Cyril Brulebois pgpqTr7Zt9rqV.pgp Description: PGP signature
Re: RFS: rafb
Please. Pretty please with sugar on top. Use “list-reply” and stop sending mail copies unless someone asks for it. On 20/01/2008, Moe Smith wrote: > Hmm, okay, where would I fetch the deb? > I'm actually running etch (pinned) but with lenny and unstable in my > sources.list. "apt-get install -t unstable lintian" only gave me the > lenny version. I'd say wrong pinning, then. You can use aptitude to choose the version you want, use “force version” in synaptics, or use “install lintian=$version” in apt-get or aptitude. See “apt-cache policy lintian” to get available versions. > Well, I understand there are concerns wrt maintenance overhead and > that small packages may be more likely to turn into orphans than, say, > xorg. Maybe utilities as small as mine (or, say, the flickr-upload > stuff) are really not worth including. But otoh I wonder how many of > the small things can be left out before users start looking for other > distros :-\ As it has already been pointed out, better group small utilities sharing the same goal(s) into scripts-bundle packages. > > Especially if that pastebinit does its job right and supports > > multiple hosts. > > Sure. I'm not religious about this, if pastebinit is better then make > that one go in. I didn't know about pastebinit when I created rafb > because I had only checked etch,lenny,unstable and not mentors. (my > bad, sorry, I'm new to this) No problem. I guess that somehow merging all scripts into the same package, or even into the same script shouldn't be hard, and would make the whole better. Cheers, -- Cyril Brulebois pgpZcqrDjdfab.pgp Description: PGP signature
Re: Unused libraries copyrigths
On 21/01/2008, Al Nikolov wrote: > In a case when upstream tarball contains some third party libraries > which are not used in favor to theirs packaged versions, what should > be done? > > 2b. All copyrights should be declared though the third party code is > not used in binary package (just because it is distributed in source > package). (Don't do 2a., as pointed out by Baby already.) If you're going that way, you may want to notify the security team that you're embedding code copies, but that you aren't using them. Details: http://wiki.debian.org/EmbeddedCodeCopies Cheers, -- Cyril Brulebois pgpp9PHzNeFFe.pgp Description: PGP signature
Re: RFS: gnash (updated package)
On 24/01/2008, Miriam Ruiz wrote: > PS: I have added the label "XS-DM-Upload-Allowed: yes" to > debian/control to allow Debian Maintainers uploads (that's me). If > you're not comfortable with that, please ignore this sponsorship > request. Hi Miry. It's no longer an XS- field, see the changelog entry of dpkg/1.14.16. Cheers, -- Cyril Brulebois pgp84OzIG6uFr.pgp Description: PGP signature
Re: RFS: QA Uploads
On 26/01/2008, Frank Lichtenheld wrote:
> On Thu, Jan 24, 2008 at 09:01:22PM -0500, Barry deFreese wrote:
> > http://mentors.debian.net/debian/pool/main/l/libapache2-mod-xmlrpc2/libapache2-mod-xmlrpc2_2.2.1-3.dsc
> > Fairly intrusive but makes it build and fixes 2 important bugs.
>
> debdiff between the old and new binary:
> File lists identical (after any substitutions)
>
> Control files: lines which differ (wdiff format)
>
> Depends: {+apache2.2-common,+} libc6 (>= [-2.3.6-6), libdb4.3 (>= 4.3.28-1),
> libexpat1 (>= 1.95.8), libruby1.8 (>= 1.8.4), libxmlrpc-c3, apache2-common
> (>= 2.0.50)-] {+2.7-1), libuuid1, libxmlrpc-c3+}
> Installed-Size: [-72-] {+124+}
> Maintainer: [-Andres Salomon <[EMAIL PROTECTED]>-] {+Debian QA Group <[EMAIL
> PROTECTED]>+}
> Version: [-2.2.1-2-] {+2.2.1-3+}
>
> So the dependencies on libdb4.3, libexpat1, libruby1.8 vanished? Is that
> correct?
At least from a .so point of view:
Symbol diff:
./usr/lib/apache2/modules/mod_xmlrpc.so:
@@ -1,13 +1,10 @@
NEEDED libxmlrpc.so.3
+ NEEDED libxmlrpc_util.so.3
NEEDED libxmlrpc_xmlparse.so.3
NEEDED libxmlrpc_xmltok.so.3
+ NEEDED libuuid.so.1
NEEDED librt.so.1
- NEEDED libm.so.6
NEEDED libcrypt.so.1
- NEEDED libnsl.so.1
NEEDED libpthread.so.0
NEEDED libdl.so.2
- NEEDED libdb-4.3.so
- NEEDED libexpat.so.1
NEEDED libc.so.6
- NEEDED libruby1.8.so.1.8
Since the previous (-2) revision can't be rebuilt (FTBFS), I only
applied the CMakeLists.txt diff, and both (the rebuilt one and the
“Barry one”) binaries are the same. Could it be that these NEEDED
dependencies previously came from extra linking and/or from extra Libs
in pkgconfig files (or similar), now moved to Libs.private?
Note that xmlrpc-c is in a strange shape (build states), I'm contacting
seanius through private mail about that.
Cheers,
--
Cyril Brulebois
pgpj6W4Uhyu2f.pgp
Description: PGP signature
Re: RFS: piklab (updated package)
On 26/01/2008, Miriam Ruiz wrote: > Yup, you're right here. All those changes are really confusing if you > don't follow every single list in Debian for a while, I guess. I'll > remove it, reupload the package to mentors and see if it works this > time :) Following devscripts and dpkg's changelog might be considered a SHOULD in the policy, but I must confess that following dpkg these days is a bit challenging. :) Cheers, -- Cyril Brulebois pgpygpqRdifnY.pgp Description: PGP signature
Re: handling nostrip and noopt with CDBS.
On 27/01/2008, Charles Plessy wrote: > I got very interested in CDBS, thinking that it would save me a lot of > time if for instance 'nocheck' will be implemented in the Policy some > day. I thought that it was handling nostrip and noopt automagically > but apparently it is not the case for most of the classes. > > Does anybody know a way to factorise the code to handle these options? I suggest you open a wishlist bug so that the author(s) consider adding these everywhere it is needed, possibly with examples of yours where cdbs currently fails at doing the Right Thing©®™. Note that concerning nostrip, you're able to pass some variables: | /usr/share/cdbs/1/rules/debhelper.mk:DEB_DH_STRIP_ARGS = $(cdbs_dbg_package_option) Concerning notest, ditto: | /usr/share/cdbs/1/class/makefile-vars.mk:DEB_MAKE_TEST_TARGET = | /usr/share/cdbs/1/class/makefile-vars.mk:_cdbs_deprecated_vars += DEB_MAKE_TEST_TARGET | /usr/share/cdbs/1/class/makefile-vars.mk:DEB_MAKE_CHECK_TARGET = $(DEB_MAKE_TEST_TARGET) -- Cyril Brulebois pgp3geKXHI1eT.pgp Description: PGP signature
Re: RFS: pidgin-rhythmbox (try 2)
On 29/01/2008, Jonny Lamb wrote: > * debian/docs is a little pointless as all "README*" files are >automatically included[0]. I don't read it as you do. Given dh_installdocs's manpage, and dh_make's code (quoted below), I'd rather say that such files are automatically detected when dh_make'ing and added to the docs file, later used by dh_installdocs. | our @DOCS= split / |\n/, `ls -1 N[Ee][Ww][Ss] *[Ff][Aa][Qq]* *.[Tt][Xx][Tt] README* *.README [rR]eadme* *.[rR]eadme [Bb][Uu][Gg][Ss] *[tT][oO][dD][oO]* 2>/dev/null`; Cheers, -- Cyril Brulebois pgpT3Xl4y7h3l.pgp Description: PGP signature
Re: RFS: bulletml (updated package)
On 30/01/2008, Luca Bruno wrote: > Anyway I'm wondering, as part of the Game Team, don't you have an > usual sponsor? Did you ask him before mailing -mentors? As a general remark, there are many packages maintained in this team, and additional sponsors wouldn't hurt. > As I see this is usually maintained by Miriam, and she has DM > privilege, wouldn't be better for you both if she does the upload and > set the DM-Allowed field? For this particular package, that looks like a nice idea. Cheers, -- Cyril Brulebois pgp2kjMkkbwSa.pgp Description: PGP signature
Re: RFS: pidgin-rhythmbox (try 2)
On 31/01/2008, Jon Dowland wrote: > Agreed - I've added it to the source stanza in my git repo. Come to > think of it, I should make that publically accessible and add the VCS > control field too. I'll take a look at that tonight. Note that collab-maint is (IMHO) a nice place for that, just get added to the collab-maint group, log into alioth, cd /git/collab-maint, generate a new repository (a script is there) and push your branches and tags there. It's even said to be backuped for you (!). Cheers, -- Cyril Brulebois pgpBFv0BnowBY.pgp Description: PGP signature
Re: .menu and .desktop files
On 31/01/2008, Siegfried-Angel wrote: > As an Ubuntu Developer I ask you to please do so, as if a package is > missing a .desktop file it will have to be modified in Ubuntu to add > it (and do this again each time we get a new revision of it from > Debian, until the Maintainer adds it to Debian). Which shouldn't take long if the patches get submitted to the Debian maintainers (as opposed to relying on the Debian maintainers to dig patches.ubuntu.com on her/his own — which I had several times already, and is a bit of… weird). Cheers, -- Cyril Brulebois pgpr1ujyS6yk5.pgp Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Julien Lavergne wrote:
> That's something I wanted to do, but I didn't find a good way to do
> that. I tried to replace ${shlibs:Depends} with only necessary
> library, but dpkg-shlibdeps still get the same warnings.
Oh, no, you definitely don't want to touch that!
The idea is to get rid of extra/unneeded “-lfoo -lbar …” in the
upstream Makefile, so as to link only against the libraries that are
actually used.
Sometimes, just deleting an -lfoo would do. But more commonly, the
build system doesn't allow you to use fine-grained library
dependencies. That's where LDFLAGS=-Wl,--as-needed is your friend,
since it tells the linker to forget about the unused libraries
(resulting in less NEEDED entries, and happy dpkg-shlibdeps).
*BUT* that might break the resulting binaries, since (depending on
various things, like build/link options), you may end up with
undefined references, which result in runtime crashes.
To avoid that, you probably want to use another LDFLAG(S):
-Wl,-z,defs, which explicitely forbids such undefined references.
Note that this might still break the build system, but that *is* a
good thing. Usually, the problem is that the intermediate builds are
broken, since the resolution of undefined references is (again, in
some conditions) postponed to the final linking. By using this option,
you explicitely forbid any single undefined reference (including in
the intermediate targets), which means that you might sometimes have
to modify the Makefiles to add some -lfoo or -lbar, or e.g. add
TARGET_LINK_LIBRARIES() in cmake build systems.
That's a bit of work, but you'll probably end up with less
dependencies (expressed in less Depends:), which is obviously
(installed size, testing migration, etc.) a good thing.
Cheers,
--
Cyril Brulebois
pgptP128LiBWj.pgp
Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Neil Williams wrote:
> > Note that this might still break the build system, but that *is* a
> > good thing.
>
> (Agreed, but is probably easier to fix upstream than in Debian,
> YMMV).
Well, if you're packaging something, basic understanding on what the
code is doing, what submodules exist and so on, is expected. That's
IMHO a very good way to get more and more familiar with upstream's
code. And helping upstream fix this kind of problem is usually very
welcome (beside being part of the maintainer's job — I mean: working
together with upstream).
> but if that extra dependency is genuinely necessary for some other
> application which would almost inevitably be installed alongside the
> package in question, then no harm is done.
I don't buy this “genuinely necessary”. There are some exceptions, but
dependencies between binaries (as in executables and shared objects,
or -data packages are what I call “genuinely necessary”. I'm not going
to second-guess what is then necessary besides that. If there are more
to come, that should be in Depends: anyway (like the -bin of a
library, in addition to ${shlibs:Depends}), or Recommends or whatever.
Blocking (or being blocked for) testing migration still hurts.
> > That's a bit of work, but you'll probably end up with less
> > dependencies (expressed in less Depends:), which is obviously
> > (installed size, testing migration, etc.) a good thing.
>
> Agreed, it is a v.good thing. Not sure it is yet something we should
> be advising on mentors, that's all. It may well be harder than
> expected and the methods are not that user-friendly.
Why? Maintaining a package is not (just) about making lintian happy
and uploading new versions. Getting rid of extra dependencies is IME a
very good learning experience, and I wish it would be the kind of
questions asked during T&S (at least: I'd have been glad to have to
work on this kind of problem).
And it's (still IMHO) a very good occasion to learn about linker
flags, and possibly have a deeper view on how autotools, cmake, scons
(erk) deal with that.
Cheers,
--
Cyril Brulebois, still in NM, FWIW.
pgpgNdwPtc9AF.pgp
Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Neil Williams wrote: > What I meant was if dependencyA appears in the dpkg-shlibdeps list > of "not needed" linkages for 'foo' but foo is nearly always > installed alongside bar which uses symbols from dependencyA (i.e. > dpkg-shlibdeps doesn't complain about dependencyA in the build of > bar), then foo probably doesn't need to be altered. It's no > absolutely necessary for foo to Depend on dependencyA but it doesn't > hurt in the majority of cases. I now see your point, but I still disagree. Say foo depends on bar, bar depends on baz, and there's an extra link (hence Depends) between foo and baz. baz gets a bumped SONAME, bar gets rebuilt (through binNMUs). Fine. Err, no. foo has to be rebuilt as well. Too bad. I'm not only speaking about testing migration here. That means extra libraries installed whereas the old version on baz could have gone away in a single round. There's no use having additional unneeded dependencies, even if they appear to be legit. > there are also cases where dpkg-shlibdeps reports an extra linkage > where the library concerned is already packaged alongside a library > that does need to be linked against the package - libdl is the most > common. I agree that there are some special cases, like libdl, pthreads, and so on. But ISTR that whole pages were reported by dpkg-shlibdeps, not only a few lines. > Well, it's not something I am doing for my own packages, yet, so I > don't want to push it onto those maintainers whom I sponsor when I > am not comfortable getting it to work on my own packages. I understand that, of course, but I wouldn't jump to conclusions (I'm not sure we should…) anyway. > I'm experimenting with a few things upstream where the upstream > ./configure asks for the pkg-config data but then either does some > parsing of it or substitutes a (shorter) replacement but pkg-config > exists for a good reason and (IMHO) -Wl,as-needed isn't a complete > solution to the problem (with or without zdefs). I didn't say (or at least not in these words) it was a silver bullet, but rather a workaround in the cases where simple patches against the build systems seem unreasonsable (e.g. qmake?), and as a learning experience. > the complication is that tinkering with pkg-config data like this > can trip up porters and cross builders and as my main workload is > cross building, I'm not about to break my own work. :-) I know what porting means, look in the BTS for kfreebsd-* bugs. > Now I'm all in favour of reducing spurious dependencies - as anyone > would expect whilst working on making Debian small enough for > embedded devices - but not at the cost of making more work for > myself when cross building the same package. I just want to be sure > the changes actually work before recommending them to others. IMHO, > -Wl,--as-needed -Wl,zdefs is not at that stage, yet. In the thread (on -devel) where the use of those options were discussed, I don't remind of people reporting broken packages due to that. But if you could find examples of broken packages because of that, I'm very interested (in having a look and eventually fixing them if I can do that). Cheers, -- Cyril Brulebois pgpUIuPy4cVfN.pgp Description: PGP signature
Re: RFS: avant-window-navigator 0.2.1
On 03/02/2008, Neil Williams wrote:
> Just imagine the chaos in Debian if the pkgconfig data of
> libgtk+2.0-0 was changed now. Each reverse dependency would then
> need upstream changes to add extra libs to the build that were
> previously implied. That would be just as disruptive as a full
> SONAME transition in Gtk+ itself - how long is it now since gtk1
> became gtk2? Adding a new pc file is the only realistic method that
> I can see because it supports all builds, not just Debian and the
> migration can be done incrementally.
Well, that pkgconfig modification is “your” plan, and I understand
(quite) well the implications it has, but I don't really see how it is
relevant to (not) using LDFLAGS.
> These kind of things have implications far beyond the current
> package but this is, IMHO, TheRightWay(tm) to fix things, not using
> -Wl,--as-needed.
That might be a means. But given the hell we already have, dealing
with upstreams only shipping a .la file, or not shipping any
{.la,.pc} at all, it's not the kind of modifications I'd like to
see happening know.
Again, I said LDFLAGS is a means of getting (quite safely) rid of
extra dependencies, and that it is *not* a silver bullet. Or call
“TheRightWay©®™” if you like.
> In the meantime, I think it's worth being cautious about
> recommending trimming of dependencies. Maybe applications can be
> trimmed without too many consequences but I wouldn't advise trimming
> the dependencies of a library (or library pkgconfig file) on mentors
> - which is a problem because it is with libraries where the benefits
> of trimming are most evident.
Note that I share your concerns about modifying .pc files, but also
that I didn't suggest such a change, ever; since indeed, it would
require serious testing (at least rebuilds, layer by layer, of all
r-depending packages; but also checking whether functionalities were
lost, etc.).
Besides that, I still don't get the “why we wouldn't advise…” part. If
that leads to problem(s), then that'll be reported, and fixed. But not
even *trying* to improve things looks very wrong to me. We have tools
to detect extra dependencies. We have means of getting rid of (some
of) them, others to ensure we don't introduce breakages (like
undefined references). Why not using them? Just stating “that might
not be safe” looks like FUD to me.
If you want dangerous things, I have real examples: the new symbols
feature from dpkg, which already broke several (previously working)
packages on various architectures, be it armel, kfreebsd-*, etc.
Symbols are *not* safe to be used yet, and that has been announced
since the very beginning, by porters, and that has proven to be right
since (and there are still breakages reported nowadays).
If you want another one: using --as-needed without -z,defs, for the
reasons I already mentioned. But I'm not advertising that, either.
AFAICT, the above-mentioned LDFLAGS didn't break packages until now,
and are used quite often (I'd bet see the gnome-related packages,
since lool has been advocating these options in the thread on -devel,
although I didn't check), at least on a bunch of package I maintain,
or that I'm preparing.
Not to mention that we are on -mentors, and that packages get
double-checked, by the sponsoree (which is supposed to have checked
the runtime quite seriously), and by a sponsor, who could at least
spot the use of --as-needed without -z,defs.
Really, I don't see why we shouldn't encourage people using those
options.
Cheers,
--
Cyril Brulebois
pgpUtuNNnbi31.pgp
Description: PGP signature
Re: RFS: thailatex (updated package)
On 04/02/2008, Theppitak Karoonboonyanan wrote: > Yet another small update with unchanged version number: Build-dep on > dpkg-dev (>= 1.14.13), for proper support of the Vcs-Cvs field. I wouldn't care so much. Either you're building for unstable or experimental, and that's guaranteed already; or you're building a backport of whatever, for which those fields are AFAICT quite irrelevant. And dpkg is quite cool, and should only discard unrecognized fields, and shouldn't fail because of them. Cheers, -- Cyril Brulebois pgpVAEzHFl3yT.pgp Description: PGP signature
Re: List of out-of-date packages on a given architecture.
On 05/02/2008, Charles Plessy wrote: > I was just wondering if there was a tool accsssible to non-DDs, that > would allow to get the list of packages that have been uploaded more > than 10 days ago, d-d-c might help? > but never built on a given architecture. Not that I know. You probably want to check the queues on buildd.net, which should give you an overview of the state of each port. > I am about to write an email to the buildd admin of mips and mipsel > to ask for my packages to be built but before I would like to see if > I am just unlucky, or if this is a more general dysfunctioning. mipsel has a huge backlog, and ISTR that mips too. Nothing related to your particular packages, I'd say. Remarks based on some packages of mine, and of some packages I've been more or less tracking during the last weeks. Cheers, -- Cyril Brulebois pgp9lOxcHxyNs.pgp Description: PGP signature
Re: List of out-of-date packages on a given architecture.
On 05/02/2008, Kumar Appaiah wrote:
> lam FTBFSing on mipsel due to a gcc bug:
> http://experimental.ftbfs.de/fetch.php?&pkg=lam&ver=7.1.2-1.1&arch=mipsel&stamp=1202167930&file=log&as=raw
Enjoy 4.3 series… An IMHO interesting test would be trying to get it
built with 4.2.
> lapack FTBFSing on mips due to a mysterious reason:
> http://experimental.ftbfs.de/fetch.php?&pkg=lapack&ver=3.1.1-0.2&arch=mips&stamp=1202168381&file=log&as=raw
Maybe killed from outside, not necessarily a compiler error like the
first one.
> If I get enough money later in life, I'm definitely buying one of
> these machines, _just_ for testing out stuff and doing a
> dput/dupload of packages built on them.
Porter machines could help, anyway. Depending on the architectures,
there are some of them available (at least for DDs). Some nice people
even offer access to their architectures to mere contributors (hppa,
kfreebsd-*, for example).
> Would look awesome to stand apart with a mips(el) or s390 upload,
> when others are doing only source+{i386,amd64}. :-)
You're forgetting powerpc uploads anyway. :p
Cheers,
--
Cyril Brulebois
pgpAudAZWrfYC.pgp
Description: PGP signature
Re: List of out-of-date packages on a given architecture.
On 05/02/2008, Kumar Appaiah wrote: > (Removing CC to debian-mips, as your last mail got the point across). Well, that was on purpose… > > Enjoy 4.3 series... An IMHO interesting test would be trying to > > get it built with 4.2. > > While I'd love to, "this is a job for Debian (mips) man!". What I > mean is, someone has to do this on a machine and tell me if this is > a regression (since doko has ruled out the possiblity of GCC 4.2 > being the preferred build toolchain component, we have confirm that > it's a regression). … since I'd bet it's more likely to have a subscriber of -mips than a subscriber of -mentors be able to do so, that's why I replied with a cross-post. You might want to try [EMAIL PROTECTED], but looks to me you might have more chance by asking the -mips subscribers. Cheers, -- Cyril Brulebois pgpmx7ObiBLxq.pgp Description: PGP signature
Re: RFR: meritous
On 05/02/2008, Dylan R. E. Moonfire wrote: > Sorry about that. The package name is 'meritous' not 'mertious', I > keep misspelling it but the package name is correct. OK. Specifying a fixed subject. Direct link to the source package: http://mfgames.com/debian/dists/unstable/main/source/meritous_1.2+dfsg-0pre2.dsc Some items to work on follow. Binary package, lintian reports: , | I: meritous: arch-dep-package-has-big-usr-share 3460kB 95% | I: meritous: binary-has-unneeded-section ./usr/games/meritous .comment ` The first one indicates it might be interesting to split the packaging meritous + meritous-data packages, the second being arch-independent. The second sounds like you shouldn't call “strip” directly, but rather let dh_strip do the job itself. I guess it detects the binary is stripped, so doesn't act at all, but it could have been stripped further in case dh_strip would have done the job alone. Just a wild guess, though. There's also this file: , | ./usr/share/doc/meritous/gpl.txt.gz ` Looks like an extra license file to me, the copyright file is sufficient, you can drop this one. JFTR, your clean rule does its job, the diff is still clean after a binary build, then a source build. Now, source package. Version is 1.2+dfsg-0pre2. I'm not sure what the “0pre2” indicates. If that's a preview (release candidate) of 1.2, that might be 1.2~0pre2 or something similar. 1.2~pre2 might be what you want, since I guess the 0 was only there to make sure it sorts before a -1. So, if you're going to use 1.2~pre2 as upstream version (remember to rename your .orig.tar.gz accordingly), that would mean 1.2~pre2-1 for the version you mention in debian/changelog. You could add a Homepage field in the control file, as well as Vcs-* headers if you're maintaining your package in a publicly-accessible version control system, see [1], item 3 (debcheckout). 1. http://lists.debian.org/debian-devel-announce/2008/02/msg0.html debian/docs: gpl.txt should be dropped, which would solve the point raised above. debian/menus: looks like “needs” wasn't adapted, was it? Although the filename is pretty clear about its goal, you probably want to document what your data_in_share.patch patch does. I'd suggest at least an entry in debian/changelog (which I usually find sufficient), but I've seen advised to also include a header in the patch itself, see “quilt header”. You may want to use some quilt options to make your patch look a bit nicer, like --no-index, --no-timestamps, -p ab, etc. FWIW, I'm using: ,[ ~/.quiltrc ]--- | QUILT_NO_DIFF_INDEX=true | QUILT_DIFF_ARGS="--color=auto -p ab" | QUILT_REFRESH_ARGS="-p ab" ` debian/README.Debian should be moved to debian/changelog (see the comment above, about documenting the patch). No need to explain that in this file, which is mostly intended for end users. debian/rules: nothing is done in the configure target, you probably might remove it altogether with the its -stamp. strip call, already pointed out above. The detection of whether a make clean call is a bit surprizing. Couldn't you just call make clean inconditionally? Ah, OK, I see. I suggest you forward it to upstream to rather use rm -f on these files, which makes it possible to call “make clean” at any moment. You could eventually replace it with the following call, which would make it obvious what is intended, until upstream fixes it: , | find -name '*.o' -delete ` still debian/rules, you might use .install file to handle the installation of these files, rather than calling “install” manually. I'm not sure how dh_fixperms might handle the permissions of files under /usr/games, maybe the ownership is set appropriately, I'd suggest you try something like that. (You could grep in pkg-games's trunk to see whether some other packages are using chown/chmod or --group.) It's also good practice to delete the unused dh_* calls. Note that you aren't calling dh_installmenu. You could also use one of the file shipped in the share directory as an icon (in the menu file). Personal taste: I wouldn't use “(TM)” after Debian in the manpage footer. I'm also quite unhappy with the default “but may be used”. I tend to rather use “and may be”, which makes the intention clearer (you probably want upstream to include the manpage, so that you can just forget about it). It might be nitpicky, but I've been asked by one of my upstream about a manpage I updated, which contained such a statement. It might nice to see how to support debug builds, that is: no stripping and no optimization (Policy 10.1). That might require some tweaks in the upstream makefile, so that you can specifying some flags from debian/rules (like "-g -O0" in C(C)FLAGS). I think it's all for now, let me know if you have any troubles, or when you have an updated package, I'll have it sponsored. Cheers, -- Cyril Brulebois pgpkfQWkDWbSY.pgp Description: PGP signature
Re: RFS: swath 0.3.2-1 (updated package)
On 06/02/2008, Paul Wise wrote: > Well, I just checked the Vcs-* links, they seem to point to upstream > rather than the Debian packaging. They also have a debian dir in > them that doesn't seem to be updated. For the record, some reasons for asking upstream not to include a debian/ directory in the released tarballs: http://kitenet.net/~joey/blog/entry/on_debian_directories_in_upstream_tarballs/ Cheers, -- Cyril Brulebois pgp49SYfPwkUQ.pgp Description: PGP signature
Re: RFR: meritous
On 06/02/2008, Cyril Brulebois wrote: > OK. Specifying a fixed subject. And uploaded. Cheers, -- Cyril Brulebois pgpH9PcddM6mO.pgp Description: PGP signature
Re: Copyright question
On 06/02/2008, Jean Parpaillon wrote: > 3. All advertising materials mentioning features or use of this > software must display the following acknowledgement: > This product includes software developed at the University of > Tennessee, Knoxville, Innovative Computing Laboratories. > > 4. The name of the University, the name of the Laboratory, or the > names of its contributors may not be used to endorse or promote > products derived from this software without specific written > permission. > > > I've read DFSG and I'm not sure if items 3 and 4 are problematic. Can > someone help me ? If it's not ok, may it be in contrib ? See http://wiki.debian.org/DFSGLicenses, BSD-3 (without point 3.) isn't a problem. The advertising requirement (3.) is a problem, though. Note that if a package isn't DFSG-free, it can't go to contrib either. Contrib is for DFSG-free material depending on non-free (or contrib in turn) stuff, see Policy 2.2.2. Cheers, -- Cyril Brulebois pgpEMeCiAgb5l.pgp Description: PGP signature
Re: Copyright question
On 06/02/2008, Sebastian Harl wrote: > Just to make this clear […] Yep, thank you (all) for clarifying that, sorry for the inconvenience. Cheers, -- Cyril Brulebois pgpyGch4L5nAE.pgp Description: PGP signature
Re: RFC: Howto exclude config.sub and config.guess updates from .diff.gz
On 11/02/2008, David Paleino wrote: > Not true: > [Snip unrelated logic stuff.] Yes, true. Functionally, you want foo => bar. Check (assuming here foo is absent): , | [EMAIL PROTECTED]:~$ [ ! -f foo ] && echo "Doing bar 1" | Doing bar 1 | [EMAIL PROTECTED]:~$ [ -f foo ] && echo "Doing bar 2" | [EMAIL PROTECTED]:~$ [ ! ! -f foo ] || echo "Doing bar 1" | Doing bar 1 | [EMAIL PROTECTED]:~$ [ ! -f foo ] || echo "Doing bar 2" | [EMAIL PROTECTED]:~$ ` Now, moving that to a Makefile: , | #!/usr/bin/make -f | | and: | [ ! -f foo ] && echo "Doing bar 1" | [ -f foo ] && echo "Doing bar 2" | | or: | [ ! ! -f foo ] || echo "Doing bar 1" | [ ! -f foo ] || echo "Doing bar 2" ` You now get: , | [EMAIL PROTECTED]:~$ make or | [ ! ! -f foo ] || echo "Doing bar 1" | Doing bar 1 | [ ! -f foo ] || echo "Doing bar 2" | [EMAIL PROTECTED]:~$ make and | [ ! -f foo ] && echo "Doing bar 1" | Doing bar 1 | [ -f foo ] && echo "Doing bar 2" | make: *** [and] Erreur 1 ` > but I can't understand why it couldn't suggest something like: > > [ -f Makefile ] && $(MAKE) distclean > > which triggers the same result (at least in bash -- that's why I'm > supposing that "&&" needs to be escaped somehow in Makefiles). Explained already in my first mail, and in extenso by Justin. -- Cyril Brulebois pgpy7kq0QwpEG.pgp Description: PGP signature
Re: RFC: Exclude config.sub and config.guess from
On 11/02/2008, David Paleino wrote: > This seems to me more hackish than it should; is there a cleaner way > to do it (maybe I'm just complicating myself and don't see The Easy > Way [1])? You could have a look at how cdbs does it, which might help. > [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. That's simple, compare: [ foo ] && bar [ ! foo ] || bar If foo, then bar, and success. If not foo, then not bar, and failure. Here is your problem. The foo/bar relationship is the same, but not the return code, which is problematic in a Makefile, since it introduces a failure, thus make stops (see lintian about ignoring the errors in the clean target). Cheers, -- Cyril Brulebois pgpK2yQJ1P7Md.pgp Description: PGP signature
Re: Long descriptions in RFS emails.
On 11/02/2008, Andres Mejia wrote: > Perhaps it's best to include where the description and other > information should go. I'm thinking something like: > […] > The package appears to be lintian clean. I'd like not to see this in a template anymore. And rather a “State of the package with the latest lintian version available (in unstable):”, reminding people that this is not just a sentence to copy over, and that one has to actually run lintian… > The upload would fix these bugs: XX . . . Maybe suggesting to include a description and/or the severity of the bugs might help spot “important” uploads. > http://mentors.debian.net/debian/pool/main/p/package/package_version.dsc That URL is IMHO very sufficient. > Reason: This is a new upstream. It fixes a security issue that > allowed this and that. etc. . . . That might be a nice summary instead of just a list of bugs, titles, severities as I proposed above, but the idea is just the same. Cheers, -- Cyril Brulebois pgpCX1ODeUXnL.pgp Description: PGP signature
Re: [CDBS] adding commands to the checking target.
On 13/02/2008, Charles Plessy wrote: > I have disabled the tests on arm m68k s390 because they are not so > fast, and on mips mipsel hppa because the buildds for these arches > are not keeping up. That won't help your package get faster on the top of the queue. And this doesn't seem to be a valid reason at all to skip the test on some archs. Anyway, you know that m68k isn't taken into account for testing migration, right? > Anyway, I do not expect any user on these architectures. How is that a reason? I'd suggest not second-guessing users, and anyway, that can help spot arch-specific troubles (like in the kernel, ISTR hppa troubles detected at buildtime), or underlying bugs that might not be detected on other platforms by the testsuite, but ready-to-bite anyway. > I am all open to enable the tests if one can prove me wrong with a > message from a real user (the package name is primer3). And that user would be reading -mentors? I'd rather enable the tests on all architectures, except on those where you *might* have a *real* reason not to (I don't know, maybe you might want to disable the testsuite because an item of the toolchain is currently buggy and would make your package FTBFS?). Current statuses of various architectures aren't a reason to do so. -- Cyril Brulebois pgpZzqgAMssjw.pgp Description: PGP signature
Re: Skipping tests on some arches.
On 13/02/2008, Charles Plessy wrote: > 1h05 on sparc, > 37 min on mipsel, > 39 min on mips, > 37 min on powerpc, > 19 min on hppa, > 6 min on amd64… What about *relative* numbers, e.g. what % of the time is spent in the build itself (gcc and friends), and what % of the time is spent in the testsuite? Anyway, (almost) less than 1 hour everywhere isn't what I call time-consuming from a buildd point of view. > Not a big deal, except of course if everybody makes test like this. More tests, less bugs. > In popcon, there are 26 mips users, and primer3 is used by 0.1 % of > the Debian users. Popcon is no absolute knowledge. Anyway, 25+ users is far from negligible AFAICT. Remember popcon can be disabled for various reasons (e.g. privacy). I also seem to recall having heard of mips (but I might be mistaken) clusters being used for specialized research in related areas (but I'm not used to this domain, just reading the description of the package). > I still think that it is useless to wait for mips users to have > primer3 build before letting bug fixes to primer3 migrate to > testing, but as you noted, that it is a different story. Indeed, that's nothing related here, and you've been already heavily discussing the buildd redundancy matter elsewhere… > If the persons who care about the Debian ports do not mind my > package eating their CPUs, I'll happily re-enable the tests > everywhere. Less than 3/4 hour isn't what I call eating CPU. Go and see how many *hours* are spent in some packages. Again, I'd rather see buildd being used as much as possible to catch problems at build time than letting bugs pass through and bite users at runtime, which is always a PITA to debug. YMMV. -- Cyril Brulebois pgpwdLKzcWCwG.pgp Description: PGP signature
Re: Anonymous delayed queue?
On 14/02/2008, Charles Plessy wrote: > If you or somebody else agree that it is of general interest (in > private if you want to limit the traffic on this list), I can > propose an update for the Developpers Reference. Isn't that just basic UNIX knowledge? -- Cyril Brulebois pgpw1gdAWeJOJ.pgp Description: PGP signature
Re: Writing get-orig-source targets to conform with policy
On 17/02/2008, Kapil Hari Paranjape wrote: > If you want to document how/why you re-packaged the source for > Debian, this should be in README.Debian-source. No, that is supposed to be in debian/copyright. See recent discussions on -mentors, then moved to -devel & -policy, subthread starting around <[EMAIL PROTECTED]>. Cheers, -- Cyril Brulebois pgp6HJ8IFaX8W.pgp Description: PGP signature
Re: RFS: nettee
On 19/02/2008, Paul Wise wrote: > debian/docs: No need to distribute empty files nor a HTML copy of > the manual page. As for the HTML copy of the manual page, I wouldn't advise skipping it as a rule of thumb. When it's a long manpage, it might make sense to keep a nice-to-read copy around. I'm also thinking of git manpages, with cross-references and the like, where it's very handy to have them in HTML format. I don't know whether that applies to nettee, though. Cheers, -- Cyril Brulebois pgpmzSNLxsM18.pgp Description: PGP signature
[Done] RFS: colorgcc - Colorizer for GCC warning/error messages
On 27/02/2008, Barry deFreese wrote: > http://mentors.debian.net/debian/pool/main/c/colorgcc/colorgcc_1.3.2.0-8.dsc Being taken care of. Cheers, -- Cyril Brulebois pgplmaBgAevDv.pgp Description: PGP signature
Re: removal of a package. (ee)
On 28/02/2008, Mauro Lizaur wrote: > Well, i would like to hear more opinions and some advices on how to do this. Hi, http://wiki.debian.org/ftpmaster_Removals Cheers, -- Cyril Brulebois pgpVecbTAupDK.pgp Description: PGP signature
Re: Adding a second binary architecture to an upload
On 29/02/2008, Carlo Segre wrote: > I know that it is possible to add a second binary architecture .deb > to an upload. I just can't seem to find it documented anywhere. mergechanges(1) Cheers, -- Cyril Brulebois pgpbjoPdJpyWP.pgp Description: PGP signature
Re: Requests for sponsors to upload NMUs
On 04/03/2008, Neil Williams wrote: > > So why are we doing this now? This is an NMU - minimal changes > > scenario. Well, maybe the world isn't *that* black and white. Remember, NMUs are a way to help people fix their bugs, get their packages back into shape, etc. IANADD, etc., but I already got a few NMUs sponsored, and beside a single (IIRC) maintainer, I've never been insulted because I was doing some unrelated changes, fixing some glitches. > (And a mere lintian error/warning is not a good reason to file a new > bug either, that's why lintian exists.) (Ask jfs about that: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=27;bug=464264) > Sponsors, can we please stick to the rules for NMUs so that those > who seek advice here can get clear guidance on what is required? For the record, last MU for the considered package was back in 2005. Which might explain why Barry introduced above-the-usual-NMU-level changes. Cheers, -- Cyril Brulebois pgpb43OgxtRFp.pgp Description: PGP signature
Re: RFS: QA Upload: jack-tools -- various JACK tools: plumbing, play, udp, ctl, scope, clock
On 08/03/2008, Barry deFreese wrote: > Thanks for looking at this. I don't get these on i386 ( I only get 2 > warnings and 1 informational about a manpage). I don't have an amd64. “Usual” problem. > Any suggestions/pointers? You could use “chrpath” (-d) to remove the rpaths on the binaries (regardless of the architecture, no need to special-case). Poke me if you need examples. Cheers, -- Cyril Brulebois pgpTtAXLechCm.pgp Description: PGP signature
Re: No orig.tar.gz or diff.gz with pdebuild
On 08/03/2008, Todd A. Jacobs wrote: > If I try to do a standard build, I get all sorts of errors like: No. Not all are errors. > dpkg-source: cannot represent change to > test/test_compare/compare_siemens/siemens_010_f.png: binary file contents > changed > dpkg-source: cannot represent change to > test/test_compare/compare_siemens/siemens_012_f.png: binary file contents > changed > dpkg-source: cannot represent change to > test/test_compare/compare_confirmed/barcode_004_a.png: binary file contents > changed > dpkg-source: cannot represent change to > test/test_compare/compare_confirmed/barcode_014_c.png: binary file contents > changed Indeed, diff.gz can't hold diffs for binary stuff, only for text thingies. Those files probably get (re)generated during the build, so you might want to remove them in the clean target, so that they're no longer a problem while building .diff.gz. > dpkg-source: warning: executable mode 0755 of > 'test/test_compare/compare_siemens.sh' will not be represented in diff > dpkg-source: warning: executable mode 0755 of > 'test/test_compare/compare_confirmed.sh' will not be represented in diff > dpkg-source: warning: executable mode 0755 of > 'test/test_compare/compare_generated.sh' will not be represented in diff > dpkg-source: warning: executable mode 0755 of 'dmtxscangrid.c' will not > be represented in diff Those are warnings only. > dpkg-source: warning: ignoring deletion of file config.guess > dpkg-source: warning: ignoring deletion of file config.sub Those too, and you'll get the same if you do what I suggest for the images above. > So, what does one normally do when using subversion sources, rather > than a numbered release? That's obviously part of my problem here, > since libdmtx-0.4.0 is really libdmtx-0.4.0+svn102. I don't see how preparing svn thingies are relevant here, you just have to adapt the clean target to get rid of modified binaries (after having checked they are finally generated again, of course). Cheers, -- Cyril Brulebois pgpzjedAjJNz8.pgp Description: PGP signature
Re: BTS Command to get messages to a BUG#
On 15/03/2008, Michelle Konzack wrote: > Please can you tell me the BTS/PTS command (and the E-Mail) > which I must use to get all messages to a Bug#. Would "bts -m show N" suit your needs? Cheers, -- Cyril Brulebois pgpMnGbcNOr0L.pgp Description: PGP signature
Re: BTS Command to get messages to a BUG#
On 15/03/2008, Michelle Konzack wrote: > Please can you tell me the BTS/PTS command (and the E-Mail) > which I must use to get all messages to a Bug#. Would "bts -m show N" suit your needs? Cheers, -- Cyril Brulebois PS: Sending again, possibly broken ISP. pgpmb1sunmdur.pgp Description: PGP signature
Re: watchfiles for sourceforge packages
On 22/03/2008, Carlo Segre wrote: > As of a short time ago, this no longer works and results in a broken > watch file. Does anyone know if this is permanent or alternatively, a > better (at least working) URL to use in the watch file? man uscan, http://sf.net/ is your friend. Cheers, -- Cyril Brulebois pgpJrvZg1YSiD.pgp Description: PGP signature
Re: RFS: mother
On 22/03/2008, Antonio De Luci wrote: > * Package name: mother > Version : 0.6.4-r4 > Upstream Author : Federico Tomassini - Efphe <[EMAIL PROTECTED]> > * URL : http://www.dbmother.org/ Please remove the homepage from the long description, there's a dedicated “Source” field for that. The long description could be reformatted, so that you leave empty lines, or keep everything in a single paragraph, instead of just going back to the beginning of the next line. The Depends: on psycopg2 looks buggy. Shouldn't it be python-psycopg2 instead? > It builds these binary packages: > python-mother - Mother is an Object Relational Mapper with strong > introspection > > Description:Mother is an Object Relational Mapper with strong introspection Don't write “foo - foo is a bar” in the short description. “Object Relational Mapper with…” looks better (although I'm not a native English speaker anyway). > The package appears to be lintian clean. No. | [EMAIL PROTECTED]:~/tmp/mother-0.6.4$ lintian -i -I | ../mother_0.6.4-r4_i386.changes | wc -l | 31 Why is the revision -r4 anyway? Should be just -4. Also, your diff is empty. Shouldn't you be building a Debian native package if you're including your debian/ directory in the original tarball? Anyway, I'll recommend *not* doing so, and keeping debian/ outside of the tarball, not building a Debian native package. Cheers, -- Cyril Brulebois pgpy4SWxjKO3p.pgp Description: PGP signature
Re: RFS: mother
On 22/03/2008, Cyril Brulebois wrote: > [things] Woops, I almost forgot in those few comments that you're not closing your ITP bug in your changelog. Cheers, -- Cyril Brulebois pgpdvjKT5uLuZ.pgp Description: PGP signature
Re: RFS: QA Upload: eterm-themes -- Themes for Eterm, the Enlightened Terminal Emulator
On 29/03/2008, Laszlo Boszormenyi wrote: > First, was the debhelper compatibility upgrade necessary? I think > leaving it at level 4 makes backporting easier. $ rmadison debhelper debhelper | 4.2.32 | oldstable | source, all debhelper | 5.0.42 | etch-m68k | source, all debhelper | 5.0.42 |stable | source, all debhelper | 6.0.5 | testing | source, all debhelper | 6.0.10 | unstable | source, all So, unless you're backporting for oldstable, that's quite safe. -- Cyril Brulebois pgpcjvDjynoZa.pgp Description: PGP signature
Re: FTP excuses for lprng dont make sense to me
On 30/03/2008, Craig Small wrote: > It looks like HPPA and Armel just take their sweet time so its not a > build problem, but a taking too long to get up-to-date problem. > > Now, where is my previous version (3.8.A~rc2-1) gone? You uploaded …~rc4-1, and since …~rc2-1 was only in unstable, it got replaced with the …~rc4-1 upload. > It's not like lprng is new, its years old! since 1996. NEW as in not in testing. See [1] from the PTS page [2]. 1. http://packages.qa.debian.org/l/lprng/news/20080116T233918Z.html 2. http://packages.qa.debian.org/l/lprng.html Nice to see some “ng” packages aging since '96. :p > Bug 462605 was fixed, not introduced, in 3.8.A~rc4-1. I believe it's due to your package not being built on every arch. Cheers, -- Cyril Brulebois pgpdPN930rGqE.pgp Description: PGP signature
Re: RFS: arename
On 08/04/2008, Helmut Grohne wrote: > As far as I can see your package is perl-only, so > [...] > 3) Why is your package Architecture: all instead of any? Why are you asking questions you've answered already? -- Cyril Brulebois pgpyI9lKR8lcD.pgp Description: PGP signature
Re: Proposed new package, bugs-everywhere_0.0.193-1.1
On 21/04/2008, Ben Finney wrote: > I'd appreciate any feedback from those more experienced with Debian > packaging in general and Python packaging in particular. I won't be able to comment much on the python part since you're using -central, that I don't know. Anyway, some quick comments: - debhelper version mismatch: 5 is debian/compat, >= 6 in debian/control. - strange to see there's only a © 2005 copyright line, IIRC the project has been quite active lately. But still IIRC you're more versed into legalese than I am, so you probably told them to update their copyright notices. Hmm, and a quick grep shows that you're missing at least: ./libbe/hg.py:# Copyright (C) 2007 Steve Borho <[EMAIL PROTECTED]> - debian/README.Debian looks like superfluous (and contains a different address, for the sake of the argument). Maw, KiBi pgpFLMemf8KIo.pgp Description: PGP signature
Re: Alioth complains about new project registration
On 21/04/2008, Ben Finney wrote: > I can't easily find administrative contact email address at the Alioth > website http://alioth.debian.org/>, so I'm asking here in the > hope of some overlap. Just gave it a quick shot, you can search for “alioth” in “Software/group”, and spot “Site admin”, and then use their tracker. Interestingly, the project summary shows 2 public ML, whereas only one pops up when one clicks on that item. Maw, KiBi PS: BTW, the use of “” has been deprecated in favour of “<$foo>”. pgptJv2d06ilY.pgp Description: PGP signature
Re: RFS: bugs-everywhere
On 24/04/2008, Ben Finney wrote: > > Did you get the mail from Alexander? > > Alexander who? When was it sent? Schmehl. http://lists.debian.org/debian-mentors/2008/04/msg00330.html Mraw, KiBi. pgpCHeoD6L7Mb.pgp Description: PGP signature
Re: foo.diff.gz "difficult to read" (was: RFS: bugs-everywhere)
On 25/04/2008, Ben Finney wrote: > How is it difficult to read? I've opened it in Emacs and 'zless' and > in either of them it reads like any other diff. Like any other unified > diff, the changes are clearly marked by file, hunk location, and > context lines. What readability problems are you seeing? What > improvements would you want to see in the diff? Which means that all modifications to upstream sources are mixed in that diff, along with the addition of the debian/ directory. > As for a "patch management system", I find packages that use them > *more* difficult to understand as an outsider than those that use the > standard foo.diff.gz. If one is used, there should be one patch per topic, stored as debian/patches/$topic, thus grouping all modifications to upstream sources in a single file, thus helping people understand which diffs belong to which topic, and have an idea what's going on. > I've read much discussion for and against, and I'm currently convinced > that such systems are detrimental, on balance, for those wanting to > work with the package. So, no thanks, I'll decline on that suggestion > and continue to ship a standard foo.diff.gz. Note that a standard foo.diff.gz will still be shipped, it will only contain the addition of a debian/ (along with debian/patches/) directory. Just trying to clarify what was meant… Mraw, KiBi. pgpd6FswjIdKH.pgp Description: PGP signature
Re: RFS: php5-rar
On 27/04/2008, Deepak Tripathi wrote: > I am looking for a sponsor for my package "php5-rar". Various remarks: - debian/Changelog, what for? - debian/control: buggy indentation in long description. - debian/control: unsure about the section, please check the php policy. - debian/copyright: you don't quote the GPL boilerplate, IIRC it's better to do so. - debian/pecl: Unsure what it's used for (there's only a commented dh_pecl in debian/rules). - debian/php5-rar.dirs: probably unnecessary. - debian/rules: sorry, but: what a mess! You probably want to get rid of everything v4-related, as well as all commented out rules. There's also dh_install instead of calling install with a zillion parameters. Mraw, KiBi. pgpEODnf79TaE.pgp Description: PGP signature
Re: RFS: php5-rar
On 27/04/2008, Deepak Tripathi wrote: > It builds these binary packages: > php5-rar - rar module for PHP 5 Ah, I forgot that point: is the algo the same as in unrar? unrar-free? You might need to adjust the section in the former case; and to adjust the description for the latter, to be more precise about what that extension can do. Mraw, KiBi. pgp4hqiidXzMb.pgp Description: PGP signature
Re: RFS: gcin (updated package, closes RC bug #406036)
On 27/04/2008, Wen-Yen Chuang wrote: > The only one lintian warning is > "W: gcin: package-name-doesnt-match-sonames libgcin-im-client1". > It is unnecessary to pack a "libgcin-im-client1" package, because > libgcin-im-client.so.1.0.2 is only used by gcin internally. I didn't build it, so I cannot check, but is that SO in /usr/lib? If so, and if it's a private library, it might be moved to a subdirectory of /usr/lib (and then used through a rpath). Mraw, KiBi. pgpZ6Fodoo7La.pgp Description: PGP signature
Re: RFS: gcin (updated package, closes RC bug #406036)
On 27/04/2008, Gonéri Le Bouder wrote: > > You can read more about that at > > http://wiki.debian.org/RpathIssue > > > > That should be fixed... > > "Currently, the only generally accepted use of this feature in Debian > is to add non-standard library path (like /usr/lib/) to > libraries that are only intended to be used by the executables or > other libraries within the same source package." > > I think we are in this case. Exactly. Mraw, KiBi. pgpHgTLyDJirw.pgp Description: PGP signature
Re: tesseract-ocr: missing-dependency-on-libc
On 29/04/2008, Jeffrey Ratcliffe wrote:
> I assume that the gencontrol warning is connected to the missing
> dependency. I have, though, got ${shlibs:Depends} in Depends
What does dpkg --info on the binaries say? (pipe it into grep ^Depends)
> and I even tried manually adding libc too, all without luck.
DON'T DO THAT.
There are libc6, libc6.1, libc0.1, and libc0.3 around. You don't want to
hardcode it. Ever.
I was about to look into it, but your package FTBFSes with gcc 4.3,
patch attached.
While writing the patch, I noticed that upon resume (debuild -b -nc),
./configure gets run again, which is kind of unfortunate (although not
that long on a reasonable machine, it's at least inelegant). Oh, and
even during a regular build, there's a "configure" even after "make".
Also, your clean target doesn't do its job. Calling "debuild -b &&
debuild -S":
| dpkg-source: info: building tesseract in tesseract_2.03-1.1.diff.gz
| dpkg-source: warning: newly created empty file 'tessdata/spa.unicharset' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.pffmtable' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.inttemp' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/ita.inttemp' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/fra.pffmtable' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.freq-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/spa.DangAmbigs' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.unicharset' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/spa.word-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.word-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.inttemp' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.normproto' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.DangAmbigs' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.normproto' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/ita.word-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.normproto' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/fra.user-words' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/fra.normproto' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.word-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.DangAmbigs' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.unicharset' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/ita.unicharset' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.word-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/ita.DangAmbigs' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/fra.word-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.freq-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/fra.DangAmbigs' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.pffmtable' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.unicharset' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/deu.inttemp' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/fra.freq-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/spa.normproto' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.user-words' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/spa.user-words' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/nld.user-words' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/ita.user-words' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/eng.freq-dawg' will
not be represented in diff
| dpkg-source: warning: newly created empty file 'tessdata/ita.freq-dawg' will
not be represented i
Re: tesseract-ocr: missing-dependency-on-libc
(List-reply is your friend, I don't need extra copies, thanks.) On 29/04/2008, Jeffrey Ratcliffe wrote: > Ahhh. Thanks. Now it is lintian clean. But I have the following > warnings. In another package, I fixed similar warning by setting > LDLOADLIBS in rules. I could set LIBS here, except that > /usr/bin/tesseract DOES use libtiff, whereas the others don't. > > I could try and patch the Makefiles after configure, but that seems > rather hackish. Is there an elegant way of doing this? You could try and use LDFLAGS to pass -Wl,--as-needed (linker flags). But since it could break silently some parts of your build, it shouldn't be used without -Wl,-z,defs which will help spot possible missing -l$foo options in intermediate objects (if any). You can pass LDFLAGS to the ./configure script. Mraw, KiBi. pgpy2mLjtG6Ar.pgp Description: PGP signature
Re: RFS: pydance
On 01/05/2008, Brandon wrote: > Team has an abundance of maintainers, and not enough developers. Games > packages are often "pending upload" for many months at a time. Which might have changed some time ago, look at Gonéri's upload rate if you're not convinced. Mraw, KiBi. pgp7zEx4lobEz.pgp Description: PGP signature
Re: Examples
On 05/05/2008, Thibaut Paumard wrote: > IANADD, but I would put the doc and example files in > /usr/share/doc/packagename-doc. > /usr/share/doc/packagename/README.Debian should mention that the > reader can find doc in /usr/share/doc/packagename-doc once the > packagename-doc package is installed. Which makes two locations to look into while browsing /u/s/d. As a user, I prefer very much having everything under /u/s/d/$package/, eventually under various html/, pdf/, examples/, contrib/, etc. directories. Mraw, KiBi. pgp78pl5JWKzh.pgp Description: PGP signature
Re: Examples
On 05/05/2008, Thibaut Paumard wrote: > Actually I was sort of guessing the only package allowed to put > anything under /usr/share/doc// was itself. It's > probably the core of the original post. Is this assumption incorrect? AFAICT, yes. Particularly when the binaries come from the very same source, so that the maintainer is kind of aware of the possible implications of moving this or that bit of doc from a package to another (e.g. can handle moving a manpage/HTML manual or two from/to the $foo package -- say it's considered core documentation -- to/from the $foo-doc package, possibly setting Replaces: where needed, etc.). > I have no precise excerpt from policy to back it up. :) > Note that /usr/share/doc/-doc/ will be created anyway. If it contains the usual Debian changelog and copyright file, there's no reason to have a look there in the first place. If one installs $foo-doc, isn't it a bit logical to check for its documentation in /u/s/d/$foo? > If the actual doc is installed under /usr/share/doc//, then > /usr/share/doc/-doc/ should definitely point to it somehow, > via symlink(s) or README.Debian. Beware of symlinking. That means a strict dependency (because of the copyright file). And one probably doesn't want to update a possibly several dozens MB large -doc package when moving from 1.2.3 to 1.2.4, which is say a bugfix release only. Not to mention what happens when the package gets binNMU'd. Want to update a -doc package for that? Oh, and the funny part: how do you declare a strict Depends: on an Arch: any package from an Arch: all package? Mraw, KiBi. pgpJIco44IFlL.pgp Description: PGP signature
Re: RFS: ffmpegthumbnailer
On 10/05/2008, Vincent Bernat wrote:
> I see no other problem with your package. Let's see if some one else
> finds one. You could improve a bit the manual page by stating that -i
> and -o are mandatory, that -i waits for a video file and -o will output
> a PNG.
You could spare some Depends in the ffmpegthumbnailer package (wdiff):
| Depends: [-libavcodec1d (>= 0.cvs20070307), libavformat1d (>= 0.cvs20070307),
libavutil1d (>= 0.cvs20070307),-] libc6 (>= 2.7-1), libffmpegthumbnailer2 (>=
1.2.5), libgcc1 (>= 1:4.1.1-21), [-libjpeg62, libogg0 (>= 1.0rc3), libpng12-0
(>= 1.2.13-4), libraw1394-8,-] libstdc++6 (>= [-4.2.1-4), libswscale1d (>=
0.cvs20070307), libtheora0 (>= 0.0.0.alpha7.dfsg-1.1), libvorbis0a (>= 1.1.2),
libvorbisenc2 (>= 1.1.2)-] {+4.2.1-4)+}
You can check what happens with your current source package, and the
same with that additional line after other includes in debian/rules:
| DEB_CONFIGURE_EXTRA_FLAGS = LDFLAGS="-Wl,--as-needed -Wl,-z,defs"
(Check the build logs, and debdiff both binary .changes files.)
Mraw,
KiBi.
pgpZwZAAfw4rV.pgp
Description: PGP signature
Re: RFS figtoipe
On 11/05/2008, Alexander Bürger wrote: > Sorry, I was not on the debian-mentors list. In which case, you might want to add an In-Reply-To header, pointing to the message you're answering to, so that the thread won't break. Mraw, KiBi. pgpav5I4oXVgC.pgp Description: PGP signature
Re: RFS: libtorrent-rasterbar and qBittorrent (updated)
On 21/05/2008, Simon Richter wrote: > I wonder what we should do with ASIO. > > You are essentially patching the source to use the ASIO version inside > Boost. There is also a standalone ASIO library (which uses "asio" > instead of "boost::asio") I've been told long ago (months) that the standalone one might disappear once it's merged into boost (as of 1.35), so I guess that the standalone is going to be deprecated in favour of the one included with newer boost versions. Mraw, KiBi. pgpH4XTdEfiXw.pgp Description: PGP signature
Re: Compiling with -mtune?
On 22/05/2008, Neil Williams wrote: > To check the arch, always test against the HOST architecture. Native > builds set HOST == BUILD but if the package is ever cross-built, your > debian/rules must allow building an ARM package on amd64 (HOST=ARM, > BUILD=amd64) and *NOT* enable -mtune. That should read: “If you want to make Neil Williams happy, your debian/rules must allow building an ARM package on amd64”. That sentence most probably lacked an “e.g.”, “for example”, or “in particular” somewhere. Mraw, KiBi. pgpusonWo709f.pgp Description: PGP signature
Re: Compiling with -mtune?
On 22/05/2008, Neil Williams wrote: > I currently spend large amounts of time crossbuilding packages for ARM > on amd64 machines so, yes, ARM on amd64 was an example. This might not be that obvious for people not aware of your timetable, which is why I highlighted it was meant to be an example rather than _the_ only one setup to support. Mraw, KiBi. pgpRFV9jZjLC7.pgp Description: PGP signature
Re: Compiling with -mtune?
On 22/05/2008, Neil Williams wrote: > > I think csound is unlikely to be cross-built. Sound synthesis is a > > pretty cpu-intensive task. > > :-) don't think that cross-building is only for low resource units. And please don't second-guess people in general. Think of those using clusters, e.g. > I suppose csound may also require a lot of RAM. kdepim's build process comes to mind. > It is still possible that an arch could be sufficiently powerful to > *run* csound but not capable of building gcc for itself. (I would be > surprised if running csound is quite as much workload as compiling > gcc.) People might also want to cross-build using a single huge machine acting as build-server, so that there's a single system to maintain, rather than having to maintain (and own?) a machine for each arch. Mraw, KiBi. pgp06G9HYeybI.pgp Description: PGP signature
Re: RFS: gtk-nodoka-engine
On 25/05/2008, Christopher James Halse Rogers wrote: > The upload would fix these bugs: 443934 Reported by: "Diego Escalante Urrelo" <[EMAIL PROTECTED]>; Date: Tue, 25 Sep 2007 02:36:04 UTC. Although I read: Feel free to take over, I have lost interest. there's also: Just to let anyone reading that I'm just waiting for my local DD (rudy) to upload the packages for me, they are in mentors.debian.net right now. Diego (added to Cc since I'm not sure he reads the list) has also sent me some days ago the URLs for his packages to be sponsored. Could you please decide who is going to maintain that package (and under which name), maybe together? Mraw, KiBi. pgp2BHQiJDhMM.pgp Description: PGP signature
Re: bits from the DMs/NMs/AMs?
On 28/05/2008, Thibaut Paumard wrote: > Hi, o<, maybe you missed the following bits? “[Please CC me in all replies, or reply only to me.]” Mraw, KiBi. pgpTqlUSvqhBF.pgp Description: PGP signature
Re: RFS: poco and poco-doc (updated packages) [3rd try]
On 02/06/2008, Krzysztof Burghardt wrote: > > Since you are removing non-free stuff from orig tarball, you > > should either explain in README.Debian-source how to get the dfsg > > tarball from the orig tarball or add a get-orig-source in > > debian/rules. > > README.Debian-source added. Change is tinny. Only one directory > contains examples with NDA notice. Those files were removed. Last time I checked, debian/copyright was the best place to document this, see devref 6.7.8.2 (although it was previously advised to use README.Debian-source). Mraw, KiBi. pgpsq5RWdospf.pgp Description: PGP signature
