Bug#661309: RFS: task-spooler/0.7.2-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package task-spooler * Package name: task-spooler Version : 0.7.2-1 Upstream Author : Lluís Batlle i Rossel vi...@vicerveza.homeunix.net * URL : http://vicerveza.homeunix.net/~viric/soft/ts/ * License : GPLv2+ Section : misc It builds those binary packages: task-spooler - personal job scheduler To access further information about this package, please visit the following URL: http://mentors.debian.net/package/task-spooler Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/task-spooler/task-spooler_0.7.2-1.dsc Regards, Alexander Inyukhin -- 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/20120226082400.ga5...@shurick.grid.su
Re: Explain to me any all
* Paul Elliott pelli...@blackpatchpanel.com [120226 02:03]: The new standard allows any all in the Architecture field. Please explain this new feature. What does it do and under what circumstances should it be used? It's for the Architecture field of the .dsc. As that field is automatically generated, you don't use it normally. As maintainer you usually edit the debian/control field. There every binary package has an Architecture list. This Architecture in the .dsc is the merged list of all those architectures. If one package is e.g. architecture i386 and one is architecture any, then those are merged to any (as there is a package to be generated on any architecture, it does not matter that on i386 there are even more packages to generate). What is changed is what happens if one .deb is architecture any and one .deb is architecture all. Former versions of dpkg merged that to any and policy reflected that. The problem with this is that it loses information whether there are architecture all packages to be built. As architecture all packages were never built by the buildds, this was no actual problem, so only fixed recently. Current versions of dpkg merge this to any all, and policy was changed to reflect this. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120226110207.ga2...@client.brlink.eu
Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library
Hi, Stephen M. Webb stephen.w...@bregmasoft.ca writes: On 02/12/2012 05:49 AM, Ansgar Burchardt wrote: Stephen M. Webbstephen.w...@bregmasoft.ca writes: * There are files licensed under the GFDL in tutorial/example. [...] I have reworded debian/changelog for clarification and added a clause to debian/copyright for the example files. A new source package has been uploaded to mentors.debian.net. Please don't assume specific versions of licenses if upstream does not say so (debian/copyright says GFDL-1.3+ while the example files in the tarball say just GFDL unless I missed something). Also you mentioned the LGPL-2.1 instead of the GFDL later. Upstream has been unable to clarify the licensing of the particular source in question (the original author is out of contact) and has suggested it be removed from the source tarball, since it is neither built nor packaged. Is this a preferred alternative? I think it is fine to just document that it is released under a GFDL license (any version) and add a note that we assume there are no invariant sections, no front cover and no back cover texts. The GFDL even states so: If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. and If the Document does not identify any Invariant Sections then there are none. (and I assume the same holds for cover texts). So I would use something like: Files: tutorial/example/* Copyright: 2000, Stefanus Du Toit License: GFDL-NIV-1.0+ This file is covered by the GNU Free Documentation License. . On Debian systems the full text of the GNU Free Documentation License can be found in `/usr/share/common-licenses/GFDL'. Comment: No invariant sections, no front cover and no back cover texts are given. Maybe refer to a specific version instead, but as we don't have versions 1.0 or 1.1 in common-licenses, you would have to refer to 1.2 or 1.3. Regards, Ansgar -- 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/87ehthrfmo@deep-thought.43-1.org
Re: Explain to me any all
Fantastic, thanks very much Bernhard, I think that's the explanation we're all needed. Regards, Dmitry. On Sunday 26 February 2012 22:02:15 Bernhard R. Link wrote: * Paul Elliott pelli...@blackpatchpanel.com [120226 02:03]: The new standard allows any all in the Architecture field. Please explain this new feature. What does it do and under what circumstances should it be used? It's for the Architecture field of the .dsc. As that field is automatically generated, you don't use it normally. As maintainer you usually edit the debian/control field. There every binary package has an Architecture list. This Architecture in the .dsc is the merged list of all those architectures. If one package is e.g. architecture i386 and one is architecture any, then those are merged to any (as there is a package to be generated on any architecture, it does not matter that on i386 there are even more packages to generate). What is changed is what happens if one .deb is architecture any and one .deb is architecture all. Former versions of dpkg merged that to any and policy reflected that. The problem with this is that it loses information whether there are architecture all packages to be built. As architecture all packages were never built by the buildds, this was no actual problem, so only fixed recently. Current versions of dpkg merge this to any all, and policy was changed to reflect this. Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201202262352.35402.only...@member.fsf.org
Re: Announcing Debexpo v2
I just wanted to thank you sincerely for all the hard work of yours which is so very useful for all of us. Thank you, Arno and Nicolas! Good work. Cheers, Dmitry. -- 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/201202262357.47195.only...@member.fsf.org
build server at home?
Dear mentors, Could any of you share experience of having your own private build server? I'm thinking of something which could build uploaded source for as many architectures as possible on amd64 host, and ideally put the results to 'reprepro'-managed tree. The goal is to simplify package deployment to internal infrastructure for evaluation before upload to debian. Any hints for quick start please? Thank you. Regards, Dmitry. -- 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/201202270005.46734.only...@member.fsf.org
RE: Announcing Debexpo v2
I have two things. The lintian version is not up2date it doesn't know the new standard version 3.9.3 He doesn't recognise closing of itp BUG in the wnpp package, he see it as an error. With kind regards, Bas van den Dikkenberg -Oorspronkelijk bericht- Van: onlyjob [mailto:only...@gmail.com] Namens Dmitry Smirnov Verzonden: zondag 26 februari 2012 13:58 Aan: debian-mentors@lists.debian.org Onderwerp: Re: Announcing Debexpo v2 I just wanted to thank you sincerely for all the hard work of yours which is so very useful for all of us. Thank you, Arno and Nicolas! Good work. Cheers, Dmitry. -- 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/201202262357.47195.only...@member.fsf.org -- 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/9345AD5DE363814DA41482800A8D50641C906AE8@srv01.dikkenberg.local
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson naes...@gmail.com, 2012-02-25, 22:43: + ... except with autoconf-dickey it doesn't, so use autotools-dev's dh_ commands; bump build-depends to autotools-dev (= 20100122.1) accordingly. (Yes, even though it says Do NOT in the autools-dev README.Debian.gz.) Typo: autools-dev → autotools-dev. * Add support for dpkg-buildflags(1) by bumping debhelper compatibility level (and build-depends) to 9. I wanted to double-check that the hardening flags are actually used, but the build log is not particularly helpful: |dh_auto_build | make[1]: Entering directory `/build/tack-9xzja7/tack-1.07' | compiling ansi | compiling charset | compiling color | compiling control | compiling crum | compiling edit | compiling fun | compiling init | init.c: In function 'reset_init': | init.c:134:3: warning: ignoring return value of 'system', declared with attribute warn_unused_result [-Wunused-result] | compiling menu | compiling modes | compiling output | compiling pad | compiling scan | compiling sync | compiling sysdep | sysdep.c: In function 'spin_flush': | sysdep.c:369:4: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] | compiling tack | linking tack ... Could you please make it print actual commands that are being run? (See also bug #628515.) Later in the build log I see: | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if debian/tack/usr/bin/tack were not uselessly linked against it (they use none of its symbols). It would be nice if you could get rid of this dependency. (But that's OK if you don't want to.) -- Jakub Wilk -- 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/20120226130904.ga5...@jwilk.net
Re: Announcing Debexpo v2
Hi, Thank you for the announcement. I am glad to see these improvements. It is really great! Few negative moments which I am recently faced with [1]: 1) Error Package closes bugs in a wrong way. Your script processes wnpp pseudo-package in wrong way. 2) Package has lintian warnings: - newer-standards-version 3.9.3 (current is 3.9.2) - unknown-copyright-format-uri http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ I think that the last version of lintian from Debian Sid should be used here. Best regards, Boris [1] http://mentors.debian.net/package/kde-gtk-config -- 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/148451330262...@web64.yandex.ru
Bug#660774: RFS: gnash/0.8.10-3~bpo60+1 [DM uploads to bpo]
Hi, it looks like gnash is no longer on mentors.d.n, probably it was removed because unstable has a higher version (might be a bug in debexpo). Could you make the package available somewhere else? Also consider to update the Git branch as well. Regards, Ansgar -- 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/87aa45ra4v@deep-thought.43-1.org
Re: Announcing Debexpo v2
Le 26/02/2012 à 14:15, Boris Pek tehnic...@yandex.ru écrivit : Hi, Thank you for the announcement. I am glad to see these improvements. It is really great! Few negative moments which I am recently faced with [1]: 1) Error Package closes bugs in a wrong way. Your script processes wnpp pseudo-package in wrong way. 2) Package has lintian warnings: - newer-standards-version 3.9.3 (current is 3.9.2) - unknown-copyright-format-uri http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ I think that the last version of lintian from Debian Sid should be used here. Hi, First of all thanks for your kind words. The wnpp issue you report was noticed and fixed just right after the reimport of the previous data, sorry about that. For the second issue, an up-to-date lintian backport was just uploaded by Tolimar, and the mentors.d.n lintian was updated. You can reupload now and everything should be okay. Cheers, -- Nicolas Dandrimont -- 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/87vcmtyao4@poincare.home.olasd.eu
Processed: retitle 660955 to RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 [ITP] -- documentation for GCC 4.6
Processing commands for cont...@bugs.debian.org: retitle 660955 RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 [ITP] -- documentation for GCC 4.6 Bug #660955 [sponsorship-requests] RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 -- documentation for GCC 4.6 Changed Bug title to 'RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 [ITP] -- documentation for GCC 4.6' from 'RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 -- documentation for GCC 4.6' severity 660955 wishlist Bug #660955 [sponsorship-requests] RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 [ITP] -- documentation for GCC 4.6 Severity set to 'wishlist' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 660955: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660955 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13302641032473.transcr...@bugs.debian.org
Bug#658426: xfonts-bolkhov/20001007-7 [ITA] -- Cyrillic fonts for X
tag 658426 + moreinfo thanks Hi, Daniel Martí danielmarti.deb...@gmail.com writes: http://mentors.debian.net/debian/pool/main/x/xfonts-bolkhov/xfonts-bolkhov_1.1.20001007-7.dsc the .orig.tar.gz you used differs from the one currently in the archive: Files: 6ef8024579061b77c835ec950dfdb8ee 871068 xfonts-bolkhov_1.1.20001007.orig.tar.gz 99c0594cc6076cd50c3a1ab29cd26226 10527 xfonts-bolkhov_1.1.20001007-6.diff.gz Files: dcc1a666c29a80fd7d9f3c0675a8cd08 889978 xfonts-bolkhov_1.1.20001007.orig.tar.gz a399807926862db01a652e53f2c78663 11546 xfonts-bolkhov_1.1.20001007-7.debian.tar.gz Please upload a version built against the right upstream tarball. Regards, Ansgar -- 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/8762etr97a@deep-thought.43-1.org
Processed: Re: xfonts-bolkhov/20001007-7 [ITA] -- Cyrillic fonts for X
Processing commands for cont...@bugs.debian.org: tag 658426 + moreinfo Bug #658426 [sponsorship-requests] RFS: xfonts-bolkhov/20001007-7 [ITA] -- Cyrillic fonts for X Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 658426: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658426 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.13302644934726.transcr...@bugs.debian.org
Bug#660774: RFS: gnash/0.8.10-3~bpo60+1 [DM uploads to bpo]
On 02/26/2012 02:34 PM, Ansgar Burchardt wrote: it looks like gnash is no longer on mentors.d.n, probably it was removed because unstable has a higher version (might be a bug in debexpo). Could you make the package available somewhere else? Also consider to update the Git branch as well. I can dput it correctly and git repo is already updated and tagged. [same previous link] http://mentors.debian.net/debian/pool/main/g/gnash/gnash_0.8.10-3~bpo60+1.dsc Thanks. -- Gabriele -- 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/4f4a3d51.9090...@gmail.com
Bug#660774: marked as done (RFS: gnash [DM uploads to bpo])
Your message dated Sun, 26 Feb 2012 15:20:46 +0100 with message-id 87y5rpptfl@deep-thought.43-1.org and subject line Re: Bug#660774: RFS: gnash/0.8.10-3~bpo60+1 [DM uploads to bpo] has caused the Debian Bug report #660774, regarding RFS: gnash [DM uploads to bpo] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 660774: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660774 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Hi, following [0], first upload has to be sponsored. Could anyone please upload gnash to backports for me? http://mentors.debian.net/debian/pool/main/g/gnash/gnash_0.8.10-3~bpo60+1.dsc [it should go in testing tomorrow] Thanks. -- Gabriele [0] http://lists.debian.org/debian-backports/2011/12/msg00011.html ---End Message--- ---BeginMessage--- Hi, Gabriele Giacone 1o5g4...@gmail.com writes: I can dput it correctly and git repo is already updated and tagged. I did upload the package, please make sure it works correctly. The Git repository still looks outdated, at least the squeeze-backports branch: http://anonscm.debian.org/gitweb/?p=pkg-flash/gnash.git;a=shortlog;h=refs/heads/squeeze-backports The last change is from 2011-08-04. Maybe you forgot to push the changes? Regards, Ansgar ---End Message---
Bug#659083: RFS: xmoto -- 2D motocross platform game
tag 659083 + moreinfo
thanks
Hi,
Stephen Kitt st...@sk2.org writes:
dget -x http://mentors.debian.net/debian/pool/main/x/xmoto/xmoto_0.5.9-1.dsc
You do not include the full license text for src/glext.h in the
copyright information.
Have the patches been forwarded upstream?
You use debhelper compat level 9, so why don't you build-depend on
debhelper (= 9)?
Please update at least config.{guess,sub}, see [1] for details, or just
use dh-autoreconf (my personal preference).
The source for bin/xmoto.bin seems to be missing, compare with
upstream's SVN repository[2]. I have filed a bug[3] as it is also
the case for the version currently inthe archive. Please ask upstream
to include the source and ideally built xmoto.bin instead of including
it, see also [4] for more details.
Regards,
Ansgar
[1] file:///usr/share/doc/autotools-dev/README.Debian.gz
[2] http://svn.tuxfamily.org/viewvc.cgi/xmoto_xmoto/trunk/bin/
[3] http://bugs.debian.org/661340
[4] http://www.freedesktop.org/wiki/Games/Upstream#Source
--
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/87ty2dprxz@deep-thought.43-1.org
Processed: Re: Bug#659083: RFS: xmoto -- 2D motocross platform game
Processing commands for cont...@bugs.debian.org: tag 659083 + moreinfo Bug #659083 [sponsorship-requests] RFS: xmoto -- 2D motocross platform game Added tag(s) moreinfo. thanks Stopping processing here. Please contact me if you need assistance. -- 659083: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659083 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- 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/handler.s.c.133026799224520.transcr...@bugs.debian.org
Bug#659894: RFS: minidlna/1.0.24+dfsg-1 -- lightweight DLNA/UPnP-AV server (new upstream version)
Benoît Knecht benoit.kne...@fsfe.org writes: dget -x http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.24+dfsg-1.dsc The package was removed due to a bug in the new debexpo version. Could you upload it again? Regards, Ansgar -- 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/87pqd1prv2@deep-thought.43-1.org
Bug#660774: closed by Ansgar Burchardt ans...@debian.org (Re: Bug#660774: RFS: gnash/0.8.10-3~bpo60+1 [DM uploads to bpo])
On Sun, Feb 26, 2012 at 02:54:46PM +, Debian Bug Tracking System wrote: The last change is from 2011-08-04. Maybe you forgot to push the changes? It was neither updated nor tagged as I said. Sorry. Pushed. -- Gabriele -- 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/20120226150951.GA10526@phenomenon
Re: RFS: quickrdp
Dear mentors. A new upstream version of quickrdp is released and I have packaged it for Debian. I would be happy if someone would sponsor my package. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/quickrdp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/q/quickrdp/quickrdp_1.1.4-1.dsc Previous requests and suggestions have been applied to the new upstream version of quickrdp. Thank you, Tobias -- 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/ca+zffsbg3jsw9z1jsa902x7bhavqkfryogavoxxfpovk1ps...@mail.gmail.com
Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library
On 02/26/2012 06:35 AM, Ansgar Burchardt wrote: I think it is fine to just document that it is released under a GFDL license (any version) and add a note that we assume there are no invariant sections, no front cover and no back cover texts. I have modified the debian/copyright file as suggested and uploaded a new source package to mentors.debian.net. dget -x http://mentors.debian.net/debian/pool/main/a/atlas-cpp/atlas-cpp_0.6.2-1.dsc Thanks -- Stephen M. Webb stephen.w...@bregmasoft.ca -- 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/4f4a6718.2090...@bregmasoft.ca
Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library
On 02/26/2012 06:35 AM, Ansgar Burchardt wrote: I think it is fine to just document that it is released under a GFDL license (any version) and add a note that we assume there are no invariant sections, no front cover and no back cover texts. I have modified the debian/copyright file as suggested and uploaded a new source package to mentors.debian.net. dget -x http://mentors.debian.net/debian/pool/main/a/atlas-cpp/atlas-cpp_0.6.2-1.dsc Thanks -- Stephen M. Webb stephen.w...@bregmasoft.ca -- 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/4f4a6730.4010...@bregmasoft.ca
Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library
Hi, Stephen M. Webb stephen.w...@bregmasoft.ca writes: http://mentors.debian.net/debian/pool/main/a/atlas-cpp/atlas-cpp_0.6.2-1.dsc The new lintian version made me aware of another problem I had missed: E: libatlas-cpp-0.6-dev: arch-dependent-file-not-in-arch-specific-directory usr/bin/atlas_convert N: N: This package is Multi-Arch same, but it installs an ELF binary in N: the directory that is not architecture-specific. N: N: Refer to https://wiki.ubuntu.com/MultiarchSpec for details. N: N: Severity: serious, Certainty: possible N: N: Check: binaries, Type: binary, udeb The easiest solution would be to just leave the Multi-Arch field for now, otherwise it would need to go to an extra package. But I am not sure if that is worth it. I also noticed a typo in the package description for libatlas-cpp-0.6-dev: developmentfiles misses a space. Regards, Ansgar -- 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/87y5rpo3si@deep-thought.43-1.org
Bug#660162: RFS: tack/1.07-2
On Sun, Feb 26, 2012 at 8:09 AM, Jakub Wilk jw...@debian.org wrote: * Samuel Bronson naes...@gmail.com, 2012-02-25, 22:43: + ... except with autoconf-dickey it doesn't, so use autotools-dev's dh_ commands; bump build-depends to autotools-dev (= 20100122.1) accordingly. (Yes, even though it says Do NOT in the autools-dev README.Debian.gz.) Typo: autools-dev → autotools-dev. Oops! * Add support for dpkg-buildflags(1) by bumping debhelper compatibility level (and build-depends) to 9. I wanted to double-check that the hardening flags are actually used, but the build log is not particularly helpful: | dh_auto_build | make[1]: Entering directory `/build/tack-9xzja7/tack-1.07' | compiling ansi | compiling charset | compiling color | compiling control | compiling crum | compiling edit | compiling fun | compiling init | init.c: In function 'reset_init': | init.c:134:3: warning: ignoring return value of 'system', declared with attribute warn_unused_result [-Wunused-result] | compiling menu | compiling modes | compiling output | compiling pad | compiling scan | compiling sync | compiling sysdep | sysdep.c: In function 'spin_flush': | sysdep.c:369:4: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] | compiling tack | linking tack ... Could you please make it print actual commands that are being run? (See also bug #628515.) Hmm, yes, that can be a problem. Unfortunately, it's currently hardwired into the Makefile at configure time; this is likely related to a desire to work with a wider range of Make implementations than is usual? I'll take a look at the source again and/or ask upstream if we can do something like the make V=yes thing here... Later in the build log I see: | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if debian/tack/usr/bin/tack were not uselessly linked against it (they use none of its symbols). It would be nice if you could get rid of this dependency. (But that's OK if you don't want to.) Yes, I've already reported this upstream[1], and Thomas seemed sympathetic? [1]: http://thread.gmane.org/gmane.comp.lib.ncurses.bugs/4797 Yours gratefully, -- Samuel Bronson -- 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/cajyzjmdzgr1qjh8zccnwr6wkrnhnfmnpeb+-rwqxfmnxrch...@mail.gmail.com
Bug#661389: RFS: roxterm/2.5.2-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package roxterm * Package name: roxterm Version : 2.5.2-1 Upstream Author : Tony Houghton h...@realh.co.uk * URL : http://roxterm.sourceforge.net * License : GPL-2+, LGPL-3+ Section : x11 It builds these binary packages: roxterm- Multi-tabbed GTK+/VTE terminal emulator - virtual package for GTK3 roxterm-common - Multi-tabbed GTK+/VTE terminal emulator - common files roxterm-gtk2 - Multi-tabbed GTK+/VTE terminal emulator - GTK2 version roxterm-gtk3 - Multi-tabbed GTK+/VTE terminal emulator - GTK3 version To access further information about this package, please visit the following URL: http://mentors.debian.net/package/roxterm Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_2.5.2-1.dsc Changes since the last upload: * New upstream version: + maitch.py: Reorder args in compiler checks: libs must come after source on some systems. + More flexible close window/tab warnings. + Added global option to use dark theme. + Revamped configlet (Configuration Manager). + --tab only reuses windows on current workspace unless overridden by --title. + SVG-derived pixmaps are included in release tarballs for convenience. + Option to use dark GTK theme variant. * debian/control: Removed imagemagick and librsvg2-bin from Build-Depends (see above). * Debian packaging now maintained with git-buildpackage. * debian/control: + Bump Standards-Version: 3.9.3. + Each binary package has a unique short description. * debian/copyright: New URL for Format. * Changed target back to unstable instead of experimental. Regards, Tony Houghton -- 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/20120226211130.5a474285@tiber
Processed: block 554155 with 658114, block 654892 with 658032, block 648668 with 658235 ...
Processing commands for cont...@bugs.debian.org: block 554155 with 658114 Bug #554155 [wnpp] ITP: mysql-sandbox -- manages multiple, sandboxed instances of mysql servers on the same machine Was not blocked by any bugs. Added blocking bug(s) of 554155: 658114 block 654892 with 658032 Bug #654892 [wnpp] ITP: libgxps -- GObject based library for handling and rendering XPS documents. Was not blocked by any bugs. Added blocking bug(s) of 654892: 658032 block 648668 with 658235 Bug #648668 [wnpp] ITP: libjreen1 -- powerful Jabber/XMPP library implemented in Qt/C++ Was not blocked by any bugs. Added blocking bug(s) of 648668: 658235 block 658381 with 658782 Bug #658381 [wnpp] ITP: libapr-memcache0 -- apr_memcache is a client for memcached Was not blocked by any bugs. Added blocking bug(s) of 658381: 658782 retitle 658782 RFS: libapr-memcache [ITP] -- apr_memcache is a client for memcached Bug #658782 [sponsorship-requests] RFS: libapr-memcache0 -- apr_memcache is a client for memcached Changed Bug title to 'RFS: libapr-memcache [ITP] -- apr_memcache is a client for memcached' from 'RFS: libapr-memcache0 -- apr_memcache is a client for memcached ' block 645103 with 658835 Bug #645103 [wnpp] ITP: aspsms-t -- aspsms-t is an open source /*GPL*/ jabber2sms transport written in perl // http://github.com/micressor/aspsms-t Was not blocked by any bugs. Added blocking bug(s) of 645103: 658835 block 658720 with 658959 Bug #658720 [wnpp] ITP: phpvirtualbox-4.1 -- An open source, AJAX implementation of the VirtualBox user interface written in PHP. Was not blocked by any bugs. Added blocking bug(s) of 658720: 658959 block 606373 with 658992 Bug #606373 [wnpp] ITP: cxxtest -- a xUnit-like framework for C/C++ Was not blocked by any bugs. Added blocking bug(s) of 606373: 658992 block 652718 with 659047 Bug #652718 [wnpp] ITP: rpg -- Readable Password Generator Was not blocked by any bugs. Added blocking bug(s) of 652718: 659047 block 599924 with 659077 Bug #599924 [wnpp] ITP: plowshare -- command-line application to download files for file-sharing websites. Was not blocked by any bugs. Added blocking bug(s) of 599924: 659077 block 631139 with 660049 Bug #631139 [wnpp] ITP: mosh -- fast R6RS Scheme interpreter Was not blocked by any bugs. Added blocking bug(s) of 631139: 660049 block 660140 with 660162 Bug #660140 [wnpp] ITP: tack -- terminfo action checker Was not blocked by any bugs. Added blocking bug(s) of 660140: 660162 block 650198 with 660175 Bug #650198 [wnpp] ITP: fcgi-daemon -- Perl-aware FastCGI daemon Was not blocked by any bugs. Added blocking bug(s) of 650198: 660175 block 654970 with 660194 Bug #654970 [wnpp] ITP: drwright -- Typing monitor to force typing breaks Bug #651504 [wnpp] RFP: drwright -- monitors your typing and forces you to periodically take typing breaks Was not blocked by any bugs. Added blocking bug(s) of 654970: 660194 Was not blocked by any bugs. Added blocking bug(s) of 651504: 660194 block 639192 with 660270 Bug #639192 [wnpp] ITP: gnonograms -- Design and solve Nonogram (Tsunami, Griddler) puzzles Was not blocked by any bugs. Added blocking bug(s) of 639192: 660270 block 518230 with 660314 Bug #518230 [wnpp] ITP: nbc -- Compiler for LEGO Mindstorms NXT Was not blocked by any bugs. Added blocking bug(s) of 518230: 660314 severity 660606 normal Bug #660606 [sponsorship-requests] RFS: acsccid/1.0.3-1 -- PC/SC driver for ACS USB CCID smart card readers Severity set to 'normal' from 'wishlist' block 656044 with 660955 Bug #656044 [wnpp] RFP: gcc-4.6-doc -- documentation for the GNU compilers (gcc, gobjc, g++) Was not blocked by any bugs. Added blocking bug(s) of 656044: 660955 block 466542 with 661309 Bug #466542 [wnpp] ITP: task-spooler -- local batch job queue Was not blocked by any bugs. Added blocking bug(s) of 466542: 661309 block 642282 with 658160 Bug #642282 [wnpp] ITP: libapache2-mod-socket-policy-server -- libapache2-mod-socket-policy-server is an Apache2 module for serving Adobe socket policies. Was not blocked by any bugs. Added blocking bug(s) of 642282: 658160 thanks Stopping processing here. Please contact me if you need assistance. -- 642282: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=642282 654970: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=654970 660606: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660606 658782: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658782 599924: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=599924 656044: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656044 631139: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631139 652718: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652718 650198: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650198 466542: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466542 660140: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660140 518230: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518230 658720:
Bug#658114: RFS: mysql-sandbox -- Install and set up one or more MySQL server instances easily
Hi, have you tried contacting the MySQL maintainers (CCed)? Maybe on of them is interested in this package. Mateusz Kijowski mateusz.kijow...@gmail.com writes: I am looking for a sponsor for my package mysql-sandbox. * Package name: mysql-sandbox Version : 3.0.24-1 Upstream Author : Giuseppe Maxia g...@cpan.org * URL : http://mysqlsandbox.net/ * License : GPL-2 Section : database It builds those binary packages: mysql-sandbox - Install and set up one or more MySQL server instances easily To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mysql-sandbox Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mysql-sandbox/mysql-sandbox_3.0.24-1.dsc I would be glad if someone uploaded this package for me. Regards, Ansgar -- 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/87haydtgq5@deep-thought.43-1.org
Re: RFS: themole | python3 only app | 8 days since last RFS
Why priority extra? Sorry, my bad. I've changed it to optional. You build depend on debhelper (= 9.0.0), but debhelper doesn't use such versioning scheme anymore. Even if did, debhelper (= 9) would be both shorter and more friendly to backporters. I didn't know that. Fixed. Debian Policy 3.9.3 has been just released, you probably want to bump Standards-Version. Thanks for that advise. I dind't change that because my lintian was complaining, but surely in a near future it won't. Fixed. Vcs-* fields are support for point to Debian packaging repository, not upstream repository. I didn't know that either. I thought it was for any VCS. Fixed. Unless there are good reasons (like: license issues, or tremendous space saving), I'd advise to use the pristine upstream tarball. But if you really must repackage, then it'd nice if: - package had version number that indicate that the source was repackaged (it's common to use +dfsg suffix is stuff was repackaged for DFSG reasons, or +ds otherwise); - you provided get-orig-source target in debian/rules. I've modified the upstream tarball in order to save space, and to avoid writing all copyright information in d/copyright. Anyway, following your advise now I'm using the pristine upstream tarball, and I've updated d/copyright. Thanks for all the advises, Jacub. For anyone who is willing to sponsor themole, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/themole/themole_0.2.6-1.dsc More information about hello can be obtained from: http://themole.nasel.com.ar/. Changes since the last upload: * Changed priority from extra to optional * Updates Standards-Version to 3.9.3 * Removed Vcs-* fields. * Now using pristine upstream tarball. Regards, Raúl Benencia -- 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/20120226213152.ga19...@lelouch.lan
Bug#660162: RFS: tack/1.07-2
On Sun, Feb 26, 2012 at 1:35 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 26, 2012 at 8:09 AM, Jakub Wilk jw...@debian.org wrote: * Samuel Bronson naes...@gmail.com, 2012-02-25, 22:43: + ... except with autoconf-dickey it doesn't, so use autotools-dev's dh_ commands; bump build-depends to autotools-dev (= 20100122.1) accordingly. (Yes, even though it says Do NOT in the autools-dev README.Debian.gz.) Typo: autools-dev → autotools-dev. Oops! * Add support for dpkg-buildflags(1) by bumping debhelper compatibility level (and build-depends) to 9. I wanted to double-check that the hardening flags are actually used, but the build log is not particularly helpful: | dh_auto_build | make[1]: Entering directory `/build/tack-9xzja7/tack-1.07' | compiling ansi | compiling charset | compiling color | compiling control | compiling crum | compiling edit | compiling fun | compiling init | init.c: In function 'reset_init': | init.c:134:3: warning: ignoring return value of 'system', declared with attribute warn_unused_result [-Wunused-result] | compiling menu | compiling modes | compiling output | compiling pad | compiling scan | compiling sync | compiling sysdep | sysdep.c: In function 'spin_flush': | sysdep.c:369:4: warning: ignoring return value of 'read', declared with attribute warn_unused_result [-Wunused-result] | compiling tack | linking tack ... Could you please make it print actual commands that are being run? (See also bug #628515.) Hmm, yes, that can be a problem. Unfortunately, it's currently hardwired into the Makefile at configure time; this is likely related to a desire to work with a wider range of Make implementations than is usual? I'll take a look at the source again and/or ask upstream if we can do something like the make V=yes thing here... Later in the build log I see: | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if debian/tack/usr/bin/tack were not uselessly linked against it (they use none of its symbols). It would be nice if you could get rid of this dependency. (But that's OK if you don't want to.) Yes, I've already reported this upstream[1], and Thomas seemed sympathetic? [1]: http://thread.gmane.org/gmane.comp.lib.ncurses.bugs/4797 Okay, fixed all but the dependency warning: http://mentors.debian.net/debian/pool/main/t/tack/tack_1.07-1~mentors6.dsc tack (1.07-1~mentors6) unstable; urgency=low * New upstream release. * Adopt package. Closes: #660140 (ITP for this package). * Switch to dpkg-source 3.0 (quilt) format. * Fix hyphen-used-as-minus-sign warning from lintian. * Re-add debian/watch file (was dropped in 1.06-3). * Enable build warnings. * Add Vcs-Browser: and Vcs-Git: fields to debian/control. * Install a symlink CHANGES.gz - changelog.gz in the doc directory. * Update debian/copyright to final DEP5 format. * Use dh-autoreconf to regenerate the configure script during build + Build-depends on dh-autoreconf and autoconf-dickey. + This also takes care of pulling up-to-date config.guess and config.sub scripts in from autotools-dev. + ... except with autoconf-dickey it doesn't, so use autotools-dev's dh_ commands; bump build-depends to autotools-dev (= 20100122.1) accordingly. (Yes, even though it says Do NOT in the autotools-dev README.Debian.gz.) * Add support for dpkg-buildflags(1) by bumping debhelper compatibility level (and build-depends) to 9. + Drop the LDFLAGS=-Wl,-z,defs,-ltic from the call to dh_auto_configure, so that configure will pick up the LDFLAGS from dpkg-buildflags(1). + Replace it with: - LIBS=-ltic as an argument to dh_auto_configure - DEB_LDFLAGS_MAINT_APPEND for the rest. Build-Depends: dpkg-dev (= 1.16.1). * New patch 03-allow-echoing-compilation-commands.patch, which enables printing of compilation commands by default. * Update package to Standards-Version: 3.9.3. * Thanks to Jakub Wilk for his thorough review. -- Samuel Bronson naes...@gmail.com Fri, 24 Feb 2012 16:22:24 -0500 -- 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/CAJYzjmf5XrLn5jta084+5MOoH3bB0mxCt1Ap40eE9U=rwje...@mail.gmail.com
Bug#660162: RFS: tack/1.07-2
* Samuel Bronson naes...@gmail.com, 2012-02-26, 17:49: * Fix hyphen-used-as-minus-sign warning from lintian. This patch... * New patch 03-allow-echoing-compilation-commands.patch, which enables printing of compilation commands by default. ...and this patch have Forwarded headers pointing to gmane. Could you use links to the official web archive (i.e., http://lists.gnu.org/archive/html/bug-ncurses/) instead? Not every one likes gmane (e.g. I cannot stand its UI); lists.gnu.org would be more neutral. (I won't be insistent about this, feel free to ignore me.) Also, if you wanted the patch headers to follow DEP-3, then you probably need to remove stuff like diff -Naurp tack.orig/tack.1 tack/tack.1 or Index: tack-1.06/tack.1. Otherwise such lines could[0] be misinterpreted by a parser as a part of patch header. [0] I said could because the specification is far being clear (or maybe I should say s/clear/unambiguous/). -- Jakub Wilk -- 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/20120227002112.ga8...@jwilk.net
Bug#660162: RFS: tack/1.07-2
Hmm, yes, that can be a problem. Unfortunately, it's currently hardwired into the Makefile at configure time; this is likely related to a desire to work with a wider range of Make implementations than is usual? I did that a different way (there's a macro which I normally use for most scripts). Later in the build log I see: | dpkg-shlibdeps: warning: dependency on libncurses.so.5 could be avoided if debian/tack/usr/bin/tack were not uselessly linked against it (they use none of its symbols). It would be nice if you could get rid of this dependency. (But that's OK if you don't want to.) Yes, I've already reported this upstream[1], and Thomas seemed sympathetic? [1]: [94]http://thread.gmane.org/gmane.comp.lib.ncurses.bugs/4797 I'm working on a fix for this now (have coded it, and have to check it on a few platforms). I spent all of last week on the ncurses changes that I finished yesterday (investigating cross compiles led to review of not-recently-built stuff which reminded me about the OpenBSD warning messages, etc). tack is much simpler (I haven't tried cross compiling it yet ;-) -- Thomas E. Dickey dic...@invisible-island.net http://invisible-island.net ftp://invisible-island.net signature.asc Description: Digital signature
RFS: tth/4.03+ds-1 [ITA] [upstream, first] -- TeX/LaTeX to HTML converter
Dear mentors, dear TeX maintainers: I am looking for a sponsor for my package tth. * Package name: tth Version : 4.03+ds-1 Upstream Author : Ian Hutchinson ihu...@mit.edu * URL :http://hutchinson.belmont.ma.us/tth/ * License : GPL-2+ Section : tex It builds those binary packages: tth - TeX/LaTeX to HTML converter tth-common - Scripts common to tth and ttm ttm - TeX/LaTeX to MathML converter To access further information about this package, please visit the following URL: http://mentors.debian.net/package/tth Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/t/tth/tth_4.03+ds-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Jerome BENOIT -- 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/4f4adf5f.6080...@rezozer.net
optional package in Build-Depends (how?)
Dear mentors, I have an interesting problem on my hands: The package I need to build have optional build dependency (libgpm-dev) which is not available on all platforms. If I just put it to Build-Depends, package will FTBFS on some platforms. So idea is to specify an optional (soft) build-dependency like Build-Depends: libgpm-dev | TRUE where 'TRUE' would stand for essential package like 'dpkg'. However I suspect there must be a better way to do that, a practical equivalent to hypothetical 'Build-Recommends'. What would be the best practice for such case? Any suggestions? Thank you. All the best, Dmitry. -- 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/201202271251.20803.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
See section 7.1 of debian-policy for examples on how to do that (you probably want linux-any for the arch): http://www.debian.org/doc/debian-policy/ch-relationships.html -- 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/CAKTje6GGCM8N3g1iWMhYzcdPWBu7GWmzK9e7BQ7w=rdzq6k...@mail.gmail.com
Re: optional package in Build-Depends (how?)
Hi Paul, Thanks for quick reply. On Monday 27 February 2012 13:00:32 Paul Wise wrote: See section 7.1 of debian-policy for examples on how to do that (you probably want linux-any for the arch): http://www.debian.org/doc/debian-policy/ch-relationships.html Indeed it probably could be written as Build-Depends: libgpm-dev [linux-any] But the obvious drawback would be the requirement to know all architectures where this package is available. In this case Build-Depends configuration will be ineffective against changes. Maintainer will have to track if the package was ported to new architecture and maintaining such relationships may potentially turn into expanded list of architectures. Perhaps it will work beautifully for dependencies which will never be ported. But let's discuss more general case: what if optional dependency is not ported to target architecture yet, or if if is not available in backports? There are might be situations where defining optional build dependencies without architecture wildcard may be more error-proof and easier to maintain. Another case I'm thinking of is when upstream is using unit-testing framework like 'valgrind'. I like to have post-build tests enabled. But this functionality requires an optional dependency. I don't want to risk my package to FTBFS because I put dependency only needed for unit tests to Build-Depends and it is not available on all our platforms. In such case using architecture wildcard is just inappropriate because availability of such package (may) have nothing to do with architecture. Specifically regarding 'libgpm-dev', I've made a list of architectures where it is available (below). At the moment I have no idea what 's390x' is (linux or not) so I have doubts regarding architecture wildcars to use. (OK, I admit I've checked with 'type-handling any linux-gnu' command but I'm still confused how to use architecture wildcards properly in this case) All of this makes me think about the approach to use essential alternative to make sure build will never fail because of my lack of understanding which platform will have the required package. What do you think? libgpm-dev avr32 N hppaN hurd-i386 N kfreebsd-amd64 N kfreebsd-i386 N s390x N alpha Y amd64 Y armel Y i386Y ia64Y m68kY mipsY mipsel Y powerpc Y armhf Y powerpcspe Y s390Y sh4 Y sparc Y sparc64 Y Regards, Dmitry. -- 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/201202271342.28308.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
On Mon, Feb 27, 2012 at 01:42:28PM +1100, Dmitry Smirnov wrote: Indeed it probably could be written as Build-Depends: libgpm-dev [linux-any] But the obvious drawback would be the requirement to know all architectures where this package is available. In this case Build-Depends configuration will be ineffective against changes. That's the problem I have with mudlet. libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386], liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386], It's not pretty and basically means if other arches come along and support libluajit I have to manually fix it. I don't think I could use or | because it didn't work on some build systems. A or nothing would be handy but I always get worried that you will miss linking because of a transistional bump then the program behaviour changes. Imagine if on the armel libluajit is not available temporarily. I think its better to fail to build than to issue out a package without that linking. Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. - Craig -- Craig Small VK2XLZ http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 -- 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/20120227030921.gb1...@enc.com.au
Bug#660162: RFS: tack/1.07-2
On Sun, Feb 26, 2012 at 7:21 PM, Jakub Wilk jw...@debian.org wrote: * Samuel Bronson naes...@gmail.com, 2012-02-26, 17:49: * Fix hyphen-used-as-minus-sign warning from lintian. This patch... * New patch 03-allow-echoing-compilation-commands.patch, which enables printing of compilation commands by default. ...and this patch have Forwarded headers pointing to gmane. Could you use links to the official web archive (i.e., http://lists.gnu.org/archive/html/bug-ncurses/) instead? Not every one likes gmane (e.g. I cannot stand its UI); lists.gnu.org would be more neutral. (I won't be insistent about this, feel free to ignore me.) I was actually thinking maybe I should link to the official GNU archives, but then I noticed what they did to anything resembling an email address and decided not to do that -- gmane's mangling is at least *almost* reversible. Also, if you wanted the patch headers to follow DEP-3, then you probably need to remove stuff like diff -Naurp tack.orig/tack.1 tack/tack.1 or Index: tack-1.06/tack.1. Otherwise such lines could[0] be misinterpreted by a parser as a part of patch header. [0] I said could because the specification is far being clear (or maybe I should say s/clear/unambiguous/). Well, *quilt* certainly doesn't misinterpret these lines thus. I don't really feel like removing things like this merely because of what DEP-3 neglects to specify; it really seems more like an issue with DEP-3 to me. (Also, patch #03 was originally produced by dpkg-source; I did remove some templates, but kept the overall format the same. I suppose *maybe* I should have left that line of three dashes?) If and when DEP-3 were to be clarified on this point, I'd be happy to change the patches to comply with it. -- Samuel Bronson -- 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/cajyzjmes6n5y2neg-c0r313kcydoqj6uz1_brckupc536...@mail.gmail.com
Bug#660162: RFS: tack/1.07-2
On Sun, Feb 26, 2012 at 10:17 PM, Samuel Bronson naes...@gmail.com wrote: On Sun, Feb 26, 2012 at 7:21 PM, Jakub Wilk jw...@debian.org wrote: * Samuel Bronson naes...@gmail.com, 2012-02-26, 17:49: * Fix hyphen-used-as-minus-sign warning from lintian. This patch... * New patch 03-allow-echoing-compilation-commands.patch, which enables printing of compilation commands by default. ...and this patch have Forwarded headers pointing to gmane. Could you use links to the official web archive (i.e., http://lists.gnu.org/archive/html/bug-ncurses/) instead? Not every one likes gmane (e.g. I cannot stand its UI); lists.gnu.org would be more neutral. (I won't be insistent about this, feel free to ignore me.) I was actually thinking maybe I should link to the official GNU archives, but then I noticed what they did to anything resembling an email address and decided not to do that -- gmane's mangling is at least *almost* reversible. Also, if you wanted the patch headers to follow DEP-3, then you probably need to remove stuff like diff -Naurp tack.orig/tack.1 tack/tack.1 or Index: tack-1.06/tack.1. Otherwise such lines could[0] be misinterpreted by a parser as a part of patch header. [0] I said could because the specification is far being clear (or maybe I should say s/clear/unambiguous/). Well, *quilt* certainly doesn't misinterpret these lines thus. I don't really feel like removing things like this merely because of what DEP-3 neglects to specify; it really seems more like an issue with DEP-3 to me. (Also, patch #03 was originally produced by dpkg-source; I did remove some templates, but kept the overall format the same. I suppose *maybe* I should have left that line of three dashes?) If and when DEP-3 were to be clarified on this point, I'd be happy to change the patches to comply with it. -- Samuel Bronson But note that Thomas Dickey has prepared a snapshot which is supposed to do patch #03's job a different way, and fix that dpkg-shlibdeps warning: http://lists.gnu.org/archive/html/bug-ncurses/2012-02/msg00022.html. (I'll take a look at this in the morning.) -- 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/CAJYzjmfGBkEC63TgD1semm48KvbBUZCEnE=2xmjbtst2tms...@mail.gmail.com
Re: optional package in Build-Depends (how?)
Hi Craig, Thak you for sharing your experience. On Monday 27 February 2012 14:09:21 Craig Small wrote: That's the problem I have with mudlet. libluajit-5.1-dev [amd64 armel i386 kfreebsd-i386], liblua5.1-0-dev [!amd64 !armel !i386 !kfreebsd-i386], Very interesting and useful. This is exactly what I'm afraid of. How can fellow maintainer track the changes in all architectures effectively? I imagine the maintenance pain for such configuration and it is probably breaks once in a while... It's not pretty and basically means if other arches come along and support libluajit I have to manually fix it. I don't think I could use or | because it didn't work on some build systems. I see... A or nothing would be handy but I always get worried that you will miss linking because of a transistional bump then the program behaviour changes. Imagine if on the armel libluajit is not available temporarily. I think its better to fail to build than to issue out a package without that linking. This is a very valid point, thank you. You're right, if libgpm-dev is not available on i386 or amd64 for whatever reason, build should fail rather than ignore the problem. Which makes this dependency package optional only on some architectures so I probably need to use something like libgpm-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], or libgpm-dev [linux-any], It's not too bad after all. Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. OK, so for really optional packages like 'check' or 'bison' it may be appropriate to use something like check | dpkg if we're not linking against it. I understand it much better now. Thank you. Cheers, Dmitry -- 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/201202271518.25990.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Dmitry Smirnov only...@member.fsf.org writes: On Monday 27 February 2012 14:09:21 Craig Small wrote: Specifically to your testing, valgrind testing should probably be opportunistic, so test if valgrind is available and don't otherwise. I think dejagnu does it that way. OK, so for really optional packages like 'check' or 'bison' it may be appropriate to use something like check | dpkg if we're not linking against it. I would only consider using a hack like this if the package really isn't available everywhere. For something like bison, just build-depend on bison and be done with it. As much as possible, you should try to ensure that the package builds exactly the same way everywhere, using the same tools, and only back off from that if some tool really isn't available at all on some target architecture. Even with valgrind, personally I'd just list a specific set of architectures on which valgrind is required, even if you also opportunistically test for its existence. There's no reason to allow *not* running valgrind tests on i386 and amd64. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/877gz86gsc@windlord.stanford.edu
Re: optional package in Build-Depends (how?)
Hi Russ, On Monday 27 February 2012 15:28:51 Russ Allbery wrote: Even with valgrind, personally I'd just list a specific set of architectures on which valgrind is required, even if you also opportunistically test for its existence. There's no reason to allow *not* running valgrind tests on i386 and amd64. It makes perfect sense for complete (working) test suits. I had an experience with valgrind only recently when upstream introduced yet-to-be completed tests which are failing everywhere so far. I'm already ignoring tests failure using override override_dh_auto_test: -dh_auto_test In which case it makes perfect sense not to take the risk of FTBFS on some architectures for the sake of testing which is not even useful yet. Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). So again I had to ignore post-build test(s) failure. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. While I'm with you and I fully share the desire not to allow skipping tests on i386 or amd64, I think risk of FTBFS outweighs it. You see, When I build the package on my amd64 host I will likely to notice if something goes wrong but my concern is more about architectures I have no access to. I'm not yet in habit of reading all build logs from all architectures upon package upload when the build was successful. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. Regards, Dmitry. -- 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/201202271628.51099.only...@member.fsf.org
Re: optional package in Build-Depends (how?)
Dmitry Smirnov only...@member.fsf.org writes: It makes perfect sense for complete (working) test suits. I had an experience with valgrind only recently when upstream introduced yet-to-be completed tests which are failing everywhere so far. I'm already ignoring tests failure using override override_dh_auto_test: -dh_auto_test In which case it makes perfect sense not to take the risk of FTBFS on some architectures for the sake of testing which is not even useful yet. Oh, okay, yes, if you're already ignoring errors from the test, then I'd only build-depend on valgrind where you want to see the results in the build logs for further work. Another package I was recently testing on GNU Hurd where some tests were failing (even though the package is working). A bug in the test suite? It's worth being careful about assuming that the package is working when the tests are failing. :) So again I had to ignore post-build test(s) failure. I don't think that makes sense to do for Hurd, actually. The package needs to be ported to it; I would let the build fail until that's happened. That may mean just porting the test suite or the test suite may be uncovering a real issue. That's generally what I do with any non-release architecture until I have time to do the (low priority, usually) porting work. You don't want to accidentally hide failures that need porting effort by making the build succeed artificially. Testing still useful to me when I read build logs, but I'm very reluctant to introduce a potential failure point with dependency more strict than necessary. Making the *dependency* strict isn't going to add a failure point. It's not like valgrind is going to disappear on i386 and amd64. While I'm with you and I fully share the desire not to allow skipping tests on i386 or amd64, I think risk of FTBFS outweighs it. You see, When I build the package on my amd64 host I will likely to notice if something goes wrong but my concern is more about architectures I have no access to. I'm not yet in habit of reading all build logs from all architectures upon package upload when the build was successful. You will generally get mail if the build fails. If the build failures are mostly due to bugs in the test suite, I agree with you. That's the criteria on which I'd make the decision. If the tests are finding bugs, then the failures are valuable and shouldn't be suppressed. And it appears to me that if tests failure is already pretty much ignored is would be acceptable to make tests optional with weak build dependency. However, Debian quite intentionally does not have such a thing as a weak build dependency, nor do I think such a thing is appropriate here. Rather, I think you should make a decision: either depend on the tools required to run the tests and ignore the test failures (if you think they're bugs in the test suite and not the package) if the output is valuable, or don't depend on the tools and skip the tests. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/871upgsqwf@windlord.stanford.edu
