Bug#717928:
While migrating photoprint, I've found this resource which might be helpful for migrators: This is bascially a (almost) complete wrapper mapping lcms1 to lcms2: https://www.vuiis.vanderbilt.edu/~welcheb/mac%20installs/GIMP/separate +-0.5.8/lcms_wrapper.h -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards. diff -Nru subsurface-4.0.3/debian/changelog subsurface-4.0.3/debian/changelog --- subsurface-4.0.3/debian/changelog 2014-05-05 15:21:27.0 +0200 +++ subsurface-4.0.3/debian/changelog 2014-08-11 20:29:05.0 +0200 @@ -1,3 +1,10 @@ +subsurface (4.0.3-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Remove osmgpsmap as dependency (Closes: #748386) + + -- Ross Gammon rossgam...@mail.dk Mon, 11 Aug 2014 20:25:14 +0200 + subsurface (4.0.3-2) unstable; urgency=medium * Make sure subsurface builds on all archs (Closes: #738438) diff -Nru subsurface-4.0.3/debian/control subsurface-4.0.3/debian/control --- subsurface-4.0.3/debian/control 2014-02-27 11:55:36.0 +0100 +++ subsurface-4.0.3/debian/control 2014-08-11 20:27:22.0 +0200 @@ -11,7 +11,6 @@ libdivecomputer-dev (= 0.3.0), libqt4-dev, libqtwebkit-dev, - libosmgpsmap-dev, libgconf2-dev, libtool, libxml2-dev, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748386: [Pkg-running-devel] Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
On Tue, 2014-08-12 at 09:19 +0200, Christian PERRIER wrote: Quoting Tobias Frost (t...@debian.org): tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks for your work (as pkg-running team member, I leave priority to Sylvestre Ledru, who is probably busy elsewhere...which explains why nothing happened with that issue). I included the NMU changes to our git repository and tagged the release, so please push the NMU the DELAYED/0..or let's just wait for 5 days...:-) Ok, just pushed to DELAYED/0. Thanks for the feeback :) -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748386: [Pkg-running-devel] Bug#748386: subsurface: diff for NMU version 4.0.3-2.1
On 12. August 2014 09:19:49 MESZ, Christian PERRIER bubu...@debian.org wrote: Quoting Tobias Frost (t...@debian.org): tags 748386 + pending thanks Dear maintainer, I've prepared an NMU for subsurface (versioned as 4.0.3-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Thanks for your work (as pkg-running team member, I leave priority to Sylvestre Ledru, who is probably busy elsewhere...which explains why nothing happened with that issue). I included the NMU changes to our git repository and tagged the release, so please push the NMU the DELAYED/0..or let's just wait for 5 days...:-) Ok, Just uploaded. -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757540: libosl: diff for NMU version 0.6.0-3.1
tags 757540 + patch tags 757540 + pending thanks Dear maintainer, I've prepared an NMU for libosl (versioned as 0.6.0-3.1) and uploaded it to DELAYED/10. Please feel free to tell me if I should delay it longer. Regards. diff -Nru libosl-0.6.0/debian/changelog libosl-0.6.0/debian/changelog --- libosl-0.6.0/debian/changelog 2014-02-08 14:16:05.0 +0100 +++ libosl-0.6.0/debian/changelog 2014-08-12 19:06:44.0 +0200 @@ -1,3 +1,10 @@ +libosl (0.6.0-3.1) unstable; urgency=medium + + * Non-maintainer upload. + * Changing B-D on boost to unversioned one. (Closes: #757540) + + -- Tobias Frost t...@debian.org Tue, 12 Aug 2014 17:06:15 + + libosl (0.6.0-3) unstable; urgency=medium * Added new patches: diff -Nru libosl-0.6.0/debian/control libosl-0.6.0/debian/control --- libosl-0.6.0/debian/control 2014-02-08 14:16:05.0 +0100 +++ libosl-0.6.0/debian/control 2014-08-12 18:33:53.0 +0200 @@ -2,7 +2,7 @@ Section: libs Priority: optional Maintainer: Daigo Moriwaki da...@debian.org -Build-Depends: cdbs, dpkg-dev (= 1.16.1~), debhelper (= 7), quilt, libcppunit-dev (= 1.10.2-5), libboost1.54-all-dev +Build-Depends: cdbs, dpkg-dev (= 1.16.1~), debhelper (= 7), quilt, libcppunit-dev (= 1.10.2-5), libboost-all-dev Standards-Version: 3.9.4 Homepage: http://gps.tanaka.ecc.u-tokyo.ac.jp/gpsshogi/pukiwiki.php Vcs-Browser: http://git.debian.org/?p=collab-maint/libosl.git;a=summary -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757995: wfmath: diff for NMU version 1.0.2+dfsg1-0.2
Package: wfmath Version: 1.0.2+dfsg1-0.1 Severity: normal Tags: patch pending Dear maintainer, I've prepared an NMU for wfmath (versioned as 1.0.2+dfsg1-0.2) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru wfmath-1.0.2+dfsg1/debian/changelog wfmath-1.0.2+dfsg1/debian/changelog --- wfmath-1.0.2+dfsg1/debian/changelog 2014-08-10 18:02:00.0 +0200 +++ wfmath-1.0.2+dfsg1/debian/changelog 2014-08-13 09:21:38.0 +0200 @@ -1,3 +1,10 @@ +wfmath (1.0.2+dfsg1-0.2) unstable; urgency=medium + + * Non-maintainer upload. + * Upload to unstable. + + -- Tobias Frost t...@debian.org Wed, 13 Aug 2014 09:21:29 +0200 + wfmath (1.0.2+dfsg1-0.1) experimental; urgency=low [ Tobias Frost ] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758046: vmpk: potential embedded code copy (src:rtmidi)
Package: vmpk Severity: normal Dear Maintainer, It seems that there is a embedded code copy in vmpk. See the files RtMidi.h and .cpp it seems that the embedded copy is rather old, versioned 1.0.14... -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757442: RFS: polyphone/1.4 [RFP]
On Wed, 2014-08-13 at 17:46 +0200, Davy Triponney wrote: Thank a lot for the report. - polyphone_1.4.orig.tar.gz is now present in SourceForge (https://sourceforge.net/projects/polyphone/files/polyphone% 20releases/1.4/) Regarding get-orig-source, I read this page: https://wiki.debian.org/onlyjob/get-orig-source My watch file is correct since the last version is recognized and downloaded by uscan. But I don't know how to integrate this nice feature by modifying the file rules even with the explanations. And I don't know what result I would get. A self-updating package creator? get-orig-source is needed if you don't cant get the orig.tar. One example us, if there isn't one and you pull directly from a repository. A example for this would be my package gmrender-resurrect. Or, if you had to remove files for DFSG freeness (which nowerdays uscan can do for you via ExcludeFiles in d/copyright). So if uscan won't work for you, you need the target... Otherwise not. - copyright file is fixed, copyright headers added in some source files, - debian/share directory has been removed - the icon resolution is now 512*512, it doesn't come from a vector file, ok, I just saw that my comment regarding the icon was incomplete... srry about that. The intention is that every file needs its source and regenerated at build time -- the resolution is not a concern, but we need the preferred form for modiciations here. So it would be great if you could publish the source for the icon and -- if possible -- regenerate it at build time to the desired sizes... - debian/polyphone.1 has been completed, - ITP bug retitled, - pdebuilder now can build the package. I'm sorry for the dependency mistakes. The new package has been uploaded https://mentors.debian.net/package/polyphone The above reads very good :) Taking a look now... - clavier/RT*.cpp seems like an embedded code copy, fortunately its already packaged in Debian is rtmidi, but unfortunatly the package in Debian is much newer than the code in polyphone, so some additional porting beside patching the build system to use the packaged one might be necessary. (Embedded code copies are very discouraged -- refer to the Policy §4.13) (But patching this will help you on another possible issue: The license on RTMidi. It says: Any person wishing to distribute modifications to the Software is *requested* to send the modifications to the original developer Update: I just see that this is a widget, probably from the package vmpk)... It seems is possible to package the QT Widget on its own...) However, for this widget I'd ignore that one for the moment... In the packaged version request has been replaced with ask and a sentence added that this is not a requirements. I discussed this on d-mentors: there were concerns about DFSG compliance, but the concerns are void when only asking. (I'm not saying that the request isn't ok, but this can cause questions at ftp-masters later on) Another embedded library seems to be the The Synthesis ToolKit in synthetiseur/elements/* (also packaged in Debian) Another one: qcustomplot Another one: sfarklib. (However, this one needs to be packaged) lib/portaudio.h shouldn't be there... :-P For the moment please remove the file with a patch -- to show that it is not used. (If possible, drop that file in your next release) - d/copyright: It probably misses a Files:* rule with Copyright Davy Triponney and License: GPL-3+ Files: clavier/* Copyright: 2008-2014 Pedro Lopez-Cabanillas, p...@users.sf.net License: GPL-3+ Your name is missing here as copyright holder Three files without copyright: ./clavier/RtError.h UNKNOWN *No copyright* ./sfark/sfarkglobal.cpp UNKNOWN *No copyright* ./sfark/sfarkglobal.h UNKNOWN *No copyright* ressources/* are missing in d/copyright. Is the manual hand written or generated? (However, as not installed, this is OK) Just a question (to avoid a typo) You license debian/* with GPL-2+ while the rest is GPL-3+ (different version). As you have the or later this is ok, but its easier if license of the packaging is exactly same. No need to change, though. Ok so please check the remaining d/copyright issues, and please check if it is feasible to use the packaged libraries instead of your embedded copies. Could you (if feasible to be used) already file an ITP for sfArkLib? Cheer up, we're getting closer :) Regards, Davy -- tobi signature.asc Description: This is a digitally signed message part
Bug#756202:
Hi, I saw the same after converting to systemd as init: Delay until some systemd script times out. In the hope this helps someone seeing the same issue, this are my observations: In my case the reason was that somehow the UUID of the swap device changed, so that systemd was simply waiting for the wrong device. The UUID changed when I migrated to systemd, however the very first reboot was still fast. (though I did not boot to X this time has I had to recompile the nvidia stuff) After I changed to the new UUID, the system boots as expected. Maybe this helps someone with the same isssue.. I don't know why the UUID changed in the first place. The upgrade also included a kernel update. (linux-image-amd64:amd64 3.14+57 - 3.14+59) (timeline to back that up with information) Last reboot with sysv: Aug 14 09:55:20 mordor kernel: [0.00] Initializing cgroup subsys cpuset (..) Aug 14 09:55:20 mordor kernel: [ 25.798452] Adding 16775164k swap on /dev/mapper/cryptswap. Priority:-1 extents:1 across:16775164k First reboot with systemd as init: Aug 14 11:37:36 mordor kernel: [0.00] Initializing cgroup subsys cpuset (..) Aug 14 11:37:36 mordor kernel: [ 26.772168] Adding 16775164k swap on /dev/mapper/cryptswap. Priority:-1 extents:1 across:16775164k (proof that this is systemd:) Aug 14 11:37:37 mordor systemd[1]: Starting Authenticate and Authorize Users to Run Privileged Tasks... Second reboot: Aug 14 11:51:42 mordor kernel: [0.00] Initializing cgroup subsys cpuset (..) Aug 14 11:51:44 mordor systemd[1]: Expecting device dev-disk-by\x2duuid-918c7c50\x2d17ed\x2d4e21\x2d9026\x2d6aedacaec283.device... Aug 14 11:53:14 mordor systemd[1]: Job dev-disk-by\x2duuid-918c7c50\x2d17ed\x2d4e21\x2d9026\x2d6aedacaec283.device/start timed out. Aug 14 11:53:14 mordor systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-918c7c50\x2d17ed\x2d4e21\x2d9026\x2d6aedacaec283.device. Aug 14 11:53:14 mordor systemd[1]: Dependency failed for /dev/disk/by-uuid/918c7c50-17ed-4e21-9026-6aedacaec283. My setup: - LUKS crytped root sda4_crypt UUID=x-xxx---x9d2 none luks - LUKS crypted swap with derived key from root device cryptswap UUID=x-xxx---xdc3 sda4_crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived,swap the relevant fstab line: UUID=x-xxx---x283 noneswapdefaults 0 0 (resume kernel-param -- however resume not yet tested after migration:) resume=/dev/mapper/cryptswap ls -la /dev/disk/by-uuid/ lrwxrwxrwx 1 root root 10 Aug 14 13:11 x-xxx---x1b2 - ../../dm-1 lrwxrwxrwx 1 root root 10 Aug 14 13:11 x-xxx---x9d2 - ../../sda4 lrwxrwxrwx 1 root root 10 Aug 14 13:11 x-xxx---x5c0 - ../../dm-0 lrwxrwxrwx 1 root root 10 Aug 14 13:11 x-xxx---xdc3 - ../../sda3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758128: uswsusp: initramfs-hook does not remove trailing spaces in resume device name
Package: uswsusp Version: 1.0+20120915-5 Severity: normal Hi, in my /etc/uswsusp.conf I had accidentially a trailing space after the resume device name. Howver, s2disk happyly accepts that line 8remove the space) and suspends. However, on resume, resume is never tried. Debugging into it I found that there is no /sbin/resume in the initrd. Due to the extra space, /usr/share/initramfs-tools/hooks/uswsusp did not consider the device as valid and did nnot add /sbin/resume, so resuming fails. I think the solution is to sed out trailing spaces... Thanks! -- tobi -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/3 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages uswsusp depends on: ii debconf [debconf-2.0] 1.5.53 ii libblkid1 2.20.1-5.8 ii libc6 2.19-7 ii libgcrypt111.5.3-5 ii liblzo2-2 2.08-1 ii libpci31:3.2.1-2 ii libx86-1 1.1+ds1-10 Versions of packages uswsusp recommends: ii initramfs-tools 0.115 ii mount2.20.1-5.8 uswsusp suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713344: mercator: diff for NMU version 0.3.2-1.1
Control: tags 713344 + pending Control: tags 734961 + pending Dear maintainer, As announced, as libwfmath is now in the archives, uploading to force a rebuild and fixing the symbols. I've prepared an NMU for mercator (versioned as 0.3.2-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru mercator-0.3.2/debian/changelog mercator-0.3.2/debian/changelog --- mercator-0.3.2/debian/changelog 2013-06-21 19:21:39.0 +0200 +++ mercator-0.3.2/debian/changelog 2014-08-15 20:10:49.0 +0200 @@ -1,3 +1,11 @@ +mercator (0.3.2-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Fixing symbol file (Closes: #713344) + * Libwfmath-1.0 is in the archive, so B-D on it is fine now (Closes: #734961) + + -- Tobias Frost t...@debian.org Fri, 15 Aug 2014 18:10:38 + + mercator (0.3.2-1) unstable; urgency=low * new upstream release diff -Nru mercator-0.3.2/debian/libmercator-0.3-3.symbols mercator-0.3.2/debian/libmercator-0.3-3.symbols --- mercator-0.3.2/debian/libmercator-0.3-3.symbols 2013-06-21 19:21:39.0 +0200 +++ mercator-0.3.2/debian/libmercator-0.3-3.symbols 2014-08-15 19:42:56.0 +0200 @@ -1,608 +1,457 @@ libmercator-0.3.so.3 libmercator-0.3-3 #MINVER# - (c++)ZeroSpiralOrdering::~ZeroSpiralOrdering()@Base 0.3.0 - (c++)ZeroSpiralOrdering::operator()(int, int)@Base 0.3.0 - (optional=inline)_ZN6WFMath7PolygonILi2EED1Ev@Base 0.3.0 - (optional=inline)_ZN6WFMath7PolygonILi2EED2Ev@Base 0.3.0 - (c++)Mercator::AreaShader::AreaShader(int)@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Ball::~AdjustTerrainMod()@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Ball::AdjustTerrainMod(float, WFMath::Ball2 const)@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Ball::apply(float, int, int) const@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Ball::setShape(float, WFMath::Ball2 const)@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Polygon::~AdjustTerrainMod()@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Polygon::AdjustTerrainMod(float, WFMath::Polygon2 const)@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Polygon::apply(float, int, int) const@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::Polygon::setShape(float, WFMath::Polygon2 const)@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::RotBox::~AdjustTerrainMod()@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::RotBox::AdjustTerrainMod(float, WFMath::RotBox2 const)@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::RotBox::apply(float, int, int) const@Base 0.3.0 + (c++)Mercator::AdjustTerrainModWFMath::RotBox::setShape(float, WFMath::RotBox2 const)@Base 0.3.0 + (c++)Mercator::Area::addToSegment(Mercator::Segment) const@Base 0.3.0 + (c++)Mercator::Area::~Area()@Base 0.3.0 + (c++)Mercator::Area::Area(int, bool)@Base 0.3.0 + (c++)Mercator::Area::checkIntersects(Mercator::Segment const) const@Base 0.3.0 + (c++)Mercator::Area::clipToSegment(Mercator::Segment const) const@Base 0.3.0 + (c++)Mercator::Area::contains(float, float) const@Base 0.3.2 + (c++)Mercator::Area::removeFromSegment(Mercator::Segment) const@Base 0.3.0 + (c++)Mercator::Area::setShader(Mercator::Shader const*) const@Base 0.3.0 + (c++)Mercator::Area::setShape(WFMath::Polygon2 const)@Base 0.3.0 (c++)Mercator::AreaShader::~AreaShader()@Base 0.3.0 - _ZN8Mercator10BandShader16key_lowThresholdE@Base 0.3.0 - _ZN8Mercator10BandShader17key_highThresholdE@Base 0.3.0 - _ZN8Mercator10BandShader20default_lowThresholdE@Base 0.3.0 - _ZN8Mercator10BandShader21default_highThresholdE@Base 0.3.0 - _ZN8Mercator10BandShaderC1ERKSt3mapISsfSt4lessISsESaISt4pairIKSsfEEE@Base 0.3.0 - _ZN8Mercator10BandShaderC1Eff@Base 0.3.0 - _ZN8Mercator10BandShaderC2ERKSt3mapISsfSt4lessISsESaISt4pairIKSsfEEE@Base 0.3.0 - _ZN8Mercator10BandShaderC2Eff@Base 0.3.0 - _ZN8Mercator10BandShaderD0Ev@Base 0.3.0 - _ZN8Mercator10BandShaderD1Ev@Base 0.3.0 - _ZN8Mercator10BandShaderD2Ev@Base 0.3.0 - _ZN8Mercator10FillShaderC1ERKSt3mapISsfSt4lessISsESaISt4pairIKSsfEEE@Base 0.3.0 - _ZN8Mercator10FillShaderC1Ev@Base 0.3.0 - _ZN8Mercator10FillShaderC2ERKSt3mapISsfSt4lessISsESaISt4pairIKSsfEEE@Base 0.3.0 - _ZN8Mercator10FillShaderC2Ev@Base 0.3.0 - _ZN8Mercator10FillShaderD0Ev@Base 0.3.0 - _ZN8Mercator10FillShaderD1Ev@Base 0.3.0 - _ZN8Mercator10FillShaderD2Ev@Base 0.3.0 - _ZN8Mercator10HighShader13key_thresholdE@Base 0.3.0 - _ZN8Mercator10HighShader17default_thresholdE@Base 0.3.0 - _ZN8Mercator10HighShaderC1ERKSt3mapISsfSt4lessISsESaISt4pairIKSsfEEE@Base 0.3.0 - _ZN8Mercator10HighShaderC1Ef@Base 0.3.0 - _ZN8Mercator10HighShaderC2ERKSt3mapISsfSt4lessISsESaISt4pairIKSsfEEE@Base 0.3.0 - _ZN8Mercator10HighShaderC2Ef@Base 0.3.0 + (c++)Mercator::AreaShader::AreaShader(int)@Base 0.3.0 + (c++)Mercator::AreaShader::checkIntersect(Mercator::Segment const) const@Base 0.3.0 + (c++)Mercator::AreaShader::shadeArea(Mercator::Surface, Mercator::Area const*) const@Base 0.3.0 + (c++)Mercator::AreaShader
Bug#701273: eris: diff for NMU version 1.3.21-0.1
Control: tags 701273 + patch Control: tags 701273 + pending Dear maintainer, I've prepared an NMU for eris (versioned as 1.3.21-0.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. The NMU-diff is based on the current version in git. Regards. diff --git a/debian/changelog b/debian/changelog index 31d499a..2fe94f2 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,5 +1,10 @@ -eris (1.3.21-1) unstable; urgency=low +eris (1.3.21-0.1) unstable; urgency=low + [ Tobias Frost ] + * Non-maintainer upload. + * Fixing symbol file for liberis. + + [ Stephen M. Webb ] * new upstream release * debian/control: bumped build-dep versions for new WorldForge packages * renamed packages due to new SONAME @@ -12,7 +17,7 @@ eris (1.3.21-1) unstable; urgency=low from source * debian/control: fixed Vcs-Browser URL - -- Stephen M. Webb stephen.w...@bregmasoft.ca Sun, 11 Aug 2013 17:26:33 -0400 + -- Tobias Frost t...@debian.org Sat, 16 Aug 2014 07:10:01 + eris (1.3.19-5) unstable; urgency=low diff --git a/debian/liberis-1.3-20.symbols b/debian/liberis-1.3-20.symbols index 9bb067a..4d75ddf 100644 --- a/debian/liberis-1.3-20.symbols +++ b/debian/liberis-1.3-20.symbols @@ -47,9 +47,9 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER# _ZN4Eris10SpawnPointC2ERKSsRKSt6vectorINS_13CharacterTypeESaIS4_EES2_@Base 1.3.19 _ZN4Eris10SpawnPointD1Ev@Base 1.3.19 _ZN4Eris10SpawnPointD2Ev@Base 1.3.19 - _ZN4Eris10TimedEventD0Ev@Base 1.3.19 - _ZN4Eris10TimedEventD1Ev@Base 1.3.19 - _ZN4Eris10TimedEventD2Ev@Base 1.3.19 + (optional=inline)_ZN4Eris10TimedEventD0Ev@Base 1.3.19 + (optional=inline)_ZN4Eris10TimedEventD1Ev@Base 1.3.19 + (optional=inline)_ZN4Eris10TimedEventD2Ev@Base 1.3.19 _ZN4Eris10ViewEntity11onTaskAddedEPNS_4TaskE@Base 1.3.19 _ZN4Eris10ViewEntity13onSoundActionERKN5Atlas7Objects8SmartPtrINS2_9Operation17RootOperationDataEEE@Base 1.3.19 _ZN4Eris10ViewEntity19onVisibilityChangedEb@Base 1.3.19 @@ -280,9 +280,9 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER# _ZN4Eris4Poll12new_timeout_E@Base 1.3.19 _ZN4Eris4Poll5_instE@Base 1.3.19 _ZN4Eris4Poll8instanceEv@Base 1.3.19 - _ZN4Eris4PollD0Ev@Base 1.3.19 - _ZN4Eris4PollD1Ev@Base 1.3.19 - _ZN4Eris4PollD2Ev@Base 1.3.19 + (optional=inline)_ZN4Eris4PollD0Ev@Base 1.3.19 + (optional=inline)_ZN4Eris4PollD1Ev@Base 1.3.19 + (optional=inline)_ZN4Eris4PollD2Ev@Base 1.3.19 _ZN4Eris4Room10appearanceERKSs@Base 1.3.19 _ZN4Eris4Room10checkEntryEv@Base 1.3.19 _ZN4Eris4Room10createRoomERKSs@Base 1.3.19 @@ -508,9 +508,9 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER# _ZN4Eris8IGRouterD0Ev@Base 1.3.19 _ZN4Eris8IGRouterD1Ev@Base 1.3.19 _ZN4Eris8IGRouterD2Ev@Base 1.3.19 - _ZN4Eris8PollDataD0Ev@Base 1.3.19 - _ZN4Eris8PollDataD1Ev@Base 1.3.19 - _ZN4Eris8PollDataD2Ev@Base 1.3.19 + (optional=inline)_ZN4Eris8PollDataD0Ev@Base 1.3.19 + (optional=inline)_ZN4Eris8PollDataD1Ev@Base 1.3.19 + (optional=inline)_ZN4Eris8PollDataD2Ev@Base 1.3.19 _ZN4Eris8TypeInfo11addAncestorEPS0_@Base 1.3.19 _ZN4Eris8TypeInfo12setAttributeERKSsRKN5Atlas7Message7ElementE@Base 1.3.19 _ZN4Eris8TypeInfo12validateBindEv@Base 1.3.19 @@ -908,7 +908,8 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER# _ZNSt5dequeISsSaISsEE16_M_push_back_auxERKSs@Base 1.3.19 (regex|optional=inline)_ZNSt5dequeISsSaISsEE17_M_reallocate_mapE[mj]b@Base 1.3.19 (optional=inline)_ZNSt5dequeISsSaISsEE19_M_destroy_data_auxESt15_Deque_iteratorISsRSsPSsES5_@Base 1.3.19 - _ZNSt5dequeISsSaISsEE5eraseESt15_Deque_iteratorISsRSsPSsE@Base 1.3.19 + (optional)_ZNSt5dequeISsSaISsEE5eraseESt15_Deque_iteratorISsRSsPSsE@Base 1.3.19 + (optional)_ZNSt5dequeISsSaISsEE8_M_eraseESt15_Deque_iteratorISsRSsPSsE@Base 1.3.21 (regex|optional=inline)_ZNSt5dequeISsSaISsEED[12]Ev@Base 1.3.19 _ZNSt6vectorIN4Eris10ServerInfoESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base 1.3.19 (regex)_ZNSt6vectorIN4Eris10ServerInfoESaIS1_EE7reserveE[mj]@Base 1.3.19 @@ -981,9 +982,10 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER# (optional=inline)_ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE5eraseERKS2_@Base 1.3.19 _ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E@Base 1.3.19 (optional=gcc-4.7)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE10_M_insert_EPKSt18_Rb_tree_node_baseS8_RKSs@Base 1.3.19 + (optional)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE10_M_insert_EPSt18_Rb_tree_node_baseS7_RKSs@Base 1.3.21 (optional=inline)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE11equal_rangeERKSs@Base 1.3.19 (optional=gcc-4.7)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE12_M_erase_auxESt23_Rb_tree_const_iteratorISsES7_@Base 1.3.19 - _ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE16_M_insert_uniqueERKSs@Base 1.3.19 + (optional)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE16_M_insert_uniqueERKSs@Base 1.3.19 (optional=inline
Bug#701273:
This is the right diff...
(Overlooked one versioned dependency on wfmath in the -dev package)
diff --git a/debian/changelog b/debian/changelog
index 31d499a..f3472e0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,11 @@
-eris (1.3.21-1) unstable; urgency=low
+eris (1.3.21-0.1) unstable; urgency=low
+ [ Tobias Frost ]
+ * Non-maintainer upload.
+ * Fixing symbol file for liberis.
+ * Adding patch remove silent-rules.
+
+ [ Stephen M. Webb ]
* new upstream release
* debian/control: bumped build-dep versions for new WorldForge packages
* renamed packages due to new SONAME
@@ -12,7 +18,7 @@ eris (1.3.21-1) unstable; urgency=low
from source
* debian/control: fixed Vcs-Browser URL
- -- Stephen M. Webb stephen.w...@bregmasoft.ca Sun, 11 Aug 2013 17:26:33 -0400
+ -- Tobias Frost t...@debian.org Sat, 16 Aug 2014 07:10:01 +
eris (1.3.19-5) unstable; urgency=low
diff --git a/debian/control b/debian/control
index a2d9b1f..68f3017 100644
--- a/debian/control
+++ b/debian/control
@@ -56,7 +56,7 @@ Depends: libatlas-cpp-0.6-dev (= 0.6.2),
libglib2.0-dev,
libsigc++-2.0-dev,
libskstream-0.3-dev (= 0.3.8),
- libwfmath-0.3-dev (= 0.3.11),
+ libwfmath-1.0-dev,
${misc:Depends}
Description: WorldForge client entity library - development files
Eris is designed to simplify client development (and avoid repeating the
diff --git a/debian/liberis-1.3-20.symbols b/debian/liberis-1.3-20.symbols
index 9bb067a..4d75ddf 100644
--- a/debian/liberis-1.3-20.symbols
+++ b/debian/liberis-1.3-20.symbols
@@ -47,9 +47,9 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER#
_ZN4Eris10SpawnPointC2ERKSsRKSt6vectorINS_13CharacterTypeESaIS4_EES2_@Base 1.3.19
_ZN4Eris10SpawnPointD1Ev@Base 1.3.19
_ZN4Eris10SpawnPointD2Ev@Base 1.3.19
- _ZN4Eris10TimedEventD0Ev@Base 1.3.19
- _ZN4Eris10TimedEventD1Ev@Base 1.3.19
- _ZN4Eris10TimedEventD2Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris10TimedEventD0Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris10TimedEventD1Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris10TimedEventD2Ev@Base 1.3.19
_ZN4Eris10ViewEntity11onTaskAddedEPNS_4TaskE@Base 1.3.19
_ZN4Eris10ViewEntity13onSoundActionERKN5Atlas7Objects8SmartPtrINS2_9Operation17RootOperationDataEEE@Base 1.3.19
_ZN4Eris10ViewEntity19onVisibilityChangedEb@Base 1.3.19
@@ -280,9 +280,9 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER#
_ZN4Eris4Poll12new_timeout_E@Base 1.3.19
_ZN4Eris4Poll5_instE@Base 1.3.19
_ZN4Eris4Poll8instanceEv@Base 1.3.19
- _ZN4Eris4PollD0Ev@Base 1.3.19
- _ZN4Eris4PollD1Ev@Base 1.3.19
- _ZN4Eris4PollD2Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris4PollD0Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris4PollD1Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris4PollD2Ev@Base 1.3.19
_ZN4Eris4Room10appearanceERKSs@Base 1.3.19
_ZN4Eris4Room10checkEntryEv@Base 1.3.19
_ZN4Eris4Room10createRoomERKSs@Base 1.3.19
@@ -508,9 +508,9 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER#
_ZN4Eris8IGRouterD0Ev@Base 1.3.19
_ZN4Eris8IGRouterD1Ev@Base 1.3.19
_ZN4Eris8IGRouterD2Ev@Base 1.3.19
- _ZN4Eris8PollDataD0Ev@Base 1.3.19
- _ZN4Eris8PollDataD1Ev@Base 1.3.19
- _ZN4Eris8PollDataD2Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris8PollDataD0Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris8PollDataD1Ev@Base 1.3.19
+ (optional=inline)_ZN4Eris8PollDataD2Ev@Base 1.3.19
_ZN4Eris8TypeInfo11addAncestorEPS0_@Base 1.3.19
_ZN4Eris8TypeInfo12setAttributeERKSsRKN5Atlas7Message7ElementE@Base 1.3.19
_ZN4Eris8TypeInfo12validateBindEv@Base 1.3.19
@@ -908,7 +908,8 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER#
_ZNSt5dequeISsSaISsEE16_M_push_back_auxERKSs@Base 1.3.19
(regex|optional=inline)_ZNSt5dequeISsSaISsEE17_M_reallocate_mapE[mj]b@Base 1.3.19
(optional=inline)_ZNSt5dequeISsSaISsEE19_M_destroy_data_auxESt15_Deque_iteratorISsRSsPSsES5_@Base 1.3.19
- _ZNSt5dequeISsSaISsEE5eraseESt15_Deque_iteratorISsRSsPSsE@Base 1.3.19
+ (optional)_ZNSt5dequeISsSaISsEE5eraseESt15_Deque_iteratorISsRSsPSsE@Base 1.3.19
+ (optional)_ZNSt5dequeISsSaISsEE8_M_eraseESt15_Deque_iteratorISsRSsPSsE@Base 1.3.21
(regex|optional=inline)_ZNSt5dequeISsSaISsEED[12]Ev@Base 1.3.19
_ZNSt6vectorIN4Eris10ServerInfoESaIS1_EE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPS1_S3_EERKS1_@Base 1.3.19
(regex)_ZNSt6vectorIN4Eris10ServerInfoESaIS1_EE7reserveE[mj]@Base 1.3.19
@@ -981,9 +982,10 @@ liberis-1.3.so.20 liberis-1.3-20 #MINVER#
(optional=inline)_ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE5eraseERKS2_@Base 1.3.19
_ZNSt8_Rb_treeIPN4Eris9MetaQueryES2_St9_IdentityIS2_ESt4lessIS2_ESaIS2_EE8_M_eraseEPSt13_Rb_tree_nodeIS2_E@Base 1.3.19
(optional=gcc-4.7)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE10_M_insert_EPKSt18_Rb_tree_node_baseS8_RKSs@Base 1.3.19
+ (optional)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE10_M_insert_EPSt18_Rb_tree_node_baseS7_RKSs@Base 1.3.21
(optional=inline)_ZNSt8_Rb_treeISsSsSt9_IdentityISsESt4lessISsESaISsEE11equal_rangeERKSs@Base 1.3.19
(optional=gcc-4.7
Bug#704786: ember: diff for NMU version 0.6.2+dfsg-2.1
Control: tags 704786 + patch Control: tags 753767 + patch Dear maintainer, I've prepared an NMU for ember (versioned as 0.6.2+dfsg-2.1). The diff is attached to this message. Regards. diff -Nru ember-0.6.2+dfsg/debian/changelog ember-0.6.2+dfsg/debian/changelog --- ember-0.6.2+dfsg/debian/changelog 2012-06-13 21:46:01.0 +0200 +++ ember-0.6.2+dfsg/debian/changelog 2014-08-16 17:07:14.0 +0200 @@ -1,3 +1,15 @@ +ember (0.6.2+dfsg-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * Apply patch 0014-boost-1.53.patch from git repository. + * Patching to support wfmath-1.0 and ogre-1.8 (Backport from new upstream +version): Patch 0015-ogre18-wfmath10.patch. (Closes: #704786) + * The rebuild will also allow installing it again (Closes: #753767) + * Adding versioned B-D on liberis-dev 1.3.21-0.1 to ensure that the NMU +of eris is considered. (Can be removed the next upload) + + -- Tobias Frost t...@debian.org Sat, 16 Aug 2014 17:05:12 +0200 + ember (0.6.2+dfsg-2) unstable; urgency=low * fixed a FTBFS on random arches due to --parallel on dh_install diff -Nru ember-0.6.2+dfsg/debian/control ember-0.6.2+dfsg/debian/control --- ember-0.6.2+dfsg/debian/control 2012-06-09 17:01:51.0 +0200 +++ ember-0.6.2+dfsg/debian/control 2014-08-16 17:11:15.0 +0200 @@ -9,10 +9,10 @@ libatlas-cpp-0.6-dev (= 0.6.1), libboost-thread-dev, libcegui-mk2-dev (= 0.7.5), - liberis-1.3-dev (= 1.3.19), + liberis-1.3-dev (= 1.3.21-0.1~), liblua5.1-0-dev, libmercator-0.3-dev (= 0.3.0), - libogre-dev (= 1.7.0), + libogre-1.8-dev, libopenal-dev, libpcre3-dev, libsdl1.2-dev, diff -Nru ember-0.6.2+dfsg/debian/patches/0014-boost-1.53.patch ember-0.6.2+dfsg/debian/patches/0014-boost-1.53.patch --- ember-0.6.2+dfsg/debian/patches/0014-boost-1.53.patch 1970-01-01 01:00:00.0 +0100 +++ ember-0.6.2+dfsg/debian/patches/0014-boost-1.53.patch 2014-08-16 10:55:18.0 +0200 @@ -0,0 +1,14 @@ +Description: fixes FTBFS using boost1.53-dev +Author: Stephen M. Webb stephen.w...@bregmasoft.ca + +--- a/src/components/ogre/SceneManagers/EmberPagingSceneManager/src/OgrePagingLandScapeData2D.cpp b/src/components/ogre/SceneManagers/EmberPagingSceneManager/src/OgrePagingLandScapeData2D.cpp +@@ -116,7 +116,7 @@ + _save (); + //Use the shared pointer for deletion + //delete[] mHeightData; +- mHeightDataPtr.reset(0); ++ mHeightDataPtr.reset(); + mHeightData = 0; + _unload(); + mIsLoaded = false; diff -Nru ember-0.6.2+dfsg/debian/patches/0015-ogre18-wfmath10.patch ember-0.6.2+dfsg/debian/patches/0015-ogre18-wfmath10.patch --- ember-0.6.2+dfsg/debian/patches/0015-ogre18-wfmath10.patch 1970-01-01 01:00:00.0 +0100 +++ ember-0.6.2+dfsg/debian/patches/0015-ogre18-wfmath10.patch 2014-08-16 15:32:13.0 +0200 @@ -0,0 +1,233 @@ +--- a/configure.ac b/configure.ac +@@ -252,7 +252,7 @@ + # Check for OGRE + OGRE_VERSION=1.7.0 + OGRE_MAX_VERSION=1.8.0 +-PKG_CHECK_MODULES(OGRE, [OGRE = $OGRE_VERSION OGRE $OGRE_MAX_VERSION], ++PKG_CHECK_MODULES(OGRE, [OGRE = $OGRE_VERSION OGRE = $OGRE_MAX_VERSION], + [ + CXXFLAGS=$CXXFLAGS $OGRE_CFLAGS + LIBS=$LIBS $OGRE_LIBS +@@ -448,7 +448,7 @@ + + # Check for the WorldForge libs + PKG_CHECK_MODULES(WF, [eris-1.3 = 1.3.19 \ +- varconf-1.0 = 0.6.7 mercator-0.3 = 0.3.0 atlascpp-0.6 = 0.6.2 wfmath-0.3 = 0.3.11 libwfut-0.2 = 0.2.1], ++ varconf-1.0 = 0.6.7 mercator-0.3 = 0.3.0 atlascpp-0.6 = 0.6.2 wfmath-1.0 libwfut-0.2 = 0.2.1], + [ + CXXFLAGS=$CXXFLAGS $WF_CFLAGS + LIBS=$LIBS $WF_LIBS +--- a/src/components/ogre/scripting/bindings/lua/ogre/OgreEntity.pkg b/src/components/ogre/scripting/bindings/lua/ogre/OgreEntity.pkg +@@ -278,7 +278,7 @@ + morph animation, 'includes_pose_animation true' if using pose animation + and 'includes_skeletal_animation true' if using skeletal animation. + */ +- bool isHardwareAnimationEnabled(void) const; ++ bool isHardwareAnimationEnabled(void); + + /** Overridden from MovableObject */ + //void _notifyAttached(Node* parent, bool isTagPoint = false); +@@ -433,7 +433,7 @@ + BIND_HARDWARE_MORPH + }; + /// Choose which vertex data to bind to the renderer +- Ogre::Entity::VertexDataBindChoice chooseVertexDataForBinding(bool hasVertexAnim) const; ++ Ogre::Entity::VertexDataBindChoice chooseVertexDataForBinding(bool hasVertexAnim); + + /** Are buffers already marked as vertex animated? */ + bool _getBuffersMarkedForAnimation(void) const; +--- a/src
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
On Sun, 2014-08-17 at 19:27 +0200, Sebastiaan Couwenberg wrote: On 08/17/2014 06:35 PM, Jaromír Mikeš wrote: I just uploaded new upstream version of qmapshack 0.3.0 to debian mentors. This package fixing all previous issues, I would be grateful for reviewing. Regarding the copyright file I suggest to use the SPDX license shortnames as much as possible. http://spdx.org/licenses/ So instead of BSD (3 clause) as used by licensecheck, use BSD-3-Clause instead. And use the minor numbers for the GPL licenses, so GPL-3.0+ instead of GPL-3+. The copyright-format 1.0 specifies that license names cannot contain spaces (unless they define exceptions), using the SPDX license names prevents that. https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax Yes, it should be BSD-3-Clause. Its sufficient to write GPL-3+, as the copyright-format 1.0 writes: For SPDX compatibility, versions with trailing dot-zeroes are considered to be equivalent to versions without (e.g., 2.0.0 is considered equal to 2.0 and 2). (Also used in the examples) There is also an additional space after the Source field that should be removed. Jaromír, can you fix those tho minor things and maybe run wrap-and-sort over it. Then ping me... If you want, uploda it to mentors, but I can also work from the git repository) I'll take a look at the package tomorrow morning then... Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
On Sun, 2014-08-17 at 19:46 +0200, Jaromír Mikeš wrote: Can you please advice what to do with LGPL-2.1 with Digia Qt LGPL Exception 1.1 license? Files: src/helpers/CTextEditWidget.cpp src/helpers/CTextEditWidget.h I'd write: License: QT_COMMERICIAL or GPL-3 or LGPL-2.1 with Digia Qt LGPL Exception 1.1 (as you have the option to choose one of the three. The execption is like the OpenSSL exception in the examples of the link[1]) And then of course matching License paragraphs for the new licenses. [1] https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-syntax best regards mira -- tobi signature.asc Description: This is a digitally signed message part
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
On 17. August 2014 21:51:36 MESZ, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: Thanks for incorporating the feedback. I think the WTFPL short name should keep the version number, WTFPL-2 was better IMHO. The text of the QT license exception is still missing the LGPL exception text. I suggest at least the changes included in the attached patch. Since the license text of the QT commercial license is not known, and appears to be specific to each commercial licensee (because you need to contact them first, it's likely part of the contract negotiation), I would drop the QT_COMMERICAL license option too and just use: License: GPL-3.0+ or LGPL-2.1 with Digia Qt LGPL Exception 1.1 This is what qtmultimedia-opensource-src uses too, except in reverse order. Kind Regards, Bas -- GPG Key ID: 4096R/E88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 Regarding the patch: I'm not near a PC right now, so can't check: Are you sure the license of those files with the exception had a or later on their GPL option? Regarding the commercial option: I wouldn't leave it out, as IMHO d/copyright should be a exact representation on the license, even if a option is not really applicable. -- Tobias Frost 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
Hi Sebastiaan, On Sun, 2014-08-17 at 23:57 +0200, Sebastiaan Couwenberg wrote: On 08/17/2014 10:55 PM, Tobias Frost wrote: Regarding the patch: I'm not near a PC right now, so can't check: Are you sure the license of those files with the exception had a or later on their GPL option? I'm pretty sure about that. The QT project licensing page links to the licenses as published by the FSF which contain the or later part. Furthermore the LICENSE.LGPL and LICENSE.GPL files contained in QT projects contain or (at your option) any later version. No I disagee. You cannot refer to the published complete license text here; LICENSE.GPL begins with Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. so one can be sure that it is not modified for the purpose to have the or later option. As there is no no-later veision of the license file, we have to read on. Later in the license the or-later-option is introduced: Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. The files in question do *NOT* have the any later version specified, so the AND evaluated to false and it does not apply. That means you have only GPL-3 as option. As licenses are bound to the specific artifact, it is very dangerous to say other packages using QT do it this way. Looking at http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-textedit-cpp.html (looks like the source of the file), and on http://qt-project.org/doc/qt-5/licensing.html I don't see any or later option too. (However, this would be only an addtional, non-authoritive datapoint anyway, as the only thing that counts is the text in the artifact) Regarding the commercial option: I wouldn't leave it out, as IMHO d/copyright should be a exact representation on the license, even if a option is not really applicable. I agree in general, but we're not able to document the text of the commercial license. Thats not the point. The message is There is a third license option available which are individually negotiated. See the URL for details or contact us Details on the license are not necessary and the don't impact the use under the other license options. The other QT software I looked at also don't specify the commercial license, have you found any that do and if so how do they handle this issue? At least qat4-x11 and pulseview. They just have the license header in d/copyright. But IMHO other packagaes are a hint, not necessarily always correct. (This could be also a question for d-legal.) http://metadata.ftp-master.debian.org/changelogs/main/q/qt4-x11/unstable_copyright http://metadata.ftp-master.debian.org/changelogs/main/p/pulseview/unstable_copyright Kind Regards, Bas -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
On Sun, 2014-08-17 at 21:11 +0200, Jaromír Mikeš wrote: Ok, review complete. When below things are fixed, I will upload it. -- tobi d/copyright: (beside the already discussed things) - Files-Excluded not needed - Whats the copyright of the gpx examples? - src/cursors not documented d/dirs not needed, you can remove it. wrap-and-sort (please over the complete directory. Just run it from the root package directory.) e.g d/control will look much better afterwards) d/rules: - please remove the last line (the commented line gunzuip ... ) - the mv is not required: You can use the -O option of wget; also not that get-orig-source should get the tarball and leaves it in the current directory. (Policy 4.9), so the ../ in the mv is not right. d/clean + d/rules - please clean the generated icons in e.g d/clean and rebuild them during build. (there is such a nice script for doing this in the src :)) General rule: If there is a source, use it during build. E.g also compass.png should be regenerated. signature.asc Description: This is a digitally signed message part
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
On Mon, 2014-08-18 at 14:11 +0200, Sebastiaan Couwenberg wrote: On 08/18/2014 08:52 AM, Tobias Frost wrote: Hi Sebastiaan, On Sun, 2014-08-17 at 23:57 +0200, Sebastiaan Couwenberg wrote: On 08/17/2014 10:55 PM, Tobias Frost wrote: Regarding the patch: I'm not near a PC right now, so can't check: Are you sure the license of those files with the exception had a or later on their GPL option? I'm pretty sure about that. The QT project licensing page links to the licenses as published by the FSF which contain the or later part. Furthermore the LICENSE.LGPL and LICENSE.GPL files contained in QT projects contain or (at your option) any later version. No I disagee. You cannot refer to the published complete license text here; LICENSE.GPL begins with Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. so one can be sure that it is not modified for the purpose to have the or later option. As there is no no-later veision of the license file, we have to read on. Later in the license the or-later-option is introduced: Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and any later version, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. The files in question do *NOT* have the any later version specified, so the AND evaluated to false and it does not apply. That means you have only GPL-3 as option. As licenses are bound to the specific artifact, it is very dangerous to say other packages using QT do it this way. Looking at http://qt-project.org/doc/qt-5/qtwidgets-richtext-textedit-textedit-cpp.html (looks like the source of the file), and on http://qt-project.org/doc/qt-5/licensing.html I don't see any or later option too. (However, this would be only an addtional, non-authoritive datapoint anyway, as the only thing that counts is the text in the artifact) The license header in the artifact doesn't state the or later, but refers to the license as published by the FSF which does include it: ** GNU Lesser General Public License Usage ** Alternatively, this file may be used under the terms of the GNU Lesser ** General Public License version 2.1 as published by the Free Software ** Foundation and appearing in the file LICENSE.LGPL included in the ** packaging of this file. Please review the following information to ** ensure the GNU Lesser General Public License version 2.1 requirements ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. ** ** In addition, as a special exception, Digia gives you certain additional ** rights. These rights are described in the Digia Qt LGPL Exception ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. ** ** GNU General Public License Usage ** Alternatively, this file may be used under the terms of the GNU ** General Public License version 3.0 as published by the Free Software ** Foundation and appearing in the file LICENSE.GPL included in the ** packaging of this file. Please review the following information to ** ensure the GNU General Public License version 3.0 requirements will be ** met: http://www.gnu.org/copyleft/gpl.html. The full license text is not included in the header, but is deferred to the license as published by the FSF. Since the licenses as published by the FSF include or (at your option) any later version GPL-3+ applies. QT projects include the LICENSE.GPL and LICENSE.LGPL files as referred to in the header, but these are not included in qmapshack as they are in QT projects. The LICENSE.GPL and LICENSE.LGPL files included in QT projects are verbatim copies of the licenses as published by the FSF which includes or (at your option) any later version. The QT code included in qmapshack is taken from the QT examples, and the license applied to that include or (at your option) any later version: https://qt-project.org/doc/qt-4.7/demos-textedit-textedit-cpp.html https://qt-project.org/doc/qt-4.7/licensing.html https://qt-project.org/doc/qt-4.7/gpl.html https://qt-project.org/doc/qt-4.7/lgpl.html The artefact fails to state the option explictly. As Ansgar already replied, this is necessary to apply the or later option. Regarding the commercial option: I wouldn't leave it out, as IMHO d/copyright should be a exact representation on the license, even if a option is not really applicable. I agree in general, but we're not able to document the text of the commercial license. Thats not the point. The message is There is a third license option available which are individually negotiated. See the URL for details or contact us Details on the license are not necessary and the don't impact the use under
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
On Mon, 2014-08-18 at 09:02 +0200, Jaromír Mikeš wrote: Od: Sebastiaan Couwenberg sebas...@xs4all.nl I think the WTFPL short name should keep the version number, WTFPL-2 was better IMHO. The text of the QT license exception is still missing the LGPL exception text. I suggest at least the changes included in the attached patch. Since the license text of the QT commercial license is not known, and appears to be specific to each commercial licensee (because you need to contact them first, it's likely part of the contract negotiation), I would drop the QT_COMMERICAL license option too and just use: License: GPL-3.0+ or LGPL-2.1 with Digia Qt LGPL Exception 1.1 Done and uploaded to debian mentors. Well, there were lots of discussion regarding this... So if you wonder what to use now, I (still) think that you should use this: (or like; I didn't make it beautiful, like identation... The Exception license is taken from here: https://qt.gitorious.org/qt/qt/raw/bfa0be8a1bf68200f1ba9deff4a9215ee066:LGPL_EXCEPTION.txt) License: QT-Commercial or GPL-3.0 or LGPL-2.1 with Digia Qt LGPL Exception 1.1 License: QT-Commercial Commercial License Usage Licensees holding valid commercial Qt licenses may use this file in accordance with the commercial license agreement provided with the Software or, alternatively, in accordance with the terms contained in a written agreement between you and Digia. For licensing terms and conditions see http://qt.digia.com/licensing. For further information use the contact form at http://qt.digia.com/contact-us. License: LGPL-2.1 with Digia Qt LGPL Exception 1.1 Alternatively, this file may be used under the terms of the GNU Lesser General Public License version 2.1 as published by the Free Software Foundation and appearing in the file LICENSE.LGPL included in the packaging of this file. Please review the following information to ensure the GNU Lesser General Public License version 2.1 requirements will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. . In addition, as a special exception, Digia gives you certain additional rights. These rights are described in the Digia Qt LGPL Exception version 1.1, included in the file LGPL_EXCEPTION.txt in this package. . Digia Qt LGPL Exception version 1.1 As an additional permission to the GNU Lesser General Public License version 2.1, the object code form of a work that uses the Library may incorporate material from a header file that is part of the Library. You may distribute such object code under terms of your choice, provided that: (i) the header files of the Library have not been modified; and (ii) the incorporated material is limited to numerical parameters, data structure layouts, accessors, macros, inline functions and templates; and (iii) you comply with the terms of Section 6 of the GNU Lesser General Public License version 2.1. . Moreover, you may apply this exception to a modified version of the Library, provided that such modification does not involve copying material from the Library into the modified Library's header files unless such material is limited to (i) numerical parameters; (ii) data structure layouts; (iii) accessors; and (iv) small macros, templates and inline functions of five lines or less in length. . Furthermore, you are not required to apply this additional permission to a modified version of the Library. -- tobi signature.asc Description: This is a digitally signed message part
Bug#737515: dictionaries-common-dev: dh_aspell
On Sun, 2014-05-18 at 23:01 +0200, Andreas Beckmann wrote: On 2014-05-16 21:54, Tobias Frost wrote: + * Example-package to demonstrate dh_aspell-simple available +dictionaries-common-dev =1.23.3. See bug #737515 for details. +Build-Depends-Indep: aspell (= 0.60.3-3), + dictionaries-common-dev (= 1.23.2) * inconsistent version numbers * ... available since d-c-d = 1.23.3 ... Right, fixed. I changed the B-D to = 1.23.3 (as Agustin mentioned he will do an upload soon; I guess it's gonna be .3.) +override_dh_auto_configure: + # This is not a autoconf configure: ./configure * ... not an autoconf ... Corrected. check that d/* has no trailing whitespace (just in case people are going to copy+paste ...) Also fixed. I reuploaded the current state to mentors; It should be here: http://mentors.debian.net/debian/pool/main/a/aspell-it/aspell-it_2.4-20070901-0-2.1.dsc (Of course the binary on mentors is currently built against dictionaries-common-dev 1.23.2, so it will need a rebuild anyway as soon as 1.23.3 is in the archives.) Andreas PS: should we request a transition tracker at some point? PPS: MANY THANKS! Welcome :) -- Tobi signature.asc Description: This is a digitally signed message part
Bug#740240: libdrizzle4: UDS connect getting into infinite loop
On 20. Mai 2014 18:15:36 MESZ, Botond Botyanszki b...@siliconium.net wrote: Hi Tobias, Sorry about the delay. Finally I could try the patch and libdrizzle4 seems to be working fine with it. I'd appreciate if you could add this to the drizzle build to have a working libdrizzle4 package. Thanks, Botond On Thu, 27 Feb 2014 19:52:31 +0100 Tobias Frost t...@frost.de wrote: If you want, you can just give it a try and compile drizzle with the patch. As far as I can see, the only required change is to add this line --- libdrizzle/conn.cc.orig 2014-02-27 19:43:37.811668879 +0100 +++ libdrizzle/conn.cc2014-02-27 19:44:11.488212682 +0100 @@ -1301,6 +1301,8 @@ } } while (0); +drizzle_state_pop(con); + return DRIZZLE_RETURN_OK; #else return DRIZZLE_RETURN_COULD_NOT_CONNECT; (This is in function drizzle_return_t drizzle_state_connect(drizzle_con_st *con) The lines-# are for the latest version in sid, but as far as I see it has not much changed since 7.1.36-stable) Would be great if you could give it a try and let me know if this fixes it.. -- Tobias Hi Botond, Thanks for testing. I will prepare an upload on the next weekend. Too -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737515: dictionaries-common-dev: dh_aspell
On Sat, 2014-05-24 at 18:13 +0200, Agustin Martin wrote:
2014-05-19 22:00 GMT+02:00 Tobias Frost t...@coldtobi.de:
I reuploaded the current state to mentors; It should be here:
http://mentors.debian.net/debian/pool/main/a/aspell-it/aspell-it_2.4-20070901-0-2.1.dsc
(Of course the binary on mentors is currently built against
dictionaries-common-dev 1.23.2, so it will need a rebuild anyway as soon
as 1.23.3 is in the archives.)
Hi,
Thanks for your work in this reference package.
Finally had time to look into it. Just a couple of mostly cosmetic
issues, see attached patch.
-Vcs-git: git://anonscm.debian.org/users/derevko-guest/aspell-it.git
+Vcs-Git: git://anonscm.debian.org/users/derevko-guest/aspell-it.git
for the benefit of Emacs colorizer.
-Depends: aspell (= 0.60.3-3), ${misc:Depends}, ${aspell:Depends}
+Depends: ${misc:Depends}, ${aspell:Depends}
current installdeb-aspell ${aspell:Depends} sets plain aspell as
dependency. Since oldstable aspell is 0.60.6-4, plain aspell should be
enough, as Andreas suggested. If for some reason an explicit minimal
aspell version is needed it would indeed need to be added, but I do
not think is the case.
I've just uploaded a new version of the example package to mentors
(location's the same).
Changes are the suggested ones above: B-D only on unversioned aspell,
s/Vcs-git/Vcs-Git, removing aspell dependency in binary package.
By the way, dictionaries-common-dev 1.23.3 is already in the archive.
A new 1.23.4 will be uploaded soon with some changes regarding
emacsen-common dependency, but it will not affect aspell-simple.
Ok.
PS: should we request a transition tracker at some point?
I wonder how many plain aspell dicts will benefit of this. Have to
look at this when I have time.
Regards,
I think I've already collected this information. (However, this might be
inaccurate in details as the context was a little different when I
assembled this information. The focus was at that time if it has the
hashfile symlinked. )
Then likely those packages would benefit from dh_aspell-simple:
aspell-br
aspell-cs
aspell-cy
aspell-el
aspell-en
aspell-fr
aspell-ga
aspell-gu
aspell-hi
aspell-hr
aspell-hsb
aspell-hu
aspell-is
aspell-it
aspell-kk
aspell-kn
aspell-ml
aspell-mr
aspell-or
aspell-pa
aspell-pl
aspell-sk
aspell-sl
aspell-ta
aspell-te
aspell-uz
aspell-ro
aspell-sv
aspell-tl
signature.asc
Description: This is a digitally signed message part
Bug#737515: [Fwd: aspell-it uploaded to mentors.debian.net]
Hi Agustin, Just prepared aspell-it for the NMU. (just adding dch entry to close #638424) Do you want to sponsor the upload and put it into DELAY/15? Here's the link to m.d.n: http://mentors.debian.net/debian/pool/main/a/aspell-it/aspell-it_2.4-20070901-0-2.1.dsc Thanks! -- tobi signature.asc Description: This is a digitally signed message part
Bug#754663: rdfind: did not understand option 1:-dryrun
Package: rdfind Version: 1.3.1-1 Severity: normal Dear Maintainer, The manpage and rdfind --help says that it understands -dryrun. However, it seems it does not: #rdfind -dryrun did not understand option 1:-dryrun #rdfind -n did not understand option 1:-n #rdfind -n . expected true or false, not . Found in wheezy (1.3.1-1) and also in sid (1.3.4-2). -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rdfind depends on: ii libc6 2.19-5 ii libgcc1 1:4.9.0-7 ii libnettle4 2.7.1-2+b1 ii libstdc++6 4.9.0-7 rdfind recommends no packages. rdfind suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750433: Bug#750439: RFS: argtable2/12-1+cfg.1 [NMU]
Control: tags -1 +moreinfo Hallo Chen, Thanks for your contributions to Debian. As Jakub already indicated in #750419, you need to ensure using the appropiate versioning for NMUs. It looks like that your NMUs generally do not close any bugs, however a NMU should always target (important) bugs in the BTS. Some of the bugs your appearantly targeting are not of important and release critical severity. Therefore you should first contact the maintainer (e.g. via the BTS by sumitting patches to the bugs and ask for an upload) before going for an NMU. I suggest you to read https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu and then reupload the packages to mentors after following the procedures laid out there (I'm tagging the bugs moreinfo because of this) Again, thanks for your contributions :) -- Tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753013: ITP: cppdb -- SQL Connectivity Library
Package: wnpp Followup-For: Bug #753013 Packing repository will be here: https://gitorious.org/cppdb-debian/cppdb-debian/source -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752696: ITP/RFA soci -- C++ database access library
Package: wnpp Followup-For: Bug #752696 Owner: Tobias Frost t...@coldtobi.de Originally I intended to package soci as I planned to utilize it in solarpowerlog. However as soci was not a perfect match for my needs, I'm now using antother library, cppdb (#753013). So if anyone wants/need/... to take over, just do it. You can grab my packaging repository here: https://gitorious.org/soci-debian/soci-debian/ -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740507: [wnpp] ITA log4cxx
Package: wnpp Control: retitle -1 ITA: log4cxx -- A logging library for C++ Control: owner -1 ! I'm intending to adopt the package as it is a r-depends of one of my packages. (However, I assume that this endavour will take a little longer until ready, please feel free to nevertheless make QA uploads in the meantime) -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740507:
Actually got further than expected, current status is here: https://gitorious.org/log4cxx-debian -- Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741637:
Hi Olly, I've asked in #debian-ftp to avoid me raising libxapian22's priority and then discovering they'd prefer to demote aptitude instead. Cheers, Olly thanks for feedback. I'm not clear about your chatt.. ftpmaster sees that as a bug in aptitude and likes to demote aptidue from *required* to *optional*? If so, please free to reassign it to aptitude. (and keeping serious as it affects a must clause of the policy) Please let me know, as there are also two other prioity violations induced by aptitude; to help me coordinate. Thanks! -- Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741637: libxapian22: Please raise package priority to important
Control: -1 affects aptitude Control: 741635 affects aptitude (sorry, hitted send accidentially; I just wanted to comment my view on the policy.) While this certainly needs addressing, and I'm fine with changing libxapian22 if that's what if preferred, policy doesn't appear to justify filing this as RC in libxapian22 - [aptitude] must not depend on packages with lower priority values would justify this being RC in aptitude, but not in the dependent package(s). Well, I read the second sentence of the policy that way that it also can be applied to the dependent packages, that the policy don't care which prioirties are changes, unless one of the priorities will be changed. And that implies to me that this bug can be also on the dependent package, and why should be severity different then? -- Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741635:
Control: severity -1 important Hi, Just a note that in the other bug I filed regarding the priority (#741637) the maintainer got the feedback to demote aptitude instead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742322:
PS: Can't reboot by normal means: LANG=C reboot Failed to open /dev/initctl: No such device or address Failed to talk to init daemon. current systemd status: ps x | grep systemd 1 ?Ss 0:06 /lib/systemd/systemd --system --deserialize 17 558 pts/0S+ 0:00 grep systemd 6545 ?Ss 0:00 /lib/systemd/systemd-udevd 6577 ?Ss 0:00 /lib/systemd/systemd-journald 6583 ?Ss 0:00 /lib/systemd/systemd-logind 20611 ?S 0:00 systemd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742322:
Update: After rebooting using Magic SysReq, system boots and apt-get install -f completes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742322: (no subject)
Can't reproduce by downgrading and re-upgrading. Stopping here putting effort into systemd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747816: Review openalpr
Hallo Stefan, as promised some weeks ago, here's your review :) Here's an (unordered) list of thing I found during checking your package. Maybe you want to check them if they are valid and correct them? I just saw that the ITP is not owned by you. Did you coordinate with the one filing the ITP? (If so, you should document it there, if not you should ask Matt Hill if he intends to to the packaging or not... The bug's text is not clear here.) - Upstream released in the meantime 1.1.1 ... Can you update your package to the latest version? - The tarball does not match the upstream tarball. 7585916d11fef3ea88bba3249e839524 ../openalpr_1.1.0.orig.tar.gz d1446343788a52514e78afd33b73fe66 /home/tobi/Downloads/openalpr-1.1.0.tar.gz (Did you directly pull from the repository -- as there was a .git directory in it?) - d/README.source -- I think you don't need this file, let it go... :) - d/patches/* -- please add a dep3 header; does it make sense to send the patch upstream? - d/control -- as you are building a library I miss somehow a -dev package... Also the package description of the binary package openalpr needs to explain a little better what this package is for. Currently it only describes the libary, not the tool(s) you could find in the package. - d/copyright is incomplete and should be of the machine-readable debian/copyright file format (dep5) (licensecheck and /usr/lib/cdbs/licensecheck2dep5 can help you here, but you need anyway to check every file.. - any reason not to enable multiarch for the lib? - when building you should instruct cmake to be verbose (e.g show the complete gcc commandline... (I think you just need to make VERBOSE=1) in d/rules) - the package does not build in a pdebuilder enviorment (chrpath not found; missing B-D?) Is chrpath really needed? - symbol files for c++ libraries are IMHO a little bit fragile and after installing chrpath it failed here. So you need to work on those or drop the symbol file for this moment) - you manually have a lots of manually added library dependencies on the binary packge --- are they needed? Shouldn't be shlibs:depends enough find the needed dependencies? nitpicks: - d/* -- I suggest to use wrap-and-sort to sort e.g the dependencies. - d/control -- there are some trailing white-spaces you should remove (wrap-and-sort will do it for you) - There are many could avoid a useless dependency warnings... Can you check if a --as-needed linker option would work? Ok, thats it for now. Thanks for working on the package, it's looks like a quite tricky package to do :) -- tobi signature.asc Description: This is a digitally signed message part
Bug#753013: ITP: cppdb -- SQL Connectivity Library
Package: wnpp Tags: -1 pending Followup-For: Bug #753013 Owner: Tobias Frost t...@debian.org cppdb is now in NEW. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745525: Please migrate to lcms2
Source: libmng Followup-For: Bug #745525 Control: block -1 755287 Triaging this, the new upstream version 2.0.0 seems to have a configure switch to enable lcms2. -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755287: src:libmng: Please upload new version
Dear Kartik,
I've prepared a package for the new libmng upstream version 2.0.2.
Please see attached diff (ONLY the debian directory given.)
NOTE: The diff is against 1.0.10-3, not against the NMU
I just uploaded to DELAYED/5
As the soname changes, the target is experimental to prepare for an
transition.
Thanks for considering an upload of the new version.
--
Tobi
diff -Naur libmng-1.0.10/debian/changelog libmng-2.0.2/debian/changelog
--- libmng-1.0.10/debian/changelog 2011-09-16 15:41:19.0 +
+++ libmng-2.0.2/debian/changelog 2014-08-03 10:57:34.784522541 +
@@ -1,3 +1,17 @@
+libmng (2.0.2+dfsg-0.1) experimental; urgency=medium
+
+ * Non-maintainer upload.
+ * New upstream release (Closes: #755287)
+ * Uploading to experimental as the soname has changed and will require a
+transistion.
+ * Repack tarball using Exclude-Files in d/copyright to remove non-free
+file contrib/msvc/mngview/sRGB.icm (Closes: #699304).
+ * While on it, also remove config.log and config.status from the upstream
+tarball to avoid 2 lintian warnings.
+ * Build against lcms2 (Closes: #745525)
+
+ -- Tobias Frost t...@debian.org Sun, 03 Aug 2014 10:33:44 +
+
libmng (1.0.10-3) unstable; urgency=low
* debian/control:
diff -Naur libmng-1.0.10/debian/control libmng-2.0.2/debian/control
--- libmng-1.0.10/debian/control 2011-09-16 16:18:21.0 +
+++ libmng-2.0.2/debian/control 2014-08-03 08:29:38.598695659 +
@@ -3,14 +3,14 @@
Priority: optional
Build-Depends: debhelper (= 8.1.3),
libjpeg-dev,
- liblcms1-dev,
+ liblcms2-dev,
libtool,
zlib1g-dev
Maintainer: Kartik Mistry kar...@debian.org
Homepage: http://www.libmng.com
Standards-Version: 3.9.2
-Package: libmng1
+Package: libmng2
Architecture: any
Multi-Arch: same
Replaces: libmng-dev ( 1.0.0-3), libmng
@@ -29,9 +29,9 @@
Section: libdevel
Replaces: libmng
Depends: ${misc:Depends},
- libmng1 (= ${binary:Version}),
+ libmng2 (= ${binary:Version}),
libjpeg-dev,
- liblcms1-dev,
+ liblcms2-dev,
zlib1g-dev
Description: M-N-G library (Development headers)
The libmng library supports decoding, displaying, encoding, and various other
diff -Naur libmng-1.0.10/debian/copyright libmng-2.0.2/debian/copyright
--- libmng-1.0.10/debian/copyright 2011-09-16 15:22:20.0 +
+++ libmng-2.0.2/debian/copyright 2014-08-03 10:14:51.910560307 +
@@ -1,6 +1,7 @@
-Format: http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=filerev=174
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: libmng
Source: http://www.libmng.com
+Files-Excluded: contrib/msvc/mngview/sRGB.icm config.log config.status
Files: *
Copyright: (C) 2000, Gerard Juyn ger...@libmng.com
diff -Naur libmng-1.0.10/debian/libmng1.docs libmng-2.0.2/debian/libmng1.docs
--- libmng-1.0.10/debian/libmng1.docs 2010-06-02 06:21:00.0 +
+++ libmng-2.0.2/debian/libmng1.docs 1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-README
diff -Naur libmng-1.0.10/debian/libmng1.install libmng-2.0.2/debian/libmng1.install
--- libmng-1.0.10/debian/libmng1.install 2011-08-14 04:19:35.0 +
+++ libmng-2.0.2/debian/libmng1.install 1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/*.so.*
diff -Naur libmng-1.0.10/debian/libmng2.docs libmng-2.0.2/debian/libmng2.docs
--- libmng-1.0.10/debian/libmng2.docs 1970-01-01 00:00:00.0 +
+++ libmng-2.0.2/debian/libmng2.docs 2010-06-02 06:21:00.0 +
@@ -0,0 +1 @@
+README
diff -Naur libmng-1.0.10/debian/libmng2.install libmng-2.0.2/debian/libmng2.install
--- libmng-1.0.10/debian/libmng2.install 1970-01-01 00:00:00.0 +
+++ libmng-2.0.2/debian/libmng2.install 2011-08-14 04:19:35.0 +
@@ -0,0 +1 @@
+usr/lib/*/*.so.*
diff -Naur libmng-1.0.10/debian/patches/linux-makefile.diff libmng-2.0.2/debian/patches/linux-makefile.diff
--- libmng-1.0.10/debian/patches/linux-makefile.diff 2010-06-12 09:26:36.0 +
+++ libmng-2.0.2/debian/patches/linux-makefile.diff 2014-08-03 07:55:40.861723685 +
@@ -1,62 +1,12 @@
Description: Fix for Linux's makefile for 1.0.10
Author: Kartik Mistry kar...@debian.org
Forwarded: https://sourceforge.net/tracker/?func=detailaid=3015139group_id=5635atid=105635
-Last-Update: 2010-06-12
+Comment: (Tobias Frost) Original version forwarded, upstream 90% applied it. Residual's here.
+Last-Update: 2014-08-03
libmng-1.0.10.orig/makefiles/makefile.linux
-+++ libmng-1.0.10/makefiles/makefile.linux
-@@ -14,25 +14,25 @@ CC=gcc
- OPTIONS = -DMNG_BUILD_SO -DMNG_FULL_CMS
-
- # where make install puts libmng.a,libmng.so*,libmng.h,libmng_conf.h,libmng_types.h
--prefix=/usr/local
-+prefix=/usr
-
- # Where the zlib library and include files are located
- #ZLIBLIB=../zlib
- #ZLIBINC=../zlib
--ZLIBLIB=/usr/local/lib
--ZLIBINC=/usr/local/include
-+ZLIBLIB=/usr/lib
-+ZLIBINC=/usr
Bug#745530: Please migrate to lcms2
Package: cegui-mk2 Followup-For: Bug #745530 Dear Maintainer, While triaging lcms-related bugs I saw that cegui-mk2 does not actually use lcms: If built in a pdebuilder environment with and without lcms entered as B-D the binary result byte-identical. Same also when additionally dropping libmng-dev, which would also pull in lcms. Therefore I assume that it is safe to drop B-D on liblcms and libmng. I will schedule an NMU later. -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742749:
Reopening, as there is no watch file in the latest upload... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756042: RFS: sandboxgamemaker/2.8.2+dfsg-1 [ITA][RC]
On Sun, 2014-08-03 at 23:07 -0300, Eriberto wrote: Hi! I am confuse... Is ok to revision and upload the current package in mentors? Thanks! Eriberto Sure, you can always upload to mentors. You don't even have to delete it from mentors beforehand. (Just make sure to keep the Debian revision-string, don't increment it.) -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757172: Spurious build dep on libmng
On 6. August 2014 00:01:48 MESZ, Moritz Muehlenhoff j...@debian.org wrote: Source: cegui-mk2 Severity: normal Hi, your package build-depends on libmng, bug apparently it doesn't link against/use libmng. Please double-check and remove the stray build dep. Cheers, Moritz Control: tags -1 +pending Hi Moritz, my NMU due to enter the archives in a few days is already targeting this. -- tobi -- Tobias Frost 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7
Bug#757243: RFS: qmapshack/0.2.0+ds1-1
Control: tags -1 moreinfo On Wed, 2014-08-06 at 17:11 +0200, Jaromír Mikeš wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package qmapshack * Package name: qmapshack Version : 0.2.0+ds1-1 Upstream Author : Oliver Eichler oliver.eich...@gmx.de * URL : https://bitbucket.org/maproom/qmapshack/wiki/Home * License : GPL-3+ Section : science A. It builds those binary packages: qmapshack - GPS mapping (GeoTiff and vector) and GPSr management To access further information about this package, please visit the following URL: http://mentors.debian.net/package/qmapshack Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/q/qmapshack/qmapshack_0.2.0+ds1-1.dsc More information about hello can be obtained from http://www.example.com. Regards, Jaromír Mikeš Hi Mikeš, Thanks for packaging... However, I found a few things - d/copyright is incomplete, there are at least 2 files not documented for the 3rdParty folder. (CGetOpt.cpp and main.cpp) (The html file in this dir is obviously generated by doxygen), the examples gpx are also not in the copyright file. There are two animated gifs in src/animated, which are Loading indicators are from: http://ajaxload.info/; (README in the file) The site says The gifs are totally free to use .. This unfortunatly does satisfy the DFSG rules, as for example the permissions for modifying, distribution are not included. (So maybe contact the ownder of ajaxload.info, because I assume that they are just not aware of the fine details of copyright law) Also there are three png without source in cursors .. one of the files refer to a Eric (string in file), so also here upstream needs to clearify copyright situation. (A image search on the net indicates that this cursors are public domain.. http://www.rw-designer.com/cursor-set/proton) in src/icons/cache/COPYRIGHT I read All icons in this directory are from the Open Cache Manager project http://opencachemanage.sourceforge.net/; Checking that site tells me that that project has released files under Apache 2.0 Stopping here on checking copyright; you need to work through it again and probably also ask upstream to take a little bit more care to more carefully document licenses... The manpage is basically empty. Please extent it (and submit it upstream.) Nitpicks: As you are already repacking, - you could also remove all the pre-generated icons (as you should regenerate them at build-time from the svgs :)) - you could e.g xz as compression method, instead of gz. The other files in debian/ just need a wrap-and-sort run over it :) Can you check if the override of the autoinstall target could be done with an d/install file? -- tobi signature.asc Description: This is a digitally signed message part
Bug#752897: rm -rf debian/tmp/usr/share/doc/lucene++-3.0.6/
On Fri, 2014-08-29 at 08:23 +0100, Gianfranco Costamagna wrote: Hi Tobias, sorry for top posting, I'm on vac and mobile :-) The reason for the VCS not created is that I'm not yet in the ubuntu unity team, so I don't have write permissions to create it :-) I'll talk to sil how does he feel about maintaining in collab-maint/git! As you can see I'm a proud git and git-buildpackage user, so I'll benefit a lot from the git usage :-) In the meanwhile feel free to drop them, the new upstream release I think will come shortly (basically I got accepted all my patches and I think we have testsuite working on git right now, I tested it a little bit). So we can add CVS in the second upload, I'll also try to use the system gconv rather than the (working) embedded one! Have many thanks for your time! Gianfranco Sent from Yahoo Mail on Android Hi Gianfranco, Yes, collab-maint would be indeed the best option and can be done after the initial upload. So just remove VCS-* for now and re-add once you've decided how to go on. Back to the package. Sorry, took me longer than expected to take deeper look, but the review should be complete now. So I think this will be the last iteration... During the review of d/copyright I found those mismatches which might need clarification: - ./src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp ./src/contrib/analyzers/common/analysis/fa/PersianAnalyzer.cpp seems to be generated from BSD Data. Not sure how they have been generated and what is the effective license is indeed tricky. Can you check with upstream how the data is processed and if that is enough to constitute a new copyright? (However, It would be best if the files could be autogenerated at build time and the stoplist file distributed with the tarball.) For now, I'd recommend to add an comment to d/copyright stating that the file has been created using BSD-Licensed data from http://... - ./src/contrib/snowball/libstemmer_c/* is missing in d/copyright and it is (as far as can see) an embedded code copy. (Debian source package snowball). As convenience copies are strongly discouraged, please try to patch lucene so it will link against the package version. (If you find out, this is not feasible, please let me know along with your reasoning) So, this seems now to be the last two points to be fixed. Then I'll upload it :) -- tobi signature.asc Description: This is a digitally signed message part
Bug#732723:
Control: Tags -1 fixed-upstream This bug could be fixed by packaging upstream version 0.8.3 or later [1] -- tobi [1] http://cegui.org.uk/download/cegui-083 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748591:
Hi Philip, while browsing open RFS bugs I saw that yours is done, but the package still marked needs sponsor. Please toggle that setting to no Thanks! -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751009:
Hi Nigel, (I do not intend to sponsor this package, sorry.) I had a few minutes, so here is a very short review (for sure not complete:) You are also upstream, aren't you? Then I suggest reading https://wiki.debian.org/UpstreamGuide (So you should for example consider removing the debian directory from your repository; it will be hard for you to keep that in sync... :)) d/changelog: for a new package its only Initial release (Closes #xx); delete the rest. There's should be an empty line between the header line and the entries Hint: Use dch(1) to create your d/changelog, don't do it manually You need to remove your logfiles when the package is purged. (using a postrm script) See policy 10.8 There is a linitian problem with the long description, refer also to policy 3.4.1 d/rules I'd suggest not to override targets if there are other means, like d/clean instead of override_dh_autoclean AUTHORS and TODO needs not to be installed in the binary package, as it does not contain information useful to the user. Thanks! -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758232:
Hi Willem, here's a short review; I do not intend to sponsor this package. You are also upstream, aren't you? Then I suggest reading https://wiki.debian.org/UpstreamGuide (I always write that; However, I did not spot any common errors :)) Reviewing the pacakge (unordered list) - You need to file an ITP bug - When you upload a package for the first time to Debian, the only changelog entry is Intial Release (Closes #your-itp-bug) - (The Debian-part of the package-version is then also -1 ) - d/rules --with-quilt is not needed. See man dh_quilt_patch - d/watch does not work. - Please remove the boilerplate-text (line2-7 from d/rules - If possible, move lyx to Build-Depends-Indep as it is only needed for buiding arch:all doc pacakage. This saves severval indirect B-Ds... -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752897: rm -rf debian/tmp/usr/share/doc/lucene++-3.0.6/
Hi Tobias Hi Gianfranco, Yes, collab-maint would be indeed the best option and can be done after the initial upload. So just remove VCS-* for now and re-add once you've decided how to go on. Removed Back to the package. Sorry, took me longer than expected to take deeper look, but the review should be complete now. So I think this will be the last iteration... During the review of d/copyright I found those mismatches which might need clarification: - ./src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp ./src/contrib/analyzers/common/analysis/fa/PersianAnalyzer.cpp seems to be generated from BSD Data. Not sure how they have been generated and what is the effective license is indeed tricky. Can you check with upstream how the data is processed and if that is enough to constitute a new copyright? (However, It would be best if the files could be autogenerated at build time and the stoplist file distributed with the tarball.) For now, I'd recommend to add an comment to d/copyright stating that the file has been created using BSD-Licensed data from http://... https://github.com/luceneplusplus/LucenePlusPlus/issues/70 - ./src/contrib/snowball/libstemmer_c/* is missing in d/copyright and it is (as far as can see) an embedded code copy. (Debian source package snowball). As convenience copies are strongly discouraged, please try to patch lucene so it will link against the package version. (If you find out, this is not feasible, please let me know along with your reasoning) https://github.com/luceneplusplus/LucenePlusPlus/issues/71 So, this seems now to be the last two points to be fixed. Then I'll upload it :) thanks again, I opened the two above upstream issues, because the problem is not debian-specific and I'm not in the position of force a system library when a custom delta might be needed (and moreover I don't see it used, as I wrote on the issue). So I'll update as soon as I get upstream feedbacks! Great. Regarding the issue 70 (let me quote it by the issue number), as said it would be ok for me just to comment the fact in d/copyright (and in a later upload act according upstream's decission). Regarding 71, if you are sure that it won't be used, just use a debian-specific patch to remove it. Regarding the submitted issue upstream, please note that according to the package libstemmer Snowball upstream doesn't build shared libraries, so they are Debian-specific. We can wait for upstreams' reaction, but we can also go on; just decide and let me know. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758266: RFS: air-quality-sensor/0.1.1-3 [ITP]
Control: owner -1 ! Control: tags -1 +pending Hallo Benedikt, here's a review: - Package does not build, misses at least a B-D on libusb-1.0-0-dev and pkg-config - as the manpage is created using help2man, you should regenerate it during build - you do not need to set a link from the debian manpage, but you can directly install the manpage. (See 5.16 of the new maintainers' guide) - You should dh_autoreconf instead of autotools-dev (as you also use automake), see https://wiki.debian.org/Autoreconf#Using_autotools-dev - d/changelog Debian version starts at -1 for new packages, and state only Initial Release (Closes #ITP-Bug) - please use spaces for indentation in d/copyright - same for postinst - don't install README -- is has no additional information and only duplicates the package description - you need to depend on adduser in your binary pacakge. (The review might be incomplete as I have to stop now; please fix the above and re-upload to mentors, then give me a ping -- tobi On Thu, 2014-08-28 at 23:36 +0200, Benedikt Wildenhain wrote: Hi Baird, On Thu, Aug 28, 2014 at 09:19:26AM +1000, Riley Baird wrote: Indoor Air Monitor, so I can't test it. However, looking over your package, afaict everything is fine, except you should remove the unnecessary comments in d/rules and d/watch. thanks for the hint, I fixed that. Kind regards, Benedikt Wildenhain signature.asc Description: This is a digitally signed message part
Bug#752897: rm -rf debian/tmp/usr/share/doc/lucene++-3.0.6/
On Tue, 2014-09-02 at 11:01 +0100, Gianfranco Costamagna wrote:
Il Lunedì 1 Settembre 2014 15:42, Tobias Frost t...@frost.de ha scritto:
Hi Tobias
Hi Gianfranco,
Yes, collab-maint would be indeed the best option and can be done after
the initial upload. So just remove VCS-* for now and re-add once
you've
decided how to go on.
Removed
Back to the package. Sorry, took me longer than expected to take deeper
look, but the review should be complete now. So I think this will be
the
last iteration...
During the review of d/copyright I found those mismatches which might
need clarification:
- ./src/contrib/analyzers/common/analysis/ar/ArabicAnalyzer.cpp
./src/contrib/analyzers/common/analysis/fa/PersianAnalyzer.cpp
seems to be generated from BSD Data. Not sure how they have been
generated and what is the effective license is indeed tricky. Can you
check with upstream how the data is processed and if that is enough to
constitute a new copyright? (However, It would be best if the files
could be autogenerated at build time and the stoplist file distributed
with the tarball.)
For now, I'd recommend to add an comment to d/copyright stating
that the
file has been created using BSD-Licensed data from http://...
https://github.com/luceneplusplus/LucenePlusPlus/issues/70
- ./src/contrib/snowball/libstemmer_c/* is missing in d/copyright
and
it is (as far as can see) an embedded code copy. (Debian source package
snowball). As convenience copies are strongly discouraged, please try
to
patch lucene so it will link against the package version.
(If you find out, this is not feasible, please let me know along with
your reasoning)
https://github.com/luceneplusplus/LucenePlusPlus/issues/71
So, this seems now to be the last two points to be fixed. Then I'll
upload it :)
thanks again, I opened the two above upstream issues, because the problem
is not debian-specific and I'm not in the position of force a system
library
when a custom delta might be needed (and moreover I don't see it used,
as
I wrote on the issue).
So I'll update as soon as I get upstream feedbacks!
Hi again Tobias
Great. Regarding the issue 70 (let me quote it by the issue number), as said
it would be ok for me just to comment the fact in d/copyright (and in a
later
upload act according upstream's decission).
Wonderful, updated
Regarding 71, if you are sure that it won't be used, just use a
debian-specific patch to remove it.
Regarding the submitted issue upstream, please note that according to the
package libstemmer Snowball upstream doesn't build shared libraries,
so they
are Debian-specific.
yes, for the moment I disabled them, I think nobody will complain since the
package is a newly packaged one in debian.
With the next upload we can enable the debian version safely (if upstream
agrees) :)
We can wait for upstreams' reaction, but we can also go on; just decide and
let me know.
Would be nice to go on, in this way ftpmaster can look at the package, since
the freeze is approaching ;)
As soon as the package is accepted I'll take care of ask for a new release,
fixing all this kind of doubts here :)
many thanks again
diff -Nru lucene++-3.0.6/debian/changelog lucene++-3.0.6/debian/changelog
--- lucene++-3.0.6/debian/changelog2014-08-26 12:49:11.0 +0200
+++ lucene++-3.0.6/debian/changelog2014-09-01 12:28:56.0 +0200
@@ -1,10 +1,3 @@
-lucene++ (3.0.6-2) unstable; urgency=medium
-
- * Update copyright file.
- * move doxygen to Build-Depends-Indep.
-
- -- Gianfranco Costamagna costamagnagianfra...@yahoo.it Tue, 26 Aug 2014
11:36:24 +0200
-
lucene++ (3.0.6-1) unstable; urgency=low
* Initial release (Closes: #750148).
diff -Nru lucene++-3.0.6/debian/control lucene++-3.0.6/debian/control
--- lucene++-3.0.6/debian/control2014-08-26 11:36:18.0 +0200
+++ lucene++-3.0.6/debian/control2014-09-01 12:31:42.0 +0200
@@ -17,8 +17,6 @@
Standards-Version: 3.9.5
Section: libs
Homepage: https://github.com/luceneplusplus/LucenePlusPlus
-Vcs-Bzr: https://code.launchpad.net/~ubuntu-unity/lucene++/debian
-Vcs-Browser: http://bazaar.launchpad.net/~ubuntu-unity/lucene++/debian/files
Package: liblucene++-dev
Section: libdevel
diff -Nru lucene++-3.0.6/debian/copyright lucene++-3.0.6/debian/copyright
--- lucene++-3.0.6/debian/copyright2014-08-26 13:01:05.0 +0200
+++ lucene++-3.0.6/debian/copyright2014-09-02 11:33:24.0 +0200
@@ -10,6 +10,16 @@
Copyright: 1999, 2000, 2002 Aladdin Enterprises
License: zlib
+Files:
src/contrib/analyzers/common/analysis/{ar/ArabicAnalyzer.cpp,fa/PersianAnalyzer.cpp}
+Copyright: 2009-2014 Alan Wright
+License: Apache-2.0 or LGPL-3+
+Comment: Generated from http://members.unine.ch
Bug#760352: gnome-shell-extension-brightness-control: Not suitable for jessie
Package: gnome-shell-extension-brightness-control Severity: serious this extension is not working under gnome = 3.12 and as this version of gnome is going into jessie this extension should not. (Also gnome 3.12 has basically this extension built-in; so upstream already said some time ago it will not fix this) I will request removal of the package soon. -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760453: RFS: amap/5.4+dfsg-1
Control: owner -1 t...@debian.org Control: tags -1 +pending +moreinfo Control: block 753704 by -1 Hi Gianfranco, Well, amap has been previously been removed from Debian due to licesnse reasons. (Please see #346313) You write in #753704 that is no longer is the case -- I just saw that LICENSE.AMAP is still there without any further digging; can you briefly update me? Otherwise, would be non-free possible (I need to think about it -- its complex topic -- if an upload to non-free could be possible instead license-wise) Upstream also writes that amap is depreciated in favour of nmap... Do you have any specific *why* wee still should have it in Debian, this question is not to torture, but this question could come up from other parties. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760453: RFS: amap/5.4+dfsg-1
On Thu, 2014-09-04 at 14:36 +0100, Gianfranco Costamagna wrote: Hi Gianfranco, Well, amap has been previously been removed from Debian due to licesnse reasons. (Please see #346313) You write in #753704 that is no longer is the case -- I just saw that LICENSE.AMAP is still there without any further digging; can you briefly update me? Hi Tobias, In #346313 the developer says: hmmm so basically I need to edit the LICENSE.GNU file to remove the license name as well as to remove the no further restrictions paragraph from it? ok, I will do that then for the next release ... Seems that the developer didn't do this, but in the source files (headers) you can see the license is GPL, and the LICENSE.GNU is almost the same as the one in usr/share/common-licenses. So IANAL, but we can just refer to the GPL-2 license, because the other one is not actually used? Well, the presence of the LICENSE.AMAP file and stating that this is the LICENCE FOR AMAP (all version) brings some doubt that GPL-2 (or GPL-2+ as in the souce) is the effective license; it could be GPL-2 witorth AMAP Restrictions (lets look at those below) and that would be indeed I just checked debsnap olds version (doing just a lazy gbp import-dscs --debsnap amap) and compared it to the current source: The license headers in the *.(c|h) has not been changed since. (So I fear that we cannot say it's GPL without a clear statement from upstream.) Unfortunatly, LICENSE.AMAP is not dfsg-free: For example, it fails The Desert Island test (must be made available to the author free of charge). and maybe The Dissident Test (enforcing that commercial use say that it uses the programm; 4. and 5. of the license. [1] (The special requirements for use in commercial fields are non-free as well, DFSG §5) Licenses' §2 except for a small transfer/medium fee is non-free (see 12j and 21 in [1]) Licenses' §3 is clearly non free (DFSG §6); refer to the famous JSON Licsense Must used for good not evil (see also (BTW, License 6 is a contradition to the source -- the source says GPL-2+ while §6 says only GPL-2) [1] https://people.debian.org/~bap/dfsg-faq.html So its non-free... Unless the authors relicenses in a way that LICENSE.AMAP is not applicavble anymore. Trickier is to evaluate if the AMAP and the GPL are compatible, because if not the whole would be not even distributeable. (GPL §7) So my concerns are GPL §6 -- You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Is herein the complete license or just the GPL part? I think I read somewhere (couldn't find the source now) the latter, and then it would become not distributeable at all I absolutely not sure on the above -- this question should be directed to debian-legal... (If I'd be right, amap would not even suitable for non-free) Otherwise, would be non-free possible (I need to think about it -- its complex topic -- if an upload to non-free could be possible instead license-wise) I don't know about this, I still don't understand this kind of licenses war (I mean, I understand them but I don't like them) ;) Yes, copyright/licenses are hard, tedious and boring, but unfortunatly it is very important to be accurate here, as these might create legal risks for the project. Upstream also writes that amap is depreciated in favour of nmap... Do you have any specific *why* wee still should have it in Debian, this question is not to torture, but this question could come up from other parties. some tools (e.g. openvas) uses it, moreover for some specific applications should perform better than nmap. So today, I recommend to rather use nmap -sV for application fingerprinting rather than amap (although in some circumstances amap will yield better results, but these are rare). Currently there are two tools for this purpose: amap (you are looking at it), and nmap (www.insecure.org/nmap). Both have their strength and weaknesses, as they deploy different techniques. We recommend to use both tools for reliabe identification. I know some penetration testing distros uses it, but I don't know how better performs than nmap, so maybe we can just leave it go. Ok, it seems that for (the niche of) pentesting this program could be interesting in addtion to nmap. (I think the website says that amap can do IPV6, but nmap not -- I don't know if this is real or just old information) -- tobi signature.asc Description: This is a digitally signed message part
Bug#760453: RFS: amap/5.4+dfsg-1
On 5. September 2014 10:14:56 MESZ, Gianfranco Costamagna costamagnagianfra...@yahoo.it wrote: Hi Tobias, Il Venerdì 5 Settembre 2014 8:46, Tobias Frost t...@debian.org ha scritto: On Thu, 2014-09-04 at 14:36 +0100, Gianfranco Costamagna wrote: Hi Gianfranco, Well, amap has been previously been removed from Debian due to licesnse reasons. (Please see #346313) You write in #753704 that is no longer is the case -- I just saw that LICENSE.AMAP is still there without any further digging; can you briefly update me? Hi Tobias, In #346313 the developer says: hmmm so basically I need to edit the LICENSE.GNU file to remove the license name as well as to remove the no further restrictions paragraph from it? ok, I will do that then for the next release ... Seems that the developer didn't do this, but in the source files (headers) you can see the license is GPL, and the LICENSE.GNU is almost the same as the one in usr/share/common-licenses. So IANAL, but we can just refer to the GPL-2 license, because the other one is not actually used? Well, the presence of the LICENSE.AMAP file and stating that this is the LICENCE FOR AMAP (all version) brings some doubt that GPL-2 (or GPL-2+ as in the souce) is the effective license; it could be GPL-2 witorth AMAP Restrictions (lets look at those below) and that would be indeed I just checked debsnap olds version (doing just a lazy gbp import-dscs --debsnap amap) and compared it to the current source: The license headers in the *.(c|h) has not been changed since. (So I fear that we cannot say it's GPL without a clear statement from upstream.) Unfortunatly, LICENSE.AMAP is not dfsg-free: For example, it fails The Desert Island test (must be made available to the author free of charge). and maybe The Dissident Test (enforcing that commercial use say that it uses the programm; 4. and 5. of the license. [1] (The special requirements for use in commercial fields are non-free as well, DFSG §5) Licenses' §2 except for a small transfer/medium fee is non-free (see 12j and 21 in [1]) Licenses' §3 is clearly non free (DFSG §6); refer to the famous JSON Licsense Must used for good not evil (see also (BTW, License 6 is a contradition to the source -- the source says GPL-2+ while §6 says only GPL-2) [1] https://people.debian.org/~bap/dfsg-faq.html So its non-free... Unless the authors relicenses in a way that LICENSE.AMAP is not applicavble anymore. Trickier is to evaluate if the AMAP and the GPL are compatible, because if not the whole would be not even distributeable. (GPL §7) So my concerns are GPL §6 -- You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License. Is herein the complete license or just the GPL part? I think I read somewhere (couldn't find the source now) the latter, and then it would become not distributeable at all I absolutely not sure on the above -- this question should be directed to debian-legal... (If I'd be right, amap would not even suitable for non-free) Otherwise, would be non-free possible (I need to think about it -- its complex topic -- if an upload to non-free could be possible instead license-wise) I don't know about this, I still don't understand this kind of licenses war (I mean, I understand them but I don't like them) ;) Yes, copyright/licenses are hard, tedious and boring, but unfortunatly it is very important to be accurate here, as these might create legal risks for the project. Upstream also writes that amap is depreciated in favour of nmap... Do you have any specific *why* wee still should have it in Debian, this question is not to torture, but this question could come up from other parties. some tools (e.g. openvas) uses it, moreover for some specific applications should perform better than nmap. So today, I recommend to rather use nmap -sV for application fingerprinting rather than amap (although in some circumstances amap will yield better results, but these are rare). Currently there are two tools for this purpose: amap (you are looking at it), and nmap (www.insecure.org/nmap). Both have their strength and weaknesses, as they deploy different techniques. We recommend to use both tools for reliabe identification. I know some penetration testing distros uses it, but I don't know how better performs than nmap, so maybe we can just leave it go. Ok, it seems that for (the niche of) pentesting this program could be interesting in addtion to nmap. (I think the website says that amap can do IPV6, but nmap not -- I don't know if this is real or just old information) I suspect the license problem is too risky, even if upstream is *clearly* don't caring about the wrong license files (yes
Bug#760448: RFS: wapiti/2.3.0+dfsg-1 [ITA]
Control: owner -1 t...@debian.org Control: tags -1 +pending Setting BTS status to indicate that I'll take care of this RFS. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761074: RFS: cputool/0.0.7-1 [ITP]
Control: owner -1 ! Tags: pending Hi Nigel, The quality of the package is very good; I just saw a few nitpicks which I'd ask you fix before I upload it: - d/copyright - please join the lines AllWorldIT and your contact (as it does not describe a new copyright) - mind to add a Upstream-Contact Header? - Comment (line 3) is not needed, please remove it (its in d/control) - there are extra ,s after the years in line 8 and 12 - has a final blank line - d/control - I'd prefer only to override when necessary. In this case, please remove the file using d/clean. - please use dh_autoreconf Thanks for your contribution! -- tobi signature.asc Description: This is a digitally signed message part
Bug#761074: RFS: cputool/0.0.7-1 [ITP]
On Wed, 2014-09-10 at 21:01 +, Nigel Kukard wrote: Hi Nigel, even if already uploaded, you've askes two question I'd like to answer: On 09/10/2014 08:22 PM, Tobias Frost wrote: - there are extra ,s after the years in line 8 and 12 Could you clarify this for me Tobias, I must be missing something, I copied an example that Eriberto gave me here... http://metadata.ftp-master.debian.org/changelogs/main/s/sentinella/unstable_copyright The format is specified in https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field The file format gives you many freedoms, so you format actually not really wrong, but for the symmetry the , was somehow disturbing my eyes as a comma indicates somehow there is something to follow. As said, its a nitpick. - d/control - I'd prefer only to override when necessary. In this case, please remove the file using d/clean. - please use dh_autoreconf Sorted. I now have this, I hope its what you were referring to... *** $ cat rules #!/usr/bin/make -f %: dh $@ --with autoreconf *** Yes, perfect. (you've also added a B-D on dh_autoreconf, haven't you?) Thanks again for your time! -N -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761354: drizzle: not suitable for jessie
Source: drizzle Severity: serious As maintainer I just decided that drizzle should not be in Jessie: - Upstream development came to an halt (last commit 2013) - Security Team indicated that they'd prefer only one SQL Server in Jessie, which I think should not be drizzle. Therefore filing this bug to prevent drizzle going to Jessie. drizzle has no reverse B-D. -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
On 15. September 2014 12:30:51 MESZ, Dariusz Dwornikowski dariusz.dwornikow...@cs.put.poznan.pl wrote: Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package libstrophe - again. The last version was rejected because of undocumented licensing. I fixed these now, after claryfing things with FTP Masters. NOTE: the package links to OpenSSL but we choose the license to be MIT, so it is not a violation. The code is however licensed both GPL and MIT. * Package name: libstrophe Version : 0.8.6-1 Upstream Author : Jack Moffit j...@metajack.im * URL : http://strophe.im/libstrophe/ * License : MIT and GPL-3+ Section : libdevel It builds those binary packages: libstrophe-dev - Library for writing XMPP clients - development files libstrophe0 - Library for writing XMPP clients - shared library libstrophe is a minimal XMPP library written in C. It has almost no external dependencies, only an XML parsing library (expat or libxml are both supported). It is designed for both POSIX and Windows systems. I worked with libstrophe upstream past months to make it suitable for Debian. I helped them with autotools, so that shared library is built along the static one. Encouraged them to tag relases in github, and together we closed some pull requests. Libstrophe is used by profanity.im, a console XMPP client inspired by IRSSI, which I intend to pack too, this week. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libstrophe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libs/libstrophe/libstrophe_0.8.6-1.dsc Or go directly to the VCS at Alioth git: http://anonscm.debian.org/cgit/collab-maint/libstrophe.git More information about *libstrophe* can be obtained from http://strophe.im/libstrophe/. Changes since the last upload: * Initial release (Closes: #511341) Regards, -- Dariusz Dwornikowski, Institute of Computing Science, Poznań University of Technology www.cs.put.poznan.pl/ddwornikowski/ room 2.7.2 BTiCW | tel. +48 61 665 29 41 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140915103051.gd16...@blackstar.cs.put.poznan.pl Control: tags -1 pending Control: owner -1 t...@debian.org Hi Dariusz, I will take care tonight. -- tobi -- Tobias Frost 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
Control: tags -1 moreinfo pending Control: owner -1 ! Hi Dariusz, somehow the d/copyright is still not matching 100% to the code... At least for many files there is a Copyright (c) 2005-2009 Collecta, Inc which is not in d/copyright. So probably this copyright owner is missing for the * rule. Can you please fix it. Also, I'm missing see a proof for the or later option of the GPL, as it would have to be explictly stated by upstream, see GPL-3 §14. So write GPL-3 or ask upstream for clarification. (Please wrap your comment, there is also two empty lines at the end of the file and one empty line in the middle. Those are nitpicks, though) Thanks! -- Tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761687: RFS: abraca/0.8.0+dfsg-1 -- Simple and powerful graphical client for XMMS2
Hi Daniels, On Mon, 2014-09-15 at 21:07 +0100, Daniel Lintott wrote: On 15/09/14 20:49, Daniel Svensson wrote: On Mon, Sep 15, 2014 at 9:45 PM, Daniel Lintott dan...@serverb.co.uk mailto:dan...@serverb.co.uk wrote: Hi Daniel, On 15/09/14 20:13, Daniel Svensson wrote: * Add me to Maintainers since old maintainer is M.I.A. Did the MIA Team actually orphan the package, as I can't find a WNPP bug for abraca? I may be wrong, but I believe unless the package is orphaned, it's not possible to become maintainer. I may be wrong here though I'm not sure where I can see if a package is orphaned or not, but the maintainer doesn't reply to my emails and haven't updated the package even though I've provided all the changes needed to both the debian packaging and the software. I have no strong opinion in any direction on how to progress. I just want the package into testing again before the freeze and will comply with any recommendations you have to make this a smooth ride. I've just double-checked the WNPP package[1] to check for a bug for abraca... but can't see one, so it's possible it hasn't yet been orphaned. It can be frustrating when dealing with old packages and inactive maintainers. The process the MIA Team follow is laid in [2]. I'm not a DD myself, so I can't say I know the exact way to proceed... as a guess it may be worth dropping an email to the MIA Team [3] to find out what is happening. Sorry I can't be of more use Hopefully one of the DD's or more knowledgeable folk on here may have some better answers too. There are no indications that the package has been orphaned, so it likely hasn't. However, I'really appreciate the effort to bring it into testing, and your solution would be: NMU it. ;-) So prepare it as a NMU and reupload it to mentors and then ping me. (I'll take a look when I find a minute; note: I *did* not look into the package yet, so I've not decided yet if I sponsor the upload) As The MIA database is only working for DDs, and the current maintaier isn't one, one can only guess from his DDPO: the last known actvity was March 2012. So there is a indications of MIA. Yes, you really should contact the MIA team and make them aware of this possible MIA. Please send them the mails to already sent. That will help them... However, lets try another ping right now. Fabrizio: Can you please briefly reply and give an indication if you still interested in maintaining abraca. If not, just reply that it is ok to orphan. Regards Daniel [1] http://bugs.debian.org/wnpp [2] https://wiki.debian.org/qa.debian.org/MIATeam [3] https://wiki.debian.org/Teams/MIA signature.asc Description: This is a digitally signed message part
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
On Tue, 2014-09-16 at 09:07 +0200, Dariusz Dwornikowski wrote: Hi Dariusz, somehow the d/copyright is still not matching 100% to the code... At least for many files there is a Copyright (c) 2005-2009 Collecta, Inc which is not in d/copyright. So probably this copyright owner is missing for the * rule. Can you please fix it. Yes I fixed this. Also, I'm missing see a proof for the or later option of the GPL, as it would have to be explictly stated by upstream, see GPL-3 §14. So write GPL-3 or ask upstream for clarification. Fixed, yes they have GPL-3 not later. (Please wrap your comment, there is also two empty lines at the end of the file and one empty line in the middle. Those are nitpicks, though) Wrapped. We're there, almost... Last question: Do you want to change the license of debian/* also to MIT and GPL-3 (without later)? Tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#761687: RFS: abraca/0.8.0+dfsg-1 -- Simple and powerful graphical client for XMMS2
On 16. September 2014 21:24:13 MESZ, Daniel Lintott dan...@serverb.co.uk wrote: Hi Guys, On 16/09/14 07:23, Tobias Frost wrote: There are no indications that the package has been orphaned, so it likely hasn't. In case your not aware, it seems the package has now been orphaned[1] as of today (excellent work by Ricardo Mones). Regards, Daniel [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761830 Good :) So you can now adopt it officially... -- Tobias Frost 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7
Bug#761643: RFS: libstrophe/0.8.6-1 [ITP]
On 17. September 2014 12:10:32 MESZ, Dariusz Dwornikowski dariusz.dwornikow...@cs.put.poznan.pl wrote: On 16.09.14 21:13:13, Tobias Frost wrote: On Tue, 2014-09-16 at 09:07 +0200, Dariusz Dwornikowski wrote: We're there, almost... Last question: Do you want to change the license of debian/* also to MIT and GPL-3 (without later)? Fixed that and uploaded to mentors I chose GPL-3 for debian only Hi Dariusz, Well, I'd recommend against GPL only... It will make it hard for upstream to integrate patches. Let me know, if you're sure or if you have reconsidered... (This is not a blocker) However, I'll wait for your answer before uploading. -- tobi -- Tobias Frost 13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753110: Review mrrescue
tags: moreinfo Hi Steve, here's a review: - In your ITP, #707691, you write Package source uploaded to pkg-games git. but d/control has no VCS-* fields. - there are lots of trailing spaces in d/copyright, wrap-and-sort(1) should sort that. - d/copyright is incomplete. just one example: mrrescue/AnAL.lua is copyright 2009-2010 Bart Bes The website also says: All source code for Mr. Rescue with the exception of the modules slam, AnAL and TSerial, is licensed under the zlib license. Check the LICENSE file for more info. Worse, TSerial does not specify a license and the only somehow relating homepage [1] I could find does not either. Please contact upstream / author of TSerial for clearifcation. (email on [1]) PS: I just saw you did already... Please share the response with me and it the email to d/copyright as a Comment. d/mrrescue.1 the manpage is still section 1, not 6 the options section needs some tweaking: mrrsecue doesn't take args itself, but the script passes them to love(1). However, love(1) does not take args... So maybe this section should go? (Can you please explain why you pass the args to love?) I would write as the short explanation 2d arcarde action game instead of platformer built in love, as the latter gives no inportant information for the end user. d/rules please don't override targets when not really needed. - remove mrresuce.love via d/clean - at least here, there is no build_dir after build, a stripped down d/control works here. Please fix the above and give me a ping when ready. Please don't forget to send also a copy of the license-email. [1] https://love2d.org/wiki/Tserial -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759688: ufoai
Control: owner -1 ! Control: tags -1 pending I'll try to review these packages over the weekend. (the package looks huge :) (First thing that I saw -- but I don't know how's the best practice in pkg-games, so maybe this is more a question to the list: There is only one ITP filed, but three source packages (ufoai, -data, -maps and -music)? Should the ITP be cloned (and blocking each other) to be able to close a ITP or is it fine to ignore/override the lintian?) I'll probably also clone this RFS bug to have an per-package tracking of the review process. (unless this is a first-pass-package ;-)) -- tobi signature.asc Description: This is a digitally signed message part
Bug#748525:
Control: serverity -1 important Hi Josh, while this bug may be annoying, it does not justifty a grave severity, as it does NOT render the package useless. Please see https://www.debian.org/Bugs/Developer#severities Therefore downgrading. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764200: rbdoom3-bfg
control: tags -1 pending ... now in NEW .. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766342: ITP: gnome-shell-extension-suspend-button -- Gnome-shell extension allowing to modify the suspend/shutdown button in the status menu
Package: wnpp Severity: wishlist Owner: Tobias Frost t...@debian.org * Package name: gnome-shell-extension-suspend-button Upstream Author : Raphael Freudiger * URL : https://github.com/laserb/gnome-shell-extension-suspend-button * License : GPL Programming Lang: javascript Description : Gnome-shell extension allowing to modify the suspend/shutdown button in the status menu The extension is mentioned at https://wiki.debian.org/Suspend. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757442: RFS: polyphone/1.4 [RFP]
Hi Davy, nice to hear from you again.. Sorry, its already late today, so I won't complete review now... I need some clarifcation regarding the images in resources/: Where are those images from? Please dokument every image with its license. What me worries: At least csv.png seems non-DFSG-free (license Creative Commons Attribution-NoDerivs 3.0; http://www.iconsdb.com/black-icons/csv-icon.html; http://icons8.com/license/). d/copyright misses at least a Files: * rule and you need to update the years on debian/* Please check every file. E.g. one says: 2014, Davy Triponney davy.tripon...@gmail.com 2014, Andrea Celani acelan...@gmail.com but there is no Andrea Celani in d/copyright! Thanks! Please understand as the licenses of the images are show-stoppers, I will wait for your response before looking to the rest. Am Mittwoch, den 22.10.2014, 18:58 +0200 schrieb Davy Triponney: Dear Tobi, dear maintainers, I uploaded another version of Polyphone (1.5). Sources have been modified so that the following libraries are not included anymore: - qcustomplot, - stk, - rtmidi. Regarding the sfArk parser, I fulfilled in using only one library instead of two to read sfArk files. However Qt variables are still used (qint16, quint16, ...) and one small class heavily rely on Qt libraries (QMap, QFile, QByteArray...). So I didn't fill an ITP bug for this parser. Copyrights should be ok. Regarding my application to be a maintainer... I have other projects in mind and won't have time for this unfortunately. But I can of course continue to evolve my package to fix bugs or discrepancies with Debian QA. Regards, Davy signature.asc Description: This is a digitally signed message part
Bug#753110: RFS: mrrescue/1.02c-1 [ITP]
Hi Steven, what's the status of mrrescue? Do you have updates? -- Tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766342: ITP: gnome-shell-extension-suspend-button -- Gnome-shell extension allowing to modify the suspend/shutdown button in the status menu
Tags: pending # is in NEW now Am Mittwoch, den 22.10.2014, 14:39 +0200 schrieb Tobias Frost: Package: wnpp Severity: wishlist Owner: Tobias Frost t...@debian.org * Package name: gnome-shell-extension-suspend-button Upstream Author : Raphael Freudiger * URL : https://github.com/laserb/gnome-shell-extension-suspend-button * License : GPL Programming Lang: javascript Description : Gnome-shell extension allowing to modify the suspend/shutdown button in the status menu The extension is mentioned at https://wiki.debian.org/Suspend. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766148: RFS: sleepenh/1.3.2 [ITA]
Owner: -1 ! Control: tags -1 moreinfo Hi Nicolas, - you write in the changelog: * Set package source format to 3.0 (native); as agreed with original upstream author (Pedro), sleepenh is not a native Debian package That contradicts itself! And also you package version is one of a native version. Or is your version just a typo and you wanted to write 1.3-2? (I assume -- sleepenh is not a native pacakge) [1] So please make it non-native again :) - debian/compat is still 5 -- you probably wanted 9 to have all the lastest features - debian/control: I'm asking you to move the VCS to some more public service, like github or gitorious. (Allioth.debian.org would be best, but only if you already have an account). On the plus-side, you can also add a VCS-Browser As you changed debian/compat to 9 above, you also need to B-D on debhelper (= 9= - debian/copyright: The homepage does not work I suggest to put debian/* under the same license as upstream -- it could cause problems if you e.g want to upstream patched. Did you completely rewrite debian/* if, not please mention the previous maintainers. The postinst script is not needed and can be deleted (the problem it detects and fixes was of version 1.2-2.1, which is not even anymore in oldstable) Please fix above and let me know. I will sponsor this upload. -- tobi [1] https://wiki.debian.org/DebianMentorsFaq#What_is_the_difference_between_a_native_Debian_package_and_a_non-native_package.3F -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765009: Subject: RFS: abcmidi/20140928-1 [ITA]
Many thanks James! Valid points Ross, please also consider those comments. Especially please fix the build system. I missed that during my review, sorry, but I will file a bug for that. (Also, please send your patches upstream.) -- tobi Am Montag, den 20.10.2014, 21:59 +0100 schrieb James Cowgill: On Mon, 2014-10-20 at 15:59 +0200, Ross Gammon wrote: Hi All, I know everyone is busy with the Jessie Release Freeze, but I would be grateful if somebody could take a look at abcmidi (and sponsor if happy). Abcmidi has been sitting unloved for a while now (since 2007). It would be great to get the latest version into Jessie. Hi, Here's a review (I'm not a DD so can't sponsor you however). General * There is a new upstream version (16th October 2014). * #764998 abcmidi: binary-without-manpage usr/bin/abcmatch Obviously you know this, but it would be good if a manpage was added. * The file /usr/share/doc/abcmidi/VERSION seems redundant and can probably be removed. Also ÁUTHORS should not be installed. debian/copyright * You don't need to list abc.h, sizes.h, structs.h manually in the first section since they're already included when you say Files: *. * There seems to be some confusion about whether the code is GPL-2 or GPL-2+. Are you sure what you've put is correct? I see files with no copyright headers but nothing with GPL 2 only in them. * You don't need to repeat the GPL header lots of times. I'd also be tempted to merge all the GPL sections together and just have a large Copyright: block. debian/rules * I don't think you need to use autotools-dev in this package (I don't know a huge amount about this though). * The clean target doesn't work because you disabled it. This is a violation of debian policy (4.9) clean (required): This must undo any effects that the build and binary targets may have had debian/patches: * Make sure you send these patches upstream (sorry if you've already done this - they're not in the new version though). * hardening.patch: Only LDFLAGS should be passed during the link stage. Remove your CFLAGS and CPPFLAGS additions. Build There are lots of bad warnings printed when building this Examples: * parseabc.c:1701:3: warning: format ‘%s’ expects argument of type ‘char *’, but argument 3 has type ‘char **’ [-Wformat=] success = sscanf (s, %%abc-version %s, abcversion); /* [SS] 2014-08-11 */ Isn't this a buffer overflow?! * toabc.c:1490:8: warning: iteration 7u invokes undefined behavior [-Waggressive-loop-optimizations] semi = convertnote[i]; It's not too difficult to use these to make abc2midi segfault - please try and fix them if you have time. James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766698: abc2midi: Does not build two times in a row
Source: abcmidi Version: 20140928-1 Severity: serious Justification: 4.9 Hi Ross, as already written: The package does not clean properly. Please fix your d/rules. (RC critical due to Policy 4.9 by not providing the required clean target) Thanks! -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753110: RFS: mrrescue/1.02c-1 [ITP]
Am Samstag, den 25.10.2014, 17:35 +1000 schrieb Steven Hamilton: On Thu, 23 Oct 2014 11:13:44 +0200 Tobias Frost t...@frost.de wrote: Hi Steven, what's the status of mrrescue? Do you have updates? Still seeking a sponsor. Package is ready and source uploaded to Games Team git. Keen to get this in before freeze. Hi Steve, no, you've got your sponsor already... (Its the owner of the RFS bug, as recommended in http://mentors.debian.net/sponsor/rfs-howto ) Will take a look now -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753110: RFS: mrrescue/1.02c-1 [ITP]
Am Samstag, den 25.10.2014, 17:35 +1000 schrieb Steven Hamilton: Package is ready and source uploaded to Games There are no commits since July 27 -- did you push your changes? -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766682: RFS: gtk-theme-switch/2.1.0-4
Control: owner -1 ! Control: tags +pending +moreinfo Hi Marius, Am Samstag, den 25.10.2014, 00:04 +0300 schrieb Marius Gavrilescu: Package: sponsorship-requests Severity: normal Control: block 739709 by -1 Dear mentors, I am looking for a sponsor for my package gtk-theme-switch * Package name: gtk-theme-switch Version : 2.1.0-4 Upstream Author : Denis Briand de...@narcan.fr * URL : http://gna.org/projects/gtk-theme-switch/ * License : GPL-2+ Section : x11 It builds those binary packages: gtk-theme-switch - GTK+ theme switching utility To access further information about this package, please visit the following URL: http://mentors.debian.net/package/gtk-theme-switch Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/g/gtk-theme-switch/gtk-theme-switch_2.1.0-4.dsc Changes since the last upload: * Escape theme name to prevent code execution (Closes: #739709) * Bump Standards-Version to 3.9.5 here's a review: - current SV is 3.9.6 - please bump date in d/control (its still February) - why are the patches set Forwarded:no to upstream? Regarding #739709 -- I think that bug should be tagged security and priority raised to RC. What do you think? I will sponsor the upload once I've got feedback / fixes from the above 3 items. -- tobi signature.asc Description: This is a digitally signed message part
Bug#757442: RFS: polyphone/1.4 [RFP]
Control: tags -1 wontfix Marking wontfix according to http://mentors.debian.net/sponsor/rfs-howto (cannot be uploaded without fix for the copyright of the icons) -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766869: gtk-theme-switch: incomplete d/copyright
Package: gtk-theme-switch Version: 2.1.0-4 Severity: serious Justification: 4.5 Dear Maintainer, as Eriberto mentioned in an earlier review of your package [1], your d/copyright is incomplete. On a side note, please consider commments from reviewers, and do not file new RFS bugs -- it would have been appropiate here to reopen #739911. Not having accurate copyright information is a Policy violation, therefore this bug is RC. -- tobi [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739911#22 -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766000: RFS: id3lib3.8.3/3.8.3-16
(I do not intend to sponsor this package) Stefan, your package does contain lintian warnings. Many sponsor will not even look at your package with warnings present, so I advise you to fix them. Thanks -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766869: gtk-theme-switch: incomplete d/copyright
Hi Marius, no, not necessry to reopen the RFS. Checking now.. -- tobi Am Sonntag, den 26.10.2014, 14:59 +0200 schrieb Marius Gavrilescu: Tobias Frost t...@debian.org writes: as Eriberto mentioned in an earlier review of your package [1], your d/copyright is incomplete. On a side note, please consider commments from reviewers I thought I fixed this. do not file new RFS bugs -- it would have been appropiate here to reopen #739911. I'll remember this. I've uploaded a fixed version to mentors [0]. Do I still need to submit a RFS for it? [0]: http://mentors.debian.net/package/gtk-theme-switch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766869: gtk-theme-switch: incomplete d/copyright
Here's a review, only a few thing to fix: Ping me when ready. Almost right: Files: debian/* 2009, Denis Briand de...@narcan.fr is 2009-2010 2008 Barry deFreese bddeb...@comcast.net is missing for Files: * the years are not clear expect the first entry so I'd write Copyright: 2009 Maher Awamy mu...@muhri.net Aaron Lehmann aar...@vitelus.com Joshua Kwan jo...@triplehelix.org Pedro Villavicencio Garrido pvill...@gnome.cl Denis Briand de...@narcan.fr The quoted license text is of GPL-2 -- not GPL-2+ as it should be -- (mind the or later option is missing) Best is if you copy the license grant from main.c and add the On Debian.. paragraph There are two, almost indentical manpages. If - the one in the source tree is valid, remove the done in debian - if the one in the debian tree is valid, patch the one in the source tree and remove the one in the debian tree. The name in the manpage is inconsitent: Title says gtk-theme-switch but body says gtk-theme-switch2. I'd update this to reflect the binary name. -- tobi Am Sonntag, den 26.10.2014, 14:59 +0200 schrieb Marius Gavrilescu: Tobias Frost t...@debian.org writes: as Eriberto mentioned in an earlier review of your package [1], your d/copyright is incomplete. On a side note, please consider commments from reviewers I thought I fixed this. do not file new RFS bugs -- it would have been appropiate here to reopen #739911. I'll remember this. I've uploaded a fixed version to mentors [0]. Do I still need to submit a RFS for it? [0]: http://mentors.debian.net/package/gtk-theme-switch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766000: RFS: id3lib3.8.3/3.8.3-16
Am Sonntag, den 26.10.2014, 15:34 +0100 schrieb Stefan Ott: On 10/26/2014 01:43 PM, Tobias Frost wrote: (I do not intend to sponsor this package) Stefan, your package does contain lintian warnings. Many sponsor will not even look at your package with warnings present, so I advise you to fix them. Hi Tobias Thanks for the advice. Most of the current lintian warnings are pedantic or wishlist and some of them directly affect the build process. Since this upload adds multi-arch support to the package I didn't want to mess too much with other aspects of building the package - I'd rather have just one major building-related change per package revision, makes it a bit easier to find bugs. pedantic There are no wishlist lintian messages /pedantic Also, the warning about dev-pkg-without-shlib-symlink (which is the only real complaint from lintian that I see) is IMHO not entirely correct. lintian seems to expect a symlink called libid3-3.8.so while the policy manual says The development package should contain a symlink for the associated shared library without a version number. I'm assuming that this is because the id3lib package has not seen an upstream release in over a decade and we are carrying lots of packing-related information in our version strings these days (such as the c2a from the C++ ABI change in 2005). I could of course just add a lintian override and be done with it but I figured it would be better to keep this warning around as a reminder for me to look into the issue. I'm have doubts. I think lintian is right. You know what's your library name and you know the version part? I'm not an library guru, but I think the library name is libid3-3.8 and the version is 3.0.0, so lintian expectd a symling from usr/lib/x86_64-linux-gnu/libid3-3.8.so to usr/lib/x86_64-linux-gnu/libid3-3.8.so.3.0.0 For the other messages, at least P no-dep5-copyright are easily fixable and dep5 is IMHO now considered as best-practice. just my 2 cents. Anyway, I *did* upload a new version which fixes a small issue with the previous upload and I'm looking forward to additional comments. If anyone feels the urge to upload it that would be appreciated. cheers -- tobi signature.asc Description: This is a digitally signed message part
Bug#766148: RFS: sleepenh/1.3.2 [ITA]
Am Montag, den 27.10.2014, 10:52 +0100 schrieb Nicolas Schier: Dear Tobi, thanks for reviewing and sponsoring! Especially the native-vs-non-native link was quite enlightening. A few minutes ago I uploaded the new files http://mentors.debian.net/debian/pool/main/s/sleepenh/sleepenh_1.3-2.dsc including the following changes: * Fixed changelog for non-native package version * debian/compat is now 9 (was 5) and updated build-dependencies appropriately (debhelper = 9) * git-Repository moved to gitorious, updated Vcs-* fields; (obs: cleaned up repo history, non-ff-compatible) * Fixed debian/copyright: - Removed dead link in debian/copyright to upstream homepage (there is no upstream homepage anymore) - Mention original author also for debian/* files - Same license for debian/* as for upstream files * Removed obsolete postinst script As far as I understood, these should fix all your remarks. Thanks again and kind regards, Nicolas d/copyright: The years for debian/* are wrong. Pedro was maintaining the packgage until 2008, and for Files* the years are 2003-2008 (2008 is the year of the manpage) (Sorry, I missed that before, please ping me again.) Please remove the template text from d/rules, so lines 3-12 I think you don't need to export DH_OPTIONS. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767057: cyphesis: postinst problem
Package: cyphesis-cpp Severity: serious Tags: pending There is currently a problem with the postinst script provided in the last upload. Olek noticed this already and already pushed the necessary changes already to the repository. (Filing this bug for the release team to reference to) -- tobi -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748525:
Control: severity -1 grave On Fri, 2014-09-19 at 11:57 +0200, Markus Koschany wrote: Hi, It seems Josh didn't receive this message. Adding him to CC accordingly. On 19.09.2014 10:24, Tobias Frost wrote: Control: serverity -1 important Hi Josh, while this bug may be annoying, it does not justifty a grave severity, as it does NOT render the package useless. Please see https://www.debian.org/Bugs/Developer#severities Therefore downgrading. -- tobi I think in this case the bug submitter is right because this bug affects all widescreen setups including my own and I suspect most people use a widescreen ratio nowadays. So for all those people this bug is a show-stopper. In addition there are multiple other issues with this package which are described in more detail at https://bugs.debian.org/692221 In my opinion those are almost all serious problems which make the package unfit to release at least. Fortunately Hans de Goede has also setup a Git repository with patches, including a patch for #748525. https://github.com/kthakore/pangzero https://github.com/kthakore/pangzero/commit/bc3e77823772e8f87f50142778f8e6fe44badfb3 I suggest we package his version and work on a new release to fix all those issues but raise the severity to RC again until the package is in a usable state again. Markus With that addtional information I agree -- in combination, its too buggy to be in Jessie... So raising again; Of course, I'd prefer to see the maintainers to preparing the new version, but in case I will also sponsor an NMU. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759688: ufoai
Control: block -1 by 762228 On Fri, 2014-09-19 at 11:37 +0200, Markus Koschany wrote: On 19.09.2014 07:32, Tobias Frost wrote: Control: owner -1 ! Control: tags -1 pending I'll try to review these packages over the weekend. (the package looks huge :) Hi Tobi! Thank you for your interest in UFO:AI. Indeed it's one of the more complex and bigger games. :) (First thing that I saw -- but I don't know how's the best practice in pkg-games, so maybe this is more a question to the list: There is only one ITP filed, but three source packages (ufoai, -data, -maps and -music)? I presume you wanted to CC debian-devel-games. All e-mails to team maintained packages are automatically forwarded to pkg-games-devel but most of the discussion happens on debian-devel-games. Thanks; indeed I mixed those two up. Should the ITP be cloned (and blocking each other) to be able to close a ITP or is it fine to ignore/override the lintian?) FWIW, I think we should follow Lintian's advice in this case and just use one ITP bug to track the progress. https://lintian.debian.org/tags/new-package-should-close-itp-bug.html The three data packages are all part of the same game and they had to be split because of size and functional reasons but they wouldn't make sense without the ufoai source package. Well the lintian message says split of an *existing* Debian package, which is not the case here. On the other side, they are different source packages, so there would be a point for an ITP. I'll probably also clone this RFS bug to have an per-package tracking of the review process. (unless this is a first-pass-package ;-)) Sure, it is. :P Challenge accepted* :) ** :( Cheers, Markus smiling, Tobi * I'd really love to improve my first-pass-yield, but this proved to be hard up to now. ** Just cloned the RFS for -music... (762228) signature.asc Description: This is a digitally signed message part
Bug#762228: RFS: ufoai-music review
Control: -1 moreoinfo Hi Markus, so, let's start with -music - d/copyright contains *many* files not in this package. Please clean up the file. (Also, please use wildcards; this makes it far easier to review) Seems that a base/ prefix slipped in the -music part of d/copyright? Nitpick*: It looks like you are autogenerating the copyright file from LICENSES. In this case, it would probably make sense (even if the copyright-format-1.0 permits it to combine) to be more accurate and not combine so many authors in one big block. License: GPL-2 On Debian systems, the complete text of the GNU General Public License version 2 can be found in /usr/share/common-licenses/GPL-2. This is not enough -- you need to add the first 3 paragraphs of the license -- see the dep5' examples section. - d/README.Source is refering to src:ufoai -- but this has no README.Source, but should (actually a point of uifoai) I think you need to tell in this file how to get the music files, and you'll need to move the get-orig-source target from ufoai's d/control here... (I prefer to have self-containing src packages, which does not say look in yyy to do get the source for xxx ... - d/watch does not produce the source file but a file that does not even have the -music files. This might be unexpected behavior, so this needs to be documented in README.Source and in the watchfile. Otherwise, the package looks ok, but due to the current wall time I will continue tomorrow to see if my (tired) eyes have missed something. -- tobi PS: Please push your changes to the repository, I'll pull them from there. The package is just to big to download/upload for every iteration, I guess... (Instead, I also take patches.) (* nitpicks are not prerequisites for sponsorship; though I'd love to see them fixed for bonus-points) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#762228: RFS: ufoai-music review
Control: tags -1 moreinfo On Sat, 2014-09-20 at 01:22 +0200, Markus Koschany wrote: Hi Tobias, thanks for taking your time for this. On 19.09.2014 23:51, Tobias Frost wrote: Control: -1 moreoinfo Hi Markus, so, let's start with -music First of all I'd like to suggest that you start with the ufoai source package first because it contains the ufoai_copyright.py script and other information that are useful to understand the packaging of UFO:AI's data packages. My reasoning is, that because of every data package has its own orig.tar, they need to be crafted in a way to so that they will be -- individually looked at -- reach Debian quality requirements. - d/copyright contains *many* files not in this package. Please clean up the file. (Also, please use wildcards; this makes it far easier to review) The debian/copyright file is identical for ufoai-data, ufoai-music and ufoai-maps. I did this on purpose because upstream does not distinguish between those files. In fact they maintain everything in one Git repository and the LICENSE file contains all copyright information for the game data. Thus I decided to use a script to parse all license information and then I generated a machine-readable debian/copyright file out of them. This makes it far easier to review the packages IMO because you only have to check and run the script on LICENSES. It also comes with the advantage that all files are machine-readable now. Thus wildcards, except for the Files: * paragraph, aren't necessary and the whole copyright information are more precise. Seems that a base/ prefix slipped in the -music part of d/copyright? Nope, I think the base prefix is correct in d/copyright but the music and sounds directory should have been placed under the base directory in src:ufoai-music. At least that would have been more consistent. I can change that. Yes, this will fix it too. Nitpick*: It looks like you are autogenerating the copyright file from LICENSES. In this case, it would probably make sense (even if the copyright-format-1.0 permits it to combine) to be more accurate and not combine so many authors in one big block. Please see above. The script transforms upstream's LICENSES file into a machine-readable copyright format 1.0 file. I think the benefits are obvious and having the same information about authors listed as in LICENSES seems like a good thing to me. Admitting, upstream is exemplary in case of tracking of its licenses (also with the scope for Debian!), and it really helps to automate this to get a skeleton dep5 file. However -- as with the output of licensecheck of the devscripts -- the output needs to be checked and compared to *every* files in the source. The LICENSE file may (and have) also errors: For example there are files in this files with no copyright holder attributed. Or, there are URLs attributed as copyright owners. How does the script handle this? In the end this leads to wrongly attributed files that will either go unnoticed (so Debian is violating copyright law) or lead to an FTP Master reject. To make it clear: I require an 100% accurate d/copyright and this is one of the few points that are not subject to negotiations. License: GPL-2 On Debian systems, the complete text of the GNU General Public License version 2 can be found in /usr/share/common-licenses/GPL-2. This is not enough -- you need to add the first 3 paragraphs of the license -- see the dep5' examples section. https://www.debian.org/doc/debian-policy/ch-docs.html Packages distributed under the Apache license (version 2.0), the Artistic license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL (versions 2, 2.1, or 3), and the GNU FDL (versions 1.2 or 1.3) should *refer* to the corresponding files under /usr/share/common-licenses,[119] *rather than quoting them* in the copyright file. I believe we shouldn't make the process of creating debian/copyright even more painful and I think that a reference to /usr/share/common-licenses is more than enough for the most widely used free software license. I disagree. As said above, d/copyright is important. Yes, it is tedious to create it the first time and there are more exciting things to do, but it is a necessity to be done and to do it right. The policy means you should not quote the verbatim license, but it is common practice to quote the first 3 paragraphs. Otherwise we'll introduce fuzziness. Consider License GPL-2+ You refer to the GPL-2 file, which makes it non-obvious that you have the or later option in place. For the causal user, its not self-explaining what the + means. Please add the few lines, I consider it not enough to just have the reference. - d/README.Source is refering to src:ufoai -- but this has no README.Source, but should (actually a point of uifoai) I think you need to tell in this file how to get the music files, and you'll need to move the get-orig-source
Bug#759688: ufoai
On Sat, 2014-09-20 at 00:25 +0200, Markus Koschany wrote: On 19.09.2014 21:44, Tobias Frost wrote: [...] The three data packages are all part of the same game and they had to be split because of size and functional reasons but they wouldn't make sense without the ufoai source package. Well the lintian message says split of an *existing* Debian package, which is not the case here. On the other side, they are different source packages, so there would be a point for an ITP. As I already stated above the game data had to be split in different source packages but those source packages belong all to the same game hence they are all covered by ITP bug #244582. The existing package is clearly the ufoai source package. In my opinion ITPs are useful to indicate that people work on packaging certain software for Debian, so that double-work can be avoided but they are not meant to become some sort of bureaucratic exercise. They should always be filed before someone works on new software. Since the game has already been packaged, now filing new ITPs would simply be busywork. If you read through #244582 you will also notice that I mentioned the reasons for the package split in this bug report. Thus it became clear for everyone that #244582 is about all four source packages. Proposoal. Lets do it this way: - In ufoai. close the ITP as ususal changelog. - In the other packages *refer* to the ITP without closing it. - Override all lintian warnings connected to this. Regards, Markus signature.asc Description: This is a digitally signed message part
Bug#762228: RFS: ufoai-music review
Hallo Markus, Am Saturday, den 20.09.2014, 13:02 +0200 schrieb Markus Koschany: On 20.09.2014 09:57, Tobias Frost wrote: [...] I still don't see why the current copyright file does not meet Debian's quality requirements. Instead of one huge 900 MB -data package, the game data was simply split into three different source packages. This makes it much easier to fix bugs without having to upload all data files every time. The split is not under dispute. Other packages do that too, for example redeclipse. But redeclipse do it right (in my view) and their generate-copyright-script which is aware of the package it acts on. (Your script can be enhanced to do that too. Probably less time effort that I spent already on this topic.) I would like to stress: The source packages are not independent of each other, they belong together. It is due to mere technical reasons that the -data was split. In my opinion we are in full compliance with Debian's Policy because teamviewer --daemon start - we state in d/copyright that the game data was split due to technical reasons - we use a reproducible and convenient way to determine all copyright information. - the copyright file is machine-readable and every file in each source package is covered by an license paragraph in debian/copyright. Thus the whole copyright file is accurate. I disagree. Having 6362* entries in d/copyright which does not match any file is NOT accurate. To be very clear: I will NOT sign such a package with my PGP key. (*6392 is the number of lintian wildcard-matches-nothing-in-dep5-copyright messages, already music/ and sound/ subtracted) Due to the split I say we now have 4 related, but independent source packages and they should be handled as such. The Relation is no guarantee that the packages will not diverge in the future. (e.g code could go forward, while data keeps the same, or vice verse) [...] Admitting, upstream is exemplary in case of tracking of its licenses (also with the scope for Debian!), and it really helps to automate this to get a skeleton dep5 file. Indeed. UFO:AI is an exemplary and excellent free software game and its developers care a lot about tracking licenses. However -- as with the output of licensecheck of the devscripts -- the output needs to be checked and compared to *every* files in the source. Right. This is already achieved. Which license information are incorrect? The LICENSE file may (and have) also errors: For example there are files in this files with no copyright holder attributed. Or, there are URLs attributed as copyright owners. How does the script handle this? In the end this leads to wrongly attributed files that will either go unnoticed (so Debian is violating copyright law) or lead to an FTP Master reject. First of all the whole game is licensed under GPL-2+ and is copyright The UFO:AI team. In addition the LICENSES file contains all information about individual game data licenses that diverge from this general assumption. One line in LICENSES looks like that: filename | license | author | source base/maps/africa/af_empty6a.map | GNU General Public License 2.0 or later | Holger 'ShipIt' Gellrich | base/maps/africa/af_empty6.map The script splits all fields by the | delimiter and maps all filenames to their corresponding licenses and copyright holders. If there is no one mentioned under author one may assume that this is always a work by the UFO:AI team. To make it clear: I require an 100% accurate d/copyright and this is one of the few points that are not subject to negotiations. Absolutely. Could you elaborate on where a file is not accurately addressed by copyright format 1.0? Who's the copyright owner of those? base/models/objects/vegi/palm_v1/palm1.md2 | Creative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v1/palm2.md2 | Creative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v2/palm1.md2 | Cr.g teative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v2/palm2.md2 | Creative Commons Attribution-Share Alike 3.0 (if emtpy means upstream, UFO:AI Team is not in the list for that license and its not GPL-2+. Either way, d/copyright is wrong here.) contrib/7th.zip | | 2002 Iconian Fonts - Daniel Zadorozny - http://www.iconian.com/ contrib/scripts/compile_po.bat | | Kostia Kildor Romanov contrib/scripts/update_potfiles_in.bat | | Kostia Kildor Romanov no such files -- LICENSE has too many files radiant/bitmaps/texwindow_uniformsize.png | | orbweaver (commiter in darkradiant repository) | tobi@edoras:~/workspace/deb/mentors/ufoai/uf(no invariant)oai-2.5$ ls -la radiant/bitmaps/texwindow_uniformsize.png -rw-r--r-- 1 tobi tobi 101 Nov 2 2012 radiant/bitmaps/texwindow_uniformsize.png tobi@edoras:~/workspace/deb/mentors/ufoai/ufoai-2.5$ grep radiant/bitmaps/texwindow_uniformsize.png debian/copyright tobi@edoras:~/workspace/deb/mentors
Bug#762228: RFS: ufoai-music review
Addendum: On Sat, 2014-09-20 at 15:45 +0200, Tobias Frost wrote: Absolutely agreed. But can you point me to examples where the short reference to /usr/share/common-licenses was deemed not appropriate by the FTP team? From https://lists.debian.org/debian-devel-announce/2006/03/msg00023.html (the FTP master provides that link in their REJECT-FAQ, https://ftp-master.debian.org/REJECT-FAQ.html, under Copyright) Its from 2006, but still valid) - Its not enough to have the following two-liner: | On Debian systems, the complete text of the GNU General Public License | can be found in the `/usr/share/common-licenses/GPL' file. There are license headers, like the one used for GPL in the example below, you should use those. -- tobi signature.asc Description: This is a digitally signed message part
Bug#762228: RFS: ufoai-music review
On Sun, 2014-09-21 at 03:50 +0300, Peter Pentchev wrote: On Sat, Sep 20, 2014 at 10:10:00AM +0200, Christian Kastner wrote: Hi Markus, On 2014-09-20 01:22, Markus Koschany wrote: The debian/copyright file is identical for ufoai-data, ufoai-music and ufoai-maps. I find this somewhat confusing. Generally speaking, I don't believe that listing the copyright of files which are not part of the source package (in fact, which are part of another package) is policy-conform, regardless of whether upstream created the source split, or you. Just as a minor data-point, I think that it might actually be policy-conformant, as witnessed by e.g. Policy 12.5, the section about /usr/share/doc/package being a symlink to another directory. True, it discusses a slightly different case (two packages coming from the same source package), but I do believe that the intent is exactly the same - a single source package generating, say, two packages (a binary one and a data one), with the same copyright file for both. Not sure if you refering to Markus' or Christian's position when you say might be actually .. conformant .. So you wanted to state that duplicate d/copyrights are _not_ allowed for different source packages, I agree. Otherwise I think not. We might want to refine wording here, that everyone knows what I mean when I say (Debian-)source-package. We have one upstream repository snapshot split into 4 orig.tar (upstream sourcee package) and 4 (Debian-)source packages. Binary packages are the result of a (Debian-)source-package. §5.6 and §4.4 defines the Debian-source-package's name. So in our case we have 4 Debian-source packages: ufoai, ufoai-data, ufoai-music and ufoai-maps. Also d/copyright is to document the copyright for the source used to generate the binary packages. 12.5 reads only about source, so this term might be ambiguous between upstream and Debian. However, the rest of the policy does often use it in the context of unpacked source. However, there is another clause quite similar to the symling clause of 12.5.: It is in 12.3 and reads: /usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second.[116] The footnote 116 then helps to make it clear: Please note that this does not override the section on changelog files below, so the file /usr/share/doc/package/changelog.Debian.gz must refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (*same source package and version*). So I believe we need to have the same source packages to allow symlinks, to doc or, in our case duplicated copyright files. The copyright file would have to contain information about all the files in the two binary packages, Minor correction: As the copyright file is the documentation of the undelaying source package, it does not document the files in the binary package. which means that for each of the binary packages its copyright file would contain information about files that are part of another package. s/package/source package? That would be my point. It's true that the Debian Policy does not contain explicit provisions for this case - two different source packages coming from the same upstream distribution point - and it's true that the final say in these matters belongs to the FTP Masters. I think §4.5, in the Chapter Source Package, by using verbatim the intention is made quite clear: 4.5 Copyright: debian/copyright Every package must be accompanied by a verbatim copy of its copyright information and distribution license in the file /usr/share/doc/package/copyright Yes, FTP-Masters will have the final word, but it will not me how presents a package containing this question to them. Markus also already committed to a split of d/copyright. -- tobi G'luck, Peter signature.asc Description: This is a digitally signed message part
Bug#762228: RFS: ufoai-music review
Am Saturday, den 20.09.2014, 17:33 +0200 schrieb Markus Koschany: On 20.09.2014 15:45, Tobias Frost wrote: [...] I agree with you that we both waste time here. I still think the comment in debian/copyright and the nature of the split would justify a unified d/copyright file but I intend to modify the script so that everyone's happy. [...] I disagree. Having 6362* entries in d/copyright which does not match any file is NOT accurate. To be very clear: I will NOT sign such a package with my PGP key. (*6392 is the number of lintian wildcard-matches-nothing-in-dep5-copyright messages, already music/ and sound/ subtracted) Please note that's an informational warning and with the information given already, everyone knows that the three data packages should be seen as one package just split in three parts. As you extend your script those will gone too. Due to the split I say we now have 4 related, but independent source packages and they should be handled as such. The Relation is no guarantee that the packages will not diverge in the future. (e.g code could go forward, while data keeps the same, or vice verse) Nope, those packages will always be kept in sync with src:ufoai. They are not independent source packages and you should simply trust me with that statement. [...] To make it clear: I require an 100% accurate d/copyright and this is one of the few points that are not subject to negotiations. Absolutely. Could you elaborate on where a file is not accurately addressed by copyright format 1.0? Who's the copyright owner of those? base/models/objects/vegi/palm_v1/palm1.md2 | Creative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v1/palm2.md2 | Creative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v2/palm1.md2 | Cr.g teative Commons Attribution-Share Alike 3.0 base/models/objects/vegi/palm_v2/palm2.md2 | Creative Commons Attribution-Share Alike 3.0 (if emtpy means upstream, UFO:AI Team is not in the list for that license and its not GPL-2+. Either way, d/copyright is wrong here.) Empty means UFO:AI team. I will add this information more prominently to debian/copyright. contrib/7th.zip | | 2002 Iconian Fonts - Daniel Zadorozny - http://www.iconian.com/ contrib/scripts/compile_po.bat | | Kostia Kildor Romanov contrib/scripts/update_potfiles_in.bat | | Kostia Kildor Romanov no such files -- LICENSE has too many files radiant/bitmaps/texwindow_uniformsize.png | | orbweaver (commiter in darkradiant repository) | True. I removed those files. They are not part of the sources. Do you mean: You removed them manually? I didnt see any documentation; this must be explained in d/copyright. see also https://wiki.debian.org/BenFinney/software/repack: Debian Policy §12.5 says “… the copyright file must say where the upstream sources (if any) were obtained…”. This is commonly interpreted to imply that, if you re-pack the upstream source, the reason should be explained in the debian/copyright file. The machine-readable copyright file format specifies the free-form text of the “Source” field should be used for this purpose. [...] Sure I could duplicate the same code for every source package but what would we gain? Quality? Reduction of maintenance work? Come on... Above you say keeping 4 duplicated copyright files in sync is fine and now you say you cannot handle tyou are free to look for some other sponsoro keep 4 identical get-orig-targets snippets in sync? (The snippets could use, for example, use the upstream version from d/changelog to get the right commmit -- using the upstream tag and not the git commit id, then everything is wonderful and likely never needs a change. I see all of the 4 source packages as related, but independent entities. I said I could duplicate the code but I feel that we gain nothing with it since I'm the only one who has to work with those packages. According d/control this package is team maintained. As long as it is not a Policy violation, I would prefer to make some independent decisions about maintaining my own packages. I'm not enforcing the decisions to you. You can still freely decide to change according to my request or not. But out of decissions follow consequences. Let me put this in some words, being very clear and very direct: The policy only describes a minimum set of rules. Best practice can go over this standards. The policy does not constitute a right for you to demand that I lower my standards in respect what I consider best practice, especially if you fail to convince me that you are right. If you cannot accept that, I will not the one sponsoring your uploads. Now, decide for the red or blue pill. [... Ok, lets leave that without +repack. (I still think people will have the expectation without it that they will be able to find the orig.tar
Bug#759688: Bug#762228: RFS: ufoai-music review
Control: tags -1 -pending Control: noowner -1 On Sun, 2014-09-21 at 23:41 +0200, Markus Koschany wrote: Hello Tobias, On 21.09.2014 18:26, Tobias Frost wrote: Am Saturday, den 20.09.2014, 17:33 +0200 schrieb Markus Koschany: [...] I said I could duplicate the code but I feel that we gain nothing with it since I'm the only one who has to work with those packages. According d/control this package is team maintained. I have been working on this package for a year now and I am currently the only one who cares about it. As long as it is not a Policy violation, I would prefer to make some independent decisions about maintaining my own packages. I'm not enforcing the decisions to you. You can still freely decide to change according to my request or not. But out of decissions follow consequences. Let me put this in some words, being very clear and very direct: The policy only describes a minimum set of rules. Best practice can go over this standards. The policy does not constitute a right for you to demand that I lower my standards in respect what I consider best practice, especially if you fail to convince me that you are right. If you cannot accept that, I will not the one sponsoring your uploads. Now, decide for the red or blue pill. I have already lost count how many times you gave me the choice between sink or swim and it is definitely not very pleasant to learn from you that you are not interested in my opinion. Very wrong. I checked every argument from your side and actually did also research to see if I am wrong with my view. Since you are a member of the Debian Games Team, why didn't you simply ask all your questions on our list or on IRC and closed the sponsorship bugs? Besides there was always the opportunity to discuss everything in detail, at least in one other language to avoid any misunderstandings. This is not about Debian's policy or your right to make improvement proposals. You simply don't listen to the one who knows this game best without having any experience with games of this caliber. The list was always CC'ed and as there was an RFS I followed the mentors.d.n process. My focus was on the packaging work, and in this stage it is not very important what particular piece of software this is. I presume the main issue here is that you never followed my advice to have a look at the ufoai source package and to start with the game's core. Did you ever compile the sources and play the game? From the flow of our conversation, I can only deduce: No. Read carefully my mails again and you will find the clues that I indeed looked at src:ufoai. You constantly ignored my objections and never understood the necessity to create Debian compliant source tarballs out of upstream's Git repository and most importantly, how this is actually achieved in a Policy compliant way. Your question about the file removals could have been easily answered by looking at the get-orig-source target. Instead you jumped to a conclusion without considering the package maintainers ideas. Wrong, I explained the issues I found in detail several times including my reasoning (and others backed me up on my view). The perceived response was: Don't give me feedback, just upload it. This is why I told you several times that won't fly. I'm always direct, some people cannot cope with that, but also some people won't (or don't want to) understand the message otherwise. In the end we were maybe talking in total about 20-30 lines that I asked you to add -- and not to completely throw over your packaging style. The decision is not about reality or illusion. More about: Is mutual respect important? I think it is, so it's high time to quit here. Only If you equals missing respect to not being of the same opinion you are right. The Matrix reference is probably flawed, I've should used another. This has nothing to do with illusision, but more if you prefer to work together instead of constantly saying I'll wont change this. I'd really loved to help you to bring this set of packages into Debian, especially as the game itself is quite nice. Otherwise I wouldn't have invested this much time. The above I consider non productive and therefore I won't answer this thread anymore, unless it is about the packaging and somehow a way is shown to resolve the (technical) issues in a way both can live with. -- tobi signature.asc Description: This is a digitally signed message part
