RFS: unionfs-fuse - fix RC bug
Dear mentors, I'm looking for a sponsor to upload the new version 0.21-3 of unionfs-fuse in order to fix an important bug. There is a one byte buffer overflow (bug#511995). I don't think it can be used to compromise security, but still, it should be fixed as soon as possible. It builds these binary packages: unionfs-fuse - Fuse implementation of unionfs The package appears to be lintian clean. The upload would fix these bugs: 511158, 511995 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/unionfs-fuse - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/unionfs-fuse/unionfs- fuse_0.21-3.dsc I would be glad if someone uploaded this package for me. Thanks in advance, Bernd -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
What to do if the original tarball contains a debian subdirectory
Hi DD, I found a very nice little program to take pictures from a webcam, and I would like to package it. The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? If I dh_make straight after unpacking the tarball, dh_make won't modify the debian subdirectory; but I wonder if removing it beforehand will tamper the orig.tar.gz The program is fswebcam, I already uploaded it on mentors.debian.net (just modifing the files in debian/if you want to take a look at it. The upstream site is http://www.firestorm.cx/fswebcam/ Cheers, Luca -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
Luca Niccoli wrote: The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? If I dh_make straight after unpacking the tarball, dh_make won't modify the debian subdirectory; but I wonder if removing it beforehand will tamper the orig.tar.gz It's nothing wrong to make changes in ustream's /debian directory wich will be represented in diff -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
2009/1/28 Al Nikolov a.niko...@drweb.com: Luca Niccoli wrote: The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? If I dh_make straight after unpacking the tarball, dh_make won't modify the debian subdirectory; but I wonder if removing it beforehand will tamper the orig.tar.gz It's nothing wrong to make changes in ustream's /debian directory wich will be represented in diff I have a similar question. Upstream has file ./debian/files in their tarball. Lintian complained about that file so I've deleted it. But during build in pbuilder it gets added back from the orig tarball. How to handle this? -- With best regards Ледков Дмитрий Юрьевич signature.asc Description: OpenPGP digital signature
Re: What to do if the original tarball contains a debian subdirectory
Hi Dne Wed, 28 Jan 2009 15:59:03 + (BST) Dmitrijs Ledkovs dmitrij.led...@gmail.com napsal(a): I have a similar question. Upstream has file ./debian/files in their tarball. Lintian complained about that file so I've deleted it. But during build in pbuilder it gets added back from the orig tarball. How to handle this? Probably safest way is to repackage the tarball without debian directory and ask upstream to change this practice in next versions. -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: What to do if the original tarball contains a debian subdirectory
On Wed, Jan 28, 2009 at 03:59:03PM +, Dmitrijs Ledkovs wrote: I have a similar question. Upstream has file ./debian/files in their tarball. Lintian complained about that file so I've deleted it. But during build in pbuilder it gets added back from the orig tarball. How to handle this? (disclaimer: IANADD) I would add a blank debian/files file, and override lintian with a suitable explanatory comment. -- Jonathan Wiltshire PGP/GPG: 0xDB800B52 / 4216 F01F DCA9 21AC F3D3 A903 CA6B EA3E DB80 0B52 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
debian/symbols Fortran library
re: http://lists.debian.org/debian-mentors/2009/01/msg00241.html Alright, I got around to fixing all of Lintian warnings and the other issues that Rafael Laboissiere found. However, I still don't understand how to generate debian/symbols in order to satisfy the Lintian message. It also seems that debian/symbols is a relatively recent addition to packaging practices. How am I supposed to generate how should I use it? I've been reading the dpkg-gensymbols manpage and chapter 8 in Policy, but I still don't understand how to generate the symbol list in the first place? objdump? But that lists more symbols than I need, right? Help? - Jordi G. H. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
On Wed, 2009-01-28 at 16:17 +0100, Luca Niccoli wrote: I found a very nice little program to take pictures from a webcam, and I would like to package it. The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? If I dh_make straight after unpacking the tarball, dh_make won't modify the debian subdirectory; but I wonder if removing it beforehand will tamper the orig.tar.gz The program is fswebcam, I already uploaded it on mentors.debian.net (just modifing the files in debian/if you want to take a look at it. The upstream site is http://www.firestorm.cx/fswebcam/ Sounds as if you have to repack the upstream tarball. IANADD though. -- Stephan signature.asc Description: This is a digitally signed message part
Re: debian/symbols Fortran library
On Wed, Jan 28, 2009 at 10:12:00AM -0600, Jordi Guti??rrez Hermoso wrote: it? I've been reading the dpkg-gensymbols manpage and chapter 8 in Policy, but I still don't understand how to generate the symbol list http://qa.debian.org/cgi-bin/mole/seedsymbols has some autogenerated symbols files that make a good starting point. in the first place? objdump? But that lists more symbols than I need, right? Not too much more - you want to do something with pretty much every symbol. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian/symbols Fortran library
* Jordi Gutiérrez Hermoso jord...@gmail.com [2009-01-28 10:12]: re: http://lists.debian.org/debian-mentors/2009/01/msg00241.html Alright, I got around to fixing all of Lintian warnings and the other issues that Rafael Laboissiere found. However, I still don't understand how to generate debian/symbols in order to satisfy the Lintian message. It also seems that debian/symbols is a relatively recent addition to packaging practices. How am I supposed to generate how should I use it? I've been reading the dpkg-gensymbols manpage and chapter 8 in Policy, but I still don't understand how to generate the symbol list in the first place? objdump? But that lists more symbols than I need, right? Here is the cookbook: $ cd libqrupdate-1.0 $ rm -f debian/*.symbols dpkg-gensymbols* $ dpkg-gensymbols -plibqrupdate1 -Pdebian/libqrupdate1 | patch -p0 $ mv dpkg-gensymbols* debian/libqrupdate1.symbols $ perl -pi -e 's/-1//' debian/libqrupdate1.symbols Play with the commands above and look at the dpkg-gensymbols man page. There may be easier ways to generate the symbols files, but the above is the way I know of. You need also to add a call to dh_makeshlibs in debian/rules. Another thing: since the upstream name of the package is qrupdate, I think you should change Source: libqrupdate to Source: qrupdate in debian/control and change the orig.tar.gz tarball name accordingly. -- Rafael -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: RFS: xinha
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mathieu, Daniel, Sorry for the late response, it's until now that I'm reading old messages from -mentors. Mathieu Parent wrote: 2008/11/29 Mathieu Parent math.par...@gmail.com: 2008/11/27 Raphael Geissert atomo64+deb...@gmail.com: [...] There are a couple of issues in xinha itself that I will be reporting later (security issues). Do you happen to have an email address of upstream? I couldn't find it anywhere on the website. Nope. But there are some webpages: James Sleeman: http://code.gogo.co.nz/contact/index.html Raimund Meyer: http://xinha.raimundmeyer.de/ (email may be ray AT openplans.org) Since those issues are rather minor it should be fine if xinha is, in the meanwhile, uploaded to unstable so that it goes through NEW. I'm back here to know if anything is missing to upload xinha to unstable. I think I've addressed all the tips. Just this: in debian/rules check-dfsg should be marked as a PHONY target as well. Daniel, since you are involved with other js packages: could you please take a look at xinha and sponsor it? Mathieu has done an amazingly great job preparing the package, and IMO it is perfect. The current dsc can be found at: http://mentors.debian.net/debian/pool/main/x/xinha/xinha_0.95-1.dsc Cheers, - -- Raphael Geissert - Debian Maintainer www.debian.org - get.debian.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmAvoQACgkQYy49rUbZzlosGwCggcrIIkW0beecWmslfdmCKNO8 AlsAnjA5V/5JreSv9rsdXeQYY5HskeW2 =UDVt -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
I recommend that you repack your tarball, renaming the debian directory inside it to debian-upstream or something similar. And you should check with upstream if they'd be willing to stop shipping debian/* in their next releases. (The recommendation above is my opinion, and there are other DDs who think different. Me, I believe having a readable diff.gz is motivation enough as to repack the tarball.) Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Leonard Cohen - Alexandra leaving -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: libgstreamer-perl (updated package)
René Mayorga wrote: On Wed, Jan 28, 2009 at 12:38:32AM +, Antonio Radici wrote: I am looking for a sponsor for the new version 0.14-1 of my package libgstreamer-perl. Are you aware of the Debian Perl Group? Maybe your package can be team maintained there. The package appears to be lintian clean. A few observations: You have a couple of lintian warnings that comes from upstream manpages, they are easy to fix: W: libgstreamer-perl: manpage-has-bad-whatis-entry, You might want to fix those. Hi Rene', thanks for your prompt response! I will fix the package and send it to the debian perl group, I've already sent an introductory mail and they set my an account on SVN. If you still want to be my sponsor there are two packages that need to be uploaded, you can choose between battery-stats 0.3.4-1 and pam-dotfile. They are both on mentors.debian.net :-) Cheers Antonio -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Re: RFS: xinha
Hi Raphael, Daniel, On Wed, Jan 28, 2009 at 9:22 PM, Raphael Geissert atomo64+deb...@gmail.com wrote: (...) Mathieu Parent wrote: Just this: in debian/rules check-dfsg should be marked as a PHONY target as well. Done. I've uploaded the new version. Thanks. Daniel, since you are involved with other js packages: could you please take a look at xinha and sponsor it? Mathieu has done an amazingly great job preparing the package, and IMO it is perfect. The current dsc can be found at: http://mentors.debian.net/debian/pool/main/x/xinha/xinha_0.95-1.dsc Same here Mathieu Parent -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: What to do if the original tarball contains a debian subdirectory
On Thu, Jan 29, 2009 at 12:17 AM, Luca Niccoli lultimou...@gmail.com wrote: The original tarball already contains a debian subdirectory (which needs some corrections anyway), how should I deal with that? Once lenny is released (hint hint) you will be able to just use the dpkg-source v3 format, which will remove the upstream debian/ directory before unpacking the debian.tar.gz and applying the patches. Please see the dpkg-source manual page for more info. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: battery-stats (updated package)
On Tue, Jan 27, 2009 at 08:01:29PM +, Antonio Radici wrote: Dear mentors, I am looking for a sponsor for the new version 0.3.4-1 of my package battery-stats. Hi, Since battery-stats 0.3.3-2 is in testing you shouldn't upload a new upstream release in unstable[1]. experimental is still an option. You can prepare a 0.3.3-3 package with just the fix for #512701, after the upload you'll have to ask the release team to accept this package in testing[1]. For your current 0.3.4-1 package, the best is to upload it in experimental but for the moment it still has some issue: - It FTBFS is gnuplot-nox is not installed - /usr/lib/battery-stats/graph-setup should be in /usr/share/battery-stats since it's an arch indep file - /usr/share/common-licenses/GPL is now a symlink to GPL-3, you need to adjust the debian/copyright - since you provide a menu file, can you please also add a .desktop and an icon [1]: http://article.gmane.org/gmane.linux.debian.devel.announce/1250 Best regards, Gonéri Le Bouder signature.asc Description: Digital signature
RFS: qrupdate
Dear mentors, I am looking for a sponsor for my package qrupdate. Package name: qrupdate Version : 1.0-1 Upstream Author : Jaroslav Hájek high...@gmail.com URL : http://qrupdate.sf.net License : GPLv3 Section : libs It builds these binary packages: libqrupdate-dev - Fast updates of QR and Cholesky decompositions -- static library libqrupdate1 - Fast updates of QR and Cholesky decompositions The package appears to be lintian clean. The upload would fix these bugs: 512232 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/q/qrupdate - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc I've already gone through some back and forth with this package with Rafael Laboissiere[1], and I think I've addressed all the issues he's brought up. The only thing I haven't done yet is upload my changes to svn, mostly because I'm still not sure if I should use the Octave svn in Alioth, or the Scientific Computing one, or just plain Science. Kind regards - Jordi G. H. [1] http://lists.debian.org/debian-mentors/2009/01/msg00356.html -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: battery-stats (updated package)
Gonéri Le Bouder wrote: On Tue, Jan 27, 2009 at 08:01:29PM +, Antonio Radici wrote: Dear mentors, I am looking for a sponsor for the new version 0.3.4-1 of my package battery-stats. Hi, Since battery-stats 0.3.3-2 is in testing you shouldn't upload a new upstream release in unstable[1]. experimental is still an option. You can prepare a 0.3.3-3 package with just the fix for #512701, after the upload you'll have to ask the release team to accept this package in testing[1]. For your current 0.3.4-1 package, the best is to upload it in experimental but for the moment it still has some issue: - It FTBFS is gnuplot-nox is not installed - /usr/lib/battery-stats/graph-setup should be in /usr/share/battery-stats since it's an arch indep file - /usr/share/common-licenses/GPL is now a symlink to GPL-3, you need to adjust the debian/copyright - since you provide a menu file, can you please also add a .desktop and an icon Hi, thanks for your review, I will fix these problems tomorrow. Just to clarify the status of battery-stats: version 0.3.3-3 was *already* uploaded to unstable and it is not building on some arch due to the libacpi dependency. That's why I opened a bug against this package. I've taken over the upstream to incorporate the debian patches and move it to autotools, so the dependency will be managed by autotools and battery-stats will build on all architectures. Cheers Antonio -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: qrupdate
On Thu, Jan 29, 2009 at 10:06 AM, Jordi Gutiérrez Hermoso jord...@gmail.com wrote: - dget http://mentors.debian.net/debian/pool/main/q/qrupdate/qrupdate_1.0-1.dsc Some comments on just the diff.gz: You should use a Debian-specific SONAME if upstream doesn't have one. Please teach upstream about SONAMEs, ABI etc and get them to do that stuff instead of doing it yourself. debian/postinst debian/postrm look like they can be removed and generated by debhelper. debian/substvars should not be in the diff.gz patches/add-soname seems to change the whitespace in the definition of SRC, why? patches/add-soname has a typo in one of the variables added: VERSIOON patches/add-soname needs some more metadata: upstream status, author, location it was taken from (if it was taken from somewhere). you specify debhelper compat 7 but don't seem to use the features of it (annoying for backports). Also, is perl 5.10 really needed? you should definitely ask upstream to implement make install. you might want to send the function-reference script upstream along with a patch to integrate it with their build process. There is some extra whitespace: tab character before the Source: package name in debian/control extra lines in debian/watch debian/*dirs debian/*install debian/docs -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: debian OID / dicom3tools packaging
Hi, To begin, I think there's some confusion about UID and OID. They are actually the same thing, according to Clunie: What DICOM calls UIDs are referred to in the ISO OSI world as Object Identifiers (OIDs). What Mathieu is talking about is the UID Root (or org root, according to DICOM PS3.5), and I assume subsquent posts in this thread mistakenly call that an OID. On Tue, Jan 27, 2009 at 01:16:35PM +0100, Michael Hanke wrote: On Tue, Jan 27, 2009 at 01:05:25PM +0100, Mathieu Malaterre wrote: One important step of the packaging is the DICOM UID. In order to write a DICOM file, one need a unique UID for each instance of a DICOM object. For more details: I wonder whether it is possible/feasible to come up with a single OID suiteable for all users. IMHO every user/institution would need an OID -- since somehow each DICOM generated by that OID needs to result in a unique UID. It's not exactly the case that every user/institution needs their own UID Root. I used to work for a PACS company and all UIDs generated by our software -- running across hundreds of different PCs in dozens of client sites -- use the same UID Root. We could do that because we controlled the algorithm for generating the UID suffix. I expect that pretty much all PACS vendors do the same thing. To pull this off, you need to be sure that everyone using the same UID Root is using a good algorithm; e.g. one that encodes something unique (e.g. an ethernet address) from the computer, and a time/date stamp with sufficient resolution (millisecond?) to guarantee uniqueness. An industrial-strength user will likely be using their own UID Root, but a common Debian UID Root for the rest of us is probably fine. By the way, since UIDs are only 64 characters long (restricted to 0-9 and .), I'd urge you to consider keeping the Root as short as possible, so as to leave room for the suffix generation. Instead of adding med | od -b, perhaps just add .0 for dicom3tools: 1.3.6.1.4.1.9586.0 The next software package that needs a UID Root could then use 1.3.6.1.4.1.9586.1 etc. Basically, the idea is to parcel up the Debian UID space across different UID generation algorithms -- i.e. the one in dicom3tools versus the next one (using .1 root). Cheers, -Steve signature.asc Description: Digital signature
Re: debian OID / dicom3tools packaging
On Wed, Jan 28, 2009 at 07:44:27PM -0600, Steve M. Robbins wrote: Hi, To begin, I think there's some confusion about UID and OID. They are actually the same thing, according to Clunie: What DICOM calls UIDs are referred to in the ISO OSI world as Object Identifiers (OIDs). May I be the first to say, WT*F*? - Matt -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
