Modified tarballs [was: Re: RFS: minidlna (updated package and FTBFS fix)]
On Fri, Jul 22, 2011 at 09:03:07PM -0300, Fernando Lemos wrote: Hi, Just to clarify, I find it concerning that we might be accepting source uploads that don't come straight from upstream and don't match what was released upstream. I'm relieved to hear that there is a way to ensure in your specific case that the source is the same as shipped upstream. I wish this was a requirement for new packages entering Debian. We do it all the time. Just 'dpkg -l|grep dfsg' on your local system and you should find plenty of those modified source tarballs. What I, as an uploader, do in such cases is a diff between the upstream provided tarball and what's in the dfsg orig.tar.gz. You can get a rough overview with diffstat and then review suspicious additions in more detail. Sven -- And I don't know much, but I do know this: With a golden heart comes a rebel fist. [ Streetlight Manifesto - Here's To Life ] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110723074614.GA2371@marvin
Re: RFS: minidlna (updated package and FTBFS fix)
Hi Benoît, On Sat, Jul 23, 2011 at 01:39:11AM +0200, Benoît Knecht wrote: Kilian Krause wrote: On Fri, Jul 22, 2011 at 12:36:51PM +0200, Benoît Knecht wrote: I am looking for a sponsor for the new version 1.0.21+dfsg-1 of my package minidlna. - dget http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.21+dfsg-1.dsc 1. Your upoad uses a tarball that's not identical to upstream's one. Please consider adding a get-orig-tarball target to debian/rules to verify what steps are required to generate it. Yes, that's what the +dfsg in the upstream version is all about; I've replaced the icons.c file, which contained binary blobs of possibly unfree images. I've included a script to generate it, but not a get-orig-source yet, as I'm not sure how to achieve the this target may be invoked in any directory part of the policy. Any advices welcome. I'd either put a dh_testdir check in place if you don't want to make sure you can pull in the new file with `dirname $0` or just use the latter to make sure you refrence the same directory your rules file is in and build the new tarball in /tmp and then move it to the current working directory as per Debian Policy. 2. The 1.0.20+dfsg-2 never made it into Debian. Changes generated accordingly. Please double check next time. I'm not sure what you mean. I did some changes before 1.0.21 was released and checked them into git; the next version came before I had a chance to submit that one, so I added a new changelog entry and recorded further changes there. I actually prefer this to merging the changelog entries together, but maybe I should have tagged the previous version as UNRELEASED. Yes, that would have been better. You had put up a version on mentors.d.n which had a 1.0.20+dfsg-2 entry labelled as if it was uploaded to unstable yet the dak doesn't show any such version ever made it. Thus I've made it a cumulative upload with dpkg-buildpackage -v1.0.20+dfsg-1 covering both entries as opposed to only the newest one which would be the default. 3. Your patches don't use DEP-3 headers. It would be nice to have them to see which of those have already been pushed upstream etc.. I'll consider it, but right now I'm using the format generated by git-format-patch, which I find quite convenient. As said, there's nothing wrong with what you have. No offense intended. It was just a remark that there's DEP-3 out there and may come in handy but if you already use git-format-patch that's fine, too! -- Best regards, Kilian signature.asc Description: Digital signature
RFS: spice
Dear mentors, I am looking for a sponsor for my package spice. * Package name: spice Version : 0.8.2-1 Upstream Author : Red Hat, Inc. * URL : http://www.spice-space.org/ * License : LGPL 2.1+ Section : misc It builds these binary packages: libspice-server-dev - Header files and development documentation for spice-server libspice-server1 - Implements the server side of the SPICE protocol spice-client - Implements the client side of the SPICE protocol I override configure-generated-file-in-source lintian warnings, for spice_0.8.2.orig-celt.tar.gz come with config.log and config.status and debian/rules will delete them. The upload would fix these bugs: 560721 My motivation for maintaining this package is: SPICE is an interesting desktop virtulization project, I want Debian can act as a guest or hypervisor with SPICE support. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/spice - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/spice/spice_0.8.2-1.dsc I would be glad if someone uploaded this package for me. Thanks and Regards, -- Liang Guo http://bluestone.cublog.cn signature.asc Description: Digital signature
Re: RFS: ttf-staypuft (updated package)
Hi Edgar, On Fri, Jul 22, 2011 at 09:47:15PM -0500, Edgar Antonio Palma de la Cruz wrote: I am looking for a sponsor for the new version 0.04-5 of my package ttf-staypuft. - dget http://mentors.debian.net/debian/pool/main/t/ttf-staypuft/ttf-staypuft_0.04-5.dsc You remove the debian/bug directory which seems to be unintended and you also break debian/watch (from a state that was broken already AFAICT). Both of which seem unintended from reading debian/changelog yet they don't affect the quality of the upload so I've built, signed and uploaded your version as is. If you want to get the above fixed and have yet another version uploaded just ping me. Thanks. -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: spice
Hi Liang, On Sat, Jul 23, 2011 at 04:18:11PM +0800, Liang Guo wrote: I am looking for a sponsor for my package spice. I override configure-generated-file-in-source lintian warnings, for spice_0.8.2.orig-celt.tar.gz come with config.log and config.status and debian/rules will delete them. - dget http://mentors.debian.net/debian/pool/main/s/spice/spice_0.8.2-1.dsc You shouldn't need to override these warnings if the clean target would just seriously delete them (not as make distclean but plain rm -f). Alternatively you could stuff them into debian/clean. That should get rid of the warning and thus the need to override. What makes me wonder more though is that you put autotools-dev into the Build-Depends yet do not seem to make use of it. Moreover you specify this package is only suitable to build on i386 and amd64. Most probably these are the only platforms that you've built and tested this on - but apart from this, is there any known limitation why it would not be buildable on any other arch? Shouldn't the source be arch:any rather? Regarding the embedded celt I'm probably as unhappy with the solution as the rest and I'm inclined to say it should be packaged separately to scale better. Yet I also see that'd be stepping quite a lot onto the celt maintainers (who don't want the celt051 in the first place). Your patches are not marked as forwarded upstream. I guess upstream would be interested in them though. So please try to find out about the arch:all issue, add the missing autotools-dev files replacement and report back to get the upload prepared. Thanks! -- Best regards, Kilian signature.asc Description: Digital signature
Re: RFS: libspctag
Le vendredi 22 juillet 2011, Kilian Krause a écrit : With the above fix I've build, signed and uploaded your package. Thanks! Thanks a lot, Kilian. I'll take account of your comments for my next uploads. Regards, -- Jérôme SONRIER signature.asc Description: This is a digitally signed message part.
Re: Sponsored packages are not automatically deleted from debian.metors
Hi everyon, I have received a response from AT suport debian.mentors.org (Christoph Haas): I've seen that does not automatically remove the sponsored packages from debian.metors. Before, the package are removed when the package is uploaded. My last two packages (http://packages.qa.debian.org/q/qdacco.html and http://packages.qa.debian.org/d/dacco.html) have not been eliminated. Is this a change or may be a mistake? Thanks for the hint. I didn't even notice that. Apparently the recent upgrade of the mentors.debian.net server from Lenny to Squeeze updated the Python version and caused in breakage in a script. I believe it is now fixed. Best regards Christoph Regards! I. De Marchi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAPo0x0deqToraUG5MYoQW4LR7vSaPVHLoT9WvqHNt2b=nhv...@mail.gmail.com
Re: Modified tarballs [was: Re: RFS: minidlna (updated package and FTBFS fix)]
On Sat, Jul 23, 2011 at 9:46 AM, Sven Hoexter s...@timegate.de wrote: We do it all the time. Just 'dpkg -l|grep dfsg' on your local system and you should find plenty of those modified source tarballs. What I, as an uploader, do in such cases is a diff between the upstream provided tarball and what's in the dfsg orig.tar.gz. You can get a rough overview with diffstat and then review suspicious additions in more detail. Best practice for modified tarballs is to write a debian/rules get-orig-source target that downloads the upstream tarball and removes anything that needs to be removed. IIRC this is documented either in policy or devref. -- 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 Archive: http://lists.debian.org/caktje6f1mlrfda_ayqihxuytynwhdrjuae0vxui+fxyv_bd...@mail.gmail.com
Re: RFS: Jampal (2nd try)
Hi Kilian Many thanks for doing this. I used rsync since cp -a was trying to copy the svn directories. For some reason I am not sure of, it was failing with an error that it was unable to create the svn directories in the destination directory. I did not look further into why that was, but just changed to rsync. If you think that is abuse I can investigate the svn issue again. I put leading zeroes in my version number thinking that in future if I went from 2.9 to 2.10 it would be considered as a lower version somewhere. Perhaps my 3 part version number is a bit excessive. I am not sure what is so bad about a relative classpath in a jar file. I can get rid of the duplicate icon file. Regards Peter On 7/22/2011 3:07 PM, Kilian Krause wrote: Hi Peter, On Fri, Jul 15, 2011 at 01:06:09PM -0400, Peter Bennett wrote: Thank you Arno for your assistance. I have uploaded a new version of jampal, 02.01.05-1 All problems previously noted have been fixed. Having a closer look I find the version number.. uhm... interesting ;-) Nevertheless there's nothing wrong with it, so nothing to complain here. The lintian appears to be clean lintian -I --pedantic jampal_02.01.05-1.dsc gives no error. As you stress this I'm tempted to give you my output (including -X): W: tagbkup: manpage-has-errors-from-man usr/share/man/man1/tagbkup.1.gz Invalid or incomplete multibyte or wide character X: jampal: duplicate-files usr/share/doc/jampal/html/favicon.ico.gz usr/share/doc/jampal/html/images/jampal.ico.gz W: jampal: classpath-contains-relative-path usr/share/jampal/jampal.jar: ../freetts/lib/freetts.jar W: jampal: manpage-has-errors-from-man usr/share/man/man1/jampal.1.gz Invalid or incomplete multibyte or wide character none of which are truly harmful though. Especially the manpage errors are a quite frequent false positive. I am looking for a sponsor for my package jampal. - dget http://mentors.debian.net/debian/pool/contrib/j/jampal/jampal_02.01.05-1.dsc What I did stumble upon is the build-depends against rsync. After closely checking that seems to be bordering abuse yet nothing that is formally wrong. I'm somewhat unsure though why cp -a wouldn't do the same thing here. Eventually the CVS exlude would require some extra rm lines but apart from that I don't really see the benfit. As a side note it seems the DEP-5 Format URL is broken even though it's verbatim the style DEP-5 demands for AFAICT. Still strange though. Anyway, built, signed, uploaded. Thanks! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2af541.60...@comcast.net
Re: RFS: Jampal (2nd try)
Hi Kilian Sorry - I am new to this. Does this make you my sponsor? Should I update my package on Debian mentors to say I have found a sponsor? Thanks Peter On 7/22/2011 3:07 PM, Kilian Krause wrote: Hi Peter, On Fri, Jul 15, 2011 at 01:06:09PM -0400, Peter Bennett wrote: Thank you Arno for your assistance. I have uploaded a new version of jampal, 02.01.05-1 All problems previously noted have been fixed. Having a closer look I find the version number.. uhm... interesting ;-) Nevertheless there's nothing wrong with it, so nothing to complain here. The lintian appears to be clean lintian -I --pedantic jampal_02.01.05-1.dsc gives no error. As you stress this I'm tempted to give you my output (including -X): W: tagbkup: manpage-has-errors-from-man usr/share/man/man1/tagbkup.1.gz Invalid or incomplete multibyte or wide character X: jampal: duplicate-files usr/share/doc/jampal/html/favicon.ico.gz usr/share/doc/jampal/html/images/jampal.ico.gz W: jampal: classpath-contains-relative-path usr/share/jampal/jampal.jar: ../freetts/lib/freetts.jar W: jampal: manpage-has-errors-from-man usr/share/man/man1/jampal.1.gz Invalid or incomplete multibyte or wide character none of which are truly harmful though. Especially the manpage errors are a quite frequent false positive. I am looking for a sponsor for my package jampal. - dget http://mentors.debian.net/debian/pool/contrib/j/jampal/jampal_02.01.05-1.dsc What I did stumble upon is the build-depends against rsync. After closely checking that seems to be bordering abuse yet nothing that is formally wrong. I'm somewhat unsure though why cp -a wouldn't do the same thing here. Eventually the CVS exlude would require some extra rm lines but apart from that I don't really see the benfit. As a side note it seems the DEP-5 Format URL is broken even though it's verbatim the style DEP-5 demands for AFAICT. Still strange though. Anyway, built, signed, uploaded. Thanks! -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2af70b.4020...@comcast.net
Re: RFS: Jampal (2nd try)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Peter, On 23.07.2011 18:30, Peter Bennett wrote: Does this make you my sponsor? Should I update my package on Debian mentors to say I have found a sponsor? It does, yes. You should not need to remove the package on mentors.d.n as those should disappear automagically. However this was a known problem recently which should be fixed by now [1]. [1] http://lists.debian.org/debian-mentors/2011/07/msg00486.html - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOKvyGAAoJEMcrUe6dgPNtJigP/jIclrF3t3xAVfGy/y4cQTjP aFIWWxjOf3Afwd4Wx0I5WlyKjwJ+U+hmlrvBpC5+fzHlYeYSDbhut5rcrwgY9z8g L/SFx8xdTkD67+0W1QSPtvqc/t3lsTs5ATgYX7qmh8GVIxMrDZbfDMskznZu/PUc SCga8RNRTPYCwZw2u4xDyEioJOxDjuadSg3nUyDkjdapB+JUryQ3psuJDCcz16V3 RFzqfcMIo216EQJ2fxQrd7RwJ/NUI/fvjxLpaEsi8Kq6gJ6mcphrVfQfMgAycPnB Qorx3Y47gDbiYpZSFWpuNrYe8SOvoN4eBa1HKN4vnIN0TV9dBi0jm4Ixq3jelgHE RX2x4k0wc+bh2Qz/Ci8i217qgqQTq9lfSSA/vHl+01Va5nzLzaW2O02po8QGoEqu 6TpoXRr7Sh/+lTTlPyCyyMmUoNm5K0ALzNCYonxfj9tfLLsnwxmqhYZhCGSzNDea DfzDR1ArFXwXe15GEI8vPWILpZAr5Ldg+ziqZdWUecLgGPRdPtRx1cBlpp9gV5QO CiQSgONxMMyKblOxONDR8Bao7VRfTuXVKsO2Ujg8gLZUFQ8LO9OC4QjoNzEPf4nu M7ct0BgRs+pgRtIFi0dL+GW5UvVLlHMM3rST3hwZN6458xlF7gZSbuwXPCIor06L ziimj/FVwDoNZPUAmWiO =vk3r -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2afc87.1030...@toell.net
Re: RFS: Jampal (2nd try)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 23.07.2011 18:53, Arno Töll wrote: It does, yes. You should not need to remove the package on mentors.d.n as those should disappear automagically. Another note: Your package is currently in NEW [1]. Until it is accepted it won't appear in unstable. This might not take too long these days, as Tolimar seems very motivated : While it is there, mentors.d.n won't notice it was uploaded. [1] http://ftp-master.debian.org/new.html - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJOKv1VAAoJEMcrUe6dgPNtwfQP/RjDoEojic6L8g9nDQYluu6y UvlMceAQjvVdQpw74cNoB89dSdUX2/L9ObrW60hBVgtB18a8biWE7XCm66SEhBgG oTg5Rj7MAazADET4lc3wpxFqwr6ifQw4MkR2vgdRpeZNNgS69AAZQHwb3f2spuz1 Sg+/IIdZbMCHNgUdnGwkEYXQG/xbEyu+1TbSdzXtDCyK3G92yPrZM1o5F6nfoPKy tsUp4gtmSB5SWtINzwxre+Eh97MXe/mHDsYIEw7ZlyNDOOU/V+FlDIMsl0DD9H65 OB851M5jvX1FJDqZFHLS1hmMLtt8Z7/LdrJL87cC7Spp1IUbMZWkgoBfUeNfZIem Nxg5wj2O6Ue4N7OlJhw1SEtiCBMFpPq13NO9AxtkUTcXmeXEUz3zQ/hyBNoEdP/X a/8tQRqkg0CABbPVBdNeflFA6+VIfXOO8elmnMKwTec18qtMUeqF2+vAkU009Cm4 /wIDB7qXl5Z487cVmxRCZ9DdHOniAqv4g8CO9FASmaP00EkzOTOBvfuEKXkt3RAI M8wlZY14xrVs6Z7cF6XqLf18y/C0VxznplfLL/LSzYTx1Lua3/RewfzqIaS2LtCs IA05QQTY8gRJ+eQOlXJbTo5v/AvBZ2F8HROuTsSdJcCUWiGUVLw+5sxNRbh1H4Aq bqvmTd/lEtsACvgWYLvz =7XMm -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2afd56.3010...@toell.net
RFS: totem-plugin-arte (updated package)
Dear mentors, I am looking for a sponsor for the new version 3.0.0-1 of my package totem-plugin-arte. It builds this binary package: totem-plugin-arte - Totem plugin to watch streams from arte.tv The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/t/totem-plugin-arte - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/t/totem-plugin-arte/totem-plugin-arte_3.0.0-1.dsc My usual sponsor seems to be busy (or in holidays?), so I would be glad if someone uploaded this package for me. Kind regards Nicolas Delvaux signature.asc Description: This is a digitally signed message part
Re: Workflow with debian/ in VCS
Hi folks, I really wonder, why you don't just track everything in a VCS like git, set the Debian changes (to the source tree) ontop the upstream release tag and simply add the control files ? And when a new upstream release comes, simply rebase. cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110521132003.GA4693@nibiru.local
Re: RFS: spice
On Sat, Jul 23, 2011 at 4:54 PM, Kilian Krause kil...@debian.org wrote: Hi Liang, On Sat, Jul 23, 2011 at 04:18:11PM +0800, Liang Guo wrote: I am looking for a sponsor for my package spice. I override configure-generated-file-in-source lintian warnings, for spice_0.8.2.orig-celt.tar.gz come with config.log and config.status and debian/rules will delete them. - dget http://mentors.debian.net/debian/pool/main/s/spice/spice_0.8.2-1.dsc You shouldn't need to override these warnings if the clean target would just seriously delete them (not as make distclean but plain rm -f). Alternatively you could stuff them into debian/clean. That should get rid of the warning and thus the need to override. The lintian warning configure-generated-file-in-source is caused by upstream celt package, it comes with config.log and config.status, to remove this lintian warning, I need repack spice_0.8.2.orig-celt.tar.gz which I think it is not nessary. What makes me wonder more though is that you put autotools-dev into the Build-Depends yet do not seem to make use of it. Removed, Moreover you specify this package is only suitable to build on i386 and amd64. Most probably these are the only platforms that you've built and tested this on - but apart from this, is there any known limitation why it would not be buildable on any other arch? Shouldn't the source be arch:any rather? Spice embedded some ASM code (very little, only 4 lines at all), so it can only be compiled in x86 and x86_64 now. When multiplatform support added, I'll update Architecture field soon. Regarding the embedded celt I'm probably as unhappy with the solution as the rest and I'm inclined to say it should be packaged separately to scale better. Yet I also see that'd be stepping quite a lot onto the celt maintainers (who don't want the celt051 in the first place). Your patches are not marked as forwarded upstream. I guess upstream would be interested in them though. I'll forward these patches upstream soon, Thanks pointout that. So please try to find out about the arch:all issue, add the missing autotools-dev files replacement and report back to get the upload prepared. I've uploaded new spice to mentors.d.n, the download URL is still valid. I've pushed the changes to git repository too, its git repository is: git://git.debian.org/collab-maint/spice.git http://git.debian.org/?p=collab-maint/spice.git;a=summary Thanks, -- Liang Guo http://bluestone.cublog.cn -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cajwrgw7nfhq-j5o3lb7pg+gnk-ghuffureolqucwimbatsc...@mail.gmail.com
