Bug#809308: RFS: cl-asdf/3.1.6 [ITA] - Another System Definition Facility
Package: sponsorship-requests Severity: normal Dear mentors, I have taken over the debian packaging for ASDF from François-René Rideau and am looking for sponsors for the current 3.1.6 release: Package name: cl-asdf Version : 2:3.1.6-1 Upstream Author : Robert P. Goldman URL : https://common-lisp.net/project/asdf/ License : Expat Section : lisp The cl-asdf source package builds this binary package: cl-asdf- Another System Definition Facility The package appears to be lintian clean. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/cl-asdf Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.1.6-1.dsc Changes since the last upload: cl-asdf (2:3.1.6-1) unstable; urgency=low Package changes: * New uploader in control file * lintian-overrides for 2 script files which have a magic comment for invoking cl-launch New upstream release: * Fix backtrace on SBCL. * Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket #1501373). * Fix a number of issues with bundle operations (especially on non-C-compiler-based implementations). * Fix component-finding in package-inferred-system. * Fix race condition between multiple concurrent lisp processes doing ASDF builds (ticket #1483948). * Fix misplaced fasl cache on Windows. * Miscellaneous bug fixes. * Documentation improvements. Thank you Kambiz Darabi
Re: debian/watch - check multiple hosts?
Hi, >> is it possible to have uscan check multiple hosts? e.g. for GNU >> findutils I would like to look at both stable and unstable releases > >Are you aware the watch file is meant to find a *single* tarball? > >What would you want the result of scanning multiple hosts; how would >you want differences resolved to a single tarball, at a single version? I'm not sure, but I think this might be possible by having two different watch files. One for stable releases (in unstable/testing), and one for experimental tarballs (in experimental). Look e.g. to boinc https://qa.debian.org/developer.php?login=pkg-boinc-de...@lists.alioth.debian.org seems that having two packages, in unstable and experimental makes duck run twice, and report twice. I guess having them different will work and show both versions. (it is up to you to maintain two different packages in two different target series) cheers, G.
Re: RFS: Please upload cl-asdf package
Hi Mattia, On 2015-12-28 18:56 CET, Mattia Rizzolo wrote: > On Mon, Dec 28, 2015 at 06:29:03PM +0100, Kambiz Darabi wrote: >> sorry for bothering you again but there are people who are interested in >> a new debian package of ASDF 3.1.6 > > You didn't file a RFS. > Me and other "random sponors you find in -mentors" checks > https://bugs.debian.org/sponsorship-requests to see what is waiting for > sponsorship, mails gets lost too easily. thank you for the hint: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809308 >> and I would like to at least have >> some feedback on its packaging. >> >> Can some kind soul please upload the package if it is acceptable or let >> me know what to change? > Start by filing a formal RFS, I'm looking at the package, and compiling > a list of staff I'd like to see changed before uploading. > Actually, none of the things I noticed are important or blockers, but > I don't like to upload stuff in a shape I don't like them :) I'm looking forward to the comments. Thank you Kambiz
Bug#809199: RFS: gap-guava/3.12+ds1-3 [unrep fix] [dbg] -- coding theory library for GAP
On Mon, 28 Dec 2015 09:13:59 +0100 Jerome Benoit wrote: > Package: sponsorship-requests > Severity: normal > > Dear Mentors: > > I am looking for a sponsor for the package gap-guava that > I am maintining on behalf of the Debian Science Team. > This pacakge fix a reproduciblefix, introduce a debug > package, and fixes some new (so to speak) warnings. > > Thanks, > Jerome > > -- System Information: > Debian Release: Jessie* > APT prefers stable > APT policy: (990, 'stable'), (500, 'stable-updates') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (SMP w/4 CPU cores) > Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: sysvinit (via /sbin/init) > > Can you add a pointer where to get the package? Thanks!
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox
Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "otb" * Package name: otb Version : 5.2.0+dfsg-1 Upstream Author : cont...@orfe-toolbox.org * URL : http://orfeo-toolbox.org * License : CeCILL-2.0 Section : science It builds those binary packages: libotb - ORFEO Toolbox library metapackage libotb-apps - Plugins for ORFEO Toolbox applications libotb-dev - Free library of image processing algorithms - development libotbapplicationengine-5.2-1 - ORFEO Toolbox library - OTBApplicationEngine libotbcarto-5.2-1 - ORFEO Toolbox library - OTBCarto libotbcommandline-5.2-1 - ORFEO Toolbox library - OTBCommandLine libotbcommandlineparser-5.2-1 - ORFEO Toolbox library - OTBCommandLinePaser libotbcommon-5.2-1 - ORFEO Toolbox library - OTBCommon libotbcurladapters-5.2-1 - ORFEO Toolbox library - OTBCurlAdapters libotbedge-5.2-1 - ORFEO Toolbox library - OTBEdge libotbextendedfilename-5.2-1 - ORFEO Toolbox library - OTBExtendedFileName libotbfuzzy-5.2-1 - ORFEO Toolbox library - OTBFuzzy libotbgdaladapters-5.2-1 - ORFEO Toolbox library - OTBGdalAdapters libotbimagebase-5.2-1 - ORFEO Toolbox library - OTBImageBase libotbimageio-5.2-1 - ORFEO Toolbox library - OTBImageIO libotbimagemanipulation-5.2-1 - ORFEO Toolbox library - OTBImageManipulation libotbiobsq-5.2-1 - ORFEO Toolbox library - OTBIOBSQ libotbiogdal-5.2-1 - ORFEO Toolbox library - OTBIOGDAL libotbiokml-5.2-1 - ORFEO Toolbox library - OTBIOKML libotbiolum-5.2-1 - ORFEO Toolbox library - OTBIOLUM libotbiomstar-5.2-1 - ORFEO Toolbox library - OTBIOMSTAR libotbiomw-5.2-1 - ORFEO Toolbox library - OTBIOMW libotbioonera-5.2-1 - ORFEO Toolbox library - OTBIOONERA libotbiorad-5.2-1 - ORFEO Toolbox library - OTBIORAD libotbiotilemap-5.2-1 - ORFEO Toolbox library - OTBIOTileMap libotbmathparser-5.2-1 - ORFEO Toolbox library - OTBMathParser libotbmetadata-5.2-1 - ORFEO Toolbox library - OTBMetadata libotbopenthreadsadapters-5.2-1 - ORFEO Toolbox library - OTBOpenThreadsAdapters libotbossimadapters-5.2-1 - ORFEO Toolbox library - OTBOssimAdapters libotbossimplugins-5.2-1 - ORFEO Toolbox library - OTBOssimPlugins libotbpolarimetry-5.2-1 - ORFEO Toolbox library - OTBPolarimetry libotbprojection-5.2-1 - ORFEO Toolbox library - OTBProjection libotbqtwidget-5.2-1 - ORFEO Toolbox library - OTBQtWidget libotbrcc8-5.2-1 - ORFEO Toolbox library - OTBRCC8 libotbsiftfast-5.2-1 - ORFEO Toolbox library - OTBSiftFast libotbstreaming-5.2-1 - ORFEO Toolbox library - OTBStreaming libotbsupervised-5.2-1 - ORFEO Toolbox library - OTBSupervised libotbtestkernel-5.2-1 - ORFEO Toolbox library - OTBTestKernel libotbtransform-5.2-1 - ORFEO Toolbox library - OTBTransform libotbvectordatabase-5.2-1 - ORFEO Toolbox library - OTBVectorDataBase libotbvectordataio-5.2-1 - ORFEO Toolbox library - OTBVectorDataIO libotbwavelet-5.2-1 - ORFEO Toolbox library - OTBWavelet otb-bin- ORFEO Toolbox command line applications otb-bin-qt - ORFEO Toolbox graphical user interface applications otb-testdriver - ORFEO Toolbox library - OTBTestDriver python-otb - ORFEO Toolbox Python API for applications To access further information about this package, please visit the following URL: http://mentors.debian.net/package/otb Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/otb/otb_5.2.0+dfsg-1.dsc More information about otb can be obtained from http://orfeo-toolbox.org here is the ITP report - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764860 Changes since the last upload: Regards, Rashad Kanavath
Re: debian/watch - check multiple hosts?
Ben Finney wrote: > Andreas Metzler writes: >> is it possible to have uscan check multiple hosts? e.g. for GNU >> findutils I would like to look at both stable and unstable releases > Are you aware the watch file is meant to find a *single* tarball? Yes, I am aware of that. > What would you want the result of scanning multiple hosts; how would > you want differences resolved to a single tarball, at a single version? I do not see a huge conceptual difference to scanning a single host. uscan looks at a list of locations for files matching a specific pattern, with a subpattern for the version number. uscan simply grabs the file with the highest version number. Even now uscan will often find multiple files with the same version number (gz|bz2|xz) and has to choose one. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: debian/watch - check multiple hosts?
On Tue, Dec 29, 2015 at 3:24 PM, Andreas Metzler wrote: > is it possible to have uscan check multiple hosts? e.g. > for GNU findutils I would like to look at both stable and unstable > releases i.e. combining these two watchfiles: uscan already supports this, add two sites in one watch file: version=3 opts=pgpsigurlmangle=s/$/.sig/ \ ftp://alpha.gnu.org/gnu/findutils/findutils-([\d\.\d]+)\.tar\.(?:gz|bz2|xz) opts=pgpsigurlmangle=s/$/.sig/ \ ftp://ftp.gnu.org/gnu/findutils/findutils-([\d\.\d]+)\.tar\.(?:gz|bz2|xz) There are probably some warts though, especially for multi-tarball source packages. -- bye, pabs https://wiki.debian.org/PaulWise
Re: debian/watch - check multiple hosts?
Paul Wise wrote: > On Tue, Dec 29, 2015 at 3:24 PM, Andreas Metzler wrote: >> is it possible to have uscan check multiple hosts? e.g. >> for GNU findutils I would like to look at both stable and unstable >> releases i.e. combining these two watchfiles: > uscan already supports this, add two sites in one watch file: > version=3 [...] Perfect, thank you. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: O: wicd -- wired and wireless network manager
Hello, I'd like to maintain the wicd package, especially because it's a kind of popular package. That would offer me a great challenge to master. But i assume, I'll certainly make errors and certainly be very slow at the beginning in comparison with an experienced maintainer. I can't estimate if that's a critical problem or if I'm suitable for maintaining such a popular package. Of course I'll do my best. ==> So, what do you guys think about that? regards, toogley On Wed, 7 Oct 2015 22:27:13 +0200 Axel Beckert wrote: Package: wnpp Severity: normal Hi, TL;DR: wicd is a lightweight alternative to GNOME's Network Manager. It is written in Python and offers commandline, curses and GTK user interfaces. David Paleino (Cc'ed), original developer and current Debian package maintainer of wicd stated multiple times[1][2] that he has no more time to work on wicd. Upstream development already has been passed[1] over to new developers. I asked in that thread if the new upstream developers would also take over the packaging of wicd for Debian, but it has been unanswered for more than one year now, though. wicd has seen two NMUs[3][4] in the past, both related to python-urwid API changes. According to Gianfranco (Cc'ed), David said that "he would avoid seeing the package die"[2]. And since the package received two NMUs since the last maintainer upload in 2012, I think it's the best to declare it as orphaned so that it's clear that someone who's interested can take over the package. There's already some work done on the package at [5]. Any future maintainer should base on that work. I'd be available for sponsoring wicd as I've done the first NMU and sponsored the second. I may also join a dedicated team in case wicd will be team-maintained in the future. That team would just need a more python-savvy lead than me. [1] https://answers.launchpad.net/wicd/+question/227789 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800693#71 [3] https://packages.qa.debian.org/w/wicd/news/20130609T173413Z.html [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800693#56 [5] https://anonscm.debian.org/cgit/collab-maint/wicd.git Some more details about the source and binary packages: Source: wicd Section: net Priority: optional Build-Depends: debhelper (>= 7.2.3~) , python (>= 2.6.6-3~) Build-Depends-Indep: po-debconf , python-babel , gettext Standards-Version: 3.9.6 Homepage: https://launchpad.net/wicd Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/wicd.git Vcs-Git: git://anonscm.debian.org/collab-maint/wicd.git Package: wicd Architecture: all
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox
Hi Ghislain, debian policy for shared library says each library must be in a seperate package [1]. OTB is well modularaized since 5.0.0. This allows external apps or libaries to use have some of the otb libs not all For instance, monteverdi required only a small subset of libs: OTBApplicationEngine OTBQtWidget OTBImageIO OTBVectorDataIO OTBTestKernel OTBCarto OTBProjection OTBStatistics So splitting a shared library is useful there. It also aslo true for remote modules. If anyone want to write a remote module that depends on two other modules OTBCommon, OTBTestKernel. he don't need to drag in all dependencies for that. And in future otb may have more modules. If there is a problem with split up libraries, I can change it and make it simply libotb and libotb-dev What do you think? [1] https://www.debian.org/doc/debian-policy/ch-sharedlibs.html
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox [uploaded]
On 12/29/2015 11:46 AM, Sebastiaan Couwenberg wrote: Hi Rashad, Thanks for your work on otb. I've sponsored the upload. lintian did report a new spelling error, please fix this as part of the next upload: I: libotb-apps: spelling-error-in-binary usr/lib/otb/applications/otbapp_GridBasedImageResampling.so intepreted interpreted Next time please also CC the RFS bugreport to the pkg-grass-devel list as documented in the Debian GIS policy: I did add the cc. The issue was that I used the work mail to post the bug which wasn't subscribed to that list. I guarantee that this won't be a problem next time. should I fix the spelling and reupload now or wait for the NEW queue. https://pkg-grass.alioth.debian.org/policy/packaging.html#sponsorship Be aware that Alioth is currently down due to planned maintenance: https://lists.debian.org/debian-infrastructure-announce/2015/12/msg0.html This makes the git repositories and team websites hosted on Alioth unavailable too. Normally packages are automatically removed from mentors when they are accepted into the archive. Because otb will have to pass the NEW queue first, and this may take some time, please remove the otb package from mentors yourself to avoid non-actionable TODO items on the team DMD page: https://udd.debian.org/dmd/?email1=pkg-grass-devel%40lists.alioth.debian.org#todo done. Kind Regards, Bas
Bug#809308: RFS: cl-asdf/3.1.6 [ITA] - Another System Definition Facility
control: owner -1 ! control: tag -1 moreinfo On Tue, Dec 29, 2015 at 09:37:52AM +0100, Kambiz Darabi wrote: > I have taken over the debian packaging for ASDF from François-René > Rideau and am looking for sponsors for the current 3.1.6 release: [...] > dget -x > http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_3.1.6-1.dsc Yesterday I wrote this down. As I said, the followings are not blocker, but unless you have a (good) reason for not doing them, I'd prefer to see them fixed/changed. * please use short format dh * add a Vcs-Browser field * please bump d/compat to 9 * I'm pretty sure the *.dirs are mostly useless * I know nothing of lips, and less about the packaging of lips stuff, but isn't there a dh tool to autocreate the postinst snippet? * from check-all-the-things: + can you explain these? - Warning in 'control binary:"cl-asdf" Recommends:1' value 'sbcl | lisp-compiler': package lisp-compiler is unknown. Check for typos if not a virtual package. - Warning in 'control binary:"cl-asdf" Breaks:0' value 'sbcl-common (<= 1:0.9.13.0-2)': package sbcl-common is unknown. Check for typos if not a virtual package. - Warning in 'control binary:"cl-asdf" Replaces:0' value 'sbcl-common (<= 1:0.9.13.0-2)': package sbcl-common is unknown. Check for typos if not a virtual package. + please fix the first and fix upstream the others: - $ codespell --quiet-level=3 ./debian/changelog:1247: Seperate ==> Separate ./test/ecl-make-image/readme.lisp:62: doesnt ==> doesn't ./doc/asdf.texinfo:2992: throughly ==> thoroughly -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: http://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Bug#809312: marked as done (RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox)
Your message dated Tue, 29 Dec 2015 11:46:25 +0100 with message-id <56826481.40...@xs4all.nl> and subject line RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox [uploaded] has caused the Debian Bug report #809312, regarding RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox 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.) -- 809312: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809312 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "otb" * Package name: otb Version : 5.2.0+dfsg-1 Upstream Author : cont...@orfe-toolbox.org * URL : http://orfeo-toolbox.org * License : CeCILL-2.0 Section : science It builds those binary packages: libotb - ORFEO Toolbox library metapackage libotb-apps - Plugins for ORFEO Toolbox applications libotb-dev - Free library of image processing algorithms - development libotbapplicationengine-5.2-1 - ORFEO Toolbox library - OTBApplicationEngine libotbcarto-5.2-1 - ORFEO Toolbox library - OTBCarto libotbcommandline-5.2-1 - ORFEO Toolbox library - OTBCommandLine libotbcommandlineparser-5.2-1 - ORFEO Toolbox library - OTBCommandLinePaser libotbcommon-5.2-1 - ORFEO Toolbox library - OTBCommon libotbcurladapters-5.2-1 - ORFEO Toolbox library - OTBCurlAdapters libotbedge-5.2-1 - ORFEO Toolbox library - OTBEdge libotbextendedfilename-5.2-1 - ORFEO Toolbox library - OTBExtendedFileName libotbfuzzy-5.2-1 - ORFEO Toolbox library - OTBFuzzy libotbgdaladapters-5.2-1 - ORFEO Toolbox library - OTBGdalAdapters libotbimagebase-5.2-1 - ORFEO Toolbox library - OTBImageBase libotbimageio-5.2-1 - ORFEO Toolbox library - OTBImageIO libotbimagemanipulation-5.2-1 - ORFEO Toolbox library - OTBImageManipulation libotbiobsq-5.2-1 - ORFEO Toolbox library - OTBIOBSQ libotbiogdal-5.2-1 - ORFEO Toolbox library - OTBIOGDAL libotbiokml-5.2-1 - ORFEO Toolbox library - OTBIOKML libotbiolum-5.2-1 - ORFEO Toolbox library - OTBIOLUM libotbiomstar-5.2-1 - ORFEO Toolbox library - OTBIOMSTAR libotbiomw-5.2-1 - ORFEO Toolbox library - OTBIOMW libotbioonera-5.2-1 - ORFEO Toolbox library - OTBIOONERA libotbiorad-5.2-1 - ORFEO Toolbox library - OTBIORAD libotbiotilemap-5.2-1 - ORFEO Toolbox library - OTBIOTileMap libotbmathparser-5.2-1 - ORFEO Toolbox library - OTBMathParser libotbmetadata-5.2-1 - ORFEO Toolbox library - OTBMetadata libotbopenthreadsadapters-5.2-1 - ORFEO Toolbox library - OTBOpenThreadsAdapters libotbossimadapters-5.2-1 - ORFEO Toolbox library - OTBOssimAdapters libotbossimplugins-5.2-1 - ORFEO Toolbox library - OTBOssimPlugins libotbpolarimetry-5.2-1 - ORFEO Toolbox library - OTBPolarimetry libotbprojection-5.2-1 - ORFEO Toolbox library - OTBProjection libotbqtwidget-5.2-1 - ORFEO Toolbox library - OTBQtWidget libotbrcc8-5.2-1 - ORFEO Toolbox library - OTBRCC8 libotbsiftfast-5.2-1 - ORFEO Toolbox library - OTBSiftFast libotbstreaming-5.2-1 - ORFEO Toolbox library - OTBStreaming libotbsupervised-5.2-1 - ORFEO Toolbox library - OTBSupervised libotbtestkernel-5.2-1 - ORFEO Toolbox library - OTBTestKernel libotbtransform-5.2-1 - ORFEO Toolbox library - OTBTransform libotbvectordatabase-5.2-1 - ORFEO Toolbox library - OTBVectorDataBase libotbvectordataio-5.2-1 - ORFEO Toolbox library - OTBVectorDataIO libotbwavelet-5.2-1 - ORFEO Toolbox library - OTBWavelet otb-bin- ORFEO Toolbox command line applications otb-bin-qt - ORFEO Toolbox graphical user interface applications otb-testdriver - ORFEO Toolbox library - OTBTestDriver python-otb - ORFEO Toolbox Python API for applications To access further information about this package, please visit the following URL: http://mentors.debian.net/package/otb Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/otb/otb_5.2.0+dfsg-1.dsc More information about otb can be obtained from http://orfeo-toolbox.org here is the ITP report - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764860 Changes since the last upload: Regards, Rashad Kanavath --- End Message --- --- Begin Message --- Hi Rashad, Thanks for your work on otb. I've sponsored the upload. lintian did report a new spelling error, please fix this as part of the next upload: I: libotb-apps: spelling-error-in-binary usr/lib/otb/applications/otbapp_GridBasedImageResampling.so intepreted interpreted Next time please als
Bug#809199: RFS: gap-guava/3.12+ds1-3 [unrep fix] [dbg] -- coding theory library for GAP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi: On 29/12/15 10:16, Tobias Frost wrote: > On Mon, 28 Dec 2015 09:13:59 +0100 Jerome Benoit > wrote: >> Package: sponsorship-requests >> Severity: normal >> >> Dear Mentors: >> >> I am looking for a sponsor for the package gap-guava that >> I am maintining on behalf of the Debian Science Team. >> This pacakge fix a reproduciblefix, introduce a debug >> package, and fixes some new (so to speak) warnings. >> >> Thanks, >> Jerome >> >> -- System Information: >> Debian Release: Jessie* >>APT prefers stable >>APT policy: (990, 'stable'), (500, 'stable-updates') >> Architecture: amd64 (x86_64) >> Foreign Architectures: i386 >> >> Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (SMP w/4 CPU cores) >> Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) >> Shell: /bin/sh linked to /bin/dash >> Init: sysvinit (via /sbin/init) >> >> > > Can you add a pointer where to get the package? At Alioth: anonscm.debian.org/cgit/debian-science/packages/gap-guava.git Jerome > > Thanks! > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWgloJAAoJEIC/w4IMSybjMuYIALlbmEBSwADCw1RxMZu5woD+ lCdrdlU79cSkVyH/iCTlNQB7gKwxXlDvRX4j5o/t2afzuHK+2TR1qtZhoMDvWCSa iQaRzWmgsDMdxwq4BhORJcm5amryu2CQoWtguQF8unJtwGPluE/QL+0PyMfhSxSu 8nyFM/XH/9CG7XlJNm3FN0zTiXdz+TfK/fZ90fYVGiSZiMLfXsHoIuXPMoj7Hk0u FGqSF/vMoqQRq2mYKJD5rCOAht3avga4KUAb3SHs9+oVQRSpEBXmjO8Wk8NceNoU 7hE0gvSB4MX+jQj02kJCoTm7YD9HMTS/tQCNxa2NrGTa6C5Y3qjHpAKutq1oX/U= =jk57 -END PGP SIGNATURE-
Bug#809312: (no subject)
|X-Debbugs-CC: pkg-grass-de...@lists.alioth.debian.org|
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox
Hi Rashad, Thanks for working on packaging the ORFEO toolbox to Debian. I am wondering about the usefulness of having so many binary packages. I guess this reflects the fact that OTB is nicely modularized, but even toolkits like VTK / ITK are packaged with a reduced number of binary packages for simpler maintenance. Besides, none of the shlib packages have a corresponding -dev package (ala Boost for instance), so providing individual shlib packages for each binary sounds excessive. Also, please keep in mind that having one package per module means that, assuming OTB keeps introducing newer modules future releases, then new -shlib packages would have to be introduced each time and be manually validated by the release team. With a "combined" package approach (ala VTK for instance), the new modules can just be added to the existing packaging without requiring manual intervention. Best regards, Ghis On 29/12/15 09:20, Rashad Kanavath wrote: Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "otb" * Package name: otb Version : 5.2.0+dfsg-1 Upstream Author : cont...@orfe-toolbox.org * URL : http://orfeo-toolbox.org * License : CeCILL-2.0 Section : science It builds those binary packages: libotb - ORFEO Toolbox library metapackage libotb-apps - Plugins for ORFEO Toolbox applications libotb-dev - Free library of image processing algorithms - development libotbapplicationengine-5.2-1 - ORFEO Toolbox library - OTBApplicationEngine libotbcarto-5.2-1 - ORFEO Toolbox library - OTBCarto libotbcommandline-5.2-1 - ORFEO Toolbox library - OTBCommandLine libotbcommandlineparser-5.2-1 - ORFEO Toolbox library - OTBCommandLinePaser libotbcommon-5.2-1 - ORFEO Toolbox library - OTBCommon libotbcurladapters-5.2-1 - ORFEO Toolbox library - OTBCurlAdapters libotbedge-5.2-1 - ORFEO Toolbox library - OTBEdge libotbextendedfilename-5.2-1 - ORFEO Toolbox library - OTBExtendedFileName libotbfuzzy-5.2-1 - ORFEO Toolbox library - OTBFuzzy libotbgdaladapters-5.2-1 - ORFEO Toolbox library - OTBGdalAdapters libotbimagebase-5.2-1 - ORFEO Toolbox library - OTBImageBase libotbimageio-5.2-1 - ORFEO Toolbox library - OTBImageIO libotbimagemanipulation-5.2-1 - ORFEO Toolbox library - OTBImageManipulation libotbiobsq-5.2-1 - ORFEO Toolbox library - OTBIOBSQ libotbiogdal-5.2-1 - ORFEO Toolbox library - OTBIOGDAL libotbiokml-5.2-1 - ORFEO Toolbox library - OTBIOKML libotbiolum-5.2-1 - ORFEO Toolbox library - OTBIOLUM libotbiomstar-5.2-1 - ORFEO Toolbox library - OTBIOMSTAR libotbiomw-5.2-1 - ORFEO Toolbox library - OTBIOMW libotbioonera-5.2-1 - ORFEO Toolbox library - OTBIOONERA libotbiorad-5.2-1 - ORFEO Toolbox library - OTBIORAD libotbiotilemap-5.2-1 - ORFEO Toolbox library - OTBIOTileMap libotbmathparser-5.2-1 - ORFEO Toolbox library - OTBMathParser libotbmetadata-5.2-1 - ORFEO Toolbox library - OTBMetadata libotbopenthreadsadapters-5.2-1 - ORFEO Toolbox library - OTBOpenThreadsAdapters libotbossimadapters-5.2-1 - ORFEO Toolbox library - OTBOssimAdapters libotbossimplugins-5.2-1 - ORFEO Toolbox library - OTBOssimPlugins libotbpolarimetry-5.2-1 - ORFEO Toolbox library - OTBPolarimetry libotbprojection-5.2-1 - ORFEO Toolbox library - OTBProjection libotbqtwidget-5.2-1 - ORFEO Toolbox library - OTBQtWidget libotbrcc8-5.2-1 - ORFEO Toolbox library - OTBRCC8 libotbsiftfast-5.2-1 - ORFEO Toolbox library - OTBSiftFast libotbstreaming-5.2-1 - ORFEO Toolbox library - OTBStreaming libotbsupervised-5.2-1 - ORFEO Toolbox library - OTBSupervised libotbtestkernel-5.2-1 - ORFEO Toolbox library - OTBTestKernel libotbtransform-5.2-1 - ORFEO Toolbox library - OTBTransform libotbvectordatabase-5.2-1 - ORFEO Toolbox library - OTBVectorDataBase libotbvectordataio-5.2-1 - ORFEO Toolbox library - OTBVectorDataIO libotbwavelet-5.2-1 - ORFEO Toolbox library - OTBWavelet otb-bin- ORFEO Toolbox command line applications otb-bin-qt - ORFEO Toolbox graphical user interface applications otb-testdriver - ORFEO Toolbox library - OTBTestDriver python-otb - ORFEO Toolbox Python API for applications To access further information about this package, please visit the following URL: http://mentors.debian.net/package/otb Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/o/otb/otb_5.2.0+dfsg-1.dsc More information about otb can be obtained from http://orfeo-toolbox.org here is the ITP report - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764860 Changes since the last upload: Regards, Rashad Kanavath
Bug#804100: RFS: rhythmbox-plugin-alternative-toolbar/0.14.0-1~debian [ITP]
Gianfranco,
think I have had success with the watch file. I found that if you store
the signature within a branch (in this case the debian branch) then you can
directly access the .asc file via the watch file.
Also I've removed the unneeded "license removal" patch. This just leaves
the patch to Makefile.am to ensure the LICENSE file is not added to the
debian binary
The latest revision has been uploaded to mentors.
thanks
David
On 29 December 2015 at 00:36, foss.freedom wrote:
> ok - scratch that Gianfranco,
>
> I deleted the rhythmbox-plugin-alternative-toolbar_0.15.0.orig.tar.gz file
> and reran uscan --debug --force-download
>
> It came back with the same 404 error
>
> GitHub saves attached downloads to the releases/download/v0.15.0 folder
> not to the archive folder
>
>
> https://github.com/fossfreedom/alternative-toolbar/releases/download/v0.15.0/v0.15.0.tar.gz.asc
>
> As I mentioned - my regex knowledge is very limited so I dont really
> understand how to modify the watch file. I've read that link you gave me
> and I'm non-the-wiser as to how to change the watch file to find the .asc
> is the releases/download/{version} folder
>
> David
>
> On 29 December 2015 at 00:23, foss.freedom wrote:
>
>> Hi Gianfranco,
>>
>> strange that my uscan didnt pick that up.
>>
>> I've renamed the .asc file on the tag to v0.15.0.tar.gz.asc
>>
>> With regards to the license issue.
>>
>> I have to include the LICENSE part of Makefile.am so that those people
>> who compile directly from source correctly has the LICENSE file added to
>> the /usr/lib/rhythmbox/plugins/alternative-toolbar folder
>>
>> So at the very minimum I need at least a patch to remove the LICENSE part
>> of Makefile.am for Debian.
>>
>> As I mentioned in one of my emails above I couldnt get that dh-helper
>> statement working in my rules file - I raised this on unix & linux
>> stackexchange and someone mentioned you can't have cdbs and dh-helper type
>> statements in the same rule file. I can't say if this is true or not -
>> just that I couldnt get it to work.
>>
>> -
>> http://unix.stackexchange.com/questions/250683/how-to-remove-a-license-file-when-debian-packaging-using-autotools-automake
>>
>> thanks
>>
>> David
>>
>> On 28 December 2015 at 23:33, Gianfranco Costamagna <
>> costamagnagianfra...@yahoo.it> wrote:
>>
>>> Hi,
>>>
>>>
>>> uscan warning: In directory ., downloading
>>>
>>> https://github.com/fossfreedom/alternative-toolbar/archive/v0.15.0.tar.gz.asc
>>> failed: 404 Not Found
>>>
>>>
>>> seems that you have to rename it (or tweak the regex)
>>>
>>>
>>> BTW remove license . patch seems difficult to maintain, what about
>>> dropping the two patches and do something like that in your rules file?
>>>
>>> override_dh_auto_install:
>>> dh_auto_install
>>> find debian/tmp -name "LICENSE" -delete
>>>
>>> it shoud work (note: I didn't test it)
>>>
>>> cheers,
>>>
>>> G.
>>>
>>> Il Lunedì 28 Dicembre 2015 21:21, foss.freedom
>>> ha scritto:
>>>
>>>
>>>
>>> Gianfranco,
>>>
>>> I've uploaded an updated package with your suggested watch file.
>>>
>>> According to the uscan results I got the following - I presume this
>>> means success?
>>>
>>> uscan debug: matching pattern(s) (?:(?:https://github.com
>>> )?\/fossfreedom\/alternative\-toolbar\/tags)?.*/v?(\d\S*)\.tar\.gz
>>> -- Found the following matching hrefs:
>>> /fossfreedom/alternative-toolbar/archive/v0.15.0.tar.gz (0.15.0)
>>> /fossfreedom/alternative-toolbar/archive/v0.14.1.tar.gz (0.14.1)
>>> /fossfreedom/alternative-toolbar/archive/v0.14.0.tar.gz (0.14.0)
>>> Newest version on remote site is 0.15.0, local version is 0.15.0
>>> => Package is up to date
>>> Newest version on remote site is 0.15.0, local version is 0.15.0
>>> => rhythmbox-plugin-alternative-toolbar_0.15.0.orig.tar.gz already in
>>> package directory '..'
>>> -- Scan finished
>>>
>>> thanks
>>>
>>> David
>>>
>>>
>>> On 28 December 2015 at 19:21, Gianfranco Costamagna <
>>> costamagnagianfra...@yahoo.it> wrote:
>>>
>>> Hi
>>> >
>>> >
>>> >>I'm trying to get rid of the last pedantic linitian issue which is the
>>> signing of the release.
>>> >>
>>> >> I think I've figured out how to sign the .tar.gz on github
>>> >>
>>> >>gpg --default-key 7B0393D9 --armor --detach-sign
>>> alternative-toolbar-0.15.tar.gz
>>> >
>>> >
>>> >wonderful!
>>> >
>>> >>Then I attached the .asc file to the release.
>>> >>https://github.com/fossfreedom/alternative-toolbar/releases/tag/v0.15
>>> >
>>> >
>>> >exactly
>>> >
>>> >>I created a .pgp file in the debian folder with:
>>> >>
>>> >>gpg --export "the public fingerprint for the debian key" >
>>> debian/upstream-signing-key.pgp
>>> >>
>>> >>
>>> >>However I really dont understand regex and thus I dont know how to
>>> change the watch file from this:
>>> >>
>>> >>version=3
>>> >>opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/alternative-toolbar-$1\.tar\.gz/
>>> \
>>> >> https://github.com/fossfreedom/alternative-toolbar/tags
>>> .*/v?(\d\S*)\.tar\.gz
>>> >>
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox [uploaded]
On 29-12-15 11:54, Rashad Kanavath wrote: > should I fix the spelling and reupload now or wait for the NEW queue. I'd fix it in git now, and wait for the next upload until it passes the NEW queue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Re: webcamoid - NEW
Hi, Gianfranco > Hi, the package was already in new queue, and got accepted yesterday. > > Please move your fixes in a -2 revision and ping me when done. > > > and please start from the -1 version in experimental > Eriberto got time and is helping. Thanks to paying attention with the package. regards, -- Herbert Parentes Fortes Neto (hpfn)
Bug#808613: RFS: re2c/0.15.3-1 [ITA] -- tool for generating fast C-based recognizers
> Package name: re2c Alas, the new version failed to build on five architectures. Even worse, the build logs contain no meaningful output: .-- make check-TESTS make[2]: Entering directory '/«PKGBUILDDIR»' make[3]: Entering directory '/«PKGBUILDDIR»' FAIL: run_tests.sh PASS: testrange PASS: testston32unsafe Testsuite summary for re2c 0.15.3 # TOTAL: 3 # PASS: 2 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 See ./test-suite.log Please report to re2c-gene...@lists.sourceforge.net Makefile:1313: recipe for target 'test-suite.log' failed `-- Could you please create an "override_dh_auto_test" target in debian/rules that runs "$(MAKE) check" and if it fails, cats test-suite.log? Debugging the failure requires access to a machine, real or emulated, of one of architectures that fail. I suspect that you have no mips, powerpc, s390x, hppa or sparc64 machines lying around -- and access to Debian's porterboxes is restricted to DDs only which makes using them greatly unconvenient. Thus, I'd strongly recommend using qemu. You can either install a virtual machine by hand (which requires reading arch-specific docs) or fetch a pre-made image from https://people.debian.org/~aurel32/qemu/ -- unfortunately, these haven't been updated since wheezy which requires dist-upgrades to jessie then unstable. -- A tit a day keeps the vet away.
Bug#809348: Fwd: RFS: pentobi/10.1-1
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "pentobi", just a couple days after getting the previous version packaged and sponsored. This new major release was released today. Package name: pentobi Version : 11.0-1 Upstream Author : Markus Enzenberger URL : http://pentobi.sourceforge.net/ License : GPL-3.0+ Section : games It builds those binary packages: pentobi - clone of the strategy board game Blokus pentobi-kde-thumbnailer - clone of the strategy board game Blokus - KDE thumbnailer To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pentobi Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pentobi/pentobi_11.0-1.dsc Git repository can be viewed online at https://anonscm.debian.org/cgit/pkg-games/pentobi.git Changes since the last upload: pentobi (11.0-1) unstable; urgency=medium * New upstream release. * d/rules: "USE_QT5" not needed, qt4 support was dropped upstream. * d/pentobi.install: Add usr/share/appdata, remove usr/share/pixmaps. Cheers, Juhani Numminen
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox
On 29/12/15 10:09, Rashad Kanavath wrote: Hi Ghislain, debian policy for shared library says each library must be in a seperate package [1]. The following citation from the very link you provided is far from the definition I know of "must": "If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together." OTB is well modularaized since 5.0.0. This allows external apps or libaries to use have some of the otb libs not all For instance, monteverdi required only a small subset of libs: OTBApplicationEngine OTBQtWidget OTBImageIO OTBVectorDataIO OTBTestKernel OTBCarto OTBProjection OTBStatistics So splitting a shared library is useful there. It also aslo true for remote modules. If anyone want to write a remote module that depends on two other modules OTBCommon, OTBTestKernel. he don't need to drag in all dependencies for that. The modularization of OTB follows pretty much what ITK does from the distant look I had of it, and I am familiar with how VTK / ITK is packaged in Debian. Still neither of both were modularized too much besides the separation of the Python and Qt specific stuff, in order to reduce (co)maintenance burden. Again, you're the maintainer and the final decision is totally yours here. Besides, all the modules you provide seem to qualify for the case I cited above (same goes for ITK / VTK), hence my suggestion to place them in a common shlib package. Since you assumed that the policy "forced" you to do otherwise, I understand why you considered my advice defensively. And in future otb may have more modules. If there is a problem with split up libraries, I can change it and make it simply libotb and libotb-dev I can't comment on the "simplicity" of the conversion. Perhaps you have more experience on this aspect of packaging than I do. On a side note, by contributing to other packages than I personally maintain, I can tell you one thing: the more complicated the packaging, the least I have been inclined to invest time in co-maintenance. That is likely to apply to others. What do you think? Not that it matters anymore, since your source package has now been sponsored. Good luck with the rest though. Ghis
Bug#808538: RFS: corebird
Hi Iain, thanks for the detailed review! On Thu, 24 Dec 2015 21:37:31 + "Iain R. Learmonth" wrote: > Hi, > > Unfortunately this is not yet ready for upload. It's nearly there though. Good to hear :). > debian/copyright: This is one of the most important things to get right, > and you have got this right. Do be careful though licensing your packaging > under different terms to the upstream code. In this case, it's possible to > take patches you produce and relicense them under GNU GPL v3 (due to the > "any later version" clause) so they can be integrated upstream, but this > would not be the case with incompatible licenses. I prefer to always just > use the license that upstream used. Hm, good point, I just use GPL-2+ for all my debian/* files. I'll think about it but keep it for now. > debian/control: You've set the section to "misc". I would suggest you set > this to "web" instead. See Debian Policy §2.4 for more detail on sections. done. > The extended description also needs to be slightly more extended. Please > talk about the features this application has. done. > debian/rules: You've got some things in here that I don't believe are > necessary. I like the debian/rules to be as clean as possible, using as many > of the current defaults as possible. The following statements are redundant > as you are using compat level 9: > > export DEB_BUILD_MAINT_OPTIONS = hardening=+all > export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed I also like to use defaults but here, hardening of builds seems to be important enough to deviate from defaults. > It is acceptable to leave in the "nocheck" export as long as that's not a > permanent thing. Please contact upstream and ask them to make the tests > pass. I'll contact upstream and try to solve this. > export V = 1 > > I'm not sure what $V does. Is this really necessary for the release in the > Debian archive? As Mattia explained it produces more verbose build logs which helped me to understand failing builds on buildds in the past. > You have an "override_dh_auto_configure" section, please look up > dh-autoreconf as this will handle this for you. Currently this package is > not policy compliant as "debian/rules clean" will not restore the package to > its original state. dh-autoreconf handles storing the old versions for you > and ensuring the package is policy compliant in that respect. Thanks for catching this, I changed it now. > dh $@ --parallel > > Unless you have a good reason for the --parallel, please remove this. If it > turns out later that the Debian build systems prefer this option, it would > become a default. As I said above, I prefer defaults be used whenever > possible. I removed the "--parallel" now. > The package bulds fine using cowbuilder, and lintian has no futher > complaints, if you can fix these issues then I will be happy to sponsor this > package for you. I hope I addressed all your suggestions. I uploaded a revised build to http://mentors.debian.net/package/corebird Best, Philip signature.asc Description: OpenPGP digital signature
Bug#809312: RFS: otb/5.2.0+dfsg-1 [ITP] -- Orfeo Toolbox
Quoting Ghislain Vaillant : On 29/12/15 10:09, Rashad Kanavath wrote: Hi Ghislain, debian policy for shared library says each library must be in a seperate package [1]. The following citation from the very link you provided is far from the definition I know of "must": I didn't mean RTFM (Read the fine manual). When I was having initial package review, I was asked to move shared libs into separate packages. I initially had separated qt and python stuff only. "If you have several shared libraries built from the same source tree, you may lump them all together into a single shared library package provided that all of their SONAMEs will always change together." OTB is well modularaized since 5.0.0. This allows external apps or libaries to use have some of the otb libs not all For instance, monteverdi required only a small subset of libs: OTBApplicationEngine OTBQtWidget OTBImageIO OTBVectorDataIO OTBTestKernel OTBCarto OTBProjection OTBStatistics So splitting a shared library is useful there. It also aslo true for remote modules. If anyone want to write a remote module that depends on two other modules OTBCommon, OTBTestKernel. he don't need to drag in all dependencies for that. The modularization of OTB follows pretty much what ITK does from the distant look I had of it, and I am familiar with how VTK / ITK is packaged in Debian. Still neither of both were modularized too much besides the separation of the Python and Qt specific stuff, in order to reduce (co)maintenance burden. Again, you're the maintainer and the final decision is totally yours here. yes. modularization of otb follows that of itk. Besides, all the modules you provide seem to qualify for the case I cited above (same goes for ITK / VTK), hence my suggestion to place them in a common shlib package. Since you assumed that the policy "forced" you to do otherwise, I understand why you considered my advice defensively. Not exactly. If there is some issue with the current state of packaging, I am okay to fix it. ofcourse, going back to single libs is easy but a lot of work will be wasted. But I don't have a problem with that. sorry If I sounded defensive to your comments, it may be because i was doing a single shared libs at first and then I decided to split them. And in future otb may have more modules. If there is a problem with split up libraries, I can change it and make it simply libotb and libotb-dev I can't comment on the "simplicity" of the conversion. Perhaps you have more experience on this aspect of packaging than I do. On a side note, by contributing to other packages than I personally maintain, I can tell you one thing: the more complicated the packaging, the least I have been inclined to invest time in co-maintenance. That is likely to apply to others. I guess maintaining the symbols file is easier when packages are separated. And before I start, I looked into other packaging works in DebianGIS. All of them follow this way. So I stick to that. The complexity of maintenance you were mentioning was also similar as in the case of qgis. What do you think? Not that it matters anymore, since your source package has now been sponsored. Good luck with the rest though. Thanks. I appreciate your feedback and possible interest in maintaining the package. Ghis
Bug#808538: marked as done (RFS: corebird/1.1-1 [ITP])
Your message dated Tue, 29 Dec 2015 22:47:52 +0100 with message-id <20151229214752.ga2...@shiftout.net> and subject line Re: Bug#808538: RFS: corebird has caused the Debian Bug report #808538, regarding RFS: corebird/1.1-1 [ITP] 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.) -- 808538: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808538 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "corebird" Package name: corebird Version : 1.1-1 Upstream Author : Timm Bäder URL : http://corebird.baedert.org License : GPL-3+ Section : misc It builds those binary packages: corebird - Native Gtk+ Twitter client for the Linux desktop To access further information about this package, please visit the following URL: http://mentors.debian.net/package/corebird Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/corebird/corebird_1.1-1.dsc More information about corebird can be obtained from http://corebird.baedert.org. Regards, Philip Rinn -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (600, 'testing'), (550, 'unstable'), (500, 'testing-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- End Message --- --- Begin Message --- Hi, On Tue, Dec 29, 2015 at 07:16:08PM +0100, Philip Rinn wrote: > I uploaded a revised build to http://mentors.debian.net/package/corebird Uploaded. (: Thanks, Iain @ 32c3 -- --- End Message ---
Bug#806815: pkg-lirc team seems unmaintained
Hi all, sorry for the long delay.
Some new points for Alec (added him in the loop, and also the RFS bug
@Alec, please look at the review below, it is really complete, and report back
when you have addressed the points.
@Alexander, can you please make Stefan admin of pkg-lirc?
this way Stefan will make the final decision about accepting/rejecting new
members according to the quality of the new
lirc packages.
(EDIT: he is already an admin, thanks a lot!)
@Stefan, would you please help and review the package on mentors (after the
points below are fixed?)
I can sponsor the package, but I'll leave to you any final decision about this
sponsoring.
@Alec, I can follow up on libirman if needed, just ask me, I'll wait for
objections there :)
thanks a lot to you all,
have a nice new year!
Gianfranco
Il Lunedì 21 Dicembre 2015 7:19, Stefan Lippers-Hollmann ha
scritto:
Hi
[ it's late and I'll be on the road again for the next couple of days
before christmas, so I might miss some finer details of this mail,
although it already got longer than I hoped ]
On 2015-12-18, Gianfranco Costamagna wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi Ector, Sven and Stefan,
>
> I write to you because $somebody (upstream) is doing a lot of work, to
> fix lirc and libirman packages, and to finally put them again
>
> into a good state.
I certainly didn't have a lot time since early summer (which is slowly
normalizing), but I don't quite agree that the lirc packaging would be
in a bad state - at least not from a Debian centric look (I certainly
understand that lirc upstream wants the latest and greatest and might
disagree).
We certainly are behind the current upstream version (and it looks worse
than it is, as 0.9.0~pre1 with the upstream patches included in the Debian
package is actually equivalent to the released version of 0.9.0, except
for the version bump and tiny, no-op, build-system tweaks), but the post
0.9.1 upstream changes are extremely disruptive, they are good (and many
of them have been needed), but very disruptive (liblirc{,}-client0 is
no more --> transition (sourceful uploads) of all rdeps needed, the new
plugin structure needs checking with multi-arch, .la removal (static
linking), new/ different config file format). While we need to update,
doing this in a hurry simply isn't an option - and there isn't really a
problem with the current lirc version in Debian.
At least the current version of lirc 0.9.0~pre1 builds in current
unstable, works with all kernels >= 2.6.37 (including linux-next), is
compatible with Debian's userland (unstable and experimental) and doesn't
really have any important bugs that would need quick attention.
> In order to make the packages "upgradable" he created an upgrade
> script, converting stuff from the old and Debian specific configuration
Until lirc >= 0.9.1, this config migration was a headache[0] for me
(especially as the packaging svn already did a migration to a different
config file/ ~format (/etc/default/lirc.conf) on request of the previous
upstream, Jarod Wilson, before this new /etc/lirc/lirc_options.conf was
even under consideration); fortunately this never hit the archive. But
with lirc >= 0.9.2, the library split changes are actually worse to get
sorted.
> to the new upstream and fedora configuration (this will drop the long
> old debian delta, even if it will be a little painful, or at least
> manual).
>
> I asked him to join the team, but I failed so far, because seems that
> the team is almost not active anymore.
I can't help with that, as I'm just a member of pkg-lirc and not an
admin.
> So I'm asking you permission to NMU the packages (there is still a lot
> of work to do, and they won't be ready for some time), or (better
> solution for sure)
It took me a while to find the actual thing supposed as a lirc NMU, but
I strongly advise against uploading lirc_0.9.4~alpha-1.1.dsc from
mentors[1]. As I've just found it, I can't claim to have given it a
proper review yet, nor have I tested the actual upgrade helpers, but from
a very first glance (in the order I've found it, unsorted).
- major library transition (needs a migration approval from the release
team and serious checking with liblircclient-dev's reverse
build-dependencies in Debian
- debian/control is pretty much butchered up, those things (besides
needlessly changing the package split in several areas) aren't exactly
serious - and easily fixable, but the current changes under proposal
are bad.
- weird/ useless debian/install (the source creates multiple binaries, so
this gets ignored)
- the Breaks/ Replaces logic is broken and against Debian policy.
- debian/copyright, while better (not better, just updated for post
0.9.0) than the current version in the archive, it is a regression
compared to the current state in the packaging svn (I have the changes
needed for 0.9.1 locally (svn is just bad for testing incomplete
changes), b
Re: Source tarball update/fix
On Monday, December 28 2015, Gianfranco Costamagna wrote: > Hi, > > also the - is a good separator. Heh, sometimes the solution is so obvious... For some reason (so obscure that I cannot remember), I thought that '-' could not be used in this specific case. That's why I was trying with '+' or '~' only... Anyway, that did the trick! Thanks a lot, Gianfranco. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#808613: RFS: re2c/0.15.3-1 [ITA] -- tool for generating fast C-based recognizers
On Wed, Dec 30, 2015 at 12:30 AM, Adam Borowski wrote: > Debugging the failure requires access to a machine, real or emulated, of one > of architectures that fail. I suspect that you have no mips, powerpc, > s390x, hppa or sparc64 machines lying around -- and access to Debian's > porterboxes is restricted to DDs only which makes using them greatly > unconvenient. Thus, I'd strongly recommend using qemu. Temporary access to Debian porterboxen can be arranged: https://dsa.debian.org/doc/guest-account/ qemu is probably quicker to setup though, but may be slower. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#808538: RFS: corebird
On Wed, Dec 30, 2015 at 2:16 AM, Philip Rinn wrote: > I removed the "--parallel" now. If the upstream build system supports parallel builds, you are just wasting buildd time by removing that option, please put it back in. The only reason that it isn't the default yet is because not all upstream build systems work when run in parallel mode. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Source tarball update/fix
Sergio Durigan Junior writes: > On Monday, December 28 2015, Gianfranco Costamagna wrote: > > > also the - is a good separator. > > Heh, sometimes the solution is so obvious... For some reason (so > obscure that I cannot remember), I thought that '-' could not be used in > this specific case. It is a valid character in the upstream version string, and when upstream does in fact use that character it should of course be preserved in the Debian package version string. When *adding* a suffix that's not part of the upstream version string, though, I maintain that “-” is not a good separator to use. Conventionally, “+” is a soft indication that the suffix is not part of the upstream version string; and that's why I still advocate using “+ds1” for your suffix. (And correcting any bugs in the upstream build system which trip on that.) -- \ “Even if the voices in my head are not real, they have pretty | `\ good ideas.” —anonymous | _o__) | Ben Finney
