Re: [Help] How to fix type issue on 32bit archs in C++ (Was: Bug#852839: baitfisher: FTBFS (32-bit): mixes ::size_t and faststring::size_t)

[James Cowgill]

Hi,

On 11/12/17 08:57, Andreas Tille wrote:
> control: tags -1 help
> 
> Hi,
> 
> I admit I have to poor C++ knowledge to fix this possibly very simple
> issue.  Any help would be welcome.
> 
> Kind regards
> 
>   Andreas.
> 
> On Fri, Jan 27, 2017 at 01:23:40PM -0500, Aaron M. Ucko wrote:
>> Source: baitfisher
>> Version: 1.0+dfsg-1
>> Severity: important
>> Justification: fails to build from source
>>
>> Builds of baitfisher for 32-bit architectures such as i386 have been
>> failing:
>>
>>   range_functions.h: In member function 'bool CRangeList::add(faststring)':
>>   range_functions.h:596:31: error: invalid initialization of non-const 
>> reference of type 'faststring::size_t& {aka long unsigned int&}' from an 
>> rvalue of type 'faststring::size_t {aka long unsigned int}'
>>
>> The issue appears to be that, for some reason, class faststring has
>> (https://anonscm.debian.org/cgit/debian-med/baitfisher.git/tree/faststring2.h#n128)
>>
>>   // Shadow the "global" size_t typedef for this class.
>> typedef unsigned long size_t;

I think you should ask upstream why they have this horrific typedef
instead of defining their own size type or using the normal size_t.

Maybe ask them why they decided to reimplement std::string as well...

>> but CRangeList::add uses the global size_t typedef, which is formally
>> unsigned int on 32-bit systems:
>>
>> https://anonscm.debian.org/cgit/debian-med/baitfisher.git/tree/range_functions.h#n591
>>
>> size_t pos1=0, pos2, len=str.size();
>>
>> Although the two types are de facto equivalent on 32-bit
>> architectures, C++ compilers insist on treating them as different.
>> (This problem doesn't occur on 64-bit architectures, on which both
>> size_t typedefs are unsigned long.)
>>
>> Could you please take a look?

You need to make sure you use faststring's version of size_t. As a
workaround, I think this will work instead of the line above (untested):

  faststring::size_t pos1=0, pos2, len=str.size();

It's likely there will be other cases of this though.

James



signature.asc
Description: OpenPGP digital signature

Re: How to get debian ci test passed for proxy application

[James Cowgill]

Hi,

On 26/11/17 17:00, Roger Shimizu wrote:
> Dear mentors list,
> 
> I maintain a proxy application, shadowsocks-libev.
> I want to let it pass debian ci test. And I already confirm the test
> all passed on my local environment, and debomatic [0].
> However it failed on debian ci infrastructure [1].
> 
> [0] 
> http://debomatic-amd64.debian.net/distribution#unstable/shadowsocks-libev/3.1.1+ds-1/autopkgtest
> [1] https://ci.debian.net/packages/s/shadowsocks-libev/unstable/amd64/
> 
> For local test, it just need the commands below:
> 
> $ sudo apt install shadowsocks-libev curl dnsutils
> $ git clone https://anonscm.debian.org/git/collab-maint/shadowsocks-libev.git
> $ cd shadowsocks-libev
> $ ./tests/test.sh

Running autopkgtest as described on this page might help:
https://ci.debian.net/doc/file.MAINTAINERS.html

> The last test.sh script invokes the test, which creates local proxy
> listen to 127.0.0.1:1081, and then it calls curl command to get index
> page of google via local proxy, 127.0.0.1:1081.
> 
> My local test shows all pass, while debian ci test [1] shows a
> connection timeout message.
> So I'm wondering whether debian ci support network activity, and how
> can I configure the test to get it passed.

I think you might need a "Restrictions: isolation-container" to get
network access, but that's only a guess.

James



signature.asc
Description: OpenPGP digital signature

Re: Help needed with gcc-7 error

[James Cowgill]

Hi,

On 27/08/17 14:40, Andreas Tille wrote:
> Hi,
> 
> when trying to build sga it results in an error:
> 
> ...
> g++ -DHAVE_CONFIG_H -I. -I..  -I../Bigraph -I../Thirdparty -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fopenmp  -I/usr//include -I/usr//include/bamtools -Wall 
> -Wextra  -Wno-unknown-pragmas -std=c++98 -O3 -c -o libutil_a-VariantIndex.o 
> `test -f 'VariantIndex.cpp' || echo './'`VariantIndex.cpp
> VariantIndex.cpp: In member function 'VariantRecordVector 
> VariantIndex::getNearVariants(const string&, int, int) const':
> VariantIndex.cpp:89:46: error: call of overloaded 'abs(long unsigned int)' is 
> ambiguous
>  if(abs(record.position - position) < distance)
>   ^

In C++11, you cannot call abs on an unsigned integer (which makes no
sense anyway). Probably "record.position" needs casting to a signed type
(like long).

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: C++ help needed (Was: Bug#853375: disulfinder: ftbfs with GCC-7)

[James Cowgill]

Hi,

On 26/08/17 21:08, Andreas Tille wrote:
> Hi,
> 
> I moved disulfinder to Git[1] and tried to track down this issue with my
> limited C++ knowledge but failed.  The issue is
> 
> ...
> make[3]: Entering directory '/build/disulfinder-1.2.11/disulfind/src'
> g++ -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 
> -fdebug-prefix-map=/build/disulfinder-1.2.11=. -fstack-protector-strong 
> -Wformat -Werror=format-security -DDEFAULT_PKGDATADIR=\"/usr/share/disulfind
> In file included from Input/utils.h:1:0,
>  from Input/GlobalDescriptor.cpp:3:
> Input/../Common/Matrix.h: In constructor 'Matrix::Matrix(int, int, 
> DATATYPE*)':
> Input/../Common/Matrix.h:208:3: error: 'Exception' has not been declared
>Exception::Assert(nrows>0 && ncols>0,"construction of empty matrix");
>^

The problem is the include guard in Exception.h.

Common/Exception.h:
#define __EXCEPTION_H

By luck, this happens to collide with the include guard used by gcc-7's
exception.h header which is pulled in by some standard library includes.

/usr/include/c++/7/bits/exception.h:
#define __EXCEPTION_H 1

This means that nothing from Exception.h ever gets defined if
exception.h gets included first. disulfind is wrong here because the C++
standard explicitly states that all identifiers beginning with two
underscores are reserved.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Package not migrating

[James Cowgill]

Hi,

On 17/08/17 19:42, Ole Streicher wrote:
> I have a package (cpl) that did not migrate since 38 days, but I don't
> see a reason:
> 
> Excuse for cpl
> 
> * Migration status: BLOCKED: Needs an approval (either due to a freeze
>   or due to the source suite) 
> * 38 days old (needed 10 days)
> * Not touching package due to block request by adsb (check
>   https://release.debian.org/testing/freeze_policy.html if update is
>   needed) 
> * Piuparts tested OK - https://piuparts.debian.org/sid/source/c/cpl.html
> * Not considered 
> 
> The freeze URL above speaks about the Buster freeze, but isn't that a
> bit early?

https://release.debian.org/britney/hints/adsb:

# 20170720
# in both main and contrib, breaks britney / dak
# (#824169)
block cpl

James



signature.asc
Description: OpenPGP digital signature

Re: How to make a shared lib recognized by debhelpers?

[James Cowgill]

Hi,

On 17/07/17 20:20, Ole Streicher wrote:
> Hi,
> 
> I am currently adopting plplot [1], which included a simplification and
> modernization of the build system (using modern debhelpers).
> 
> I now have the problem, that one of the shared libraries is probably not
> detected correctly: "lintian" tells me
> 
> E: octave-plplot: unstripped-binary-or-object 
> usr/lib/x86_64-linux-gnu/octave/site/oct/api-v51/x86_64-pc-linux-gnu/plplot_octave.oct
> E: octave-plplot: missing-dependency-on-libc needed by 
> usr/lib/x86_64-linux-gnu/octave/site/oct/api-v51/x86_64-pc-linux-gnu/plplot_octave.oct
> 
> The Depends: field of the package however contains the entry
> ${shlibs:Depends}, and this also works correctly for the other binary
> packages built from the source.
> 
> The manpages of dh_makeshlibs, dh_shlibdeps and dh_strip didn't
> enlighten me here. In the original plplot package, "strip" was called
> directly in install-arch, which doesn't look very smart, because it
> f.e. also prevents the creation of a proper debug image, and
> dpkg-shlibdeps needs to be called lated as well explicitly for this
> library.

You have been hit by bug #35733 in debhelper. Possibly #862909 might
apply here as well.

I don't see an easy fix for this, so unfortunately you might have to
keep the existing workarounds in the packaging.

James



signature.asc
Description: OpenPGP digital signature

Re: Problem backporting libhmsbeagle

[James Cowgill]

Hi,

On 17/06/17 12:03, Gunter Königsmann wrote:
> Even if these code lines would work they probably should be reformulated
> by upstream so they are easier to read:
> 
> ++i assigns I the value I+1 and returns the new i. And then i is
> assigned another new value by the i= in the same line...
> 
> ...a better way to express what I believe the line should mean would be:
> 
> ++i;
> i &= 3;
> 
> Perhaps the c compiler is as unsure which assignment should have the
> precedence as I am.

Or "i = (i + 1) & 0x3" which I think looks better.

The original code invokes undefined behavior so is wrong anyway. I have
no idea why this only affects jessie-backports though.

James



signature.asc
Description: OpenPGP digital signature

Re: Depends xxx <- Version: 3:20161105-1

[James Cowgill]

Hi,

On 09/06/17 13:11, Narcis Garcia wrote:
> El 09/06/17 a les 14:01, James Cowgill ha escrit:
>> Hi,
>>
>> On 09/06/17 12:54, Narcis Garcia wrote:
>>> Hello, I'm trying to build a package that depends on another one
>>> (iputils-ping), but the other's version in Debian is marked with a
>>> notation I don't know:
>>> 3:20161105-1
>>>
>>> - Which is this software's version? 3?
>>
>> This is documented in debian-policy:
>> https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
>>
>> The upstream version is "20161105". The epoch is "3" and is used to
>> change the version scheme at a later date.
>>
>>> - What is the best formula for "control" file in my new package, having
>>> present that any version is useful for me since 3:20020927 from
>>> Debian-Sarge or older if there was?
>>>
>>> Depends: iputils-ping (>= 3)
>>> Depends: iputils-ping (>= 20020927)
>>> Depends: iputils-ping (>= 3:20020927)
>>
>> The last one is the only one which will do what you want. However, it's
>> not worth it to specify dependency versions which only matter for
>> prehistoric Debian releases, so the best thing to do would just be:
>>
>> Depends: iputils-ping
>>
>> Thanks,
>> James
> 
> Okay, I didn't want that this lintian error affected Depends and/or
> Recommends too:
> https://lintian.debian.org/tags/depends-on-build-essential-package-without-using-version.html

iputils-ping is not a build-essential package so that error doesn't
apply here.

James



signature.asc
Description: OpenPGP digital signature

Re: Depends xxx <- Version: 3:20161105-1

[James Cowgill]

Hi,

On 09/06/17 12:54, Narcis Garcia wrote:
> Hello, I'm trying to build a package that depends on another one
> (iputils-ping), but the other's version in Debian is marked with a
> notation I don't know:
> 3:20161105-1
> 
> - Which is this software's version? 3?

This is documented in debian-policy:
https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version

The upstream version is "20161105". The epoch is "3" and is used to
change the version scheme at a later date.

> - What is the best formula for "control" file in my new package, having
> present that any version is useful for me since 3:20020927 from
> Debian-Sarge or older if there was?
> 
> Depends: iputils-ping (>= 3)
> Depends: iputils-ping (>= 20020927)
> Depends: iputils-ping (>= 3:20020927)

The last one is the only one which will do what you want. However, it's
not worth it to specify dependency versions which only matter for
prehistoric Debian releases, so the best thing to do would just be:

Depends: iputils-ping

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Bug#861754: libpll: FTBFS on non-x86: x86intrin.h: No such file or directory

[James Cowgill]

Control: tags -1 patch

Hi,

On 16/05/17 09:50, Andreas Tille wrote:
> Hi Aaron,
> 
> On Mon, May 15, 2017 at 10:01:53AM -0400, Aaron M. Ucko wrote:
>>
>> Alas, non-x86 builds are still failing, with the immediate cause of
>> failure being either an uncompilable cpuid call
> 
> Hmmm, I'm a bit clueless about this.
> 
>> or (in the case of
>> powerpc[spe] and ppc64[el]) the use of x86-specific compiler flags for
>> certain files.  Please limit all of the above to x86 architectures.
> 
> I think I could realise this but I'm afraid after having done so the
> cpuid issue will remain also for these - so seeking for help here fist.

Possibly the attached patch will work?

This:
- only tries to detect x86 features on x86
- detects altivec properly (although it's not used anywhere?)
- uses GCC's __builtin_cpu_supports which is nicer than cpuid
- compiles with --disable-* on all arches except x86
- enables arch specific code on x86 (there is proper runtime detection now)
- uses debhelper 10 to avoid manual autogen
- includes architecture.mk which is required before using DEB_HOST_*

james
diff -Nru libpll-0.3.0/debian/compat libpll-0.3.0/debian/compat
--- libpll-0.3.0/debian/compat  2017-05-15 08:19:35.0 +0100
+++ libpll-0.3.0/debian/compat  2017-05-16 11:45:26.0 +0100
@@ -1 +1 @@
-9
+10
diff -Nru libpll-0.3.0/debian/patches/hardware-detect.patch 
libpll-0.3.0/debian/patches/hardware-detect.patch
--- libpll-0.3.0/debian/patches/hardware-detect.patch   1970-01-01 
01:00:00.0 +0100
+++ libpll-0.3.0/debian/patches/hardware-detect.patch   2017-05-16 
11:45:11.0 +0100
@@ -0,0 +1,61 @@
+--- a/src/hardware.c
 b/src/hardware.c
+@@ -21,45 +21,23 @@
+ 
+ #include "pll.h"
+ 
+-#ifndef __PPC__
+-#define cpuid(f1, f2, a, b, c, d)\
+-  __asm__ __volatile__ ("cpuid"  \
+-: "=a" (a), "=b" (b), "=c" (c), "=d" (d) \
+-: "a" (f1), "c" (f2));
+-#endif
+-
+ static void cpu_features_detect()
+ {
+-  unsigned int a,b,c,d;
+-
+   memset(pll_hardware,0,sizeof(pll_hardware_t));
+ 
+-#ifdef __PPC__
+-  pll_hardware->altivec_present = 1;
+-#else
+-
+-  cpuid(0,0,a,b,c,d);
+-  unsigned int maxlevel = a & 0xff;
+-
+-  if (maxlevel >= 1)
+-  {
+-cpuid(1,0,a,b,c,d);
+-pll_hardware->mmx_present= (d >> 23) & 1;
+-pll_hardware->sse_present= (d >> 25) & 1;
+-pll_hardware->sse2_present   = (d >> 26) & 1;
+-pll_hardware->sse3_present   = (c >>  0) & 1;
+-pll_hardware->ssse3_present  = (c >>  9) & 1;
+-pll_hardware->sse41_present  = (c >> 19) & 1;
+-pll_hardware->sse42_present  = (c >> 20) & 1;
+-pll_hardware->popcnt_present = (c >> 23) & 1;
+-pll_hardware->avx_present= (c >> 28) & 1;
+-
+-if (maxlevel >= 7)
+-{
+-  cpuid(7,0,a,b,c,d);
+-  pll_hardware->avx2_present = (b >> 5) & 1;
+-}
+-  }
++#if defined(__PPC__)
++  pll_hardware->altivec_present = __builtin_cpu_supports("altivec");
++#elif defined(__x86_64__) || defined(__i386__)
++  pll_hardware->mmx_present = __builtin_cpu_supports("mmx");
++  pll_hardware->sse_present = __builtin_cpu_supports("sse");
++  pll_hardware->sse2_present= __builtin_cpu_supports("sse2");
++  pll_hardware->sse3_present= __builtin_cpu_supports("sse3");
++  pll_hardware->ssse3_present   = __builtin_cpu_supports("ssse3");
++  pll_hardware->sse41_present   = __builtin_cpu_supports("sse4.1");
++  pll_hardware->sse42_present   = __builtin_cpu_supports("sse4.2");
++  pll_hardware->popcnt_present  = __builtin_cpu_supports("popcnt");
++  pll_hardware->avx_present = __builtin_cpu_supports("avx");
++  pll_hardware->avx2_present= __builtin_cpu_supports("avx2");
+ #endif
+ }
+ 
diff -Nru libpll-0.3.0/debian/patches/series libpll-0.3.0/debian/patches/series
--- libpll-0.3.0/debian/patches/series  2017-05-15 08:19:35.0 +0100
+++ libpll-0.3.0/debian/patches/series  2017-05-16 11:45:20.0 +0100
@@ -1 +1,2 @@
 have_x86intrin_h.patch
+hardware-detect.patch
diff -Nru libpll-0.3.0/debian/rules libpll-0.3.0/debian/rules
--- libpll-0.3.0/debian/rules   2017-05-15 08:19:35.0 +0100
+++ libpll-0.3.0/debian/rules   2017-05-16 11:45:26.0 +0100
@@ -2,19 +2,18 @@
 
 # DH_VERBOSE := 1
 
+include /usr/share/dpkg/architecture.mk
+
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
dh $@
 
 override_dh_auto_configure:
-   ./autogen.sh
-ifeq ($(DEB_BUILD_ARCH),i386)
-   ./autogen.sh --disable-avx --disable-sse
-   dh_auto_configure -- --disable-avx --disable-sse
+ifneq ($(filter $(DEB_HOST_ARCH_CPU), amd64 i386),)
+   dh_auto_configure
 else
-   ./autogen.sh --disable-avx
-   dh_auto_configure -- --disable-avx
+   dh_auto_configure -- --disable-sse --disable-avx --disable-avx2
 endif
 
 override_dh_install:


signature.asc
Description: OpenPGP digital signature

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[James Cowgill]

Hi,

On 28/03/17 10:37, Andreas Tille wrote:
> tags 858260 help
> thanks
> 
> Hi,
> 
> I admit that when reading the bug report I have no idea how to fix it.
> I can confirm that I can reproduce the issue in a recent unstable
> chroot.  I have added maintainers of tzdata, Debian Science and Debian
> mentors in CC - just hoping for any helpful hint.

Whatever has happened, tzdata 2017a triggered it.

tzdata 2016j-2:
> $ python3 -c "import datetime, pytz; print(repr(datetime.datetime(2011, 1, 1, 
> tzinfo = pytz.timezone('Asia/Tokyo'"
> datetime.datetime(2011, 1, 1, 0, 0, tzinfo= JST+9:00:00 STD>)

tzdata 2017a-1:
> $ python3 -c "import datetime, pytz; print(repr(datetime.datetime(2011, 1, 1, 
> tzinfo = pytz.timezone('Asia/Tokyo'"
> datetime.datetime(2011, 1, 1, 0, 0, tzinfo= LMT+9:19:00 STD>)

There was a Asia/Tokyo change in tzdata 2017a, but I don't really know
how it caused this:

@@ -1462,8 +1452,6 @@

 # Zone NAMEGMTOFF  RULES   FORMAT  [UNTIL]
 Zone   Asia/Tokyo  9:18:59 -   LMT 1887 Dec 31 15:00u
-   9:00-   JST 1896 Jan  1
-   9:00-   JCST1937 Oct  1
9:00Japan   J%sT
 # Since 1938, all Japanese possessions have been like Asia/Tokyo.

Maybe it's a bug in python-tz?

James



signature.asc
Description: OpenPGP digital signature

Re: Help with systemd to start shiny-server needed

[James Cowgill]

Hi,

On 24/03/17 15:21, Andreas Tille wrote:
> I intend to package shiny-server and have prepared some preliminary
> packaging in Debian Med Git[1].  When trying to install the resulting
> package I get:
> 
> 
> $ sudo dpkg -i ./shiny-server_1.5.0.831+dfsg-1_amd64.deb 
> (Reading database ... 582729 files and directories currently installed.)
> Preparing to unpack .../shiny-server_1.5.0.831+dfsg-1_amd64.deb ...
> Unpacking shiny-server (1.5.0.831+dfsg-1) over (1.5.0.831+dfsg-1) ...
> Setting up shiny-server (1.5.0.831+dfsg-1) ...
> User 'shiny' already exists. Ensuring proper permissions on /home/shiny.
> Job for shiny-server.service failed because of unavailable resources or 
> another system error.
> See "systemctl status shiny-server.service" and "journalctl -xe" for details.
> invoke-rc.d: initscript shiny-server, action "start" failed.
> ● shiny-server.service - ShinyServer
>Loaded: loaded (/lib/systemd/system/shiny-server.service; enabled; vendor 
> preset: enabled)
>Active: failed (Result: resources) since Fri 2017-03-24 16:20:31 CET; 18ms 
> ago
>   Process: 22246 ExecStopPost=/bin/sleep 5 (code=exited, status=0/SUCCESS)
>   Process: 22241 ExecStartPost=/bin/sleep 3 (code=exited, status=0/SUCCESS)
>   Process: 22239 ExecStart=/bin/bash -c /usr/bin/shiny-server 
> --pidfile=/var/run/shiny-server.pid >> /var/log/shiny-server.log 2>&1 
> (code=exited, status=0/SUCCESS)
>  Main PID: 22239 (code=exited, status=0/SUCCESS)
>   CPU: 7ms
> 
> Mar 24 16:20:23 sputnik systemd[1]: Starting ShinyServer...
> Mar 24 16:20:26 sputnik systemd[1]: shiny-server.service: PID file 
> /var/run/shiny-server.pid not readable (yet?) after start-post: No such file 
> or directory
> Mar 24 16:20:31 sputnik systemd[1]: Failed to start ShinyServer.

Do you know that ShinyServer actually started correctly? What does the
log say. The fact that it exited quickly looks suspicious.

shinyserver.service:
> [Service]
> TimeoutStartSec=10
> ExecStart=/bin/bash -c '/usr/bin/shiny-server 
> --pidfile=/var/run/shiny-server.pid >> /var/log/shiny-server.log 2>&1'

Why does stdout / stderr need redirecting? This is probably why the real
error message was never printed (systemd knows nothing about this log file).

> # Needed to give SS a chance to write out to the PID file.
> ExecStartPost=/bin/sleep 3
> PIDFile=/var/run/shiny-server.pid
> Type=simple

Does using "Type=simple" and "PIDFile=..." together make any sense?
Using "sleep 3" to wait for the PID file to be created seems like a huge
hack.

What happens if you use something simple like this?
[Service]
Type=simple
ExecStart=/usr/bin/shiny-server

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Attempt to build BioD blocked by undeaD and missing module string (Was: How to build D source)

[James Cowgill]

Hi,

On 26/02/17 07:03, Andreas Tille wrote:
> On Sat, Feb 25, 2017 at 10:01:17PM +0000, James Cowgill wrote:
>> On 25/02/17 21:31, Andreas Tille wrote:
>>> I intend to package BioD[1] but I have no idea how to build the D code
>>> (and run the unit tests).  Considering BioD is a library I might need
>>> something like a dynamic lib and a development package, but may be this
>>> is different for D than in C.
>>
>> It looks like it uses "dub" as it's build system. Dub is packaged but
>> has no users in the archive so you probably want to talk to the D
>> language maintainers about it first to see what the correct way to
>> handle this is.
> 
> I just added "dub run" to debian/rules.

I think you want "dub build" instead.

>> I notice it depends on undead which will need packaging first.
> 
> There are two kinds of messages:
> 
> bio/bam/bai/indexing.d(33,8): Deprecation: module std.stream is deprecated - 
> It will be removed from Phobos in October 2016. If you still need it, go to 
> https://github.com/DigitalMars/undeaD
> 
> This is what James seems to refer to - I'm not sure whether this is
> critical for the build here.  I'd be willing to package undead if needed
> but I'd prefer if some more skilled people would do so.

Ah, I was looking at upstream git master which contains this dependency
in dub.json:
"dependencies": {
"undead": "~>1.0.6"
},

> bio/bam/bai/indexing.d(38,8): Error: module string is in file 
> 'core/std/c/string.d' which cannot be read
> 
> This seems to be critical.  Do you have any hint?

Maybe this PR would help?
https://github.com/biod/BioD/pull/23

None of these errors or warnings happen for me with the latest upstream
git.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: How to build D source

[James Cowgill]

Hi,

On 25/02/17 21:31, Andreas Tille wrote:
> I intend to package BioD[1] but I have no idea how to build the D code
> (and run the unit tests).  Considering BioD is a library I might need
> something like a dynamic lib and a development package, but may be this
> is different for D than in C.

It looks like it uses "dub" as it's build system. Dub is packaged but
has no users in the archive so you probably want to talk to the D
language maintainers about it first to see what the correct way to
handle this is.

I notice it depends on undead which will need packaging first.

James



signature.asc
Description: OpenPGP digital signature

Bug#855193: RFS: slt/0.0.git20140301-2.1 [RC][NMU] -- TLS reverse-proxy with SNI multiplexing (TLS virtual hosts)

[James Cowgill]

retitle 851876 slt: FTBFS on uniprocessor systems - testsuite deadlocks
forwarded 851876 https://github.com/inconshreveable/slt/issues/5
thanks

Hi,

On 15/02/17 11:24, Roger Shimizu wrote:
> Dear James,
> 
> On Wed, Feb 15, 2017 at 7:51 PM, James Cowgill <jcowg...@debian.org> wrote:
>>
>> So do you know why the tests only pass when using 2 CPUs? That seems
>> pretty fishy to me. Maybe there is an underlying bug here?
> 
> I'm not sure the reason.
> I was just trying to help on the FTBFS RC bug during BSP Tokyo.

I found the actual cause - there's a race condition in the testsuite
which will usually (100% in practice) cause it to deadlock on single
processor systems. You can look at the bug I filed upstream if you want.

> What I know is this is not rare, like another one I fixed:
> https://bugs.debian.org/854500

This is at best a big hack, since it almost certainly hides a real bug,
but I guess in this situation it does kind of work since the bug is in
the testsuite.

> Could you kindly help to upload?
> Buildd [0] shows it actually build fine for all ARCHs I should build,
> so I don't what to trigger the autoremove ...

James



signature.asc
Description: OpenPGP digital signature

Bug#855193: RFS: slt/0.0.git20140301-2.1 [RC][NMU] -- TLS reverse-proxy with SNI multiplexing (TLS virtual hosts)

[James Cowgill]

Hi,

On 15/02/17 10:19, Roger Shimizu wrote:
> Package: sponsorship-requests
> Severity: important
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "slt" as [RC][NMU].
> I posted the patch to Bug#851876 for 4 days but no feedback.
> And pkg maintainer is in LowThresholdNmu list.
[...]
> Changes since the last upload:
> 
>   slt (0.0.git20140301-2.1) unstable; urgency=medium
> 
> [ Roger Shimizu ]
> * Non-maintainer upload.
> * debian/rules:
>   - Run dh_auto_test only if CPUs >= 2 (Closes: #851876).
> 
> I also enclosed the debdiff for NMU review.
> Thank you!

So do you know why the tests only pass when using 2 CPUs? That seems
pretty fishy to me. Maybe there is an underlying bug here?

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#854933: RFS: synergy/1.4.16-2

[James Cowgill]

Hi,

On 12/02/17 12:51, Arturo Borrero Gonzalez wrote:
> On 12 February 2017 at 09:06, Joshua Honeycutt  
> wrote:
>>
>> I understand this upload occurs during the stretch freeze and I
>> believe my changes are
>> acceptable according to the freeze policy. I think I understand the
>> unblocking process
>> once this package is uploaded and builds correctly. My debdiff for the
>> unblock bug is
>> attached and I would appreciate feedback in case I have created it 
>> incorrectly.
>>
> 
> Hi Joshua,
> 
> please send the debdiff to the release team, so open a bug in their
> pseudo-package (use reportbug). I can sponsor the upload if they allow
> this change in stretch. Let me know.

Note that the procedure for uploads during the freeze changed for
stretch[1]. You no longer need release team pre-approval for most
changes (and this upload looks fine to me).

[1] https://lists.debian.org/debian-devel-announce/2017/02/msg1.html

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#853127: RFS: osmose-emulator/1.0-3

[James Cowgill]

Control: retitle -1 RFS: osmose-emulator/1.0-3 [QA]

Hi,

On 29/01/17 23:32, Carlos Donizete Froes wrote:
> Package: sponsorship-requests
> Severity: normal
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "osmose-emulator"
[...]
>   Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> https://mentors.debian.net/debian/pool/main/o/osmose-emulator/osmose-emulator_1.0-3.dsc

Firstly, this is not a QA upload because you are already the maintainer.

The above dsc does not extract because you have used the wrong upstream
tarball. You have to use exactly (ie byte for byte identical) upstream
tarball which has already been uploaded when adding a new Debian revision.

The head of the changelog contains:
 * Restrict architecture to any-i386 any-amd64

I assume this is an attempt to fix #844779? As a porter, I find this a
bit disappointing especially since the package builds fine on the
majority of architectures. I suggest instead that you ask for this
package to be removed on armel and armhf (see [1]). That bug can then be
downgraded.

This package has a packaging repository, but it doesn't seem to be used?
https://anonscm.debian.org/cgit/pkg-games/osmose-emulator.git

[Note: I am not intending on sponsoring your package in any case, I'm
just pointing out a few issues with it]

[1] https://wiki.debian.org/ftpmaster_Removals

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Adequate reports obsolete conffiles: and now what?

[James Cowgill]

Hi,

On 21/01/17 09:51, Alec Leamas wrote:
> The new, shiny lirc 0.9.4 has received a bug report #851618. At the
> core, this is about adequate reporting
> 
> lirc: obsolete-conffile /etc/lirc/irexec.lircrc
> lirc: obsolete-conffile /etc/lirc/lircmd.conf
> lirc: obsolete-conffile /etc/lirc/hardware.conf
> lirc: obsolete-conffile /etc/lirc/lircd.conf
> lirc: obsolete-conffile /etc/lirc/lirc_options.conf
> 
> However, all of these files exists for a purpose and are not obsolete.

By definition, an obsolete conffile is a file which used to be a
conffile, isn't in a new package version, but wasn't moved/removed on
upgrade.

> The details:
> 
> - hardware.conf is indeed obsolete in 0.9.4. However, the manual,
> breaking update is about moving bits and pieces from hardware,conf to
> other files, so it needs to be around for some cycles  before it's removed.

Removing a conffile with dpkg-maintscript-helper will actually move it
(to xxx.dpkg-back) if it was modified, so I think you can safely remove
this as users will still be able to refer to it later.

> - For the other files I'm using my own scheme: The upstream files are
> installed as e. g.,lirc_options.conf.dist. This file is updated but not
> used. If the actually used lirc_options.conf is missing it's created as
> a copy of the *dist file, but otherwise kept as-is.. In other words, I
> don't try to merge possible upstream changes, I just keep the *dist
> files around as reference

Isn't this the problem conffiles was meant to solve? Dpkg will ask the
user before updating those config files and not touching them is the
default option. This will also warn the user when they may need to
update them anyway (eg new features).

I guess this is a maintainer decision on how they want to do this (even
if I think it's a bad idea) so using .dist files is still OK. In this
case, and as long as you're sure your maintainer scripts always do the
right thing, you can ignore adequate. However I think the .dist files
should be installed in /usr/share and copied from there instead of being
installed in /etc. Presumably these .dist files have been (incorrectly)
marked as conffiles already?

> Since the overall idea is that the adequate (or really dpkg) error
> message is a bug: How should I resolve this bug?

James



signature.asc
Description: OpenPGP digital signature

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

[James Cowgill]

On 19/01/17 12:20, Thibaut Paumard wrote:
> Le 19/01/2017 à 12:20, James Cowgill a écrit :
>> On a separate note: does this interfere with the alternatives system
>> which openmpi currently has? If an rpath is used, it will override any
>> libraries in the default linker search path so even if the mpi
>> alternative is changed, many applications will still use libmpi from
>> /usr/lib/x86_64-linux-gnu/openmpi/lib.
> 
> This is as it should be. The two alternative implementations (openmpi
> and mpich) are not binary-compatible.

Ahh sorry, I misread where the symlinks were pointing to. Indeed only
the .so files from the -dev package are under the alternatives system.

James



signature.asc
Description: OpenPGP digital signature

Re: OpenMPI rpath entries (Was: question on binary-or-shlib-defines-rpath)

[James Cowgill]

Hi,

On 18/01/17 22:39, Nico Schlömer wrote:
> I'm co-maintaining the Trilinos package [1] in Debian and recently found
> a bunch of new lintian warnings of the kind
> binary-or-shlib-defines-rpath [2]. It say in the description of the warning:
> ```
> To fix this problem, look for link lines like: 
> 
> gcc test.o -o test -Wl,--rpath,/usr/local/lib
> 
> or 
> 
> gcc test.o -o test -R/usr/local/lib
> 
> and remove the -Wl,--rpath or -R argument.
> ```
> Indeed, the Trilinos installation contains many of those lines, but they
> are necessary too. When executing the test binaries (which are compiled
> in the build tree alongside the libraries), they have to find the linked
> shared libraries. Messing with the rpath is necessary.
> 
> That's not true later on when the libraries are _installed_, of course.
> For this, CMake has the switch CMAKE_SKIP_INSTALL_RPATH [3], which
> serves exactly that purpose. For some reason, lintian doesn't seem to be
> happy with that though.

The CMAKE_SKIP_INSTALL_RPATH option only affects the rpaths which CMake
itself inserts. It does not affect any rpaths manually added with other
-Wl,--rpath options. The culprit here is probably openmpi which adds all
of these rpath entries:

$ mpicc -show
[...] -Wl,-rpath -Wl,/usr//lib -Wl,-rpath
-Wl,/usr/lib/x86_64-linux-gnu/openmpi/lib [...]

Maybe it shouldn't do that. The /usr//lib one is clearly useless and the
it seems that most of the libraries from
/usr/lib/x86_64-linux-gnu/openmpi/lib are symlinked into
/usr/lib/x86_64-linux-gnu anyway.

On a separate note: does this interfere with the alternatives system
which openmpi currently has? If an rpath is used, it will override any
libraries in the default linker search path so even if the mpi
alternative is changed, many applications will still use libmpi from
/usr/lib/x86_64-linux-gnu/openmpi/lib.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: mpgrafic - mpirun test program as root in automatic build

[James Cowgill]

Hi,

On 16/01/17 23:58, Boud Roukema wrote:
> hi Debian-mentors,
> 
> Is it reasonable to override the mpirun (openmpi_2.0.2~git.20161225-8)
> default preference of refusing to run as root?
> 
> I've started packaging mpgrafic for debian - this is my first
> debianisation, apart from minor private hacks after extracting debian
> source packages:
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/
> 
> I've added regression-test-0.3.7.sh to the upstream version of
> mpgrafic. This is a "reproducible run" test. The test runs the main
> binary, mpgrafic, with a frontend "mpirun", which, in general, allows
> a program to run on many different machines, without shared memory.
> This test runs explicitly on exactly one processor, for reproducibility.
> 
> Since, in general, there is no reason for mpirun to run as root,
> the sid version of mpirun (from openmpi) apparently refuses to run as root.
> (I have not reproduced this behaviour myself - Ole Streicher
> has warned me about it.) The openmpi developers provide an option
> --allow-run-as-root.
> 
> In version 0.3.7.4-1, the debian-only, openmpi-only use of this option in
> debian/rules + regression-test-0.3.7.sh
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/debian/rules
> 
> https://anonscm.debian.org/cgit/debian-astro/packages/mpgrafic.git/tree/regression-test-0.3.7.sh
> 
> 
> should presumably allow debian automatic builds to pass "make check".

I'm not sure I follow. Debhelper runs the testsuite during the build
target so it shouldn't be run as root anyway. I don't think you need any
workarounds at all for this.

James



signature.asc
Description: OpenPGP digital signature

Re: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[James Cowgill]

Hi,

On 06/12/16 22:34, Christian Seiler wrote:
> On 12/06/2016 11:22 PM, James Cowgill wrote:
>> The version number should be the version number immediately before the
>> one where the dpkg-maintscript stuff is added, not when the symlink was
>> converted to a directory.
>>
>> In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
>> in 1.95-4.8-2).
> 
> I wouldn't use that version if you ever want to backport that specific
> version of the package, it's better to specify the previous Debian
> version directly, in this case 1.95-4.8-1.

There is actually a section in dpkg-maintscript-helper(1) about why this
is a bad idea (it breaks local builds or anyone else who manually
patched your package).

Note that 1.95-4.8-2~ sorts before 1.95-4.8-2~deb8+1 anyway so there is
no issue with backports here.

James



signature.asc
Description: OpenPGP digital signature

Re: Please help with symlink_to_dir expression (Was: Bug#847234: r-cran-rcurl: directory vs. symlink conflict: /usr/lib/R/site-library/RCurl/examples)

[James Cowgill]

Hi,

On 06/12/16 21:36, Andreas Tille wrote:
> On Tue, Dec 06, 2016 at 07:06:39PM +0100, Andreas Beckmann wrote:
>> Package: r-cran-rcurl
>> Version: 1.95-4.8-1
>> Severity: serious
>> User: debian...@lists.debian.org
>> Usertags: piuparts
>>
>> ...
>> >From the attached log (usually somewhere in the middle...):
>>
>> 2m19.9s INFO: dirname part contains a symlink:
>>   /usr/lib/R/site-library/RCurl/examples/CIS (r-cran-rcurl) != 
>> /usr/share/doc/r-cran-rcurl/examples/CIS (?)
>> /usr/lib/R/site-library/RCurl/examples -> 
>> ../../../../share/doc/r-cran-rcurl/examples
>>   /usr/lib/R/site-library/RCurl/examples/CIS/cis.R (r-cran-rcurl) != 
>> /usr/share/doc/r-cran-rcurl/examples/CIS/cis.R (?)
>> /usr/lib/R/site-library/RCurl/examples -> 
>> ../../../../share/doc/r-cran-rcurl/examples
>> ...
> 
> I tried to fix this the following way.  In the Jessie package
> r-cran-rcurl_1.95-4.3-1+deb8u1_amd64.deb the examples link is:
> 
> 
> $ readlink /usr/lib/R/site-library/RCurl/examples 
> ../../../../share/doc/r-cran-rcurl/examples
> 
> 
> Since in the package in unstable examples is a directory I tried
> to fix the upgrade path by
> 
> 
> $ cat debian/maintscript
> symlink_to_dir /usr/lib/R/site-library/RCurl/examples 
> ../../../../share/doc/r-cran-rcurl/examples 1.95-4.3-1

The version number should be the version number immediately before the
one where the dpkg-maintscript stuff is added, not when the symlink was
converted to a directory.

In this case you probably want to use "1.95-4.8-2~" (if the bug is fixed
in 1.95-4.8-2).

See dpkg-maintscript-helper(1) prior-version section.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Problems with openssl when upgrading r-bioc-rtracklayer

[James Cowgill]

Hi,

On 04/12/16 19:55, Andreas Tille wrote:
> I tried to upgrade r-bioc-rtracklayer[1] to the latest upstream version
> (see trunk in SVN) but the build failed with:
> 
> * installing *source* package 'rtracklayer' ...
> ./configure: line 1676: syntax error near unexpected token `OPENSSL,'
> ./configure: line 1676: `PKG_CHECK_MODULES(OPENSSL, openssl >= 1.0, 
> OPENSSL="yes", OPENSSL="no")'
> ERROR: configuration failed for package 'rtracklayer'
> * removing 
> '/build/r-bioc-rtracklayer-1.34.1/debian/r-bioc-rtracklayer/usr/lib/R/site-library/rtracklayer'
> dh_auto_install: R CMD INSTALL -l 
> /build/r-bioc-rtracklayer-1.34.1/debian/r-bioc-rtracklayer/usr/lib/R/site-library
>  --clean . --built-timestamp='Wed, 30 Nov 2016 22:37:27 +0100' returned ex
> 
> 
> This check results from
> 
> PKG_CHECK_MODULES(OPENSSL, [openssl >= 1.0], [OPENSSL="yes"], [OPENSSL="no"])
> 
> in configure.ac - I have no idea why this fails.  Any helpful hint?

Do you have pkg-config installed?

James



signature.asc
Description: OpenPGP digital signature

Re: acedb: Another watch file issue for ftp site

[James Cowgill]

On 03/12/16 16:02, Andreas Tille wrote:
> On Sat, Dec 03, 2016 at 01:57:35PM -0200, Eriberto wrote:
>> 2016-12-03 13:54 GMT-02:00 Andrey Rahmatullin :
>>> Um.
>>> Maybe it's somehow linked to the fact that there is no "acedb" in the ls
>>> result at ftp://ftp.sanger.ac.uk/pub (even though cd works).
>>
>> yeap!
> 
> In other words:  There is no chance to fetch the archive from there? 
> 
> I'd not call this a real constraint since there was no update for nearly
> 10 years - but anyway, it would be nice to have.

Seems to be the same directory as:
ftp://ftp.sanger.ac.uk/pub/project/acedb/

which may work.

James



signature.asc
Description: OpenPGP digital signature

Re: Waiting for a package uploaded to ‘experimental’

[James Cowgill]

On 28/10/16 10:58, Ben Finney wrote:
> Howdy all,
> 
> I have uploaded a source package to the ‘expierimental’ queue. Where
> should I look for its build status?
> 
> How long would it typically take to appear at packages.debian.org after
> uploading the source package to the queue?

Which package?

dinstall has been running for the past 2 hours which may have delayed it.

James



signature.asc
Description: OpenPGP digital signature

Re: useless lintian error?

[James Cowgill]

On 28/09/16 10:55, Gianfranco Costamagna wrote:
> Hi mentors,
> I did a doona upload, with "closes #foo" in changelog, getting
> a lintian error:
> 
> E possible-missing-colon-in-closes
> closes #838630
> 
> since the bug is closed

It doesn't look closed to me.

> because the system closes bugs even without the colon, isn't this time to drop
> that error?

The uses 'Closes:' with a colon to close bugs is required by Policy
(section 4.4).

James



signature.asc
Description: OpenPGP digital signature

Re: update .preinst file

[James Cowgill]

Hi,

On 13/09/16 18:37, Herbert Fortes wrote:
> I have to update 4 debian/*.preinst files.
> 
> Right now the files are like here[0]:
> 
> 
> if dpkg --compare-versions "$2" lt "1.2.4+dfsg1-7" ; then
>rm -rf /usr/share/doc/bogofilter || true
> fi
> 
> 
> [0] -  
> https://anonscm.debian.org/git/collab-maint/bogofilter.git/tree/debian/bogofilter.preinst
> 
> 
> This approach has problems on an upgrade from Jessie to 
> Stretch[1].The recommendation today is to use 'dpkg-maintscript-helper', so
> I should change to ("a  real directory  is switched to a symlink"):
> 
> [1] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832291
> 
> if dpkg-maintscript-helper supports dir_to_symlink 2>/dev/null; then
> dpkg-maintscript-helper dir_to_symlink \
>/usr/share/doc/bogofilter bogofilter 1.2.4+dfsg1-8 bogofilter 
> -- "$@"  
> fi

Don't bother doing this. Use dh_installdeb and 'package.maintscript'
files instead. You can then drop all the preinst files.

>>From the manpage:
> 
> "pathname(/usr/share/doc/bogofilter here)  is the absolute name of the old 
> directory (the path will be a symlink at the end of the installation) and 
> new-target (bogofilter here) is the target of the  new  symlink at pathname. 
> It can either be absolute or relative to the directory containing pathname."
> 
> But the symlink is created by dh_installdocs[1] already. I just want to 
> remove 
> the directory.

Due to the way dpkg-maintscript-helper is implemented, the symlink
created with dh_installdocs is ignored, so dpkg-maintscript-helper will
create it for you. The manpage for dpkg-maintscript-helper also contains
an explanation of why 'just removing the directory in preinst' can cause
problems.

I think putting this into 'bogofilter-bdb.maintscript' and something
similar in other maintscript files should work:

dir_to_symlink /usr/share/doc/bogofilter-bdb
/usr/share/doc/bogofilter-common 1.2.4+dfsg1-8~

James



signature.asc
Description: OpenPGP digital signature

Bug#836959: RFS: usbguard/0.6.0+ds1-1

[James Cowgill]

Hi,

On 07/09/16 16:24, Muri Nicanor wrote:
> PS: I tried to test the build process on a qemu-mips machine, but i only
> could create a qemu-system-mips machine with 256MB ram, which was not
> enough for the build process. But christian said that he build-tested
> the patch and i trust his judgment.

[not directly related to the package but anyway...]

This is an unfortunate problem with the MIPS Malta kernel currently, in
that it doesn't auto-detect the amount of memory available. You have to
use something like this to make it work:

-m 2G -append 'mem=256m@0 mem=1792m@0x9000'

There is a patch to fix this though - hopefully it will get into 4.9 for
stretch:
https://www.linux-mips.org/archives/linux-mips/2016-09/msg00095.html

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: [ITA] muse-el, with issues, and questions

[James Cowgill]

On 29/08/16 21:49, Nicholas D Steeves wrote:
> Hi,
> 
> I'm adopting muse-el.  Right now it's a work-in-progress.  The steps I
> took to fixup this package can be found here:
> 
> https://github.com/sten0/muse-el
> clone: https://github.com/sten0/muse-el.git
> 
> I've also uploaded a package, with "-sa" full sources for review here:
> https://mentors.debian.net/package/muse-el
> https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+dfsg-1.dsc
> 
> I'm not sure what to make of lintian Error
> "license-problem-gfdl-invariants" against the README.  The README
> says:
> The Muse manual is available under the terms of the GNU Free
> Documentation License, Version 1.2 or any later version published by
> the Free Software Foundation; with no Invariant Sections, and with the
> Front-Cover texts and Back-Cover Texts as specified in the manual.
> 
> Does the README itself also fall under the GFDL or GPL-3?  If not,
> I'll have to add another exclusion to debian/copyright.  Additionally,
> should I break out the documentation into a non-free muse-el-doc
> package?

This seems to be bug #695783 which was fixed in 3.20+dfsg-0.1 by
removing the manual. If you haven't repacked the source, the manual
should still be removed so there shouldn't be a problem here. The
copyright statement specifically refers to the Muse manual so the README
file should be fine. Assuming there aren't any more cases of this in the
package, you can probably override the lintian error (with a suitable
comment).

> Finally, is now the time to fix the
> debian-rules-missing-recommended-target warning?  I'm saving homepage
> and Vcs fields for last.

Yes, those targets are required by policy (even though there are masses
of packages which don't implement them). Since you're adopting the
package, I would rewrite the whole of d/rules using dh.

James



signature.asc
Description: OpenPGP digital signature

Bug#801262: RFS: ppsspp/1.2.2+dfsg1-1 [ITP] -- A portable PSP emulator

[James Cowgill]

On Mon, 2016-08-22 at 09:41 +0100, James Cowgill wrote:
> Hi,
> 
> On Mon, 2016-08-22 at 00:50 -0300, Sérgio Benjamim wrote:
> > 
> > I'm trying to build it in sid, and I got a "cannot find 
> > -lavformat-ffmpeg". Did the ffmpeg lib links change [again]?
> 
> You need to use -lavformat (and others) to link with ffmpeg. The
> ffmpeg suffix was only used in the transitional period when we
> switched from libav to ffmpeg.

This should also be reverted:
https://github.com/hrydgard/ppsspp/commit/e81fa01bf0f5e75c6ab16ca1d525dc73e36bcf62

The entire ffmpeg situation was a temporary hack back then - the above
should have never been comitted.

James

signature.asc
Description: This is a digitally signed message part

Bug#801262: RFS: ppsspp/1.2.2+dfsg1-1 [ITP] -- A portable PSP emulator

[James Cowgill]

Hi,

On Mon, 2016-08-22 at 00:50 -0300, Sérgio Benjamim wrote:
> I'm trying to build it in sid, and I got a "cannot find 
> -lavformat-ffmpeg". Did the ffmpeg lib links change [again]?

You need to use -lavformat (and others) to link with ffmpeg. The ffmpeg
suffix was only used in the transitional period when we switched from
libav to ffmpeg.

James

signature.asc
Description: This is a digitally signed message part

Re: Bug#834268: RFS: open-invaders/0.3-5 [NMU] [ITA]

[James Cowgill]

Hi,

On 17/08/16 21:59, Hanno 'Rince' Wagner wrote:
> I am packaging open-invaders, a clone of space invaders. I was able to
> "port" it (with a lot of help from friends) to gcc-6, but I have a
> problem with the used libraries.
> 
> I am able to successfully compile and package open-invaders. But when
> I want to start it, the initialization of allegro4 seems to fail:
> 
> [~]$ open-invaders 
> /usr/share
> Segmentation fault

I cannot reproduce this. Your package on mentors runs fine for me.

> I used gdb and found that open-invaders crashed while initializing
> allegro:
[...]
> Thread 1 "open-invaders" received signal SIGSEGV, Segmentation fault.
> 0x77704cc7 in install_timer () from 
> /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
> (gdb) bt
> #0  0x77704cc7 in install_timer () from 
> /usr/lib/x86_64-linux-gnu/liballeg.so.4.4
> #1  0xfbd5 in initialise_game () at init.cc:521
> #2  0x74f4 in main (argc=1, argv=0x7fffe668) at main.cc:81
> (gdb) 

Install liballeggl4.4-dbgsym from the debug repository [1] and then use
'bt full' to get a full backtrace which should have much more
information about the segfault.

Also, do other allegro4 games work for you?
$ apt-cache rdepends liballegro4.4

[1] https://wiki.debian.org/AutomaticDebugPackages

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Re: Ups, pbuilder chroot broken - here comes the real build error (Was: New version of phyml: Can't exec "gcc": No such file or directory)

[James Cowgill]

Hi,

On 17/08/16 14:36, Andreas Tille wrote:
> On Wed, Aug 17, 2016 at 01:55:23PM +0100, James Cowgill wrote:
>>
>> I think there might be something up with your pbuilder chroot.s
> 
> After updating this the strange error vanished - sorry for the noise.
> 
>> At least
>> the initial stages of the build work fine for me with sbuild (gcc errors
>> out later though).
> 
> So lets come to the real build errors of [1]: I just fixed the first issue
> in a new patch (please git pull) but I do not understand this one:
> 
> ...
> gcc  -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2  -Wall -O2 -msse 
> -fomit-frame-pointer -funroll-loops -Wempty-body -Wuninitialized  
> -I/usr/include/libhmsbeagle-1 -lhmsbeagle -ldl  -c -o lk.o lk.c
> lk.c: In function 'Update_PMat_At_Given_Edge':
> lk.c:2449:31: error: invalid initializer
>int p_matrices[1] = b_fcus->Pij_rr_idx;
>^~
> lk.c:2450:31: error: invalid initializer
>double branch_lens[1] = len;

You can't initialize an array with a scalar value (double[] != double).
Also, using an array of fixed size 1 is a code smell (why use an array
at all?)

The quick fix here is probably to wrap the values in curly braces to
form a correct array initializer.

James



signature.asc
Description: OpenPGP digital signature

Re: New version of phyml: Can't exec "gcc": No such file or directory

[James Cowgill]

Hi,

On 17/08/16 13:28, Andreas Tille wrote:
> when trying to build the latest version of phyml[1] in pbuilder as usual
> I get a very strange error which is possibly best summarised by grepping
> for gcc:
> 
> $ grep gcc phyml_3.2.20160530+dfsg-1_amd64.build | grep -v Depends | tail -n 8
> Preparing to unpack .../3-gcc-6-base_6.1.1-12_amd64.deb ...
> Unpacking gcc-6-base:amd64 (6.1.1-12) over (6.1.1-11) ...
> Setting up gcc-6-base:amd64 (6.1.1-12) ...
> Preparing to unpack .../libgcc1_1%3a6.1.1-12_amd64.deb ...
> Unpacking libgcc1:amd64 (1:6.1.1-12) over (1:6.1.1-11) ...
> Setting up libgcc1:amd64 (1:6.1.1-12) ...
> Can't exec "gcc": No such file or directory at /usr/share/perl5/Dpkg/Arch.pm 
> line 128.
> Can't exec "gcc": No such file or directory at /usr/share/perl5/Dpkg/Arch.pm 
> line 128.
> 
> Any explanation for this strange behaviour?

I think there might be something up with your pbuilder chroot. At least
the initial stages of the build work fine for me with sbuild (gcc errors
out later though).

Also I don't think you've given enough of the build log for anyone to
help you that well. The only thing I can think of is that gcc isn't in
the PATH at that point (either not installed or the PATH is clobbered
somewhere). Not having a "Setting up gcc-6" line appearing after the
"Setting up gcc-6-base" line also seems a little fishy to me.

James



signature.asc
Description: OpenPGP digital signature

Re: Bug#834013: emboss, emboss-data: both packages ship /usr/share/man/man1/em_cons.1e.gz

[James Cowgill]

Hi,

On 12/08/16 14:58, Andreas Tille wrote:
> Hi,
> 
> this version was a source only upload.  If I build on my local machine
> emboss-data does not contain any dir /usr/share/man.  However, the
> binary package on the Debian mirror contains /usr/share/man/man1 with
> has two symlinks which are identical to those in the emboss package.
> 
> I can not reproduce this and I'm wondering why the source only upload
> creates files that are not created on a local build.

debian/rules contains:

override_dh_installman:
dh_installman -a -p emboss
for i in $(RENAMED) ; \
do dh_link usr/share/man/man1/$$i.1e.gz
usr/share/man/man1/em_$$i.1e.gz ; \
done

dh_link will install the symlink into the first package in debhelper's
list of packages. When doing an arch:amd64 upload this is "emboss", but
when doing an arch:all upload (which happens when you do a source
uploaded) this is "emboss-data". Thus you get two symlinks which
conflict with each other.

You should be able to reproduce this by doing two separate builds:
 One with dpkg-buildpackage -B
 One with dpkg-buildpackage -A

And comparing the generated debs.

The simple solution is to use "dh_link -pemboss" to force the symlinks
to be installed into that package.

James



signature.asc
Description: OpenPGP digital signature

Re: Creating packages for one of my C project

[James Cowgill]

Hi,

On 01/08/16 16:43, Gianfranco Costamagna wrote:
>> I would like to create 3 packages for the core part: lib (for the shared 
>> library object), dev (for headers), and doc (for documentation generated by 
>> doxygen).
> 
> 
> maybe two binaries? I guess you need one package for each repo.
> e.g.
> git1 providing the lib and headers
> 
> git2 providing the core, doc and whatever

I'm not sure I follow. Three binary packages (lib, dev, doc) is fairly
standard for a shared library package. I would expect each git repo to
be a separate source package, unless they are very tightly coupled together.

James



signature.asc
Description: OpenPGP digital signature

Re: Extracting debhelper functionality

[James Cowgill]

On Fri, 2016-07-29 at 15:33 +0300, Dmitry Bogatov wrote:
> Hello!
> 
> During my work to resolve (#832656), I encountered need to NMU
> bcron-run package. It is old-style package, that does not use
> debhelper.
> 
> I inserted call to one particular debhelper (dh_runit) in Makefile
> (total modernization in discouraged in NMU, and probably would take
> more efford).
> 
> It is all okay, but seems I need to call something more to
> 
>  - substitute #DEBHELPER# token in maintainer scripts
>  - substitute ${misc:Depends} in debian/control.
> 
> since while `bcron-run.substvars' and `bcron-run.preinst.debhelper'
> succesfully created, they seems to not influence package built by the
> fact of their existance.
> 
> What do I miss?

#DEBHELPER# is handled by dh_installdeb
misc:Depends is handled by dh_gencontrol

You'll also need dh_prep if you use any debhelper commands. But once
you've added these, you'll have half converted the package to use
debhelper anyway. Having the maintainer do a proper upload to switch to
using at least some form of debhelper would be the best solution here
IMO.

James

Re: dpkg-buildpackage: dpkg-source: no upstream tarball found

[James Cowgill]

Hi,

On Wed, 2016-07-27 at 23:16 +0200, chrishell wrote:
> Hello together,
> I have an issue with the new version of my package free42-nologo. I
> processed this the usual way: downloading, unpacking, debianize it
> with dh_make and making some changes with dquilt (makefile mainly). 

Since this is an update to an existing package, you don't need to re-
deianize it or run dh_make again. From within the packaging of the old
version, simply run 'uupdate -v  '.

See:
https://www.debian.org/doc/manuals/maint-guide/update.en.html#newupstream

> Then I invoked dpkg-buildpackage -rfakeroot -us -uc and here I got en
> error for the wrong archive format of upstream:
> 
> dpkg-source: error: can't build with source format '3.0 (quilt)': no
> upstream tarball found at
> ../free42-nologo_1.4.77.orig.tar.{bz2,gz,lzma,xz} no upstream tarball
> ...

The error message is still referencing the old version number. This
probably means you havn't added a new debian/changelog entry yet.

James

signature.asc
Description: This is a digitally signed message part

Bug#831792: RFS: scid/1:4.6.2-0.1 [NMU]

[James Cowgill]

On Tue, 2016-07-26 at 18:18 +, Gianfranco Costamagna wrote:
> control: owner -1 !
> control: tags -1 moreinfo
> 
> > I am looking for a sponsor for my package "scid":
[...]
> 3) 
> X: scid source: maybe-not-arch-all-binnmuable scid -> scid-data

This lintian tag does not indicate your package has a bug in it. The
tags description even states that you should not attempt to fix it.

James

signature.asc
Description: This is a digitally signed message part

Re: Help with shlibs system

[James Cowgill]

Hi,

On Mon, 2016-07-18 at 12:48 +0200, Peter Spiess-Knafl wrote:
> I would need some advice about the following bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820434
> 
> Stephen mentioned there I should provide a shlibs minimum version.
> I am not entirely sure what that means.
> Do I need to put a file under debian/shlibs with the following line?
> 
> libjsoncpp 1 libjsoncpp1
> 
> dh_makeshlibs creates exactly such a file under
> debian/libjsoncpp1/DEBIAN/shlibs.
> 
> What am I missing here?

An "shlibs minimum version" is a change to the shlibs/symbols control
files which causes reverse dependencies to emit something like
'Depends: libjsoncpp1 (>= XX)' instead of 'Depends: libjsoncpp1'

To do this you can either add a symbols file (this is documented in
policy), or override dh_makeshlibs with 'dh_makeshlibs -Vversion' if
you want to use a simple shlibs file. See dh_makeshlibs(1).

Symbols files are usually better since you get more fine grained
control of dependencies, but they take a lot more time to maintain
(especially for C++ libraries).

James

signature.asc
Description: This is a digitally signed message part

Re: libgdbm transition

[James Cowgill]

On Wed, 2016-07-13 at 07:35 +0100, Rebecca N. Palmer wrote:
> > We do not have automation
> > to rebuild packages and file FTBFS bugs, do we?
> 
> Automated whole-archive rebuilds have been done (see e.g. 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768691 ), but I
> don't know whether they are done regularly.

I think Dmitry is referring to the rebuilding of libgdbm reverse
dependencies which will be needed for this transition.

This is automated by the release team (see the transitions policy) once
a transition starts. For the transition to start, either all the FTBFS
bugs you found need to be fixed in unstable, or the packages in
question need removing from testing. You will have to file all the bugs
manually, but I expect all the bugs will follow a similar template.

James

signature.asc
Description: This is a digitally signed message part

Re: How to express the copyright for the debian/ sub folder?

[James Cowgill]

Hi,

On Fri, 2016-07-08 at 12:23 +, Patrick Schleizer wrote:
> Hi!
> 
> I: corridor source: unused-file-paragraph-in-dep5-copyright paragraph
> at line 3
> 
> https://github.com/adrelanos/corridor/blob/debian_new/debian/copyright
> 
> Any idea what is wrong in the debian/copyright file?

From here:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#files-field

"Multiple Files paragraphs are allowed. The last paragraph that matches
a particular file applies to it. More general paragraphs should
therefore be given first, followed by more specific overrides."

So your 'Files: *' paragraph overrides the 'Files: debian/*' paragraph.
Moving the 'Files: debian/*' paragraph to the bottom should fix it.

James

signature.asc
Description: This is a digitally signed message part

Re: wrong version number ?

[James Cowgill]

Hi,

On Thu, 2016-07-07 at 15:30 -0300, Herbert Fortes wrote:
> I am doing a QA for dvbackup package. I do not need
> a Sponsor.
> 
> debian/changelog:
> dvbackup (1:0.0.4-8) unstable; urgency=low ( I am doing )
> dvbackup (1:0.0.4-7) unstable; urgency=low ( current version )
> 
> After 'debuild':
> 
> dvbackup_0.0.4-8_amd64.deb ( no epoch )
> 
> $ apt-get download dvbackup
> dvbackup_1%3a0.0.4-7_amd64.deb ( epoch )

This is normal. By default, dpkg-deb does not include the epoch in the
filename, whereas when apt downloads packages it renames it. This
usually isn't a problem because dpkg ignores the filename anyway.

> Why ?

I'm not entirely sure, but it's been like this since forever.

James

signature.asc
Description: This is a digitally signed message part

Bug#829286: RFS: newlisp/10.7.0-2

[James Cowgill]

Hi,

On Sun, 2016-07-03 at 14:28 -0400, Sergio Durigan Junior wrote:
> On Sunday, July 03 2016, Gianfranco Costamagna wrote:
> > as a DM, I'm pretty sure (but I can't check this anymore since I
> > moved to DD),
> > that you can reschedule stuff for other people too.
> > Can you please try this command?
> > dcut ftp-master reschedule -d 0 -f newlisp_10.7.0-2_source.changes
> > 
> > this should move the newlisp in incoming queue
> 
> Hm, here's what I see when I try it:
> 
>   D: dcut 0.2.1
>   D: trying to get maintainer email from environment
>   D: Uploader from env: Sergio Durigan Junior 
>   D: first argument "ftp-master" treated as host
>   D: loading dput
>   D: calling dput.read_configs
>   D: Parsing Configuration File /etc/dput.cf
>   D: Parsing Configuration File /home/sergio/.dput.cf
>   D: Successfully parsed command "reschedule -d 0 -f 
> newlisp_10.7.0-2_source.changes"
>   D: calling debsign: ['debsign', '-mSergio Durigan Junior ',
>   
> '/tmp/dcut.RMMfsD/dcut.Sergio_Durigan_Junior__sergiodj_sergiodj_net_.1467570258.1694.commands']
>   .commands file has invalid Commands line: reschedule -d 0 -f 
> newlisp_10.7.0-2_source.changes
>   debsign: .commands file appears to be invalid. see:
>   ftp://ftp.upload.debian.org/pub/UploadQueue/README
>   for valid format
>   Error: debsign failed.
> 
> Is this my fault?

I think the syntax is:
 dcut reschedule newlisp_10.7.0-2_source.changes 0-day

The above link that dcut outputted contains the format of all the
available commands.

James

signature.asc
Description: This is a digitally signed message part

Bug#828024: RFS: libretro-beetle-wswan [ITP]

[James Cowgill]

Hi,

On Mon, 2016-06-27 at 10:00 -0400, PICCORO McKAY Lenz wrote:
> this package are market as done! but the package are still not in
> debian package !
> 
> removed yet from mentors but i cannot retrieve from sid! the dsc file
> are not found!

The package was acccepted into unstable about an hour ago:
 https://tracker.debian.org/news/778708

You'll need to wait a bit for the archive software to update itself and
for all the mirrors to sync. It should appear later today.

James

signature.asc
Description: This is a digitally signed message part

Bug#827623: RFS: luakit/2012.09.13-r1-9 ITA -- fast and small web browser extensible by Lua

[James Cowgill]

Control: tags -1 moreinfo

Hi,

On Sat, 2016-06-18 at 13:28 -0700, Herminio Hernandez, Jr. wrote:
> Package: sponsorship-requests
> Severity: normal
> 
>  Dear mentors,
> 
>  I am looking for a sponsor for my package "luakit"

It seems the only change you've made to the package is to set the
Maintainer field to yourself. I doubt you will get sponsorship for this
because you haven't actually improved anything.

There are bug reports here you could look at:
https://bugs.debian.org/luakit

This bug might be an issue for the stretch release:
https://bugs.debian.org/790207

Also the lintian errors here:
https://lintian.debian.org/maintainer/packa...@qa.debian.org.html#luakit

I see from this bug that luakit has been recently revived using the
contents of a fork:
https://github.com/luakit/luakit/issues/299

You should try and get them to make an official release which you could
then package.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#825302: RFS: usbguard/0.4-2 [ITP]

[James Cowgill]

Control: severity -1 wishlist
Control: block 791919 by -1
Control: tags -1 moreinfo

Hi,

On Wed, 2016-05-25 at 21:10 +0200, Muri Nicanor wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "usbguard"

This looks like quite an interesting package, so here's a review.

You do not own the wnpp bug for this package. You need to retitle the
bug from an RFP to ITP and set yourself as the owner. Do this before
trying to fix anything else.

Since libusbguard.so is in a public libs directory, you must put it in
a separate package (probably called libusbguard0). You should then put
all the development files in libusbguard-dev. I see you added a lintian
override for this, but didn't say why you did it in the comment.

Please run wrap-and-sort so wrap the Build-Depends field in the control
file.

You don't need the -2 changelog entry since your -1 version was never
uploaded.

You add a group "usbguard" in postinst but didn't remove it in postrm.
You should probably do that during the purge step.

The other things in postrm seem incorrect. Why do you need to remove
the service file manually?

"usbguard" must depend on adduser to use addgroup in your postinst.

The *.install files should use a wildcard (*) instead of including the
multiarch directory manually. At the moment the package will FTBFS
everywhere except amd64.

In rules, --with-bundled-spdlog=no doesn't seem to work.

Enable parallel building (dh --parallel) if it works.

You build-depend on dh-autoreconf, but don't actually run it. Use
something like "dh --with=autoreconf,systemd".

copyright:
 Upstream code is GPL-2+ (not GPL-2)
 The license identifier for the Boost License is "BSL-1.0"
 The license identifier for your "MIT-License" is "Expat"
  https://spdx.org/licenses/
 Authors isn't a valid field name. You can use Comment or
  Upstream-Contact instead.

The default config doesn't allow the root user to use usbguard. This
doesn't offer ant additional security, but does add inconvenience.

usbguard.service contains:
 WantedBy=base.target
but base.target doesn't exist on my system.

The usbguard-rules.conf manpage uses "usbguard-daemon.conf" in the NAME
section (and other places) which is obviously a typo.

Please submit the patch you added upstream when you get the chance.

Finally, although you've fixed all the lintian warnings, please try and
fix some of the info tags.

I: usbguard source: duplicate-short-description usbguard usbguard-dev
I: usbguard source: debian-watch-file-is-missing
I: usbguard: hardening-no-pie usr/bin/usbguard
I: usbguard: hardening-no-bindnow usr/bin/usbguard
I: usbguard: spelling-error-in-binary 
usr/lib/x86_64-linux-gnu/libusbguard.so.0.0.0 Uknown Unknown
I: usbguard: hardening-no-bindnow usr/lib/x86_64-linux-gnu/libusbguard.so.0.0.0
I: usbguard: hardening-no-pie usr/sbin/usbguard-daemon
I: usbguard: hardening-no-bindnow usr/sbin/usbguard-daemon
I: usbguard: spelling-error-in-manpage 
usr/share/man/man5/usbguard-rules.conf.5.gz formated formatted
I: usbguard: no-symbols-control-file 
usr/lib/x86_64-linux-gnu/libusbguard.so.0.0.0
I: usbguard: systemd-service-file-missing-documentation-key 
lib/systemd/system/usbguard.service

Hopefully I've covered everything!

James

signature.asc
Description: This is a digitally signed message part

Re: cdist: TeX in sid

[James Cowgill]

Hi,

On Sat, 2016-05-21 at 18:06 +0300, Dmitry Bogatov wrote:
> When building cdist-4.0.0, I encountered listed error with sbuild.
> Seems it is issues with TeX, not with my package. Any suggestions?
> 
> How read this '/tmp/fmtutils.C8RsuPiw' file, for example?
> 
>   Processing triggers for tex-common (6.05) ...
>   Running updmap-sys. This may take some time... done.
>   Running mktexlsr /var/lib/texmf ... done.
>   Building format(s) --all.
>   This may take some time... 
>   fmtutil failed. Output has been stored in
>   /tmp/fmtutil.C8RsuPiw
>   Please include this file if you report a bug.

This is bug #824835 and it's a bug in TeX itself.

James

signature.asc
Description: This is a digitally signed message part

Bug#820644: RFS: libretro-snes9x [ITP]

[James Cowgill]

Hi,

On Sun, 2016-04-10 at 21:46 -0300, Sérgio Benjamim wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Hey dear mentors!
> 
> I'm looking for a sponsor for my package "libretro-snes9x"
> 
> This is the libretro port of Snes9x.
> 
> Snes9x is a cross platform SNES emulator, fast and it has a good
> compatibility with commercial games.
> 
> The code diverge from Snes9x upstream, so let's use the libretro
> fork.

This seems to be unredistributable.

These files require a GPL license exception to link with the non-free
code:

> Files: libretro/*
> Copyright: 2011-2015 The RetroArch Team
> License: GPL-3+

> Files: win32/objfix.c
> Copyright: 1998-2005 Charles Bilyue'
> License: GPL-2+

> Files: debian/*
> Copyright:
>  2011-2014 Hunter Kaller (hizzlekizzle) 
>  2014-2016 Sergio Benjamim (sergio-br2) 
> License: GPL-3+

I'm not convinced the license exception granted by these pieces of code
applies here (it's not MAME and technically this is an Snes9x
derivative):

> Files:
>  filter/xbrz.*
>  filter/xbrz-config.h
> Copyright: 2012-2015 Zenju (zenju AT gmx DOT de)
> License: GPL-3 with special exception

> Files:
>  jma/crc32.cpp
>  jma/jma.cpp
> Copyright: 2004-2006 NSRT Team
> License: GPL-2
> Comment: The authors of the GPL portions have granted an exception to Snes9x
>  (but not to Snes9x derivitives) to use their code.

> Files: jma/portable.h
> Copyright:
>  2004-2006 NSRT Team ( http://nsrt.edgeemu.com )
>  2002 Andrea Mazzoleni ( http://advancemame.sf.net )
> License: GPL-2
> Comment: The authors of the GPL portions have granted an exception to Snes9x
>  (but not to Snes9x derivitives) to use their code.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Re: package stuck in unstable after switching to AutomaticDebugPackages

[James Cowgill]

On Sun, 2016-05-08 at 19:57 +0100, James Cowgill wrote:
> Hi,
> 
> On Sun, 2016-05-08 at 20:17 +0200, Alex Mestiashvili wrote:
> > 
> > Hi All,
> > 
> > gearmand package has stuck in unstable due to missing -dbg
> > packages:
> > 
> >  https://release.debian.org/migration/testing.pl?package=gearmand
> > 
> > The debug packages were removed after switching to automatic debug
> > packages [0].
> > 
> > How do I force the migration ?  What is the right way to switch to
> > automatic -dbgsym packages ?
>
> It's not migrating because the old dbg packages are still in sid.
> Usually stuff like this is removed automatically by dak's auto
> decrufter but apparently not this time.
> 
> If you file a NBS removal bug against ftp.debian.org then the package
> should migrate after the dbg packages are removed manually.

And you also should have a call to dh_strip --dbgsym-migration in your
debian/rules (see dh_strip(1)). This wont prevent testing migration
though.

James

signature.asc
Description: This is a digitally signed message part

Re: package stuck in unstable after switching to AutomaticDebugPackages

[James Cowgill]

Hi,

On Sun, 2016-05-08 at 20:17 +0200, Alex Mestiashvili wrote:
> Hi All,
> 
> gearmand package has stuck in unstable due to missing -dbg packages:
> 
>  https://release.debian.org/migration/testing.pl?package=gearmand
> 
> The debug packages were removed after switching to automatic debug
> packages [0].
> 
> How do I force the migration ?  What is the right way to switch to
> automatic -dbgsym packages ?

It's not migrating because the old dbg packages are still in sid.
Usually stuff like this is removed automatically by dak's auto
decrufter but apparently not this time.

If you file a NBS removal bug against ftp.debian.org then the package
should migrate after the dbg packages are removed manually.

James

signature.asc
Description: This is a digitally signed message part

Re: Seeking sponsorship for a non-maintainer-update (NMU) of freecell-solver: update to version 4.2.0 and some cleanups

[James Cowgill]

Hi,

On Mon, 2016-04-25 at 23:03 +0300, Shlomi Fish wrote:
> I'm seeking sponsorship for an NMU I prepared of the freecell-solver
> package to
> update it to version 4.2.0 and provide some cleanups/updates for its
> meta-data:
> 
> * https://packages.debian.org/source/sid/freecell-solver
> 
> * 
> http://www.shlomifish.org/Files/files/text/freecell-solver-debian-pkg-update-to-4.2.0.nmu-bug.txt.xz

Please read this page:
http://mentors.debian.net/intro-maintainers

Since this NMU involves a new upstream version, reviewers will probably
want a full Debian source package (.dsc and related tarballs) to review
this. Upload it to mentors.debian.net if possible. After you've done
that, you should file a RFS bug against the sponsorship-requests
pseudo-package. This is all documented at the above link in Step 4.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Re: Uncertain ABI with libags and GSequencer

[James Cowgill]

Hi,

On Wed, 2016-04-20 at 22:46 +0200, Joël Krähemann wrote:
> I'm the developer of Advanced Gtk+ Sequencer or for short gsequencer.
> Now I would like to provide following libraries in a non-standard
> location like /usr/share/gsequencer.
> 
> * libags
> * libags-thread
> * libags-server
> * libags-audio
> * libags-gui
> * libgsequencer
> 
> I think that libgtk-2.0 initially did the same in its early years
> about 15 years ago. Are there any documents or guidelines to provide
> libraries for debian GNU/Linux? And what if I can't guarantee ABI
> conformance, yet?

Firstly, you should use /usr/lib/gsequencer as the proper place to put
private libraries. /usr/share is for arch-independent files only.

As long as they're private, you can do pretty much what you want with
your libraries. Other Debian packages must not use them however.
Breaking the ABI is also not an issue (for Debian at least).

If you ever want to move them into a public directory you would need to
give them a proper SONAME and make sure the ABI isn't broken regularly.

> What about providing static linked GSequencer since I use it to debug
> the application?

Are you talking about fully statically linked (including static libc
etc) or just statically link against your libraries?

Using static libc is not allowed except in special circumstances. If
it's just your private libraries then you are free to do that if you
want. Is it totally nessesary though? Why can't you debug your
application when it isn't statically linked? Is such a package actually
useful to other people?

James

signature.asc
Description: This is a digitally signed message part

Bug#818687: RFS: btrfs-progs/4.4.1-1.1 [NMU]

[James Cowgill]

On Wed, 2016-04-20 at 21:24 +, Gianfranco Costamagna wrote:
> Hi,
> you missed the change on postrm, and BTW I think this is out of the
> NMU scope, can we please leave the change
> out?
> I'm not too confident about it, I would like to just rename the
> package and let xnox give his opinion on
> the postinst and postrm scripts.
> 
> maybe somebody on -mentors can give an opinion about what is wrong
> with this line
> "if [ -x /usr/sbin/update-initramfs ] && [ -e 
> /etc/initramfs-tools/initramfs.conf ]"

I don't think there's anything particularly wrong with that line.

Thr previous attempts at fixing this (using 'hash' and 'command -v')
are both bashisms so they shouldn't be used.

If you really want to fix the lintian warning, using 'which' is
probably the best idea here since it's an essential executable, not a
shell builtin.

if which update-initramfs > /dev/null 2>&1 && [ -e 
/etc/initramfs-tools/initramfs.conf ]

Also see:
https://www.debian.org/doc/manuals/developers-reference/ch06.html#bpp-debian-maint-scripts
https://lintian.debian.org/tags/command-with-path-in-maintainer-script.html

James

signature.asc
Description: This is a digitally signed message part

Re: How to avoid version restrictions for JS libraries (Was: Bug#820879: r-cran-shiny: uninstallable in sid: Depends: libjs-jquery (< 1.11.3+dfsg.0~) but 1.12.3-1 is to be installed)

[James Cowgill]

Hi,

On Wed, 2016-04-13 at 13:13 +0200, Andreas Tille wrote:
> via this bug I learned (the hard way) that a
> 
>    Depends: ${js:Depends}
> 
> will be resolved into
> 
>    libjs-jquery (<< 1.11.3+dfsg.0~), libjs-jquery (>= 1.11.3+dfsg)
> 
> (for instance) in the final package.  I have no reason to assume that
> the actual version that was available at package build time is the
> only
> valid dependency for my package.  So it seems unadvisable to use
> ${js:Depends} depends at all to avoid continuous uploading of the
> package (depending from 9 different libjs-* packages) if any of its
> libjs-* was uploaded with a new version.
> 
> I wonder what the idea behind this resulution of the ${js:Depends}
> would be since I have the feeling that this is not sensible in the
> most practical cases.
> 
> Am I missing something?

I think those dependencies come from dh_linktree and are placed in
${misc:Depends}, not ${js:Depends}.

dh_linktree(1) contains this:

Since symlink trees are created statically at build-time, they are not
very future-proof and have a risk to miss some files introduced by a
newer version of the package providing the file tree which is
duplicated. That's why the generated dependencies generally ensure that
the same upstream version be used at run-time than at build-time.

James

signature.asc
Description: This is a digitally signed message part

Re: Handling of symbols file on Debian build

[James Cowgill]

Hi,

On Sat, 2016-04-02 at 10:41 +0200, Jörg Frings-Fürst wrote:
> I have some questions about the handling of symbols files at Debian.
> 
> The quotes based on the package bitz-server[1].
> 
> My symbols file are[2]:
> 
> [quote]
> libicap.so.1 libicap1 #MINVER#
>  (c++)"icap::RequestHeader::read_header(std::__cxx11::basic_string, 
> std::allocator > const&)@Base" 1.0.0
>  (c++)"icap::RequestHeader::RequestHeader(std::__cxx11::basic_string, 
> std::allocator > const&)@Base" 1.0.0
>  (c++)"icap::RequestHeader::RequestHeader(std::__cxx11::basic_string, 
> std::allocator > const&)@Base" 1.0.0
> [/quote]
[...]
> The building at armel[4] fails with:
> 
> [quote]
> --- debian/libicap1.symbols (libicap1_1.0.0-1_armel)
> +++ dpkg-gensymbols782sDG 2016-02-12 21:11:15.078848642 +
> @@ -1,4 +1,6 @@
>  libicap.so.1 libicap1 #MINVER#
> + 
> _ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_iS9_NS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_comparevT_T0_SM_T1_T2_@Base
>  1.0.0-1
> + 
> _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPSt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEiESt6vectorIS9_SaIS9_iNS0_5__ops15_Iter_comp_iterIN4icap6Header27encapsulated_header_comparevT_SL_T0_T1_@Base
>  1.0.0-1
>   (c++)"__gnu_cxx::__normal_iterator, std::allocator > > 
> std::__find_if<__gnu_cxx::__normal_iterator, std::allocator > >, 
> __gnu_cxx::__ops::_Iter_pred > > >(__gnu_cxx::__normal_iterator, 
> std::allocator > >, __gnu_cxx::__normal_iterator, std::allocator > >, 
> __gnu_cxx::__ops::_Iter_pred > >, std::random_access_iterator_tag)@Base" 1.0.0
>   (c++)"icap::Header::Header()@Base" 1.0.0
>   (c++)"icap::Header::attach(std::__cxx11::basic_string, std::allocator >, 
> std::__cxx11::basic_string, std::allocator >)@Base" 1.0.0
> @@ -64,18 +66,18 @@
> [/quote]

Welcome to the world of C++ template instantiations!

C++ has a rule called the One Deinition Rule (ODR). The rule states
that there is exactly one definition of every used function (including
templates) in an executable. When compiling a normal program, this is
solved by compiling the template once for every translation unit it's
used, and then the linker contains special support for merging all the
definitions into one. When shared objects are used, for every library
and executable which uses a function, the linker emits a weak global
symbol for it. The dynamic linker then merges all the symbols together
so that only one is used.

What you're seeing here are these weak template instantiation symbols
used to implement the ODR. In theory, any consumers of your library
should work whether these symbols are defined or not (since consumers
should have an implementation too), so they are not part of the ABI.

Since these symbols are usually from the std:: namespace, I generally
ignore all of them using a regex which covers most cases (this will
obviously fail if your library actually does emit std:: symbols).

Something like this handles it:
https://sources.debian.net/src/libsfml/2.3.2%2Bdfsg-1/debian/libsfml-system2.3v5.symbols/

James

signature.asc
Description: This is a digitally signed message part

Re: Package openBVE requires a new maintainer

[James Cowgill]

Hi,

On Fri, 2016-03-25 at 14:44 +, Christopher Lees wrote:
> I hope this is the correct place to try and get into touch with someone.
> 
> I appear to have become the current upstream coder for the package openBVE:
> https://packages.debian.org/search?keywords=openbve
> My Github repository is here:
> http://github.com/leezer3/OpenBVE/
> 
> This was abandoned by the original developer in ~2007 or so, and
> unfortunately the version in the Debian repositories is broken on anything
> above Wheezy.

I had a go with the version in unstable using some routes I found and
things seem to work ok. What exactly is broken?

> Whilst I'm not sure I'd currently consider my much updated version ready
> for Debian itself, I would like to get into touch with someone who could
> potentially adopt the maintainership of the current package, and fix the
> current breaking issues with it.
> 
> When that's done, discussion could be had about what is required, and guide
> me through the process of getting a version of my builds into the
> repositories.
> 
> I have tried mailing the current maintainer- Paul Sladen, but whilst I've
> had two replies promising he'll get back to me, I've had nothing more.
> Whilst I have no experience in Debian packaging, I'm happy to work with
> someone to get this situation sorted out.

Did you contact the Debian CLI Applications Team, the team listed in
the maintainer field of the package as well?
pkg-cli-apps-t...@lists.alioth.debian.org

How long ago were those replies? The package was last updated in
January this year so it doesn't seem unmaintained.

James

signature.asc
Description: This is a digitally signed message part

Re: Help with new version of iqtree needed

[James Cowgill]

On Thu, 2016-03-10 at 14:39 +0100, Andreas Tille wrote:
> Hi,
> 
> I#m facing a C++ problem with the new version of iqtree.  If I build the
> current state in Git[1] I get:
> 
> ...
> [  7%] Building C object pll/CMakeFiles/pll.dir/evaluateGenericSpecial.c.o
> cd /build/iqtree-1.4.0+dfsg/obj-x86_64-linux-gnu/pll && /usr/bin/cc  
> -DIQ_TREE -D_USE_PTHREADS -D__SSE3 -I/build/iqtree-1.4.0+dfsg 
> -I/build/iqtree-1.4.0+dfsg/obj-x86_64-linux-gnu  -g -O2 
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
> -D_FORTIFY_SOURCE=2  -pthread-o 
> CMakeFiles/pll.dir/evaluateGenericSpecial.c.o   -c 
> /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c
> In file included from 
> /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:46:0:
> /build/iqtree-1.4.0+dfsg/pll/pllInternal.h:150:30: warning: inline function 
> 'bitcount_64_bit' declared but never defined
>  extern __inline unsigned int bitcount_64_bit(uint64_t i);
>   ^
> In file included from /build/iqtree-1.4.0+dfsg/pll/pll.h:79:0,
>  from /build/iqtree-1.4.0+dfsg/pll/mem_alloc.h:16,
>  from 
> /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c:31:
> /build/iqtree-1.4.0+dfsg/pll/evaluateGenericSpecial.c: In function 
> 'evaluateGTRCATPROT':
> /usr/lib/gcc/x86_64-linux-gnu/5/include/pmmintrin.h:86:1: error: inlining 
> failed in call to always_inline '_mm_hadd_pd': target specific option mismatch
>  _mm_hadd_pd (__m128d __X, __m128d __Y)
>  ^

_mm_hadd_pd is a sse3 intrinsic so you have to pass -msse3 to allow GCC
to use it. However, this will cause a SIGILL on any amd64/i386
processor without sse3 so instead the code should be replaced with
something more portable.

James

signature.asc
Description: This is a digitally signed message part

Bug#816652: RFS: compiz/1:0.9.12.2 [ITP:722451]

[James Cowgill]

Hi,

[I've added Jean-Philippe in case he wants to weigh in]

On Thu, 2016-03-03 at 19:58 +0100, Vincent Auboyneau wrote:
> On Thu, Mar 03, 2016 at 03:03:11PM +0000, James Cowgill wrote:
> > > The first step is getting compiz back in debian. It has been cleaned up,
> > > and polished with the last version of upstream.  I have followed the
> > > previous advice of Adam Borowski, and set the jpeg and png deps strait.
> > Sounds good, assuming it can easily be used with an existing DE in
> > Debian (I used to use compiz but I think I've forgotten how it all
> > worked).
>
> The obvious prime target is the mate desktop, which is growing in users,
> and has become an official ubuntu flavour, so they recently added a
> plugin for better integration.
> This is also, according to several professional in this area, the most
> accessible desktop available for some impaired users, partly because it
> provides stability.

Ok I'm fine with compiz being reintroduced into Debian.

> > > there is the question of the source format, should it be 3(native) or
> > > quilted?
> > 3.0 (quilt)
> > 
> > Native is intended for projects developed by Debian itself. These are
> > usually infastructure type projects (like dpkg, debhelper, etc). Most
> > packages should not be native.
> if using quilt, i need to generate a orig.tar.gz, so how'd you proceed
> with that? just tar the thing, rename it?

In a normal package, the orig.tar.gz should (if possible) be identical
to the upstream release version. You probably want this file:

https://launchpad.net/compiz/0.9.12/0.9.12.2/+download/compiz-0.9.12.2.tar.bz2

BUT, I have noticed that instead of using patches, Ubuntu has been
creating "fake" upstream releases when fixing bugs. This isn't great
since the latest bugfixes are now only found in Ubuntu and aren't
easily split out for other distributions. The best solution is to try
and get a new release of compiz with these fixes and then persuade
Ubuntu developers to ship patches in debian/patches rather than
manually patching the source. The ideal change flow should be
Upstream -> Debian -> Ubuntu.

The alternatives to that don't look nice. You could move the diff
between ubuntu and upstream into debian/patches, but it looks massive.

> > > Another issue, that is pending resolve, is a couple lintian errors:
> > > compiz-dev: package-contains-cmake-private-file 
> > > usr/share/cmake-3.0/FindCompiz.cmake
> > > compiz-dev: package-contains-cmake-private-file 
> > > usr/share/cmake-3.0/FindOpenGLES2.cmake
> > > Are those critical? or is it ok till resolution?
> > You're not allowed to ship files in /usr/share/cmake-* because that
> > directory is internal to cmake. Things will also break when cmake gets
> > upgraded - infact what you're doing is already broken in sid.
> > 
> > You should try and use CMake config files if possible, although they
> > can be a bit fiddly to setup. For now you could either drop those
> > files, or move them to some other directory (which will not
> > automatically be searched).
> > 
> > See:
> > https://lintian.debian.org/tags/package-contains-cmake-private-file.html
> I've already sent a mail to this part's creator, as it is indeed fiddly.

Ok, hopefully that can be sorted - it has to be removed for the moment
though.

> > > As for functionnal tests, compiz is used by ~20 people, and is ready
> > > from sid to jessie-backports.
> > > I await more instructions and pieces of sound advice, of which i know
> > > debian people have plenty.
> > > 
> > > project is uploaded to alioth:
> > > https://alioth.debian.org/projects/compiz/
> > > git clone git+ssh://$u...@git.debian.org/git/pkg-a11y/compiz.git
> > I've only had a brief look but there a few obvious issues:
> >  - Needs "de-ubuntifying" (changelogs, control, etc)
> I have been told (by a DD) that changelog "mixing" was ok, since ubuntu
> was already using it as a project changelog (not just deb changelog),
> and debian's additions would only affect last entry.
> What do you suggest?

OK, in that case leaving those entries should be fine. I did notice the
Debian version number is earlier than the Ubuntu version in the
changelog which isn't going to work properly - maybe that can be fixed
with a new upstream release :)

> >  - Maintainer field needs sorting out. Who exactly is working on this?
> >    - Also you don't own the ITP - are you working together?
> I work with Jean-philippe yes. we could transfer ownership indeed.

You don't need to transfor ownership if everyone involved is ok with
what's going on.

You should remove the XSBC-Original-Maintainer field, and replace t

Re: RFS: Compiz making its comeback into debian

[James Cowgill]

Hi,

On Thu, 2016-03-03 at 14:09 +0100, Ksamak wrote:
> Hey fellow debian lovers.
> I think it's time to re-empower some users, who like fancyness in their
> desktop, with compiz!
[...]
> The first step is getting compiz back in debian. It has been cleaned up,
> and polished with the last version of upstream.  I have followed the
> previous advice of Adam Borowski, and set the jpeg and png deps strait.

Sounds good, assuming it can easily be used with an existing DE in
Debian (I used to use compiz but I think I've forgotten how it all
worked).

> there is the question of the source format, should it be 3(native) or
> quilted?

3.0 (quilt)

Native is intended for projects developed by Debian itself. These are
usually infastructure type projects (like dpkg, debhelper, etc). Most
packages should not be native.

> Another issue, that is pending resolve, is a couple lintian errors:
> compiz-dev: package-contains-cmake-private-file 
> usr/share/cmake-3.0/FindCompiz.cmake
> compiz-dev: package-contains-cmake-private-file 
> usr/share/cmake-3.0/FindOpenGLES2.cmake
> Are those critical? or is it ok till resolution?

You're not allowed to ship files in /usr/share/cmake-* because that
directory is internal to cmake. Things will also break when cmake gets
upgraded - infact what you're doing is already broken in sid.

You should try and use CMake config files if possible, although they
can be a bit fiddly to setup. For now you could either drop those
files, or move them to some other directory (which will not
automatically be searched).

See:
https://lintian.debian.org/tags/package-contains-cmake-private-file.html

> As for functionnal tests, compiz is used by ~20 people, and is ready
> from sid to jessie-backports.
> I await more instructions and pieces of sound advice, of which i know
> debian people have plenty.
> 
> project is uploaded to alioth:
> https://alioth.debian.org/projects/compiz/
> git clone git+ssh://$u...@git.debian.org/git/pkg-a11y/compiz.git

I've only had a brief look but there a few obvious issues:
 - Needs "de-ubuntifying" (changelogs, control, etc)
 - Maintainer field needs sorting out. Who exactly is working on this?
   - Also you don't own the ITP - are you working together?
 - The package cannot be built since these dependencies do not exist 
   in Debian. How did you test this on Debian if it cannot be built?

The following packages have unmet dependencies:
 sbuild-build-depends-compiz-dummy : Depends: dh-migrations but it is not 
installable
 Depends: dh-translations but it is not 
installable
 Depends: libxorg-gtest-dev but it is not 
installable
E: Unable to correct problems, you have held broken packages.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#814806: RFS: libauxv/1.1.0-1 [ITP] -- libauxv -- Auxiliary Vector Library library

[James Cowgill]

Hi,

On Mon, 15 Feb 2016 16:48:56 +0100 Frederic Bonnard  
wrote:
> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "libauxv"
> 
>  Package name: libauxv
>  Version : 1.1.0-1
>  Upstream Author : Libauxv team
>  URL : https://github.com/Libauxv/libauxv

From the upstream README:

WARNING: This library is going to be discontinued. Please use glibc's
getauxval() function for similar functionality instead.

So given that, is it actually a good idea to package this in Debian?

It looks like getauxval was introduced in glibc 2.16 which is already
in jessie.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#814859: RFS: runescape/0.1-1 [ITP] -- Set in a fantasy world of war, landscapes and sinister powers

[James Cowgill]

Hi,

I have a few comments on this pavkage.

Firstly although it's clear you've put some work into this, I'm not so
sure packaging this client is that useful. I'm using Google Chrome, and
going to www.runescape.com and clicking "Play Now" launches the client
(through an external jar which autolaunches). Does this package do
anything more than that? When a linux runescape client is mentioned,
it's usually referring to Hikari Knight's client which has lots of
other features - https://launchpad.net/rsu-client

On the upstream code:
rs-lang/*:
 * Downloading over http is a security risk - use https.
 * Why not use $(mktemp -d)?
 * There's a lot of duplication between the files here which could be
   improved.

On the packaging itself:
d/README.Debian:
 * If you haven't changed the original source at all, you don't need
   this file.

d/control:
 * Since the program downloads non-free jars and executes them, the
   package must go into contrib and not main.
 * I think you've got the Build-Depends and Depends fields mixed up.
   Surely you need default-jre to RUN runescape rather than build the
   debian package?
 * The short description doesn't mention that this is a game.
 * The extended description should mention the non-freeness of the game
   itself.

d/copyright:
 * I'm not sure any of this code is copyright Jagex. Please use the
   correct Source and Files: * copyright.
 * Copyright is needed for runescape.xpm. I suspect this image is non-
   free.
 * Do not use "GPL-2" as the shortname if the license is not exactly
   the GPL-2.
 * You could probably shorten that section a bit with a reference to
   the common license in /usr/share/common-licenses.

d/rules:
 * The rules are very overcomplicated for what the package need to do.
   You could probably replace all of it with "%: dh $@".

d/runescape-docs.docs:
 * This file does nothing.

Thanks,
James

signature.asc
Description: This is a digitally signed message part

Bug#804947: RFS: inform/6.31.1+dfsg-2

[James Cowgill]

Hi,

On Sat, 2015-11-14 at 10:55 +1100, Ben Finney wrote:
> On 13-Nov-2015, James Cowgill wrote:
> > From the build log for dpkg-buildpackage -b (which does work):
> > > In file included from linker.c:9:0:
> > > linker.c: In function ‘write_link_byte’:
> > > header.h:618:36: warning: cast from pointer to integer of different size 
> > > [-Wpointer-to-int-cast]
> > >  #define subtract_pointers(p1,p2) (((int32) p1)-((int32) p2))
> > > ^
> > > linker.c:968:9: note: in expansion of macro ‘subtract_pointers’
> > >  if (subtract_pointers(link_data_top,link_data_holding_area)
> > >  ^
> > 
> > This looks pretty bad for any 64-bit architecture to me. My guess is
> > that it still works due to pure luck that glibc's allocator doesn't
> > start at an address above 2GB. The code is also wrong for 32-bit since
> > it could potentially result in signed integer overflow if addresses in
> > the 2GB-3GB range are used.
> 
> Okay. That's unchanged (from my perspective) since before I looked at
> this package. I'll need to learn more about the problem; can you
> submit a bug report on Debian's BTS against ‘inform’?

Ok I'll do that in a minute.


> > debian/Makefile.upstream:
> >  What is the purpose of this file?
> 
> I'll look into that. It may be a remnant from some earlier change.
> 
> > debian/rules:
> >  Why not use dh?
> 
> I'd like to understand the rationales for the current ‘debian/rules’,
> before replacing it so completely. Certainly migrating to the ‘dh’
> command is a medium-term goal.

I suspect the only reason it doesn't use dh is because the package is
old.

When using dh you would replace all the build rules with something like
this:

%:
dh $@ --sourcedirectory=$(SOURCE_DIR) --with autoreconf

and then tweak it a little (you possibly only need to tweak the clean
rule and dh_installchangelogs in this case?).

> On 13-Nov-2015, Stephen Kitt wrote:
> > and with dpkg-buildpackage -A (which would be nice to have since the
> > source package produces an arch-independent binary package alongside
> > the arch-dependent one).
> 
> I suspect this is also to be addressed by using ‘dh-autoreconf’, would
> you agree?

Yep (and you've already fixed it).

James

signature.asc
Description: This is a digitally signed message part

Bug#804947: RFS: inform/6.31.1+dfsg-2

[James Cowgill]

Hi,

On Fri, 2015-11-13 at 16:36 +1100, Ben Finney wrote:
> Package: sponsorship-requests
> Severity: wishlist
> Control: tags 698980 + pending
> Control: block 698980 by -1
> 
> I am looking for a sponsor for my package ‘inform’:

Since I've used inform before, I had a small look at the package.
However, I'm not a DD so I can't upload it for you.

[...]
> This release contains the following significant changes:
> 
>   * Updated packaging to resolve Lintian errors.
>   * Prepare for switch to free software upstream versions.
> 
> Once this updated release is sponsored, I intend to collaborate with
> upstream and package their later free software versions.

Why can't you package the later free versions now?

The package FTBFS when build with dpkg-buildpackage -B:
> dpkg-buildpackage: source package inform
> dpkg-buildpackage: source version 6.31.1+dfsg-2
> dpkg-buildpackage: source distribution unstable
> dpkg-buildpackage: source changed by Ben Finney 
>  dpkg-source --before-build inform-6.31.1+dfsg
> dpkg-buildpackage: host architecture amd64
>  fakeroot debian/rules clean
> dh_testdir
> dh_testroot
> rm -f build.stamp unpack.stamp
> rm -f inform-6.31.1/config/config.guess
> rm -f inform-6.31.1/config/config.sub
> [ ! -f inform-6.31.1/Makefile ] || /usr/bin/make -C inform-6.31.1/ 
> maintainer-clean
> dh_clean
>  debian/rules build-arch
> dh_testdir
> cd inform-6.31.1/ && ./configure --prefix=/usr
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> configure: error: cannot run /bin/bash config/config.sub
> debian/rules:49: recipe for target 'build.stamp' failed
> make: *** [build.stamp] Error 1
> dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2

From the build log for dpkg-buildpackage -b (which does work):
> In file included from linker.c:9:0:
> linker.c: In function ‘write_link_byte’:
> header.h:618:36: warning: cast from pointer to integer of different size 
> [-Wpointer-to-int-cast]
>  #define subtract_pointers(p1,p2) (((int32) p1)-((int32) p2))
> ^
> linker.c:968:9: note: in expansion of macro ‘subtract_pointers’
>  if (subtract_pointers(link_data_top,link_data_holding_area)
>  ^

This looks pretty bad for any 64-bit architecture to me. My guess is
that it still works due to pure luck that glibc's allocator doesn't
start at an address above 2GB. The code is also wrong for 32-bit since
it could potentially result in signed integer overflow if addresses in
the 2GB-3GB range are used.

debian/Makefile.upstream:
 What is the purpose of this file?

debian/rules:
 Why not use dh?
 Why not use dh_autoreconf?

James

signature.asc
Description: This is a digitally signed message part

Bug#787223: RFS: vbam/1.8.0.1498-1

[James Cowgill]

On Fri, 29 May 2015 22:59:45 + (UTC) Sergio benjamim Rocha filho 
sergio_...@yahoo.com.br wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
 I am looking for a sponsor for my package vbam

Hi,

I've had a look at this (because I'm interested), however I'm not a DD
so I can't actually sponsor the package for you.

Some of this stuff may be a bit picky... You can ask me if you have any
questions or if you disagree with something :)

general
  * Have you considered maintaining the package as part of the
Debian Games team? 
  * Have you contacted Etienne Millon ?
He may be interested in this (as the maintainer of the vba
package).

d/control:
  * Why are there 2 GUI frontends to this package? Is there any
advantage of one over the other? Which one is the best / one
which you would recommend?
  * The Vcs-Svn and Vcs-Browser fields in d/control are usually
used for packaging repositories (which contain a debian/
directory), not links to the upstream repositories.
  * You can drop the version on cmake, squeeze already has 2.8.2.
  * vba-common should be Architecture: all.
  * You probably want a versioned dependency from vbam-gtk and vbam
-wx to vbam-common.
  * nasm doesn't seem to be used in the build so you can drop it.
  * The version of vba in the archive has a dependency from vba-gtk
to vba. Does this package need that?
  * The trademark disclaimer probably doesn't need to be in the
description, but you can put it in d/copyright if you want (I
don't know how necessary it is).

d/changelog:
  * Please squash all the changelog entries. You should generally
use one entry per version actually uploaded to Debian.

d/copyright:
  * Need copyright information for files in CMakeScripts/ and data/
  * The files licensed under GPL-2 only are problematic since there
is some GPL-3 files here as well. The files must be replaced or
re-licensed with permission of the author(s). If they aren't
used, then copyright file should say that.

d/patches/gtk.patch:
  * Is this necessary? Can't you just use -DENABLE_GTK=ON?

d/rules:
  * What are the commented lines (starting DEB_BUILD_ARCH_CPU) in
d/rules for? Remove them if they're now obsolete.
  * Remove the stuff about CMAKE_VERBOSE_MAKEFILE, dh always
enables that flag anyway.
  * CMAKE_INSTALL_PREFIX=/usr is also added by dh so you can remove
that as well.

build
  * Please fix the 'dpkg-shlibdeps: warning: package could avoid a
useless dependency' warnings by using --as-needed or preventing
the libraries being linked.
  * Try 'export DEB_LDFLAGS_MAINT_APPEND=-Wl,--as-needed'

lintian (fix all of these)
W: vbam source: dep5-copyright-license-name-not-unique (paragraph at line 124)
W: vbam source: dep5-copyright-license-name-not-unique (paragraph at line 138)
W: vbam source: dep5-copyright-license-name-not-unique (paragraph at line 243)
W: vbam source: missing-license-paragraph-in-dep5-copyright gpl-2+ (paragraph 
at line 169)
W: vbam source: missing-license-paragraph-in-dep5-copyright public-domain 
(paragraph at line 36)
X: vbam-common: package-contains-no-arch-dependent-files

vbam-sdl segfault
I tried running a game with vbam in the vbam-sdl package. When closing
the program it segfaulted. This was the stacktrace. As you can see,
fclose was called with a NULL pointer.

#0  _IO_new_fclose (fp=0x0) at iofclose.c:54
#1  0x00438cbe in SaveConfigFile () at 
/tmp/vbam/vbam-1.8.0.1498/src/common/ConfigManager.cpp:783
#2  0x0042fc6a in main (argc=2, argv=0x7fffe198) at 
/tmp/vbam/vbam-1.8.0.1498/src/sdl/SDL.cpp:1853

Tail of strace:
stat(/home/james/.vbam, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getcwd(/tmp/vbam, 2048)   = 10
stat(vbam.ini, 0x7ffd9bcb3ae0)= -1 ENOENT (No such file or directory)
stat(/home/james/.vbam/vbam.ini, 0x7ffd9bcb3ae0) = -1 ENOENT (No such file or 
directory)
stat(/usr/share/vbam/vbam.ini, 0x7ffd9bcb3ae0) = -1 ENOENT (No such file or 
directory)
stat(/etc/vbam.ini, 0x7ffd9bcb3ae0)   = -1 ENOENT (No such file or directory)
getcwd(/tmp/vbam, 2048)   = 10
stat(vbam.cfg, 0x7ffd9bcb3ae0)= -1 ENOENT (No such file or directory)
stat(/home/james/.vbam/vbam.cfg, 0x7ffd9bcb3ae0) = -1 ENOENT (No such file or 
directory)
stat(/usr/share/vbam/vbam.cfg, 0x7ffd9bcb3ae0) = -1 ENOENT (No such file or 
directory)
stat(/etc/vbam.cfg, {st_mode=S_IFREG|0644, st_size=5821, ...}) = 0
open(/etc/vbam.cfg, O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission 
denied)
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0} ---
+++ killed by SIGSEGV (core dumped) +++
Segmentation fault

cppcheck output (possible coding mistakes):
$ cppcheck -j1 --quiet -f . | grep -vF 'cppcheck: error: could not find or open 
any of the paths given.'

Bug#782847: RFS: endless-sky/0.7.9-1 [ITP]

[James Cowgill]

On Sat, 2015-04-18 at 14:31 -0400, Michael Zahniser wrote:
Dear mentors,
 
I am looking for a sponsor for my package endless-sky.

Here are some comments:

build:
The build passes -msse4.1 to g++. This will fail on non-x86 arches and
produce binaries which don't work without sse 4.1 processors on x86
arches.

debian/control:
libjpeg-turbo8-dev does not exist in debian, try libjpeg-dev
Latest standards version is 3.9.6

debian/copyright:
You need copies of CC-BY-SA-3.0 and CC-BY-3.0

debian/rules:
You should not hardcode -j4 in the rules file. Use the value given in
DEB_BUILD_OPTIONS 'parallel' instead (see policy 4.9.1).

Lintian output:
W: endless-sky: hardening-no-relro usr/games/endless-sky
I: endless-sky: hardening-no-fortify-functions usr/games/endless-sky
I: endless-sky: description-synopsis-might-not-be-phrased-properly
I: endless-sky: hyphen-used-as-minus-sign usr/share/man/man6/endless-sky.6.gz:7
I: endless-sky: desktop-entry-lacks-keywords-entry 
usr/share/applications/endless-sky.desktop
I: endless-sky-data: description-synopsis-might-not-be-phrased-properly
P: endless-sky: no-upstream-changelog
P: endless-sky-data: no-upstream-changelog

The warning should be fixed. That one is usually caused by the build
system ignoring custom CFLAGS/CXXFLAGS/etc. The others would be nice to
fix as well but are not essential.

Otherwise, the package looks good - I'm not a DD though so I can't
upload the package for you when it's done.

Thanks,
James


signature.asc
Description: This is a digitally signed message part

Bug#782847: RFS: endless-sky/0.7.9-1 [ITP]

[James Cowgill]

On Sat, 2015-04-18 at 18:02 -0400, Michael Zahniser wrote:
 Thanks for the quick feedback!
 
 If SSE 4.1 is not acceptable, is it possible to at least depend on SSE 
 3? I use some SSE intrinsics to optimize geometric calculations. Should 
 I modify the code so those instructions are used only if a special 
 command line option is given? That would mean all the official packages 
 would be un-optimized, even though all i386 and amd64 processors from 
 the last decade support SSE 3.

Nope you can't assume SSE 3 is present. You can only assume SSE 2 and
only on amd64 (not i386). If you want to use something newer, you can
use a command line option like you said, or do runtime cpu detection.

 For libjpeg, right now I use the JCS_EXT_BGRA option (converting to 
 32-bit BGRA color when decoding JPEGs). The reason I specified 
 libpeg-turbo is because other libjpeg implementations may not include 
 that extension. (But, I see that libjpeg-turbo is the default 
 implementation of libjpeg on Debian, anyway.) Is it safe to just specify 
 plain libjpeg as the dependency?

Ah I didn't know you used that - you can use libjpeg62-turbo-dev if you
specifically want libjpeg-turbo.

James

 On 04/18/2015 04:33 PM, James Cowgill wrote:
  On Sat, 2015-04-18 at 14:31 -0400, Michael Zahniser wrote:
  Dear mentors,
 
  I am looking for a sponsor for my package endless-sky.
 
  Here are some comments:
 
  build:
  The build passes -msse4.1 to g++. This will fail on non-x86 arches and
  produce binaries which don't work without sse 4.1 processors on x86
  arches.
 
  debian/control:
  libjpeg-turbo8-dev does not exist in debian, try libjpeg-dev
  Latest standards version is 3.9.6
 
  debian/copyright:
  You need copies of CC-BY-SA-3.0 and CC-BY-3.0
 
  debian/rules:
  You should not hardcode -j4 in the rules file. Use the value given in
  DEB_BUILD_OPTIONS 'parallel' instead (see policy 4.9.1).
 
  Lintian output:
  W: endless-sky: hardening-no-relro usr/games/endless-sky
  I: endless-sky: hardening-no-fortify-functions usr/games/endless-sky
  I: endless-sky: description-synopsis-might-not-be-phrased-properly
  I: endless-sky: hyphen-used-as-minus-sign 
  usr/share/man/man6/endless-sky.6.gz:7
  I: endless-sky: desktop-entry-lacks-keywords-entry 
  usr/share/applications/endless-sky.desktop
  I: endless-sky-data: description-synopsis-might-not-be-phrased-properly
  P: endless-sky: no-upstream-changelog
  P: endless-sky-data: no-upstream-changelog
 
  The warning should be fixed. That one is usually caused by the build
  system ignoring custom CFLAGS/CXXFLAGS/etc. The others would be nice to
  fix as well but are not essential.
 
  Otherwise, the package looks good - I'm not a DD though so I can't
  upload the package for you when it's done.
 
  Thanks,
  James
 



signature.asc
Description: This is a digitally signed message part

Bug#765009: Subject: RFS: abcmidi/20140928-1 [ITA]

[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.

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-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1413838769.3790.1.ca...@cowgill.org.uk

Bug#721369: RFS: libsfml/2.1+dfsg-1

[James Cowgill]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package libsfml

* Package name: libsfml
  Version : 2.1+dfsg-1
  Upstream Author : Laurent Gomila laurent@gmail.com
* URL : http://www.sfml-dev.org/
* License : zlib
  Section : libs

It builds those binary packages:

 libsfml-audio2 - Simple and Fast Multimedia Library - Audio part
 libsfml-dev - Simple and Fast Multimedia Library - Development Files
 libsfml-doc - Simple and Fast Multimedia Library - Documentation
 libsfml-graphics2 - Simple and Fast Multimedia Library - Graphics part
 libsfml-network2 - Simple and Fast Multimedia Library - Network part
 libsfml-system2 - Simple and Fast Multimedia Library - System part
 libsfml-window2 - Simple and Fast Multimedia Library - Window part
 libsfml2-dbg - Simple and Fast Multimedia Library - Debug Symbols

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/libsfml

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/libs/libsfml/libsfml_2.1+dfsg-1.dsc

--

This is a repackage of SFML to update it to version 2.1 (from 1.6).

SFML 2 has been discussed in bug #706001

The git repository where the package was developed is here:
  https://github.com/jcowgill/debian-sfml

Regards,
 James Cowgill


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1377890372.5767.7.camel@angel.local