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)
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
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
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)
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
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?
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
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
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
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
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?
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
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)
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
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)
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 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)
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
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
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?
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)
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)
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
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)
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)
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
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
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’
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?
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
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
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
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
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
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]
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)
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
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
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
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
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
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]
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
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
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?
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 ?
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
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]
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
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]
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
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]
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
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
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
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
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]
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)
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
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
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
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]
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&
Re: RFS: Compiz making its comeback into debian
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
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
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
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
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
On Fri, 29 May 2015 22:59:45 + (UTC) Sergio benjamim Rocha filho
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]
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#782847: RFS: endless-sky/0.7.9-1 [ITP]
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]
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
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 * 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
