Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)

[Sascha Steinbiss]

Hi Andreas,

after routine-update dh_missing failed due to compat level 13 which 
defaults to fail if some files are not installed.


Yep, encountered that in other places as well when updating a few (old!)
things.

This made me aware that upstream in principle installs a test suite 
we could use for an autopkgtest.  I also realised that you once

added debian/ltrsift-examples.examples - so you probably had such a
package in mind.


Well, upstream is me ;) At least the original upstream, I don't think
anyone at my former organization has adopted it in the meantime and I do
not have the time to still care for it.
But... since LTRsift is a purely graphical tool, there is no automated
test suite I know of. The files in samqqple_data are basically just
quickstart examples for the accompanying paper to provide a realistic
data set to preprocess, manually load and do first clicky analysis steps
with, I think.

Since I have no idea what reasons you had not to use this file I'll 
leave the final decision to you.


Interesting to see that there is no ltrsift-examples package indeed. But
I must have had my reasons back then...

Anyway, to be honest I don't see much long-term future for LTRsift. I am
actually surprised to see it still in Debian and not dropped out of
testing as it depends on GTK2, which I assumed was gone from Debian
already [0, 1].

I'd be happy with introducing an examples package but I don't think
there is going to be a usable autopkgtest to gain, sorry.


(Please note:  Somehow a copy of ltrsift_code ends up in the
examples dir - I did not yet investigated why this is happening.
Before I have no clear picture about your intentions I'll left this
for later investigation.)


That is a result of lines 62-65 in the Makefile, which make sure that
there is a copy of the executable in that directory, for the paper
reviewer's convenience I think (same as why we have the the static build).
I think this can be safely patched out as the prepare_encseqs script in
the sample_data directory also tries to run ltrsift_encode from the
$PATH. ltrsift_encode, BTW, is just a script that prepares the input
data and is actually just a wrapper around another tool from
GenomeTools, which we wanted to have in here for convenience.

I have pushed some changes and can upload soon.

Cheers
Sascha

[0] Apparently not, but it's dead upstream: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947713

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967603



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060955: [Pkg-privacy-maintainers] Bug#1060955: (none)

[Sascha Steinbiss]

Hi all,

Upgrading txtorcon to the latest version (23.11.0) should fix this 
problem, it does not happen there for me.


I have imported the new upstream version and updated the packaging [1] 
after adjusting the watchfile, which indeed fixes this FTBFS.


Would it be OK to push to git and team-upload? The build is fine now and
ratt [2] reports that reverse dependencies still build in unstable, with
the exception of tahoe-lafs, for which the issue is likely unrelated to 
txtorcon.

I'm just asking since my activity in the team has been mainly focused on
maintaining onioncircuits in Debian and I do not want to barge in doing
changes on other team-maintained packages.

Cheers
Sascha

[1] 
https://salsa.debian.org/satta/txtorcon/-/compare/master...master?from_project_id=19476=7=false

[2] https://github.com/Debian/ratt


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063602: seqan-needle: FTBFS on amd64: test/api/insert_delete_test (Failed)

[Sascha Steinbiss]

Hi,


https://buildd.debian.org/status/fetch.php?pkg=seqan-needle=amd64=1.0.2%2Bds-2=1707394988=0

2: [ RUN  ] insert.ibfmin
2: unknown file: Failure
2: C++ exception with description "std::bad_alloc" thrown in the test body.
2: 
2: [  FAILED  ] insert.ibfmin (0 ms)

[...]
2: [  FAILED  ] 1 test, listed below:
2: [  FAILED  ] insert.ibfmin
2: 
2:  1 FAILED TEST

 2/13 Test  #2: test/api/insert_delete_test ...***Failed0.03 sec


Unfortunately, I cannot reproduce this on my amd64 machine in a current 
sid chroot. Maybe the test tried to allocate more memory than 
temporarily available on the buildd? I'll take another look.


Cheers
S



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1032553: magic-wormhole: FTBFS in testing: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Sascha Steinbiss]

Hi Martin,


[...]

This is mentioned in
https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely
a "timing issue". Not sure if it's fixed upstream. >


Could it make sense to also patch the tests to include the delay that is
mentioned in the GitHub issue comments?


I've tried adding a 2 second delay in the failing test and that yields a
package that builds reliably for me. I just rebuild the package with the
patch 250 times successfully in a row.


Excellent, thanks a lot! I will take a look and upload if needed. The 
maintainer supports LowNMU so that should not be a problem I guess.

Otherwise please speak up now, Antoine :)


[...]

I'm not a DD, so i can't upload any fixes, but i would really appreciate
if we can get this fixed before the auto removal strikes.


Even with the 20 days transition delay we have now, this should still be 
in time for May 07.


Thanks again and have nice holidays
Sascha


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032553: magic-wormhole: FTBFS in testing: dh_auto_test: error: pybuild --test -i python{version} -p 3.11 returned exit code 13

[Sascha Steinbiss]

Hi all,

[...]
This is mentioned in 
https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely

a "timing issue". Not sure if it's fixed upstream. >


Could it make sense to also patch the tests to include the delay that is 
mentioned in the GitHub issue comments?


Cheers
Sascha




OpenPGP_signature
Description: OpenPGP digital signature

Bug#1012382: pktanon: autopkgtest fails on s390x with: wrong pcap file version: should be 2.4

[Sascha Steinbiss]

forwarded 1012382 https://github.com/KIT-Telematics/pktanon/issues/8
tags 1012382 upstream
thanks


Hi,


Your package has an autopkgtest, great. However, it fails on s390x. I
have attached the relevant piece of the log [1]. I'd like to note that
s390x is big-endian. Maybe the check for the version fails somehow?


I assume that pktanon simply isn't portable enough to work on 
architectures not intended by upstream. I have opened an issue in 
upstream's GitHub [0] -- but as a previous one [1] regarding ARM issues 
remained unanswered I assume that portability to some exotic platforms 
is probably not a high priority.


TBH I could live with that as well. Since pktanon does not seem to work 
reliably on that platform, I am going to remove s390x from the list of 
supported platforms to allow it to migrate to testing.


Cheers
Sascha

[0] https://github.com/KIT-Telematics/pktanon/issues/8
[1] https://github.com/KIT-Telematics/pktanon/issues/7


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1013938: balboa: regression + flaky autopkgtest: regularly times out on amd64, i386 and s390x

[Sascha Steinbiss]

Hi Paul,

thanks for letting me know!


I noticed that there were several runs that took 2:47 (our timeout
time), while successful runs more in the order of minutes. This
started to happen recently.
This is likely related to #1012629 [1] (also see #1012804 [2]), a hang 
issue that was in fact caused by rocksdb and was eventually fixed in 
rocksdb 7.2.2-5. Could the version that is tested in the autopkgtest and 
its dependencies be still affected by that?


[...]
On top of that, when a test just hangs that's not good for our 
infrastructure. I'll put balboa on our reject_list for amd64, i386, and 
s390x.


I see. I wonder what the procedure to get off that list is?
With an updated autopkgtest chroot, the latest librocksdb and a rebuilt 
version of balboa the autopkgtest consistently succeeds for me; see 
attached log.


Cheers
Sascha


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012629
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1012804Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
  apt-utils
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 446 kB of archives.
After this operation, 1,196 kB of additional disk space will be used.
Get:1 http://deb.debian.org/debian sid/main amd64 apt-utils amd64 2.5.0 [446 kB]
debconf: delaying package configuration, since apt-utils is not installed
Fetched 446 kB in 0s (1,135 kB/s)
Selecting previously unselected package apt-utils.
(Reading database ... 
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 12914 files and directories currently installed.)
Preparing to unpack .../apt-utils_2.5.0_amd64.deb ...
Unpacking apt-utils (2.5.0) ...
Setting up apt-utils (2.5.0) ...
Get:1 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  InRelease
Ign:1 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  InRelease
Get:2 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release [816 B]
Get:2 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release [816 B]
Get:3 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release.gpg
Ign:3 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Release.gpg
Get:4 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  Packages [4,116 B]
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Correcting dependencies...Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
 Done
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
The following additional packages will be installed:
  balboa balboa-backend-common balboa-backend-rocksdb curl libbrotli1 libcurl4
  libgflags2.2 libnghttp2-14 libpsl5 librocksdb7.2 librtmp1 libsnappy1v5
  libssh2-1
Recommended packages:
  ca-certificates publicsuffix
The following NEW packages will be installed:
  balboa balboa-backend-common balboa-backend-rocksdb curl libbrotli1 libcurl4
  libgflags2.2 libnghttp2-14 libpsl5 librocksdb7.2 librtmp1 libsnappy1v5
  libssh2-1
0 upgraded, 13 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
Need to get 4,323 kB/7,945 kB of archives.
After this operation, 25.9 MB of additional disk space will be used.
Get:1 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  balboa 2.0.0+ds-4 [3,236 kB]
Get:2 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  balboa-backend-common 2.0.0+ds-4 [354 kB]
Get:3 file:/tmp/autopkgtest-lxc.51ch70jm/downtmp/binaries  balboa-backend-rocksdb 2.0.0+ds-4 [31.6 kB]
Get:4 http://deb.debian.org/debian sid/main amd64 libgflags2.2 amd64 2.2.2-2 [83.5 kB]
Get:5 http://deb.debian.org/debian sid/main amd64 libsnappy1v5 amd64 1.1.9-2 [27.4 kB]
Get:6 http://deb.debian.org/debian sid/main amd64 librocksdb7.2 amd64 7.2.2-5 [2,921 kB]
Get:7 http://deb.debian.org/debian sid/main amd64 libbrotli1 amd64 1.0.9-2+b3 [276 kB]
Get:8 http://deb.debian.org/debian sid/main amd64 libnghttp2-14 amd64 1.47.0-1+b1 [76.3 kB]
Get:9 http://deb.debian.org/debian sid/main amd64 libpsl5 amd64 0.21.0-1.2 [57.3 kB]
Get:10 http://deb.debian.org/debian sid/main amd64 librtmp1 amd64 2.4+20151223.gitfa8646d.1-2+b2 [60.8 kB]
Get:11 http://deb.debian.org/debian sid/main amd64 libssh2-1 amd64 1.10.0-3+b1 [179 kB]
Get:12 http://deb.debian.org/debian sid/main amd64 libcurl4 amd64 7.83.1-2 [358 kB]
Get:13 http://deb.debian.org/debian sid/main amd64 curl amd64 7.83.1-2 [285 kB]
Fetched 4,323 kB in 2s 

Bug#1013588: Accepted golang-github-satta-ifplugo 0.0~git20200508.ca679be-4 (source) into unstable

[Sascha Steinbiss]

Hi Shengjing!

Even better :) I will undo my change then as well as soon as a new 
version hits the archive.


Thanks
Sascha

On 24.06.22 16:18, Shengjing Zhu wrote:

Hi,


  golang-github-satta-ifplugo (0.0~git20200508.ca679be-4) unstable; 
urgency=medium
  .
* Adjust import path for shirou/gopsutil.
  Closes: #1013588


I believe it's wrong for golang-github-shirou-gopsutil to set
XS-Go-Import-Path to github.com/shirou/gopsutil/v3.
I will revert the change in golang-github-shirou-gopsutil.

--
Shengjing Zhu


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010771: suricata: recieve erros after adding rule list

[Sascha Steinbiss]

severity 1010771 normal
thanks

Hi Tim,

I just noticed you also included your suricata.yaml configuration file 
in your bug report. I think I found the cause of your problem.


Let's take a look at a problematic rule:


9/5/2022 -- 14:20:21 -  -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] -
error parsing signature "alert udp ![$SMTP_SERVERS,$DNS_SERVERS] any ->
$DNS_SERVERS 53 (msg:"ET DNS DNS Lookup for localhost.DOMAIN.TLD";
content:"|01|"; offset:2; depth:1; content:"|00 01 00 00 00 00 00|";
distance:1; within:7; content:"|09|localhost"; fast_pattern; nocase;
classtype:bad-unknown; sid:2011802; rev:6; metadata:created_at 2010_10_13,
updated_at 2019_09_03;)" from file /var/lib/suricata/rules/suricata.rules at
line 3806


So this rule alerts if the content patterns are found in traffic from 
source addresses that are _not_ in the ranges configured for SMTP and 
DNS servers (![$SMTP_SERVERS,$DNS_SERVERS]). These variables are 
referenced in the rule but -- since the rule author does not know what 
the IP addresses of these servers are in your network -- need to be 
configured elsewhere, namely in your suricata.conf. Here's the relevant 
snippet from yours:


[...]> %YAML 1.1

---
vars:
   # more specific is better for alert accuracy and performance
   address-groups:
 HOME_NET: "[192.168.0.0/16,10.0.0.0/8,172.16.0.0/12]"
 HOME_NET: "[192.168.0.0/16]"
 HOME_NET: "[10.0.0.0/8]"
 HOME_NET: "[172.16.0.0/12]"
 HOME_NET: "any"
 EXTERNAL_NET: "!$HOME_NET"
 EXTERNAL_NET: "any"
 HTTP_SERVERS: "$HOME_NET"
 SMTP_SERVERS: "$HOME_NET"
 SQL_SERVERS: "$HOME_NET"
 DNS_SERVERS: "$HOME_NET"
 TELNET_SERVERS: "$HOME_NET"
 AIM_SERVERS: "$EXTERNAL_NET"
 DC_SERVERS: "$HOME_NET"
 DNP3_SERVER: "$HOME_NET"
 DNP3_CLIENT: "$HOME_NET"
 MODBUS_CLIENT: "$HOME_NET"
 MODBUS_SERVER: "$HOME_NET"
 ENIP_CLIENT: "$HOME_NET"
 ENIP_SERVER: "$HOME_NET"


So you are setting both SMTP_SERVERS and DNS_SERVERS to the same value 
as your HOME_NET, which here effectively is "any", i.e. any possible IP 
address. Note that each of these assignments of HOME_NET overwrites the 
previous setting, so the last one here counts.
Now, evaluating that configuration, the rule above is now requiring the 
source address to be _not_ any possible IP address, which is obviously a 
problem which leads to an error being reported:


9/5/2022 -- 14:20:21 -  -- [ERRCODE: 
SC_ERR_INVALID_SIGNATURE(39)] - Complete IP space negated. Rule

address range is NIL. Probably have a !any or an address range that
supplies a NULL address range
The solution is easy. Please set only one value for HOME_NET which 
correctly reflects your internal IP addresses and make sure that 
DNS_SERVERS and the others are also set accordingly. Did you just 
comment in all the examples [1] in the stock suricata.yaml file? These 
are just examples -- keeping the first one with the RFC1918 addresses is 
usually sufficient. Otherwise, setting these values is a typical step in 
Suricata initial configuration and baselining.


Note that the same applies to EXTERNAL_NET.

Please let me know if you have any more questions. Lowering the severity 
here since from what I can see this is not an issue with Suricata per se 
but rather related to configuration.


Best regards
Sascha


[1] https://github.com/OISF/suricata/blob/master/suricata.yaml.in#L19


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1010771: suricata: recieve erros after adding rule list

[Sascha Steinbiss]

Hi,

[...]

9/5/2022 -- 14:20:21 -  -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] -
Complete IP space negated. Rule address range is NIL. Probably have a !any or
an address range that supplies a NULL address range


This seems to indicate that in the rule below, the expression 
![$SMTP_SERVERS,$DNS_SERVERS] (most likely) negates the whole IP space. 
So this depends on what was set in these variables in your 
suricata.conf. How did you configure those? For example, when at least 
one of these is set to "any" then this situation will occur.


Please note that Suricata is unlikely to work "out of the box" without 
any additional configuration that tailors the installation to your 
system (e.g. at least setting monitoring interfaces, etc.) which is 
_not_ done when installing the Debian package.


Best regards
Sascha

Bug#999620: pktanon: autopkgtest regression on armhf

[Sascha Steinbiss]

Hi,


Do you think we should wait for this to be fixed? As I said before I (just
from my practical point of view) would be in favor of just removing the
problematic architectures.


I have no opinion on this.  But if you want the package to be releasable,
you will need to change it so that it is not building a (completely broken
and useless) package on armhf, then get agreement with the ftp team to
remove the existing armhf binaries.


Yes, sure. Will file RM bugs right after an upload disabling the builds.

BTW, since you seem to be knowledgeable in the matter, can you think of 
any other architectures I would need to exclude here other than armhf? 
Just to ensure that I remove a sensible list of affected archs and 
reduce potential rounds of additional RMs...


Thanks
Sascha


OpenPGP_signature
Description: OpenPGP digital signature

Bug#999620: pktanon: autopkgtest regression on armhf

[Sascha Steinbiss]

Hi Steve,

Many thanks for reproducing this and for offering a the detailed 
explanation. I would be happy to forward your findings to upstream 
(however, my previous issues/PRs on upstream's GitHub have gone 
unanswered). For the time being, I must admit I unfortunately do not 
have the time to fix it via a patch.


Do you think we should wait for this to be fixed? As I said before I 
(just from my practical point of view) would be in favor of just 
removing the problematic architectures.


Cheers
Sascha

On 13.04.22 22:39, Steve Langasek wrote:

Note that this will consistently fail alignment checks on architectures
which require alignment, because the initial buffer is allocated with
reasonable alignment (32bit) but the ethernet header is 14 bytes long, so
the TCP header fields will always be unaligned within the buffer.

On Wed, Apr 13, 2022 at 01:20:49PM -0700, Steve Langasek wrote:

Here is a backtrace of the armhf SIGBUS.

Note that not all ARM implementations return SIGBUS which is probably why
this was not reproducible on the porter machine.

# gdb --args pktanon -c /usr/share/doc/pktanon/examples/profiles/profile.xml 
./profiles/sample.pcap ./out.pcap
[...]
Reading symbols from pktanon...
Reading symbols from 
/usr/lib/debug/.build-id/af/1ac53f46ae133c8898358966960cba95ac7a70.debug...
(gdb) run
Starting program: /usr/bin/pktanon -c 
/usr/share/doc/pktanon/examples/profiles/profile.xml ./profiles/sample.pcap 
./out.pcap
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
---
pktanon --- profile-based traffic anonymization
---
initializing PktAnon,  configuration = 
/usr/share/doc/pktanon/examples/profiles/profile.xml
unknown element: pktanon-config: 37
unknown element: anonymizations: 102
istream: opened file ./profiles/sample.pcap
ostream: opened output file ./out.pcap
initialized

Program received signal SIGBUS, Bus error.
pktanon::TcpPacketTransformation::transform (this=, source_buffer=, destination_buffer=0xfffef35a "\212y\262X\335\300l\221", max_packet_length=40) at 
transformations/TcpPacketTransformation.cpp:88
88hton32 (output_header->ack_num);
(gdb) bt
#0  pktanon::TcpPacketTransformation::transform (this=,
 source_buffer=,
 destination_buffer=0xfffef35a "\212y\262X\335\300l\221",
 max_packet_length=40) at transformations/TcpPacketTransformation.cpp:88
#1  0x0040b77c in pktanon::IPv4PacketTransformation::transform (this=0x4b4eb0,
 source_buffer=, destination_buffer=0xfffef346 "E",
 max_packet_length=)
 at transformations/IPv4PacketTransformation.cpp:153
#2  0x0040af64 in pktanon::EthernetPacketTransformation::transform (
 this=0x4ad780, source_buffer=,
 destination_buffer=0xfffef338 
"\376\212\a\213\001\254\303\341\372DI\355\b", max_packet_length=74) at 
transformations/EthernetPacketTransformation.cpp:53
#3  0x00416862 in pktanon::transform_packet (stats=...,
 packet_len=,
 transformed_packet=0xfffef338 "\376\212\a\213\001\254\303\341\372DI\355\b", 
original_packet=0xfffef438 "", record_header=...) at Utils.h:26
#4  pktanon::IstreamInput::read_packets (this=0x4b3ce0)
 at IstreamRecordsHandler.cpp:121
#5  0x00415130 in pktanon::PktAnonRuntime::run () at PktAnonRuntime.cpp:37
#6  0x00405bfa in main (argc=, argv=)
 at src/Main.cpp:73
(gdb)

So, this is trying to do an hton32() operation on a field that is not 4-byte
aligned.

--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

Bug#1005479: toil: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13

[Sascha Steinbiss]

Hi Nilesh,

[…]
> Would it be possible to add a hint to ignore arm64 autopkgtest suite?

BTW I think this is possible already in the autopkgtest definition [1] by 
adding an Architecture: section and leaving out arm64 in the list of archs you 
list in there — if that is what you mean.

Cheers
Sascha

[1] https://people.debian.org/~eriberto/README.package-tests.html

Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

[Sascha Steinbiss]

Hi Andreas,

thanks for your quick reply!

On 19.02.22 22:17, Andreas Beckmann wrote:
> On 19/02/2022 20.13, Sascha Steinbiss wrote:
>>     79 | #error The version of CUB in your include path is not compatible
>> with this release of Thrust. CUB is now included in the CUDA Toolkit, so
>> you no longer need to use your own checkout of CUB. Define
>> THRUST_IGNORE_CUB_VERSION_CHECK to ignore this.
>>    |  ^
> 
> Currently thrust and cub are out of sync. I got somewhat distracted ...
> trying to add some autopkg tests.
> But this bug points out that thrust should have a tighter dependency on
> cub (not only >= upstreamversion , but also << upstreamversion+1).
> 
> If you want to blame anything, it's thrust.

OK, got it. Just wanted to find out if there's anything I can do from
the relion packaging side. Will take a break from working on this then
until this is sorted out.

Thanks and best wishes
Sascha

Bug#995224: [Debian-med-packaging] Bug#995224: relion-cuda: FTBFS with cub 1.14

[Sascha Steinbiss]

Hi all,

greetings from the Debian Med Sprint 2021!

[...]
> /usr/bin/nvcc -M -D__CUDACC__ 
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_projector_plan.cu -o 
> /build/relion-cuda-3.1.0/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o.NVCC-depend
>  -ccbin /usr/bin/cc -m64 -DINSTALL_LIBRARY_DIR=/usr/lib/ 
> -DSOURCE_DIR=/build/relion-cuda-3.1.0/src/ -DACC_CUDA=2 -DACC_CPU=1 -DCUDA 
> -DALLOW_CTF_IN_SGD -DHAVE_SINCOS -DHAVE_TIFF -Xcompiler 
> ,\"-g\",\"-O2\",\"-ffile-prefix-map=/build/relion-cuda-3.1.0=.\",\"-fstack-protector-strong\",\"-Wformat\",\"-Werror=format-security\",\"-O3\",\"-DNDEBUG\"
>  -arch=sm_35 -D__INTEL_COMPILER --default-stream per-thread 
> --disable-warnings -DNVCC -I/usr/include 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include 
> -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi 
> -I/build/relion-cuda-3.1.0 -I/usr/lib/fltk -I/usr/include/x86_64-linux-gnu
> nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35', 'sm_37' 
> and 'sm_50' architectures are deprecated, and may be removed in a future 
> release (Use -Wno-deprecated-gpu-targets to suppress warning).
> In file included from /usr/include/thrust/system/cuda/config.h:33,
>  from 
> /usr/include/thrust/system/cuda/detail/execution_policy.h:35,
>  from 
> /usr/include/thrust/iterator/detail/device_system_tag.h:23,
>  from 
> /usr/include/thrust/iterator/detail/iterator_facade_category.h:22,
>  from /usr/include/thrust/iterator/iterator_facade.h:37,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cub/device/../iterator/arg_index_input_iterator.cuh:48,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cub/device/device_reduce.cuh:41,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_utils_cub.cuh:16,
>  from 
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_projector_plan.cu:10:
> /usr/include/cub/util_namespace.cuh:46:2: error: #error CUB requires a 
> definition of CUB_NS_QUALIFIER when CUB_NS_PREFIX/POSTFIX are defined.
>46 | #error CUB requires a definition of CUB_NS_QUALIFIER when 
> CUB_NS_PREFIX/POSTFIX are defined.
>   |  ^
> CMake Error at 
> relion_gpu_util_generated_cuda_projector_plan.cu.o.Release.cmake:220 
> (message):
>   Error generating
>   
> /build/relion-cuda-3.1.0/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/./relion_gpu_util_generated_cuda_projector_plan.cu.o
> 
> 
> make[4]: *** [src/apps/CMakeFiles/relion_gpu_util.dir/build.make:1439: 
> src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o]
>  Error 1
> make[4]: Leaving directory '/build/relion-cuda-3.1.0/build'
> 
> 
> This seems to be the Breaking Change described in
> https://github.com/NVIDIA/cub/releases/tag/1.14.0:
> 
> #350: When the CUB_NS_[PRE|POST]FIX macros are set, CUB_NS_QUALIFIER
> must also be defined to the fully qualified CUB namespace (e.g.
> #define CUB_NS_QUALIFIER ::foo::cub). Note that this is handled
> automatically when using the new [THRUST_]CUB_WRAPPED_NAMESPACE mechanism.

I updated the relion code to the latest upstream version (3.1.3) and
tried to rebuild in the hope that it changed something: it did, now I get:

[...]
/usr/bin/nvcc -M -D__CUDACC__
/build/relion-cuda-3.1.3/src/acc/cuda/cuda_projector_plan.cu -o
/build/relion-cuda-3.1.3/build/src/apps/CMakeFiles/relion_gpu_util.dir/__/acc/cuda/relion_gpu_util_generated_cuda_projector_plan.cu.o.NVCC-depend
-ccbin /usr/bin/cc -m64 -DINSTALL_LIBRARY_DIR=/usr/lib/
-DSOURCE_DIR=/build/relion-cuda-3.1.3/src/ -DACC_CUDA=2 -DACC_CPU=1
-DCUDA -DALLOW_CTF_IN_SGD -DHAVE_SINCOS -DHAVE_TIFF -Xcompiler
,\"-g\",\"-O2\",\"-ffile-prefix-map=/build/relion-cuda-3.1.3=.\",\"-fstack-protector-strong\",\"-Wformat\",\"-Werror=format-security\",\"-O3\",\"-DNDEBUG\"
-arch=sm_35 -D__INTEL_COMPILER --default-stream per-thread
--disable-warnings -DNVCC -I/usr/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include
-I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi
-I/build/relion-cuda-3.1.3 -I/usr/lib/fltk -I/usr/include/x86_64-linux-gnu
nvcc warning : The 'compute_35', 'compute_37', 'compute_50', 'sm_35',
'sm_37' and 'sm_50' architectures are deprecated, and may be removed in
a future release (Use -Wno-deprecated-gpu-targets to suppress warning).
In file included from
/usr/include/thrust/system/cuda/detail/execution_policy.h:35,
 from
/usr/include/thrust/iterator/detail/device_system_tag.h:23,
 from
/usr/include/thrust/iterator/detail/iterator_facade_category.h:22,
 from /usr/include/thrust/iterator/iterator_facade.h:37,
 from
/build/relion-cuda-3.1.3/src/acc/cuda/cub/device/../iterator/arg_index_input_iterator.cuh:48,
 from
/build/relion-cuda-3.1.3/src/acc/cuda/cub/device/device_reduce.cuh:41,
 from

Bug#999806: pygattlib: Misbuild with multiple supported python versions

[Sascha Steinbiss]

Hi Nobuhiro,

[...]
> Python3.10 has been introduced in Ubuntu, and as part of the rebuild
> of packages against 3.10 I noticed that pygattlib misbuilds, linking
> both the python3.9 and python3.10 extensions against the same version
> of libboost_python instead of linking each against the matching
> version.
> 
> The attach patch fixes the build so that each binary extension will
> always be built against the matching libboost_python.

This bug is causing my dependent package gnome-keysign to drop out of
testing soon, so I would be happy to NMU this patch if you are fine with
that. Please let me know if you have any objections, otherwise I will
prepare a NMU in a week or so.

Thanks, and have a happy new year!
Sascha

Bug#1001981: [Pkg-privacy-maintainers] Bug#1001981: Bug#1001981: onioncircuits: Doesn't start: Permission denied: '/usr/local/lib/python3.9/dist-packages/usb-0.0.83.dev0.dist-info'

[Sascha Steinbiss]

severity 1001981 normal
thanks

FTR: The original reporter confirmed that removing the Python modules in
/usr/local got onioncircuits to start again. So lowering severity as
this is likely not a packaging bug breaking onioncircuits for everyone.

S.

On 23.12.21 12:58, Sascha Steinbiss wrote:
> Hi Richard,
> 
> thanks for your report. Let's see what I can do.
> 
>> clicking then launcher results in no visible action.
> 
> This is just in bullseye? Unfortunately I can't reproduce this,
> onioncircuits opens fine for me.
> 
>> Starting from shell
>> results in this:
>>
>> rz@rz-debian:~$ onioncircuits
> 
>> PermissionError: [Errno 13] Permission denied: 
>> '/usr/local/lib/python3.9/dist-
>> packages/usb-0.0.83.dev0.dist-info'
> 
> This is quite suspicious. There should no Python code installed by
> Debian packages in /usr/local [1]. It looks like something installed
> alongside the Debian-provided Python modules is interfering with
> operation of the pycountry module, which is a dependency of onioncircuits.
> Did you install any Python packages system-wide using pip or other means
> other than Debian packaging, maybe even using sudo? This may leave files
> around with permissions not including the rz user.
> 
> Can you please try uninstalling these files in
> /usr/local/lib/python3.9/dist-packages and try again? Thanks!
> 
> Cheers
> Sascha
> 
> [1] See Policy 9.1.2:
> https://www.debian.org/doc/debian-policy/ch-opersys.html#site-specific-programs
> 
> ___
> Pkg-privacy-maintainers mailing list
> pkg-privacy-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-privacy-maintainers
> 

Bug#1001981: [Pkg-privacy-maintainers] Bug#1001981: onioncircuits: Doesn't start: Permission denied: '/usr/local/lib/python3.9/dist-packages/usb-0.0.83.dev0.dist-info'

[Sascha Steinbiss]

Hi Richard,

thanks for your report. Let's see what I can do.

> clicking then launcher results in no visible action.

This is just in bullseye? Unfortunately I can't reproduce this,
onioncircuits opens fine for me.

> Starting from shell
> results in this:
> 
> rz@rz-debian:~$ onioncircuits

> PermissionError: [Errno 13] Permission denied: '/usr/local/lib/python3.9/dist-
> packages/usb-0.0.83.dev0.dist-info'

This is quite suspicious. There should no Python code installed by
Debian packages in /usr/local [1]. It looks like something installed
alongside the Debian-provided Python modules is interfering with
operation of the pycountry module, which is a dependency of onioncircuits.
Did you install any Python packages system-wide using pip or other means
other than Debian packaging, maybe even using sudo? This may leave files
around with permissions not including the rz user.

Can you please try uninstalling these files in
/usr/local/lib/python3.9/dist-packages and try again? Thanks!

Cheers
Sascha

[1] See Policy 9.1.2:
https://www.debian.org/doc/debian-policy/ch-opersys.html#site-specific-programs

Bug#999620: pktanon: autopkgtest regression on armhf

[Sascha Steinbiss]

Hi Paul,

sorry for the delay in replying, I was quite busy and now I have some
free time over the holidays to follow up.

>> I am puzzled. The recent upload only changed the watchfile and updated
>> Standards-Version, compat level etc -- packaging things. Nothing touched
>> the code or build rules.
> 
> Well, but maybe your build dependencies have. Also, compat level isn't
> totally safe either in general (although the issue here doesn't
> obviously look like it).

Yes, I agree it's likely not that.

[...]>> I must admit that being unfamiliar with these architectures and not
>> really having an idea of where to start, I am tempted to just remove
>> armhf from the list of supported architectures and have the version with
>> the broken autopkgtest removed from unstable. Do you probably know
>> someone who might be more knowledgeable with such architecture-specific
>> issues?
> 
> We have porters for architecture specific support. However, I'm not
> totally convinced yet it's architecture specific.

Maybe. You noted that it seems to work fine on a machine with the same
architecture but different specs.

> Is there anything I can try out for you on our armhf host to help debug
> the issue? Run the command with more debug options? Grab an output file
> from somewhere? 
Hmmm. Since I am pretty unfamiliar with the source and/or any
assumptions that are being made in the code, a good start would be to
get an idea of where in the code the bus error is triggered. You could
try the -v option but I am not sure it would help much.
I think a real stack trace would help, by running the tests with
valgrind or via gdb. Nothing one would do in a generic test suite :/
How much customization would be possible in the test run?

> I could try to run the test in testing with a rebuild of
> the package in testing, would that help?

Maybe, if that does not cost much then please try.

Cheers
Sascha

Bug#1001527: FTBFS with fmtlib 8

[Sascha Steinbiss]

Hi,

> I have uploaded fmtlib/8 to experimental, and plan to start this transition.
> 
> You package FTBFS with fmtlib/8, it has been fixed in version 2021.08.26.
> Please package the new version or backport the relevant commits.

Unfortunately never versions than the one currently in testing
(2021.05.27) can not be easily packaged, since new versions require
Apache Arrow which is not (yet) available in Debian [0]. A package for
Arrow has been prepared [1] but I am not willing to maintain this large
software dependency -- which is very actively developed with potentially
breaking API/ABI changes -- on my own so I am currently refraining from
uploading it. I have handed my preliminary work over to the Debian
Science Team.

The backport of the libfmt support update is too much of a hassle to
port to an old version that is unlikely to be used by anyone as VAST
development also moves too fast to be OK with Debian's update routine.

I suggest to let VAST drop out of testing until Apache Arrow is
available, so it does not block your transition.

Cheers
Sascha

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970021
[1] https://salsa.debian.org/science-team/arrow

Bug#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]

[Sascha Steinbiss]

Hi Roberto,

thanks for the quick response!

> I cannot attend to this at the moment, so I give you my blessing to
> proceed with the NMU.

Thanks, will do that and upload soon.

Cheers
Sascha

Bug#997248: mysql++: FTBFS: ./examples/load_jpeg.cpp:90:50: error: taking address of rvalue [-fpermissive]

[Sascha Steinbiss]

Hi everyone,

looks like upstream fixed this already [0]. The fix is easily imported
into packaging, see attached debdiff.

I would be happy to NMU this within a week or so if there is no action
by the maintainer to avoid mysql++ to be removed from testing. Please
let me know if this is not wanted. Also addressing this mail to the
previous uploader of the package.

mysql++ is a dependency of my augustus package, which I would prefer not
to be removed from testing.


Thanks
Sascha

[0]
https://github.com/tangentsoft/mysqlpp/commit/df890798c8017dee79d5e4ee0867e2dae44ca5b5
diff -Nru mysql++-3.2.5/debian/changelog mysql++-3.2.5/debian/changelog
--- mysql++-3.2.5/debian/changelog	2020-04-23 03:37:47.0 +0200
+++ mysql++-3.2.5/debian/changelog	2021-11-22 13:01:43.0 +0100
@@ -1,3 +1,11 @@
+mysql++ (3.2.5-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Incorporate patch from upstream to fix build on newer GCC versions.
+(Closes: #997248)
+
+ -- Sascha Steinbiss   Mon, 22 Nov 2021 13:01:43 +0100
+
 mysql++ (3.2.5-2) unstable; urgency=medium
 
   * Update to Standards-Version 4.5.0 (no changes)
diff -Nru mysql++-3.2.5/debian/patches/rvalue_fix_example.patch mysql++-3.2.5/debian/patches/rvalue_fix_example.patch
--- mysql++-3.2.5/debian/patches/rvalue_fix_example.patch	1970-01-01 01:00:00.0 +0100
+++ mysql++-3.2.5/debian/patches/rvalue_fix_example.patch	2021-11-22 12:55:30.0 +0100
@@ -0,0 +1,57 @@
+From df890798c8017dee79d5e4ee0867e2dae44ca5b5 Mon Sep 17 00:00:00 2001
+From: tangent 
+Date: Sat, 19 Sep 2020 17:24:45 +
+Subject: [PATCH] Exchanged the "file slurp" idiom used in
+ examples/load_jpeg.cpp for one that also works in C++11, which complains of
+ "address to rvalue" with the original formulation.
+
+FossilOrigin-Name: b062e656cc2ed9356c6f757837580a2145251c5294e382f8e2c1ad3e74a91cdd
+---
+ examples/load_jpeg.cpp | 18 ++
+ 1 file changed, 10 insertions(+), 8 deletions(-)
+
+--- a/examples/load_jpeg.cpp
 b/examples/load_jpeg.cpp
+@@ -2,9 +2,9 @@
+  load_jpeg.cpp - Example showing how to insert BLOB data into the
+ 	database from a file.
+ 
+- Copyright (c) 1998 by Kevin Atkinson, (c) 1999-2001 by MySQL AB, and
+- (c) 2004-2009 by Educational Technology Resources, Inc.  Others may
+- also hold copyrights on code in this file.  See the CREDITS.txt file
++ Copyright © 1998 by Kevin Atkinson, © 1999-2001 by MySQL AB, and
++ © 2004-2009 by Educational Technology Resources, Inc.  Others may
++ also hold copyrights on code in this file.  See the CREDITS.md file
+  in the top directory of the distribution for details.
+ 
+  This file is part of MySQL++.
+@@ -80,14 +80,16 @@
+ 	img_name = cmdline.extra_args()[0];
+ 	ifstream img_file(img_name.c_str(), ios::binary);
+ 	if (img_file) {
+-		// Slurp file contents into RAM with minimum copying.  (Idiom
+-		// explained here: http://stackoverflow.com/questions/116038/)
++		// Slurp file contents into RAM with only a single copy, per
++		// https://stackoverflow.com/a/116220  It also explains why
++// there is no concise zero-copy option here.
+ 		//
+ 		// By loading the file into a C++ string (stringstream::str())
+ 		// and assigning that directly to a mysqlpp::sql_blob, we avoid
+ 		// truncating the binary data at the first null character.
+-		img.data.data = static_cast(
+-&(stringstream() << img_file.rdbuf()))->str();
++stringstream ss;
++ss << img_file.rdbuf();
++		img.data.data = ss.str();
+ 
+ 		// Check JPEG data for sanity.
+ 		const char* error;
+@@ -130,7 +132,7 @@
+ 			// as C strings, thus causing null-truncation.  The fact
+ 			// that we're using SSQLS here is a side issue, simply
+ 			// demonstrating that mysqlpp::Null is
+-			// now legal in SSQLS, as of MySQL++ 3.0.7.
++// now legal in SSQLS, as of MySQL++ 3.0.7.
+ 			Query query = con.query();
+ 			query.insert(img);
+ 			SimpleResult res = query.execute();
diff -Nru mysql++-3.2.5/debian/patches/series mysql++-3.2.5/debian/patches/series
--- mysql++-3.2.5/debian/patches/series	2020-04-23 03:37:47.0 +0200
+++ mysql++-3.2.5/debian/patches/series	2021-11-22 12:54:57.0 +0100
@@ -1,2 +1,3 @@
 do_not_link_against_libmysqlclient_r.patch
 discover_localtime_r_with_AC_TRY_COMPILE.patch
+rvalue_fix_example.patch

Bug#999620: pktanon: autopkgtest regression on armhf

[Sascha Steinbiss]

Hi Paul,

> With a recent upload of pktanon the autopkgtest of pktanon fails in
> testing on armhf when that autopkgtest is run with the binary packages
> of pktanon from unstable. 
[...]
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?

I am puzzled. The recent upload only changed the watchfile and updated
Standards-Version, compat level etc -- packaging things. Nothing touched
the code or build rules.

Also, I can't reproduce the bus error when running the offending command
from the autopkgtest on a version I built on a porterbox:

(sid_armhf-dchroot)satta@abel:~/pktanon-2~git20160407.0.2bde4f2+dfsg$
../usr/bin/pktanon -c
../usr/share/doc/pktanon/examples/profiles/profile.xml
profiles/sample.pcap ./out.pcap
---
pktanon --- profile-based traffic anonymization
---
initializing PktAnon,  configuration =
../usr/share/doc/pktanon/examples/profiles/profile.xml
unknown element: pktanon-config: 37
unknown element: anonymizations: 102
istream: opened file profiles/sample.pcap
ostream: opened output file ./out.pcap
initialized
complete

statistics for input file 'profiles/sample.pcap'
  processed packets: 9
  errors in packets: 0
  elapsed time:  639us
  Mpps:  0.0141

I must admit that being unfamiliar with these architectures and not
really having an idea of where to start, I am tempted to just remove
armhf from the list of supported architectures and have the version with
the broken autopkgtest removed from unstable. Do you probably know
someone who might be more knowledgeable with such architecture-specific
issues?

Cheers
Sascha

Bug#987378: yara breaks golang-github-hillu-go-yara autopkgtest + ftbfs

[Sascha Steinbiss]

Hi,

I think this is done now. With YARA 4.1.2 and 
golang-github-hillu-go-yara 4.1.0 now in unstable, the build works again 
as the build-time tests complete fine.


@Hilko any other comments?

Cheers
Sascha

Bug#937269: peframe: Python2 removal in sid/bullseye

[Sascha Steinbiss]

Hi,


Please feel free to remove it for now, unless someone wants to take over.


Ack. Given that noone stepped up for about a year now, I'll go ahead and file
a removal request.


Fine with me!

Cheers
Sascha

Bug#971296: rekall: Switch to python3-pycryptodome

[Sascha Steinbiss]

Hi all,

[..]> I just discovered that rekall is no longer maintained at the upstream
> level so I'm wondering if we should not just remove the package.
> 
> Hilko, Sascha, what do you think?

Just bringing this up again... I would be in favour of removing it
completely. Would be happy to file a RM from unstable if there are no
objections.

Cheers
Sascha

Bug#971296: rekall: Switch to python3-pycryptodome

[Sascha Steinbiss]

Hi everyone,

[...]
> I just discovered that rekall is no longer maintained at the upstream
> level so I'm wondering if we should not just remove the package.
> 
> Hilko, Sascha, what do you think?

I would be fine with removing it as at least I don't have much interest
in it any more anyway. It was a dependency for GRR which has not even
been part of buster. Hilko, what do you think?

[...]
> For the time being, I increase the severity of the bug to get it out of
> testing.

OK with me.

Cheers
Sascha

Bug#971789: FTBFS: Could not determine section for ./.gopath/src/github.com/docker/cli/man/man1/docker-attach.1

[Sascha Steinbiss]

Hi,

has anyone taken any action here already? Some of my packages are
affected by this as well.

Cheers
Sascha

Bug#971154: fever: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/DCSO/fever/cmd/fever github.com/DCSO/fever/cmd/fever/cmds github.com/DCSO/fever/db github.

[Sascha Steinbiss]

reassign 971154 golang-go
thanks


Hi Lucas,

Thanks for reporting this.

[…]
>> ok   github.com/DCSO/fever/input 15.229s
>> # github.com/DCSO/fever/processing [github.com/DCSO/fever/processing.test]
>> compile: loop

To me, this looks like a possible Go regression, though. The above seems to be 
an internal compiler message, and the tests finish fine in Go 1.14. I just 
confirmed that by running the tests from the upstream code (i.e. via my GOPATH) 
with these two golang-go versions in Debian. 1.15 fails, 1.14 succeeds. 
Unfortunately the Go 1.15 changelog does not mention any known problems in that 
direction… :/

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#970340: [Debian-med-packaging] Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

[Sascha Steinbiss]

Hi all,

>> you once wrote that test.  Do you have any idea how to fix it?
> 
> Since this is just a warning, it might be sufficient to simply add
> 
>   Restrictions: allow-stderr
> 
> That would make sure that printing a warning to stderr does not cause
> the test to fail. I will test this later and fix it if that was the problem.

I can confirm that that was the issue. I have pushed a fix to git and
will make an upload later if there are no objections.

Best regards
Sascha

Bug#970340: rna-star: autopkgtest regression: --genomeSAindexNbases 8 is too large for the genome size=99940

[Sascha Steinbiss]

Hi all,

> you once wrote that test.  Do you have any idea how to fix it?

Since this is just a warning, it might be sufficient to simply add

  Restrictions: allow-stderr

That would make sure that printing a warning to stderr does not cause
the test to fail. I will test this later and fix it if that was the problem.

Cheers
Sascha

Bug#937269: peframe: Python2 removal in sid/bullseye

[Sascha Steinbiss]

Hi Moritz,

>> Just an update: Python 3 compatibility is indeed introduced in the latest 
>> upstream version, however, that version also adds some new dependencies that 
>> would need to be packaged and pass NEW. For example, python-virustotal-api, 
>> which has been in NEW for quite some time. I have also looked at adding 
>> python-oletools, but that will also need new dependencies of its own.
>> I’ll try work on this eventually, unless someone else is interested and has 
>> some spare time.
> 
> Are you still actively working on this one or should we rather remove peframe 
> for now?

I am sorry to say that I am not at the moment. The number of dependencies (and 
some license issues) to package the new version is currently exceeding my 
non-work Debian time :?

Please feel free to remove it for now, unless someone wants to take over.

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#963332: ariba: FTBFS: dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8 returned exit code 13

[Sascha Steinbiss]

Hi Andreas,

thanks for your email!

[Test failures]
[...]
>>> --
>>> Ran 356 tests in 57.387s
>>>
>>> FAILED (SKIP=2, errors=6)
>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
>>> /<>/.pybuild/cpython3_3.8_ariba/build; python3.8 -m nose -v 
>>> dh_auto_test: error: pybuild --test --test-nose -i python{version} -p 3.8 
>>> returned exit code 13
> 
> It seems the test failures are all connected to pymummer which was
> upgraded recently.

Okay, I can take a look.

> BTW, I've added a (Build-)Depends on spades which also shows up in the
> test log as missing without causing an actual error.

That's because it is not an error: ariba supports multiple assemblers,
and by default it looks like the much more lightweight fermi-lite
(libfml) is used. Hence I wouldn't depend on it; it might be a good
Suggestion though?

Best regards
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#952316: [pkg-go] Bug#952316: gopacket: FTBFS: dh_auto_build: error: cd obj-x86_64-linux-gnu && go install -trimpath -v -p 4 github.com/google/gopacket github.com/google/gopacket/afpacket github.co

[Sascha Steinbiss]

Hi.

> During a rebuild of all packages in sid, your package failed to build
> on amd64.

This is easily fixed by updating to the latest upstream version (1.1.17).

@Hilko: OK with you? I have already prepared the update as need this for
stenographer to migrate. Gopacket as a dependency has been removed from
testing due to this RC bug.

Will do a team upload on the weekend if there are no objections.

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#951765: suricata: FTBFS on armel: atomic builtins clashing with Rust objects

[Sascha Steinbiss]

Source: suricata
Severity: serious
Tags: ftbfs help
Justification: fails to build from source (but built successfully in the past)

Suricata fails to build on armel at link time [1] due to duplicate objects 
between what
is built by the Rust compiler and what is built by gcc:

/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_add_4':
(.text+0x0): multiple definition of `__sync_fetch_and_add_4'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_add_4+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_sub_4':
(.text+0x38): multiple definition of `__sync_fetch_and_sub_4'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_sub_4+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_or_4':
(.text+0x70): multiple definition of `__sync_fetch_and_or_4'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_or_4+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_and_4':
(.text+0xa8): multiple definition of `__sync_fetch_and_and_4'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_and_4+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_xor_4':
(.text+0xe0): multiple definition of `__sync_fetch_and_xor_4'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_xor_4+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_nand_4':
(.text+0x118): multiple definition of `__sync_fetch_and_nand_4'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_nand_4+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_add_2':
(.text+0x154): multiple definition of `__sync_fetch_and_add_2'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_add_2+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_sub_2':
(.text+0x1b4): multiple definition of `__sync_fetch_and_sub_2'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_sub_2+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_or_2':
(.text+0x214): multiple definition of `__sync_fetch_and_or_2'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_or_2+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_and_2':
(.text+0x274): multiple definition of `__sync_fetch_and_and_2'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_and_2+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_xor_2':
(.text+0x2d4): multiple definition of `__sync_fetch_and_xor_2'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_xor_2+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_nand_2':
(.text+0x334): multiple definition of `__sync_fetch_and_nand_2'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_nand_2+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_add_1':
(.text+0x398): multiple definition of `__sync_fetch_and_add_1'; 
../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed12b87c.compiler_builtins.k83988xm-cgu.1.rcgu.o):(.text.__sync_fetch_and_add_1+0x0):
 first defined here
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/9/libgcc.a(linux-atomic.o): in 
function `__sync_fetch_and_sub_1':
(.text+0x3f4): multiple definition of `__sync_fetch_and_sub_1'; 

Bug#950211: python-virustotal-api fails autopkg test

[Sascha Steinbiss]

Hi Matthias,

>>> Or you remove the autodep8 test from debian/control.
>> Indeed that is what I changed in 1.1.11-2 which should be in both sid
>> and bullseye by now -- I changed the autopkgtest definition and added
>> custom test scripts reflecting the situation.
>> 
>> All tests are green so far now [3]. Where did you get your log snippet from?
> 
> http://autopkgtest.ubuntu.com/packages/p/python-virustotal-api/focal/amd64

But version 1.1.11-2 (without the ubuntu1 patch) also passes its autopkgtest in 
the list on that page (row 3)?

> that's what I changed, it's still in the control file.
> 
> http://launchpadlibrarian.net/462719068/python-virustotal-api_1.1.11-2_1.1.11-2ubuntu1.diff.gz

This would also only cause the CI to run the regular autopkgtest in 
debian/tests, instead of the failing Python-specific ones that assume a 
particular mapping from import name to package name. My change in 1.1.11-2 does 
the same:

diff --git a/debian/control b/debian/control
index 83a6cfe..6032eda 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends: debhelper-compat (= 12),
python3-setuptools,
python3-requests
 Standards-Version: 4.5.0
-Testsuite: autopkgtest-pkg-python
+Testsuite: autopkgtest
 Vcs-Git: https://salsa.debian.org/debian/python-virustotal-api.git
 Vcs-Browser: https://salsa.debian.org/debian/python-virustotal-api
 Homepage: https://github.com/blacktop/virustotal-api

Plus adding a separate, explicit test setup in d/tests, of course.

I do not see where removing the Testsuite line would change anything compared 
to 1.1.11-2, given that the autopkgtest for that’s version passes even on 
Ubuntu’s CI. Am I missing something?

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#950211: python-virustotal-api fails autopkg test

[Sascha Steinbiss]

Hi Matthias,

> the autodep8 test fails, because the package is wrongly named.  The package 
> name
> should be python-virustotal-apis? 

I wanted to be in line with the name of the package on PyPi [1] as that
how I would look for this package if I wanted to use it.
'virustotal-api' is also the module name according to upstream's
setup.py [2]

Looks like upstream themselves seem to use diverging names by using
virus_total_apis as the module to import :/

> Or you remove the autodep8 test from debian/control.
Indeed that is what I changed in 1.1.11-2 which should be in both sid
and bullseye by now -- I changed the autopkgtest definition and added
custom test scripts reflecting the situation.

All tests are green so far now [3]. Where did you get your log snippet from?

Best regards
Sascha

[1] https://pypi.org/project/virustotal-api/
[2] https://github.com/blacktop/virustotal-api/blob/master/setup.py#L25
[3] https://ci.debian.net/packages/p/python-virustotal-api/



signature.asc
Description: OpenPGP digital signature

Bug#937269: peframe: Python2 removal in sid/bullseye

[Sascha Steinbiss]

Just an update: Python 3 compatibility is indeed introduced in the latest 
upstream version, however, that version also adds some new dependencies that 
would need to be packaged and pass NEW. For example, python-virustotal-api, 
which has been in NEW for quite some time. I have also looked at adding 
python-oletools, but that will also need new dependencies of its own.
I’ll try work on this eventually, unless someone else is interested and has 
some spare time.


Sascha

Bug#937811: python-hkdf: Python2 removal in sid/bullseye

[Sascha Steinbiss]

> It looks like all reverse deps are currently exclusively using the Python3 
> version: 

Or maybe not, looks like not all rdeps are displayed. Looks like things
like python-omemo and friends still depend on this.
So no removal upload for me then.

S.

Bug#937811: python-hkdf: Python2 removal in sid/bullseye

[Sascha Steinbiss]

It looks like all reverse deps are currently exclusively using the Python3 
version: 

  [vagrant@debian:~/gnome-keysign] $ apt-rdepends -r python3-hkdf
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  python3-hkdf
Reverse Depends: magic-wormhole (0.11.2-1)
Reverse Depends: python3-spake2 (0.8-2)
  magic-wormhole
Reverse Depends: gnome-keysign (1.2.0-1)
  gnome-keysign
  python3-spake2
Reverse Depends: magic-wormhole (>= 0.11.2-1)
  [vagrant@debian:~/gnome-keysign] $ apt-rdepends -r python-hkdf
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  python-hkdf

I will prepare a QA upload removing the Python2 binary package then, if there 
are no objections.

Cheers
Sascha

Bug#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

[Sascha Steinbiss]

Hi Aurelien,

thanks for the quick reply!

>> 7.8 of the policy requires that I have an ‘=‘ version relation on the 
>> package listed in ‘Built-Using' — I am not even sure how I would determine 
>> that for the source package since it’s not even used in the build?
> 
> Quoting the corresponding sentence:
> 
> "the Built-Using field must list the corresponding source package for
> any affected binary package incorporated during the build."
> 
> So you definitely need to use the source version, that's why the package
> has been rejected by dak.


Okay. So to be precise: To satisfy the exact '=' relation I need to
determine at build time what version of libbam-dev is used in the build,
and then use that version number to declare a Built-Using on the source
package (samtools-legacy) with that version number?

Thanks
Sascha

Bug#940703: [Debian-med-packaging] Bug#940703: augustus_3.3.3+dfsg-1_mips64el.changes REJECTED

[Sascha Steinbiss]

> On 19. Sep 2019, at 11:29, Aurelien Jarno  wrote:
> 
> Package: augustus
> Version: 3.3.3+dfsg-1
> Severity: serious
> 
> On 2019-09-18 23:34, Debian FTP Masters wrote:
>> augustus_3.3.3+dfsg-1_mips64el.deb: Built-Using refers to non-existing 
>> source package libbam-dev (= 0.1.19-4)
>> 
>> 
>> Mapping sid to unstable.
>> 
>> ===
>> 
>> Please feel free to respond to this email if you don't understand why
>> your files were rejected, or if you upload new files which address our
>> concerns.
>> 
>> 
>> 
> 
> The Built-Using field should use the source package (i.e.
> samtools-legacy), not the binary package.


Why? In the build am only using the static library from libbam-dev, not 
compiling source code from the samtools-legacy source package. Sorry, but this 
is a serious question as I am not sure what do do here.

7.8 of the policy requires that I have an ‘=‘ version relation on the package 
listed in ‘Built-Using' — I am not even sure how I would determine that for the 
source package since it’s not even used in the build?
Do I even need to provide a Built-Using here? Searching on code search for 
libbam-dev and samtools-legacy did not turn up a single case where a 
Built-Using was set.

Thanks
Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924359


signature.asc
Description: Message signed with OpenPGP

Bug#935917: suricata-update: cannot use suricata-update command

[Sascha Steinbiss]

Dear Aaron,

Thanks for bringing this to my attention.


> I just installed the suricata-update package from the Debian buster repo. 
> Before that, I used the github version which worked fine. 

I see.

> 
> The "suricata-update" command of the Debian package tries to execute a file 
> /usr/local/bin/suricata-update which doesn't exist (even the folder 
> /usr/local/bin doesn't exist).
> The right path should be /usr/bin/suricata-update (without local!).

Indeed the package installs suricata-update into that directory. I just tried a 
clean install on buster and all I get is exactly that file [1], which executes 
perfectly. The package never makes any reference to /usr/local/bin.

My first suspicion was that there might be a leftover script from your old 
GitHub install in your /usr/local/bin directory. /usr/local/bin is a typical 
install path for non-distribution installations, e.g. via pip/setup.py or the 
like, and comes before /usr/bin in the $PATH search dir.
However, as you are mentioning that the directory does not even exist at all, I 
am a bit puzzled.

Can you probably share the output of your ‘which suricata-update’ and the exact 
error message you get when trying to execute the command? Have you tried 
executing the command in a new shell or after doing a ‘hash -r’ (assuming you 
are using bash)? This could help find out where the problematic path comes from.

Cheers
Sascha

[1] https://packages.debian.org/buster/amd64/suricata-update/filelist

Bug#921759: sdaps: FTBFS (Error running "pdflatex" to compile the LaTeX file)

[Sascha Steinbiss]

user debian-rele...@lists.debian.org
tag 921759 + patch
usertag 921759 + bsp-2019-02-de-berlin
thank you

Dear maintainers,

Greetings from the BSP at the DCSO office in Berlin.
I fixed this issue and attached a patch.

Cheers
Sascha
diff -Nru sdaps-1.2.1/debian/changelog sdaps-1.2.1/debian/changelog
--- sdaps-1.2.1/debian/changelog	2018-01-15 22:05:56.0 +0100
+++ sdaps-1.2.1/debian/changelog	2019-02-10 15:51:38.0 +0100
@@ -1,3 +1,10 @@
+sdaps (1.2.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Disable bookmark package to address clash with 'style' option.
+
+ -- Sascha Steinbiss   Sun, 10 Feb 2019 15:51:38 +0100
+
 sdaps (1.2.1-1) unstable; urgency=medium
 
   * Initial release (Closes: #887393)
diff -Nru sdaps-1.2.1/debian/patches/disable-bookmark.patch sdaps-1.2.1/debian/patches/disable-bookmark.patch
--- sdaps-1.2.1/debian/patches/disable-bookmark.patch	1970-01-01 01:00:00.0 +0100
+++ sdaps-1.2.1/debian/patches/disable-bookmark.patch	2019-02-10 15:51:38.0 +0100
@@ -0,0 +1,18 @@
+Description: Disable bookmark package
+ According to https://golatex.de/komacv-geht-nicht-mit-style-t21445.html, there is
+ an option clash regarding the 'style' option in the bookmark package, which does
+ not recognize the 'classic' setting that is given here.
+ We disable that package to address this issue.
+Author: Sascha Steinbiss 
+Last-Update: 2019-02-10
+--- a/tex/sdaps.cls
 b/tex/sdaps.cls
+@@ -151,7 +151,7 @@
+ %---
+ % load base-class
+ %---
+-\LoadClass{scrartcl}
++\LoadClass[bookmarkpackage=false]{scrartcl}
+ 
+ 
+ %---
diff -Nru sdaps-1.2.1/debian/patches/series sdaps-1.2.1/debian/patches/series
--- sdaps-1.2.1/debian/patches/series	2018-01-15 22:05:56.0 +0100
+++ sdaps-1.2.1/debian/patches/series	2019-02-10 15:51:38.0 +0100
@@ -1,3 +1,4 @@
 remove_latex_copy.patch
 merge_texinputs.patch
 fix_tests.patch
+disable-bookmark.patch

Bug#921778: deap: FTBFS (Could not import extension sphinx.ext.pngmath)

[Sascha Steinbiss]

user debian-rele...@lists.debian.org
usertag 921778 + bsp-2019-02-de-berlin
thank you

Dear maintainers,

Greetings from the BSP at the DCSO office in Berlin.

I have fixed this bug and attached a patch for the issue.

Cheers
Sascha
diff --git a/debian/changelog b/debian/changelog
index b1133ac..d799f8c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,10 +1,15 @@
-deap (1.0.2.post2-6) UNRELEASED; urgency=medium
+deap (1.0.2.post2-6.1) UNRELEASED; urgency=medium
 
+  [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
   * d/watch: Use https protocol
   * d/tests: Use AUTOPKGTEST_TMP instead of ADTTMP
 
- -- Ondřej Nový   Tue, 13 Feb 2018 10:18:20 +0100
+  [ Sascha Steinbiss ]
+  * Use imgmath Sphinx extension instead of deprecated pngmath.
+Closes: #921778
+
+ -- Sascha Steinbiss   Sat, 09 Feb 2019 19:28:44 +0100
 
 deap (1.0.2.post2-5) unstable; urgency=medium
 
diff --git a/debian/patches/0003-remove-pngmath.patch b/debian/patches/0003-remove-pngmath.patch
new file mode 100644
index 000..ec000fb
--- /dev/null
+++ b/debian/patches/0003-remove-pngmath.patch
@@ -0,0 +1,17 @@
+Description: replace pngmath with imgmath
+ The pngmath Sphinx extension has been deprecated in Sphinx 1.4 and
+ was removed for good in Sphinx 1.8. It can be replaced safely by the
+ imgmath extension, which is also available in 1.4 (so also in stretch).
+Author: Sascha Steinbiss 
+Last-Update: 2019-02-09
+--- a/doc/conf.py
 b/doc/conf.py
+@@ -27,7 +27,7 @@
+ # coming with Sphinx (named 'sphinx.ext.*') or your custom ones
+ 
+ extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.todo',
+-  'sphinx.ext.pngmath', 'sphinx.ext.intersphinx', 'sphinx.ext.extlinks'] 
++  'sphinx.ext.imgmath', 'sphinx.ext.intersphinx', 'sphinx.ext.extlinks']
+ 
+ try:
+ import matplotlib
diff --git a/debian/patches/series b/debian/patches/series
index 233d16a..393233d 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 0001-fix-docs.patch
 0002-fix-tests.patch
+0003-remove-pngmath.patch

Bug#915175: oath-toolkit FTBFS with glibc 2.28

[Sascha Steinbiss]

user debian-rele...@lists.debian.org

usertag 915175 + bsp-2019-02-de-berlin
thank you

Dear maintainers,

Greetings from the BSP at the DCSO office in Berlin.

> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time 
> -D_FORTIFY_SOURCE=2 -fvisibility=hidden -g -O2 
> -ffile-prefix-map=/build/1st/oath-toolkit-2.6.1=. -fstack-protector-strong 
> -Wformat -Werror=format-security -c fseeko.c  -fPIC -DPIC -o .libs/fseeko.o
> fseeko.c: In function 'rpl_fseeko':
> fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! 
> Look at the code in fseeko.c, then report this to bug-gnulib."
>#error "Please port gnulib fseeko.c to your platform! Look at the code in 
> fseeko.c, then report this to bug-gnulib."
> ^
> make[7]: *** [Makefile:1402: fseeko.lo] Error 1

I have fixed this bug and NMU'd oath-toolkit_2.6.1-1.3 to DELAYED/5.
Please feel free to reschedule or cancel my upload as you see fit. I
have attached the diff.

Cheers
Sascha
diff -Nru oath-toolkit-2.6.1/debian/changelog oath-toolkit-2.6.1/debian/changelog
--- oath-toolkit-2.6.1/debian/changelog	2018-06-22 19:48:53.0 +0200
+++ oath-toolkit-2.6.1/debian/changelog	2019-02-09 16:39:41.0 +0100
@@ -1,3 +1,11 @@
+oath-toolkit (2.6.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Use _IO_EOF_SEEN as GNU libc indicator.
+Closes: #915175
+
+ -- Sascha Steinbiss   Sat, 09 Feb 2019 16:39:41 +0100
+
 oath-toolkit (2.6.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru oath-toolkit-2.6.1/debian/patches/new-glibc-check.patch oath-toolkit-2.6.1/debian/patches/new-glibc-check.patch
--- oath-toolkit-2.6.1/debian/patches/new-glibc-check.patch	1970-01-01 01:00:00.0 +0100
+++ oath-toolkit-2.6.1/debian/patches/new-glibc-check.patch	2019-02-09 16:39:41.0 +0100
@@ -0,0 +1,25 @@
+Description: Check _IO_EOF_SEEN instead of _IO_ftrylockfile
+ Needed to get fseeko.c to build with glibc 2.28.
+ Inspired by https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a71827c0bc5e0ec67af23edef4f15cee8e.
+Author: Sascha Steinbiss 
+Last-Update: 2019-02-09
+--- a/liboath/gl/fseeko.c
 b/liboath/gl/fseeko.c
+@@ -47,7 +47,7 @@
+ #endif
+ 
+   /* These tests are based on fpurge.c.  */
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   if (fp->_IO_read_end == fp->_IO_read_ptr
+   && fp->_IO_write_ptr == fp->_IO_write_base
+   && fp->_IO_save_base == NULL)
+@@ -123,7 +123,7 @@
+   return -1;
+ }
+ 
+-#if defined _IO_ftrylockfile || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
++#if defined _IO_EOF_SEEN || __GNU_LIBRARY__ == 1 /* GNU libc, BeOS, Haiku, Linux libc5 */
+   fp->_flags &= ~_IO_EOF_SEEN;
+   fp->_offset = pos;
+ #elif defined __sferror || defined __DragonFly__ || defined __ANDROID__
diff -Nru oath-toolkit-2.6.1/debian/patches/series oath-toolkit-2.6.1/debian/patches/series
--- oath-toolkit-2.6.1/debian/patches/series	2018-04-15 20:19:41.0 +0200
+++ oath-toolkit-2.6.1/debian/patches/series	2019-02-09 16:39:41.0 +0100
@@ -1 +1,2 @@
 gtkdocize.patch
+new-glibc-check.patch

Bug#884721: rsyncrypto: Segmentation fault with --delete

[Sascha Steinbiss]

user debian-rele...@lists.debian.org

usertag 884721 + bsp-2019-02-de-berlin
usertag 912051 + bsp-2019-02-de-berlin
thank you

Dear maintainers,

Greetings from the BSP at the DCSO office in Berlin.

I have fixed this bug and NMU'd rsyncrypto_1.14-1.1 to DELAYED/5. Please
feel free to reschedule or cancel my upload as you see fit. I have
attached the diff.

Cheers
Sascha
diff -Nru rsyncrypto-1.14/debian/changelog rsyncrypto-1.14/debian/changelog
--- rsyncrypto-1.14/debian/changelog	2017-09-06 19:30:22.0 +0200
+++ rsyncrypto-1.14/debian/changelog	2019-02-09 15:11:50.0 +0100
@@ -1,3 +1,13 @@
+rsyncrypto (1.14-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add explicit build dependency on automake-1.15.
+Closes: #912051   
+  * Fix segfault with --delete. Thanks to Chris Boot for the patch.
+Closes: #884721
+
+ -- Sascha Steinbiss   Sat, 09 Feb 2019 15:11:50 +0100
+
 rsyncrypto (1.14-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru rsyncrypto-1.14/debian/control rsyncrypto-1.14/debian/control
--- rsyncrypto-1.14/debian/control	2017-09-06 19:30:22.0 +0200
+++ rsyncrypto-1.14/debian/control	2019-02-09 15:11:50.0 +0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Shachar Shemesh 
-Build-Depends: debhelper (>= 9), libssl-dev (>= 1.1.0), libargtable2-dev, autotools-dev
+Build-Depends: debhelper (>= 9), libssl-dev (>= 1.1.0), libargtable2-dev, autotools-dev, automake-1.15
 Standards-Version: 4.1.0
 Homepage: https://rsyncrypto.lingnu.com
 
diff -Nru rsyncrypto-1.14/debian/patches/fix_segfault_in_unlink rsyncrypto-1.14/debian/patches/fix_segfault_in_unlink
--- rsyncrypto-1.14/debian/patches/fix_segfault_in_unlink	1970-01-01 01:00:00.0 +0100
+++ rsyncrypto-1.14/debian/patches/fix_segfault_in_unlink	2019-02-09 15:11:50.0 +0100
@@ -0,0 +1,17 @@
+Description: fix segfault
+ This fixes a crash when using rsyncrypto to refresh an
+ encrypted directory tree with --delete enabled.
+ This happens because of an infinite recursion in autofd::unlink()
+Author: Chris Boot 
+Last-Update: 2019-02-09
+--- a/autofd.h
 b/autofd.h
+@@ -216,7 +216,7 @@
+ // unless it failed with ENOENT - the file already doesn't exist
+ static int unlink(const char *pathname)
+ {
+-bool success=unlink( pathname )==0;
++bool success=::unlink( pathname )==0;
+ if( !success && errno!=ENOENT )
+ throw rscerror("Erasing file", errno, pathname );
+ 
diff -Nru rsyncrypto-1.14/debian/patches/series rsyncrypto-1.14/debian/patches/series
--- rsyncrypto-1.14/debian/patches/series	2017-09-06 19:30:22.0 +0200
+++ rsyncrypto-1.14/debian/patches/series	2019-02-09 15:11:50.0 +0100
@@ -1 +1,2 @@
 remove_precompiled_headers
+fix_segfault_in_unlink

Bug#918850: libmypaint: FTBFS with Sphinx 1.8: No module named 'sphinx.ext.pngmath'

[Sascha Steinbiss]

user debian-rele...@lists.debian.org
usertag 918850 + bsp-2019-02-de-berlin
thank you

Hi all,

Greetings from the BSP at the DCSO office in Berlin.

> libmypaint fails to build with Sphinx 1.8, currently available in
> experimental:
[...]
> The pngmath extension was deprecated in Sphinx 1.4 and has been removed [1]
> in Sphinx 1.8. The recommended alternative is sphinx.ext.imgmath [2] which
> also has SVG support in addition to PNG.
> 
> To me it looks like this extension is unused anyway: there are no “.. math::”
> directives or “:math:” roles, and libmypaint-doc does not have any generated
> PNG images. So this extension can be simply removed from extensions in
> conf.py.

I have incorporated this fix and will upload a non-maintainer upload
(libmypaint_1.3.0-2.1) to DELAYED with a 5 day delay. See attached patch
for an overview.

Cheers
Sascha

diff --git a/debian/changelog b/debian/changelog
index 3bc3051..6a01797 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+libmypaint (1.3.0-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove unused Sphinx extension. Thanks to Dmitry Shachnev for the hint.
+Closes: #918850
+  * Make build reproducible. Thanks to Chris Lamb for the patch.
+Closes: #895401
+  * Reference correct homepage. Thanks to Chris Lamb for the patch.
+    Closes: #895402
+
+ -- Sascha Steinbiss   Sat, 09 Feb 2019 12:22:40 +0100
+
 libmypaint (1.3.0-2) unstable; urgency=medium
 
   * Add Conflicts: mypaint-data to libmypaint-common. See bug 894757
diff --git a/debian/control b/debian/control
index ed96ddf..afe2bd0 100644
--- a/debian/control
+++ b/debian/control
@@ -19,7 +19,7 @@ Build-Depends: autoconf-archive,
 Standards-Version: 4.1.3
 Vcs-Browser: https://salsa.debian.org/multimedia-team/libmypaint
 Vcs-Git: https://salsa.debian.org/multimedia-team/libmypaint.git
-Homepage: https://github.com/Jehan/mypaint-brushes
+Homepage: https://github.com/Jehan/mypaint
 
 Package: libmypaint-1.3-0
 Architecture: any
diff --git a/debian/patches/disable-sphinx-math-extension.patch b/debian/patches/disable-sphinx-math-extension.patch
new file mode 100644
index 000..19286b3
--- /dev/null
+++ b/debian/patches/disable-sphinx-math-extension.patch
@@ -0,0 +1,17 @@
+Description: remove unused Sphinx extension
+ This package uses a deprecated and later removed Sphinx extension
+ that led to a FTBFS with recent Sphinx versions.
+ Since it wasn't used in the documentation anyway, it should be safe to remove.
+Author: Sascha Steinbiss 
+Last-Update: 2019-02-09
+--- a/doc/source/conf.py
 b/doc/source/conf.py
+@@ -27,7 +27,7 @@
+ 
+ # Add any Sphinx extension module names here, as strings. They can be extensions
+ # coming with Sphinx (named 'sphinx.ext.*') or your custom ones.
+-extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.intersphinx', 'sphinx.ext.todo', 'sphinx.ext.coverage', 'sphinx.ext.pngmath', 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode']
++extensions = ['sphinx.ext.autodoc', 'sphinx.ext.doctest', 'sphinx.ext.intersphinx', 'sphinx.ext.todo', 'sphinx.ext.coverage', 'sphinx.ext.ifconfig', 'sphinx.ext.viewcode']
+ 
+ # Breathe setup, for integrating doxygen content
+ extensions.append('breathe')
diff --git a/debian/patches/reproducible-build.patch b/debian/patches/reproducible-build.patch
new file mode 100644
index 000..8a0b6a5
--- /dev/null
+++ b/debian/patches/reproducible-build.patch
@@ -0,0 +1,15 @@
+Description: Make the build reproducible
+Author: Chris Lamb 
+Last-Update: 2018-04-11
+
+--- libmypaint-1.3.0.orig/doc/Doxyfile
 libmypaint-1.3.0/doc/Doxyfile
+@@ -119,7 +119,7 @@ INLINE_INHERITED_MEMB  = NO
+ # path before files name in the file list and in the header files. If set
+ # to NO the shortest path that makes the file name unique will be used.
+ 
+-FULL_PATH_NAMES= YES
++FULL_PATH_NAMES= NO
+ 
+ # If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag
+ # can be used to strip a user-defined part of the path. Stripping is
diff --git a/debian/patches/series b/debian/patches/series
index 1e8becf..e298399 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,3 @@
 dont-require-m4macros.patch
+reproducible-build.patch
+disable-sphinx-math-extension.patch

Bug#897865: Code compiles just fine with current commit in Salsa

[Sascha Steinbiss]

tags 897865 + unreproducible
user debian-rele...@lists.debian.org
usertag 897865 + bsp-2019-02-de-berlin
thanks

Hi,

a warm hello from the BSP in Berlin (and from across the table fro you,
Hilko ;).

> The current commit in Salsa -- 00b7e79dd144ebfc5d187c331353b50239b032db,
> marked "snapd (2.35.5-1) UNRELEASED" -- builds the test code including
> locking-test.c just fine, but various tests then fail.

I've tried to look into this issue but was not able to reproduce theis
FTBFS with the current unstable version snapd_2.37.2-1 (tested on amd64
and armel). Builds complete fine and show no fatal errors.

I think this bug can be closed.

Cheers
Sascha

Bug#917797: snapd: FTBFS: too many arguments in call to activation.Listeners

[Sascha Steinbiss]

tags 917797 + unreproducible
user debian-rele...@lists.debian.org
usertag 917797 + bsp-2019-02-de-berlin
thanks

Hi,

a warm hello from the BSP in Berlin.

> I found problems with am armel-on-arm64 build, but I can reproduce the
> same problem on a straight amd64 build too.

I've tried to look into this issue but was not able to reproduce theis
FTBFS with the current unstable version snapd_2.37.2-1 (tested on amd64
and armel). Builds complete fine and show no fatal errors.

I think this bug can be closed.

Cheers
Sascha

Bug#919778: [Debian-med-packaging] Bug#919778: mash FTBFS on armhf when built on arm64 hardware

[Sascha Steinbiss]

tags 919778 help
forwarded 919778 https://github.com/marbl/Mash/issues/108
thanks

Hi,

thanks for reporting this issue!
I have forwarded this upstream but I'm afraid I won't be able to do much
about it in the near future. With the upcoming freeze in mind, and given
the fact that upstream doesn't seem to be too active about our recent
bug reports, TBH I would be tempted to remove support for the
architectures with missing builds from the mash package and file RM for
the old binary packages until there is a solution.
Some other packages depend on mash so I would like to see it in buster,
since (as always, in my own humble opinion) the problematic
architectures (arm, s390, mips) are not within the typical target
audience of mash.

Also tagging this as help -- so if there's anyone with expertise in this
kind of porting work, I would surely appreciate help :)
BTW Fabian, did you get any further with #918566 as this may be related?

Cheers
Sascha


On 19.01.19 15:42, Adrian Bunk wrote:
> Source: mash
> Version: 2.1-2
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/fetch.php?pkg=mash=armhf=2.1-2=1545838322=0
> 
> ...
>dh_auto_test -a
>   make -j8 test VERBOSE=1
> make[1]: Entering directory '/<>'
> cd test ; ../mash sketch -o genomes.msh genome1.fna genome2.fna genome3.fna
> cd test ; ../mash sketch -r -I reads reads1.fastq reads2.fastq -o reads.msh
> Sketching genome1.fna...
> Sketching genome2.fna...
> Sketching genome3.fna...
> Bus error
> make[1]: *** [Makefile:94: test/reads.msh] Error 135
> 
> 
> Backtrace:
> 
> #0  0x00638d2e in MurmurHash3_x64_128 (key=0xf523a009, len=len@entry=21, 
> seed=, out=out@entry=0xf6b2dbd4)
> at src/mash/MurmurHash3.cpp:277
> #1  0x00635b4c in getHash (seq=, length=length@entry=21, 
> seed=, use64=true)
> at src/mash/hash.cpp:23
> #2  0x00639a50 in addMinHashes (minHashHeap=..., 
> seq=0xf523a008 
> "AGCCATTCTGACTGCAACGGGCAATATGTCTCTGTGTGGATTAAAGAGTGTCTGATAGCAGCTTCTGAACTGGTTACCTGCCGTGAGTAAATTATTGACTTAGGTCACTAAATACTTTAACCAATATAGGCATAGCGCACAGACAGATATTACAGAGTACACAACATCCATGAAACGCAT"...,
>  
> length=, parameters=...) at src/mash/Sketch.cpp:601
> #3  0x0063a7d6 in sketchFile (input=0x692268) at src/mash/Sketch.cpp:1264
> #4  0x006400a0 in ThreadPool Sketch::SketchOutput>::thread (arg=0xffeea370)
> at src/mash/ThreadPool.hxx:182
> #5  0xf6cd2bbe in start_thread () from 
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #6  0xf6bc94dc in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> 
> 
> 
> void MurmurHash3_x64_128 ( const void * key, const int len,
>const uint32_t seed, void * out )
> {
>   const uint8_t * data = (const uint8_t*)key;
> ...
>   const uint64_t * blocks = (const uint64_t *)(data);
> ...
> 
> 
> key=0xf523a009 is not properly aligned for that.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 



signature.asc
Description: OpenPGP digital signature

Bug#920223: gnome-keysign: fails to build because of test failures

[Sascha Steinbiss]

Hi Jeremy,

> gnome-keysign fails to build from source in a clean unstable chroot as
> seen on Ubuntu and with Debian Reproducible Builds. The build tests
> are failing.

Thanks for reporting this. Just for the record, I do indeed build all my
packages in clean unstable chroots via pbuilder/cowbuilder, but
apparently my setup does not seem to prevent outside network
connections. This caused the build to fail on Debian build servers as
some of the tests tried to connect to a wormhole relay server.

> By the way, I encourage you to do source-only uploads:
> https://wiki.debian.org/SourceOnlyUpload

Done. I'll keep in mind how to do this with gbp for later uploads :)

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#918566: [Debian-med-packaging] Bug#918566: mash FTBFS on big endian: test failures

[Sascha Steinbiss]

Hi,

FYI I have already opened an issue upstream for something that might be
related:

  https://github.com/marbl/Mash/issues/104

I suspect that some of these failures are connected to the update of
Cap'n Proto to 0.7.0, the issues only started after the dependency was
upgraded in in unstable.

Cheers
Sascha

On 1/7/19 2:14 PM, Adrian Bunk wrote:
> Source: mash
> Version: 2.1-1
> Severity: serious
> Tags: ftbfs
> 
> https://buildd.debian.org/status/package.php?p=mash
> 
> ...
> diff test/genomes.dist test/ref/genomes.dist
> 1,3c1,3
> < genome1.fna reads   0.12827 1.02947e-18035/1000
> < genome2.fna reads   0.1296046.13708e-17534/1000
> < genome3.fna reads   0.12827 1.02332e-18035/1000
> ---
>> genome1.fna  reads   0.12101 4.48626e-21441/1000
>> genome2.fna  reads   0.12827 2.61074e-18035/1000
>> genome3.fna  reads   0.12101 4.45454e-21441/1000
> make[1]: *** [Makefile:98: testDist] Error 1
> make[1]: *** Waiting for unfinished jobs
> diff test/genomes.json test/ref/genomes.json
> 18,1017c18,1017
> < 2755981392628,
> < 3189583257792,
> < 9584077549833,
> < 12718262031724,
> < 17482074590444,
> < 23032165717400,
> ...
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging
> 

Bug#905169: golang-github-graph-gophers-graphql-go: Incomplete debian/copyright?

[Sascha Steinbiss]

Hi Chris,

> I just ACCEPTed golang-github-graph-gophers-graphql-go from NEW but 
> noticed it was missing attribution in debian/copyright for at least 
> internal/validation/testdata.
> 
> This is in no way exhaustive so please check over the entire package 
> carefully and address these on your next upload.

Thanks for taking a close look that quickly. Sure enough, I will address
this issue asap.

Have a nice DebConf!

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#893697:

[Sascha Steinbiss]

Hi Sandro,

thanks for your reply.

>> this is also a problem in iva [1]. Patch attached — any comments? I don’t 
>> have too much experience with NMUs, would that be OK here? What delay would 
>> you recommend?
> 
> please hold your NMU, i'll prepare the new upstream release instead

Sure, thanks a lot for that!

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#893697:

[Sascha Steinbiss]

affects 893697 iva
thanks

Hi,

this is also a problem in iva [1]. Patch attached — any comments? I don’t have 
too much experience with NMUs, would that be OK here? What delay would you 
recommend?

Cheers
Sascha



networkx.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP

Bug#889615: python-tifffile: broken autopkgtest, broken package

[Sascha Steinbiss]

Hi again,

[...]
>> I wonder whether you have an idea how this can be fixed.
>
> Unfortunately I'm a bit swamped with work and (more so) RL stuff at the
> moment... maybe this has time until the sprint later this week?

Actually this was rather easy to address. I pushed some code that should
fix it.

Cheers
Sascha

Bug#889615: python-tifffile: broken autopkgtest, broken package

[Sascha Steinbiss]

Hi Andreas,

>> $ ./debian/tests/python-import 
>> 2017.09.14
>> Traceback (most recent call last):
>>   File "./debian/tests/python-import", line 16, in 
>> for page in tif:
>> TypeError: 'TiffFile' object is not iterable
>> $
>>
>> This part looks like it might be a bug in the test rather than the package,
>> but without being familiar with the package it's hard for me to know.
> 
> I cared for the missing dependencied (+ upgrade to latest upstream) in
> Git.  I can confirm that the remaining issue above persists.  Sascha,
> since you wrote the test, I wonder whether you have an idea how this can
> be fixed.

Unfortunately I'm a bit swamped with work and (more so) RL stuff at the
moment... maybe this has time until the sprint later this week?
Will look at it though.

Cheers
Sascha

Bug#887727: [debhelper-devel] Bug#887727: debhelper, dh-dist-zilla: dh-dist-zilla based package builds no more run dh_auto_install (and maybe other dh_auto_*)

[Sascha Steinbiss]

Hi Niels and Axel,

> Niels Thykier wrote:
>> Could you please verify that the attached patch fixes the problem for you?
> 
> systray-mdstat and roary both build fine again with this patch applied
> on top of debhelper's git HEAD.

Confirmed, and new roary upload done [x].
Thanks to you both for the quick action!

Best regards
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#881496: [Pkg-privacy-maintainers] Bug#881496: onioncircuits: python3/testing and apparmor/testing breaks onioncircuits

[Sascha Steinbiss]

Hi all,

ah, this sheds some light on the situation. However:

> audit[3722]: AVC apparmor="DENIED" operation="file_mmap" 
> profile="/usr/bin/onioncircuits" 
> name="/usr/lib/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so" 
> pid=3722 comm="onioncircuits" requested_mask="m" denied_mask="m" fsuid=1000 
> ouid=0

This is interesting, since the corresponding line in the python AppArmor
abstractions [1] (which are imported by the onioncircuits profile [2]) is:

  /usr/lib{,32,64}/python3.[0-6]/lib-dynload/*.somr,

which indeed already has the mmap flag set. It's been in testing for
some while now (since bzr revision #1671, which was the initial update
to upstream's 2.11.1).
I also can't see it being overridden anywhere. So I am not sure why this
permission should be denied...

Any ideas? (AppArmor-savvy team members?)

Cheers
Sascha


[1]
https://alioth.debian.org/scm/loggerhead/collab-maint/apparmor/view/head:/profiles/apparmor.d/abstractions/python
[2]
https://anonscm.debian.org/cgit/pkg-privacy/packages/onioncircuits.git/tree/apparmor/usr.bin.onioncircuits#n8

> So, python3/testing + apparmor/testing is a breaking
> combination. Downgrading to apparmor/stable fixes the problem.
> 
> -- System Information:
> Debian Release: buster/sid
>   APT prefers stable
>   APT policy: (500, 'stable'), (70, 'unstable'), (60, 'testing'), (50, 
> 'experimental')
> Architecture: amd64
>  (x86_64)
> 
> Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages onioncircuits depends on:
> ii  gir1.2-glib-2.01.54.1-3
> ii  gir1.2-gtk-3.0 3.22.26-1
> ii  python3-gi 3.22.0-2
> ii  python3-pycountry  17.5.14+ds1-0.1
> ii  python3-stem   1.6.0-1
> pn  python3:any
> 
> onioncircuits recommends no packages.
> 
> Versions of packages onioncircuits suggests:
> ii  tor-geoipdb  0.3.1.8-2
> 
> -- no debconf information
> 
> ___
> Pkg-privacy-maintainers mailing list
> pkg-privacy-maintain...@lists.alioth.debian.org
> https://lists.alioth.debian.org/mailman/listinfo/pkg-privacy-maintainers
> 



signature.asc
Description: OpenPGP digital signature

Bug#881496: [Pkg-privacy-maintainers] Bug#881496: onioncircuits: current python3/testing breaks onioncircuits

[Sascha Steinbiss]

Hi Mykola,

thanks for letting us know about the issue.

> --8<---cut here---start->8---
> $ onioncircuits 
> Traceback (most recent call last):
>   File "/usr/bin/onioncircuits", line 31, in 
> import stem.connection
>   File "/usr/lib/python3/dist-packages/stem/connection.py", line 134, in 
> 
> import stem.control
>   File "/usr/lib/python3/dist-packages/stem/control.py", line 265, in 
> import stem.descriptor.microdescriptor
>   File "/usr/lib/python3/dist-packages/stem/descriptor/__init__.py", line 55, 
> in 
> import stem.util.system
>   File "/usr/lib/python3/dist-packages/stem/util/system.py", line 68, in 
> 
> import ctypes
>   File "/usr/lib/python3.6/ctypes/__init__.py", line 7, in 
> from _ctypes import Union, Structure, Array
> ImportError: 
> /usr/lib/python3.6/lib-dynload/_ctypes.cpython-36m-x86_64-linux-gnu.so: 
> failed to map segment from shared object
> --8<---cut here---end--->8---

Unfortunately I an unable to reproduce this on a fresh testing amd64
Vagrant box with the same versions of python3 and stem that you are using:

  vagrant@testing:~$ apt show python3 python3-stem | grep Vers
  [...]
  Version: 3.6.3-2
  Version: 1.6.0-1

Onioncircuits (0.5-1) starts up fine and displays correct data. All I
did to set up my testing environment was installing onioncircuits, tor
and then adding the Vagrant user to the debian-tor group (so
onioncircuits would work as user).

Some googling for the "failed to map segment from shared object" message
seems to suggest some issue with missing filesystem execute permissions,
but given that it's /usr/lib we're looking at here and downgrading to
another python3 version fixes the problem, it's unlikely that's the cause.

Can anyone else in the team reproduce this issue or probably comment?

Cheers
Sascha




signature.asc
Description: OpenPGP digital signature

Bug#868614: [Debian-med-packaging] Bug#868614: cwltool FTBFS with python-typing 3.6.1-1

[Sascha Steinbiss]

Hi Michael,

[...]
> Installed /build/1st/cwltool-1.0.20170114120503
> Processing dependencies for cwltool==1.0.20170114120503
> Searching for typing<3.6,>=3.5.2
> Reading https://pypi.python.org/simple/typing/
> Download error on https://pypi.python.org/simple/typing/: [Errno -3] 
> Temporary failure in name resolution -- Some packages may not be found!
> Couldn't retrieve index page for 'typing'
> Scanning index of all packages (this may take a while)
> Reading https://pypi.python.org/simple/
> Download error on https://pypi.python.org/simple/: [Errno -3] Temporary 
> failure in name resolution -- Some packages may not be found!
> No local packages or working download links found for typing<3.6,>=3.5.2
> error: Could not find suitable distribution for 
> Requirement.parse('typing<3.6,>=3.5.2')

This is because Debian's python-typing is now 3.6.1, so that requirement
can't be satisfied. I am wondering why this limitation to versions < 3.6
is required, maybe you could shed some light on this. It builds fine
with 3.6.1 but since there don't seem to be tests it's difficult to
check whether that indeed works at runtime or not...

I also added a missing build-dependency on python-avro, which stopped
the build before. The FTBFS should be fixed now.

I have pushed my changes to git and would be happy to get some comments.

Many thanks
Sascha

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

[Sascha Steinbiss]

Hi Michael,

> I have a fix checked in as part of the 2.1-1 release, but it is blocked
> on me uploading a python3 version of sphinx-guzzle

Ah I see -- thanks, won't pursue this anymore then :)

Cheers
Sascha

> Pe 4 iul. 2017 23:12, "Sascha Steinbiss" <sa...@debian.org
> <mailto:sa...@debian.org>> a scris:
> 
> Hi all,
> 
> >> I've applied this patch to get the build working now that Python
> 3.6 is a
> >> supported version in Ubuntu. I admit I don't entirely understand
> why it is
> >> necessary! Maybe you do? :)
> >>
> > Now that python3.6 is supported in Debian, khmer FTBFS:
> >
> >
> 
> https://buildd.debian.org/status/fetch.php?pkg=khmer=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0
> 
> <https://buildd.debian.org/status/fetch.php?pkg=khmer=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0>
> 
> Does anyone know more about this issue? Otherwise I'd be inclined to
> simply apply the patch in BTS to get the bug fixed...
> 
> Kind regards
> Sascha
> 

Bug#862380: [Debian-med-packaging] Bug#862380: khmer: FTBFS with Python 3.6

[Sascha Steinbiss]

Hi all,

>> I've applied this patch to get the build working now that Python 3.6 is a
>> supported version in Ubuntu. I admit I don't entirely understand why it is
>> necessary! Maybe you do? :)
>>
> Now that python3.6 is supported in Debian, khmer FTBFS:
> 
> https://buildd.debian.org/status/fetch.php?pkg=khmer=amd64=2.0%2Bdfsg-10%2Bb1=1498774574=0

Does anyone know more about this issue? Otherwise I'd be inclined to
simply apply the patch in BTS to get the bug fixed...

Kind regards
Sascha

Bug#865039: [Debian-med-packaging] Bug#865039: libhat-trie FTBFS on 32bit: check_ahtable fails

[Sascha Steinbiss]

forwarded 865039 https://github.com/dcjones/hat-trie/issues/31
tags 865039 upstream
thanks

> On 18 Jun 2017, at 21:56, Adrian Bunk  wrote:
> 
> Source: libhat-trie
> Version: 0.1.1-1
> Severity: serious
> 
> https://buildd.debian.org/status/package.php?p=libhat-trie
> 
> ...
> make  check-TESTS
> make[3]: Entering directory '/«PKGBUILDDIR»/test'
> make[4]: Entering directory '/«PKGBUILDDIR»/test'
> ../test-driver: line 107: 10255 Segmentation fault  "$@" > $log_file 2>&1

Thanks for your report, I could reproduce this — actually I already filed a bug 
upstream in the end of April. Let’s see what they say, I just sent a followup.

Kind regards
Sascha



signature.asc
Description: Message signed with OpenPGP

Bug#863414: coyim FTBFS: xmpp: failed to verify TLS certificate: x509: certificate signed by unknown authority

[Sascha Steinbiss]

Hi Chris,

[...]
> I've uploaded coyim 0.3.7-2.1 to DELAYED/5:

Many thanks for taking care of this! I was unfortunately not able to
respond to the bug in time due to traveling :/

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#859111: [Debian-med-packaging] Bug#859111: Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

[Sascha Steinbiss]

tags 859111 pending
thanks

> bowtie2 2.3.1 introduced different default values for one of the
> parameters [1], it might be likely that it's connected to that. I
> have contacted upstream

Upstream have added support for Bowtie2 2.3.1 [1] and I can confirm that
the tests -- and hence the build -- are fixed using this latest version.
Updated Debian package currently in experimental, will upload to
unstable once the freeze is over.

Cheers
Sascha

[1] https://github.com/sanger-pathogens/ariba/issues/170



signature.asc
Description: OpenPGP digital signature

Bug#860684: [pkg-go] Bug#860684: golang-github-streadway-amqp: FTBFS on i386: dh_auto_test: go test -v -p 1 github.com/streadway/amqp returned exit code 1

[Sascha Steinbiss]

Hi all,

[...]
>> === RUN   TestGoFuzzCrashers
>> --- FAIL: TestGoFuzzCrashers (0.00s)
>> panic: runtime error: makeslice: len out of range [recovered]
>>  panic: runtime error: makeslice: len out of range
>>
>> goroutine 3445 [running]:
>> panic(0x8249520, 0x18a0e0a8)
>>  /usr/lib/go-1.7/src/runtime/panic.go:500 +0x331
>> testing.tRunner.func1(0x193c6280)
>>  /usr/lib/go-1.7/src/testing/testing.go:579 +0x14f
>> panic(0x8249520, 0x18a0e0a8)
>>  /usr/lib/go-1.7/src/runtime/panic.go:458 +0x40b
>> github.com/streadway/amqp.readLongstr(0x8343dc0, 0x190500c0, 0x0, 0x0, 0x0, 
>> 0x0)
>>  
>> /<>/obj-i686-linux-gnu/src/github.com/streadway/amqp/read.go:112
>>  +0xeb
>> github.com/streadway/amqp.readTable(0x8343dc0, 0x190500c0, 0x0, 0x0, 0x0)
>>  
>> /<>/obj-i686-linux-gnu/src/github.com/streadway/amqp/read.go:269
>>  +0x7e
>> github.com/streadway/amqp.(*reader).parseHeaderFrame(0x18664f2c, 0x19051610, 
>> 0xefbfbd5b, 0x0, 0x0, 0x0, 0x0)
>>  
>> /<>/obj-i686-linux-gnu/src/github.com/streadway/amqp/read.go:359
>>  +0x3cc
>> github.com/streadway/amqp.(*reader).ReadFrame(0x18664f2c, 0x0, 0x0, 0x0, 0x0)
>>  
>> /<>/obj-i686-linux-gnu/src/github.com/streadway/amqp/read.go:64 
>> +0x2f0
>> github.com/streadway/amqp.TestGoFuzzCrashers(0x193c6280)
>>  
>> /<>/obj-i686-linux-gnu/src/github.com/streadway/amqp/read_test.go:17
>>  +0x150
>> testing.tRunner(0x193c6280, 0x829a294)
>>  /usr/lib/go-1.7/src/testing/testing.go:610 +0x8c
>> created by testing.(*T).Run
>>  /usr/lib/go-1.7/src/testing/testing.go:646 +0x2a5
>> exit status 2
>> FAIL github.com/streadway/amqp   2.576s
>> dh_auto_test: go test -v -p 1 github.com/streadway/amqp returned exit code 1

This seems to be related to this particular test case trying to create a
slice with a length exceeding a 32-bit signed integer, which is a limit
for slices in Go. Let's see what upstream says, there's a GitHub issue
in for that now.

Kind regards
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#860692: gopacket: FTBFS on i386: XXX

[Sascha Steinbiss]

tags 860692 patch
thanks


Hi all,

[...]
> # Copy test files to build dir
> cp pcap/*.pcap obj-i386-linux-gnu/src/github.com/google/gopacket/pcap/
> cp: target 'obj-i386-linux-gnu/src/github.com/google/gopacket/pcap/'
is not a directory
> debian/rules:19: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 1

I have fixed this issue by constructing the target directory name using
DEB_HOST_GNU_TYPE instead of DEB_HOST_MULTIARCH, which correctly yields
'obj-i686-linux-gnu'. After applying attached patch, I was able to
correctly build gopacket on i386 stretch.

Best regards
Sascha
diff --git a/debian/rules b/debian/rules
index a51674b..723de78 100755
--- a/debian/rules
+++ b/debian/rules
@@ -19,7 +19,7 @@ override_dh_auto_configure:
 	dh_auto_configure
 	rm -rf $(patsubst %,obj-*/src/$(DH_GOPKG)/%,$(NOBUILD))
 	# Copy test files to build dir
-	cp pcap/*.pcap obj-$(DEB_HOST_MULTIARCH)/src/$(DH_GOPKG)/pcap/
+	cp pcap/*.pcap obj-$(DEB_HOST_GNU_TYPE)/src/$(DH_GOPKG)/pcap/
 
 override_dh_install:
 	dh_install --fail-missing


signature.asc
Description: OpenPGP digital signature

Bug#860876: [Debian-med-packaging] Bug#860876: reapr: FTBFS: Error in system call: R CMD BATCH 00.Sample/gc_vs_cov.R 00.Sample/gc_vs_cov.Rout

[Sascha Steinbiss]

reassign 860876 r-cran-kernsmooth
thanks


Hi Chris,

thanks for your bug report. I can reproduce the problem; it looks like an R 
component within REAPR’s build time tests has started to fail, causing the 
whole build to break.

[…]
>  [REAPR preprocess] Error in system call:
>  R CMD BATCH 00.Sample/gc_vs_cov.R 00.Sample/gc_vs_cov.Rout
>  debian/rules:33: recipe for target 'override_dh_auto_test' failed
>  make[1]: *** [override_dh_auto_test] Error 1
>  make[1]: Leaving directory '«BUILDDIR»'
>  debian/rules:4: recipe for target 'build' failed
>  make: *** [build] Error 2
>  dpkg-buildpackage: error: debian/rules build gave error exit status 2

I have traced the error down to the R script in question used by the tests 
(00.Sample/gc_vs_cov.R). Indeed there is an error running it, which is apparent 
when looking at 00.Sample/gc_vs_cov.Rout:

  […]
  > data=read.csv(file="00.Sample/gc_vs_cov.dat", colClasses=c("numeric", 
"integer"), header=F, sep="   ", comment.char="")
  > l=lowess(data)
  > data_out=unique(data.frame(l$x,l$y))
  > write(t(data_out), sep="", ncolumns=2, 
file="00.Sample/gc_vs_cov.lowess.dat.tmp")
  > pdf("00.Sample/gc_vs_cov.lowess.pdf")
  >   smoothScatter(data, xlab="GC", ylab="Coverage")
  Error in linbin2D(x, gpoints1, gpoints2) : object 'F_lbtwod' not found
  Calls: smoothScatter ->  ->  -> linbin2D
  Execution halted

It looks like r-cran-kernsmooth has trouble finding the Fortran components on 
newer R versions (I tested 3.4.0 from unstable). It works fine on R 3.3.3 (as 
it is in stretch). To reproduce without messing with REAPR, it should even be 
enough to try and run the tests/bkfe.R script included in the kernsmooth source:

  [vagrant@vagrant-debian:/vagrant/kernsmooth-2.23-15/tests] $ R CMD BATCH 
bkfe.R
  [vagrant@vagrant-debian:/vagrant/kernsmooth-2.23-15/tests] $ cat bkfe.Rout
  R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
  Copyright (C) 2017 The R Foundation for Statistical Computing
  Platform: x86_64-pc-linux-gnu (64-bit)

  R is free software and comes with ABSOLUTELY NO WARRANTY.
  You are welcome to redistribute it under certain conditions.
  Type 'license()' or 'licence()' for distribution details.

  R is a collaborative project with many contributors.
  Type 'contributors()' for more information and
  'citation()' on how to cite R or R packages in publications.

  Type 'demo()' for some demos, 'help()' for on-line help, or
  'help.start()' for an HTML browser interface to help.
  Type 'q()' to quit R.

  > ## failed in bkfe with exaxt powers of 2 prior to 2.23-5
  > library(KernSmooth)
  KernSmooth 2.23 loaded
  Copyright M. P. Wand 1997-2009
  > x <- 1:100
  > dpik(x, gridsize = 256)
  Error in linbin(x, gpoints, truncate) : object 'F_linbin' not found
  Calls: dpik -> linbin
  Execution halted

This also works with no problems when run using R 3.3.3. Unfortunately, I am 
not an R expert, so could someone with some more experience please have a look? 
Thanks!

Cheers
Sascha



signature.asc
Description: Message signed with OpenPGP

Bug#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

[Sascha Steinbiss]

forwarded 859111 https://github.com/sanger-pathogens/ariba/issues/170
tags 859111 upstream
thanks

Hi all,

> On Thu, Mar 30, 2017 at 06:20:16PM +0300, Adrian Bunk wrote:
>> Control: retitle -1 ariba FTBFS with bowtie2 2.3.1-1
> [...]
>> This is actually not related to the ariba version but to the bowtie2 version,
>> ariba 2.6.1+ds-1 in stretch builds with the stretch bowtie2 2.3.0-2 but 
>> FTBFS with the sid bowtie2 2.3.1-1
> 
> Do we already know whether the newer upstream version fixes this?

No, it doesn't. I just tested it. Given that the test failure seems to
be caused by differences between result and reference, and bowtie2 2.3.1
introduced different default values for one of the parameters [1], it
might be likely that it's connected to that. I have contacted upstream
[2] -- they are usually quite responsive.

Cheers
Sascha

[1] http://bowtie-bio.sourceforge.net/bowtie2/index.shtml
[2] https://github.com/sanger-pathogens/ariba/issues/170

Bug#859111: [Debian-med-packaging] Bug#859111: ariba: FTBFS: FAIL: Test run_bowtie2 unsorted

[Sascha Steinbiss]

Hi all,

>> Control: retitle -1 ariba FTBFS with bowtie2 2.3.1-1
> [...]
>> This is actually not related to the ariba version but to the bowtie2 version,
>> ariba 2.6.1+ds-1 in stretch builds with the stretch bowtie2 2.3.0-2 but 
>> FTBFS with the sid bowtie2 2.3.1-1
> 
> Do we already know whether the newer upstream version fixes this?
> 
> Sascha: could you try to import it and pehaps upload it to unstable?
> Given there is already a difference between testing and unstable (2.6.1
> vs 2.7.1) it shouldn't make much difference at this point even in the
> freeze…

Sure, I can do this later today when I find some time. I'm a bit busy
atm with unrelated work but will get back to it.

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.

[Sascha Steinbiss]

Hi Anton,

>> Switching to ‘luatex' instead of ‘tex’ fixed the issue for me. Please 
>> see attached patch. However, I would be happy if someone could take a 
>> second look. I don’t usually write Cyrillic ;)
> 
> Thanks.  I am uploading the package now. :)

Great, thanks! One more RC bug down.

Cheers
Sascha

Bug#852929: scalable-cyrfonts: FTBFS: LaTeX requires e-TeX.

[Sascha Steinbiss]

tags 852929 patch
user debian-rele...@lists.debian.org
usertags 852929 + bsp-2017-02-de-Berlin
thanks


Hi all,

[…]
> touch latex_mtx
> tex --ini '\input hugelatex.ini \dump'
> This is TeX, Version 3.14159265 (TeX Live 2016/Debian) (INITEX)
> (./hugelatex.ini
> (/usr/share/texlive/texmf-dist/tex/latex/base/latex.ltx
> ! LaTeX requires e-TeX.
> l.98 {LaTeX requires e-TeX}
>
> ))

Switching to ‘luatex' instead of ‘tex’ fixed the issue for me. Please see 
attached patch.
However, I would be happy if someone could take a second look. I don’t usually 
write Cyrillic ;)

Cheers
Sascha



use-luatex.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP

Bug#750895: python3-tempita: doesn't work with python 3.3

[Sascha Steinbiss]

Hi all,

> 2. This issue is already fixed in the upstream in this commit:
>  
> https://github.com/gjhiggins/tempita/commit/ce87d4c0f057880c5b0dc77e83e3eecad7f355a7
>  (The previous commit of this, 75064399e7e72fd67e2a0c21c675d6289e7d1ec9, 
> suffers from the same error.)

Here’s a small patch that backports their fix to this version. I also added a 
tiny autopkgtest to check the issue is fixed.

Cheers
Sascha


0001-address-encoding-issues-to-fix-750895.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP

Bug#855932: sugar-physics-activity: FTBFS: unsatisfiable build-dependencies: python-sugar-0.88, python-sugar-toolkit-0.88

[Sascha Steinbiss]

Hi,

> During a rebuild of all packages in stretch (in a stretch chroot, not a
> sid chroot), your package failed to build on amd64.
[…]
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-sugar-physics-activity-dummy : Depends: 
> > python-sugar-0.88 but it is not installable
> >  Depends: 
> > python-sugar-toolkit-0.88 but it is not installable
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.

I just tried to reproduce this in a current stretch cowbuilder chroot, and for 
me the questionable build-deps are satisfied through their alternatives in 
d/control, which are python-sugar_0.98.0-5 and python-sugar-toolkit_0.110.0-1. 
The build succeeds for me, see attached log.

I’m not sure here why your build insists on python-sugar-0.88 (if you are, I 
would be glad to be enlightened!). BTW I encountered the same issue when trying 
to reproduce #855925.

Cheers
Sascha



sugar-physics-activity.x.log.gz
Description: GNU Zip compressed data


signature.asc
Description: Message signed with OpenPGP

Bug#853931: FTBFS: dh_install: debian/suricata-hyperscan.install returned exit code 127

[Sascha Steinbiss]

Hi Arturo and James,

>> I believe you need both debhelper and dh-exec from jessie-backports to
>> make this work.
> 
> Thanks James, it works!! :-)

Thanks! I just tried the same and can confirm it works now.

Cheers
Sascha



signature.asc
Description: OpenPGP digital signature

Bug#852850: [Debian-med-packaging] Bug#852850: hilive: FTBFS (dh_auto_configure fails)

[Sascha Steinbiss]

Hi Andreas,

> ...
> CMake Error at CMakeLists.txt:37 (find_package):
>  By not providing "FindSeqAn.cmake" in CMAKE_MODULE_PATH this project has
>  asked CMake to find a package configuration file provided by "SeqAn", but
>  CMake did not find one.
> 
>  Could not find a package configuration file provided by "SeqAn" with any of
>  the following names:
> 
>SeqAnConfig.cmake
>seqan-config.cmake
> 
>  Add the installation prefix of "SeqAn" to CMAKE_PREFIX_PATH or set
>  "SeqAn_DIR" to a directory containing one of the above files.  If "SeqAn"
>  provides a separate development package or SDK, be sure it has been
>  installed.
> 
> ...
> 
> 
> From libseqan-dev 2.2.0+dfsg-5 to 2.3.1+dfsg-3 the seqan input files
> have completely changed.  Any hint from somebody with more cmake
> experience than I have whether I can / should fix hilive to adapt
> properly or whether libseqan-dev needs to be adapted?


https://anonscm.debian.org/cgit/debian-med/lambda-align.git/diff/debian/patches/set-seqan-cmake-dir.patch
 seems to have solved that problem for me in lambda-align.

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP

Bug#852546: [Debian-med-packaging] Bug#852546: bowtie2 build-depends on non-free libmath-random-perl

[Sascha Steinbiss]

Hi Adrian,

[...]
> bowtie2 (2.3.0-1) unstable; urgency=medium
> ...
>   [ Andreas Tille ]
> ...
>   * Remove code from test suite that is requiring non-free package
> libmath-random-perl
> ...
>   [ Sascha Steinbiss ]
>   * Even more new Build-Depends: libmath-random-perl, libtest-deep-perl
> ...
>  -- Sascha Steinbiss <sa...@debian.org>  Sat, 14 Jan 2017 07:50:51 +

Thanks for noticing -- since I broke it, I'll look into fixing it as well.

Cheers
Sascha

Bug#846671: [Debian-med-packaging] Bug#846671: Artemis should adapt to new htsjdk API which has dropped SAMFileReader (Was: [samtools/htsjdk] SAMFileReader vanished in Version 2.7.0 (#767))]

[Sascha Steinbiss]

Hi all,

[...]
> I do not find branch 6_0_17 and I do not even think that we need this
> extra branch.  I'd recommend to use master and as far as I understood
> Olivier's comment your test should be sufficient.

Sure. Sorry for the branch naming mixup, it was a little late ;)

> I personally also do not feel able to test but I think under this
> circumstances its a sensible approach to upload and thus enable some
> wider testing rather than expecting people to build a separate
> branch.

Agreed. I just didn't want to break functionality I am not familiar
with, as I never used this part of Artemis myself (still better than
having Artemis removed in the first place though).

> I have unmerged the fastqc and artemis bug since it seems we will be
> able to fix both packages without reintroducing the old API to htsjdk.

Good to hear!

> So I'd recommend you merge your separate branch back to master and push
> these changes.  I can have another look (I'm also currently bumping
> debhelper to compat level 10 and mark those watch files I have verified
> to version=4 just to have a marker even if version=3 works as well). I'm
> perfectly fine if you upload yourself without my additional inspection.

I see -- thanks for the housekeeping work and the upload.
As far as Artemis is concerned, it would have been a shame to have it
drop out of stretch for something like this bug.

@Andrew: I would have prepared a PR againsr sanger-pathogens/Artemis as
well but due to the level of divergence between Sanger's and Debian's
version it wasn't trivial to reduce it to a concise and short patch.
I recommend that the new Artemis developer (fingers crossed) should take
a look at Debian's full patch set, which, among other things, introduces
support for more recent dependencies (e.g. htsjdk).

Kind regards
Sascha

Bug#846671: [Debian-med-packaging] Bug#846671: Artemis should adapt to new htsjdk API which has dropped SAMFileReader (Was: [samtools/htsjdk] SAMFileReader vanished in Version 2.7.0 (#767))]

[Sascha Steinbiss]

Hi Andreas and Andrew,

to address this problem I have taken a shot at patching Debian’s Artemis to use 
the new htsjdk API, avoiding SAMFileReader and using the SamReaderFactory 
instead. This fixed the FTBFS for me.
I tested BAM file reading by opening MAL1.embl.gz from the test/data directory 
and adding MAL1_8h.bam via ‘File->Read BAM/VCF...'. One of the genes has some 
mapped reads that are indeed shown. Comparing the displayed pile of mapped 
reads to the one shown by the recent Artemis version I have on Mac OS X, the 
result seems to be correct, but given my lack of practical experience with the 
BAM/VCF/‘anything-to-do-with-reads' components of Artemis I can’t say if I 
caught everything.

I also updated the Debian version to 16.0.17, the latest release from Sanger. 
This allowed me to drop a couple of patches that I already merged earlier with 
my part-time-upstream hat on.
For now I have pushed my work into the ’6_0_17’ branch in git and I would like 
to kindly ask for some more testing. I don’t have suitable test data here and 
don’t really feel like an expert to test the right usage patterns. 

Cheers
Sascha

> On 5 Dec 2016, at 15:56, Andrew Page  wrote:
> 
> Hi Andreas,
> Thanks for letting us know.  We are actively trying to hire a Java developer 
> who will take over the maintenance and development of Artemis. So 
> unfortunately it will be at least a few months before we will have anyone in 
> post to work on it.  If you happen to know of anyone looking for a job, 
> please send them our way!
> Regards,
> Andrew
> 
> 
> 
>> On 5 Dec 2016, at 14:40, Andreas Tille  wrote:
>> 
>> Hi,
>> 
>> after uploading htsjdk 2.7.0 Artemis failed to build from source[1].  I
>> relised that the file src/main/java/htsjdk/samtools/SAMFileReader.java
>> was removed from htsjdk source and assumed that this was by accident.
>> However, upstream has dropped this interface intentionally as you can
>> read below.  In issue #767[2] an htsjdk author gives advise to use the
>> new API version.
>> 
>> Kind regards
>> 
>>  Andreas.
>> 
>> 
>> [1] https://bugs.debian.org/846671
>> [2] https://github.com/samtools/htsjdk/issues/767
>> 
>> 
>> - Forwarded message from Daniel Gómez-Sánchez  
>> -
>> 
>> Date: Mon, 05 Dec 2016 06:18:16 -0800
>> From: Daniel Gómez-Sánchez 
>> To: samtools/htsjdk 
>> Cc: Andreas Tille , Author 
>> Subject: Re: [samtools/htsjdk] SAMFileReader vanished in Version 2.7.0 (#767)
>> 
>> The file was removed in #699 because it was deprecated. I guess that either 
>> 1) fastqc/artemis should be updated to use the new API version, or 2) the 
>> classpath for them in Debian should include an older version.
>> 
>> -- 
>> You are receiving this because you authored the thread.
>> Reply to this email directly or view it on GitHub:
>> https://github.com/samtools/htsjdk/issues/767#issuecomment-264864910
>> 
>> - End forwarded message -
>> 
>> -- 
>> http://fam-tille.de
>> 
>> - End forwarded message -
>> 
>> -- 
>> http://fam-tille.de
> 
> 
> 
> -- 
> The Wellcome Trust Sanger Institute is operated by Genome Research 
> Limited, a charity registered in England with number 1021457 and a 
> company registered in England with number 2742969, whose registered 
> office is 215 Euston Road, London, NW1 2BE. 
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#828254: bro: FTBFS with openssl 1.1.0

[Sascha Steinbiss]

Hi Hilko and Kurt,

some progress on this: I have modified Hilko's patch to use new API
functions to access the OCSP response info, see attachment. This seems
to have been the last issue, Bro builds fine with this patch for me with
no additional API breaks.

Unfortunately my additions require the changes from OpenSSL pull request
#1876 [1]. Let's hope that there will be another release with that fix
before the stretch freeze... Kurt, do you think that would be realistic?
Otherwise we'll have to look into other options, up to removing OCSP
functionality from Bro.

I'd be happy to receive some comments. Thanks!

Cheers
Sascha

[1] https://github.com/openssl/openssl/pull/1876
--- a/src/File.cc
+++ b/src/File.cc
@@ -688,7 +688,7 @@
 	// Depending on the OpenSSL version, EVP_*_cbc()
 	// returns a const or a non-const.
 	EVP_CIPHER* cipher_type = (EVP_CIPHER*) EVP_bf_cbc();
-	cipher_ctx = new EVP_CIPHER_CTX;
+	cipher_ctx = EVP_CIPHER_CTX_new();
 
 	unsigned char secret[EVP_PKEY_size(pub_key)];
 	unsigned char* psecret = secret;
@@ -743,7 +743,7 @@
 			return;
 			}
 
-		delete cipher_ctx;
+		EVP_CIPHER_CTX_free(cipher_ctx);
 		cipher_ctx = 0;
 		}
 	}
--- a/src/file_analysis/analyzer/x509/X509.cc
+++ b/src/file_analysis/analyzer/x509/X509.cc
@@ -138,7 +138,9 @@
 	// we only read 255 bytes because byte 256 is always 0.
 	// if the string is longer than 255, that will be our null-termination,
 	// otherwhise i2t does null-terminate.
-	if ( ! i2t_ASN1_OBJECT(buf, 255, ssl_cert->cert_info->key->algor->algorithm) )
+	ASN1_OBJECT *algorithm;
+	X509_PUBKEY_get0_param(, NULL, NULL, NULL, X509_get_X509_PUBKEY(ssl_cert));
+	if ( ! i2t_ASN1_OBJECT(buf, 255, algorithm) )
 		buf[0] = 0;
 
 	pX509Cert->Assign(7, new StringVal(buf));
@@ -149,14 +151,12 @@
 	// actually should be (namely - rsaEncryption), so that OpenSSL will parse out the
 	// key later. Otherwise it will just fail to parse the certificate key.
 
-	ASN1_OBJECT* old_algorithm = 0;
-	if ( OBJ_obj2nid(ssl_cert->cert_info->key->algor->algorithm) == NID_md5WithRSAEncryption )
-		{
-		old_algorithm = ssl_cert->cert_info->key->algor->algorithm;
-		ssl_cert->cert_info->key->algor->algorithm = OBJ_nid2obj(NID_rsaEncryption);
-		}
+	if ( X509_get_signature_nid(ssl_cert) == NID_md5WithRSAEncryption )
+		X509_PUBKEY_set0_param(X509_get_X509_PUBKEY(ssl_cert), OBJ_nid2obj(NID_rsaEncryption), 0, NULL, NULL, 0);
+else
+		algorithm = 0;
 
-	if ( ! i2t_ASN1_OBJECT(buf, 255, ssl_cert->sig_alg->algorithm) )
+	if ( ! i2t_ASN1_OBJECT(buf, 255, OBJ_nid2obj(X509_get_signature_nid(ssl_cert))) )
 		buf[0] = 0;
 
 	pX509Cert->Assign(8, new StringVal(buf));
@@ -165,14 +165,16 @@
 	EVP_PKEY *pkey = X509_extract_key(ssl_cert);
 	if ( pkey != NULL )
 		{
-		if ( pkey->type == EVP_PKEY_DSA )
+		if ( EVP_PKEY_base_id(pkey) == EVP_PKEY_DSA )
 			pX509Cert->Assign(9, new StringVal("dsa"));
 
-		else if ( pkey->type == EVP_PKEY_RSA )
+		else if ( EVP_PKEY_base_id(pkey) == EVP_PKEY_RSA )
 			{
 			pX509Cert->Assign(9, new StringVal("rsa"));
 
-			char *exponent = BN_bn2dec(pkey->pkey.rsa->e);
+			const BIGNUM *e;
+			RSA_get0_key(EVP_PKEY_get0_RSA(pkey), NULL, , NULL);
+			char *exponent = BN_bn2dec(e);
 			if ( exponent != NULL )
 {
 pX509Cert->Assign(11, new StringVal(exponent));
@@ -181,7 +183,7 @@
 }
 			}
 #ifndef OPENSSL_NO_EC
-		else if ( pkey->type == EVP_PKEY_EC )
+		else if ( EVP_PKEY_base_id(pkey) == EVP_PKEY_EC )
 			{
 			pX509Cert->Assign(9, new StringVal("ecdsa"));
 			pX509Cert->Assign(12, KeyCurve(pkey));
@@ -190,8 +192,8 @@
 
 		// set key algorithm back. We do not have to free the value that we created because (I think) it
 		// comes out of a static array from OpenSSL memory.
-		if ( old_algorithm )
-			ssl_cert->cert_info->key->algor->algorithm = old_algorithm;
+		if ( algorithm )
+			X509_PUBKEY_set0_param(X509_get_X509_PUBKEY(ssl_cert), algorithm, 0, NULL, NULL, 0);
 
 		unsigned int length = KeyLength(pkey);
 		if ( length > 0 )
@@ -262,7 +264,7 @@
 
 	BIO *bio = BIO_new(BIO_s_mem());
 	if( ! X509V3_EXT_print(bio, ex, 0, 0))
-		M_ASN1_OCTET_STRING_print(bio,ex->value);
+		ASN1_STRING_print(bio,(ASN1_STRING *)X509_EXTENSION_get_data(ex));
 
 	StringVal* ext_val = GetExtensionFromBIO(bio);
 
@@ -444,7 +446,7 @@
 	// well, we do not have EC-Support...
 	return NULL;
 #else
-	if ( key->type != EVP_PKEY_EC )
+	if ( EVP_PKEY_base_id(key) != EVP_PKEY_EC )
 		{
 		// no EC-key - no curve name
 		return NULL;
@@ -452,7 +454,7 @@
 
 	const EC_GROUP *group;
 	int nid;
-	if ( (group = EC_KEY_get0_group(key->pkey.ec)) == NULL)
+	if ( (group = EC_KEY_get0_group(EVP_PKEY_get0_EC_KEY(key))) == NULL)
 		// I guess we could not parse this
 		return NULL;
 
@@ -473,12 +475,16 @@
 	{
 	assert(key != NULL);
 
-	switch(key->type) {
+	switch(EVP_PKEY_base_id(key)) {
 	case EVP_PKEY_RSA:
-		return BN_num_bits(key->pkey.rsa->n);
+		const BIGNUM *n;
+		RSA_get0_key(EVP_PKEY_get0_RSA(key), , NULL, NULL);
+		return BN_num_bits(n);
 
 	case EVP_PKEY_DSA:
-		return 

Bug#839320: Would you upload with disabled test?

[Sascha Steinbiss]

Hi Andreas and Adrian,

>>> since there are no responses so far I wonder how to proceed with the
>>> package. 
>>
>> Yes, that's one of the bugs that has been on my list for a while as well...

Regarding the original bug, I have confirmed again with upstream that
it's fine to disable these tests, which I have done in Git. Builds fine
for me now.

Does everyone agree? I can make an upload if so. I have also filed an
issue upstream for them to make the tests a bit more robust.

>>> I need to admit I get a different error when trying to build
>>> the current state of gubbins packaging Git:
>>>
>>> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -I../tests 
>>> -pthread -g -O2 -fdebug-prefix-map=/build/gubbins-2.1.0=. 
>>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>>> ../tests/run_all_tests-run_all_tests.o `test -f '../tests/run_all_tests.c' 
>>> || echo './'`../tests/run_all_tests.c
>>> /bin/bash ../libtool  --tag=CC   --mode=link gcc -I../tests -pthread -g -O2 
>>> -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat 
>>> -Werror=format-security  -Wl,-z,relro -Wl,-z,now -o run_all_tests 
>>> ../tests/run_all_tests-check_branch_sequences.o 
>>> ../tests/run_all_tests-check_gubbins.o 
>>> ../tests/run_all_tests-check_parse_phylip.o 
>>> ../tests/run_all_tests-check_snp_searching.o 
>>> ../tests/run_all_tests-check_snp_sites.o 
>>> ../tests/run_all_tests-check_vcf_parsing.o 
>>> ../tests/run_all_tests-helper_methods.o 
>>> ../tests/run_all_tests-run_all_tests.o -lcheck libgubbins.la -lz -lm  -lrt 
>>> -lsubunit 
>>> libtool: link: gcc -I../tests -pthread -g -O2 
>>> -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat 
>>> -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
>>> .libs/run_all_tests ../tests/run_all_tests-check_branch_sequences.o 
>>> ../tests/run_all_tests-check_gubbins.o 
>>> ../tests/run_all_tests-check_parse_phylip.o 
>>> ../tests/run_all_tests-check_snp_searching.o 
>>> ../tests/run_all_tests-check_snp_sites.o 
>>> ../tests/run_all_tests-check_vcf_parsing.o 
>>> ../tests/run_all_tests-helper_methods.o 
>>> ../tests/run_all_tests-run_all_tests.o  -lcheck ./.libs/libgubbins.so -lz 
>>> -lm -lrt -lsubunit -pthread

>>> collect2: error: ld returned 1 exit status
>>> Makefile:742: recipe for target 'run_all_tests' failed
>>> make[4]: *** [run_all_tests] Error 1
>>
>> This looks like a completely different issue altogether I have never
>> seen, for me it was always failing tests.
>> ...
> 
> That's #837445 in the check package, which became fatal with gcc-6 in 
> unstable defaulting to PIE since this week Tuesday.

I can't reproduce this in a current unstable chroot; it looks like
#837445 has been fixed.

Cheers
Sascha

Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

[Sascha Steinbiss]

Hi.

[...]
>> Thanks. This has fixed the problem for me. Is this solution OK for
everyone?
>
> Fine for me

OK, I'll upload later.

Cheers
Sascha

Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

[Sascha Steinbiss]

Hi all,

thanks John for the detailed explanation and the patches.

>> So the real solution here is to revert your autoconf-archive to 6dc6cc5^
>> and use that unborked ax_with_curses.m4, which will in future be bundled
>> with samtools.
> 
> This should have been 0351b06^.

I see. For now I have bundled the correct ax_with_curses.m4 with our source 
package (alongside ax_with_htslib.m4) and use it instead of the one in 
autoconf-archive until this issue gets addressed by you upstream.

>>> Cannot open a pty at test/test.pl line 551.
> 
> I've now further tweaked test/test.pl's pty setup to skip the tests instead
> of aborting with this message.  So you may wish to pull this in as a patch
> as well as fixing /dev inside your chroot :-)
> 
> https://github.com/samtools/samtools/commit/ce4a601a0859bc9ccfcf000dddf0ac77e7d576b3

Thanks. This has fixed the problem for me. Is this solution OK for everyone?

Cheers
Sascha

Bug#839320: Would you upload with disabled test?

[Sascha Steinbiss]

Hi Andreas,

> since there are no responses so far I wonder how to proceed with the
> package. 

Yes, that's one of the bugs that has been on my list for a while as well...

> I need to admit I get a different error when trying to build
> the current state of gubbins packaging Git:
> 
> gcc -DHAVE_CONFIG_H -I. -I..   -Wdate-time -D_FORTIFY_SOURCE=2 -I../tests 
> -pthread -g -O2 -fdebug-prefix-map=/build/gubbins-2.1.0=. 
> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
> ../tests/run_all_tests-run_all_tests.o `test -f '../tests/run_all_tests.c' || 
> echo './'`../tests/run_all_tests.c
> /bin/bash ../libtool  --tag=CC   --mode=link gcc -I../tests -pthread -g -O2 
> -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat 
> -Werror=format-security  -Wl,-z,relro -Wl,-z,now -o run_all_tests 
> ../tests/run_all_tests-check_branch_sequences.o 
> ../tests/run_all_tests-check_gubbins.o 
> ../tests/run_all_tests-check_parse_phylip.o 
> ../tests/run_all_tests-check_snp_searching.o 
> ../tests/run_all_tests-check_snp_sites.o 
> ../tests/run_all_tests-check_vcf_parsing.o 
> ../tests/run_all_tests-helper_methods.o 
> ../tests/run_all_tests-run_all_tests.o -lcheck libgubbins.la -lz -lm  -lrt 
> -lsubunit 
> libtool: link: gcc -I../tests -pthread -g -O2 
> -fdebug-prefix-map=/build/gubbins-2.1.0=. -fstack-protector-strong -Wformat 
> -Werror=format-security -Wl,-z -Wl,relro -Wl,-z -Wl,now -o 
> .libs/run_all_tests ../tests/run_all_tests-check_branch_sequences.o 
> ../tests/run_all_tests-check_gubbins.o 
> ../tests/run_all_tests-check_parse_phylip.o 
> ../tests/run_all_tests-check_snp_searching.o 
> ../tests/run_all_tests-check_snp_sites.o 
> ../tests/run_all_tests-check_vcf_parsing.o 
> ../tests/run_all_tests-helper_methods.o 
> ../tests/run_all_tests-run_all_tests.o  -lcheck ./.libs/libgubbins.so -lz -lm 
> -lrt -lsubunit -pthread
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_error.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_msg.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_pack.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_run.o):
>  relocation R_X86_64_32 against undefined symbol `error_jmp_buffer' can not 
> be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_str.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_log.o):
>  relocation R_X86_64_32S against `.rodata' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libcheck.a(check_print.o):
>  relocation R_X86_64_32S against `.rodata' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> Makefile:742: recipe for target 'run_all_tests' failed
> make[4]: *** [run_all_tests] Error 1

This looks like a completely different issue altogether I have never
seen, for me it was always failing tests.

I can take a look at gubbins later and try to figure them out. I had a
first idea of how to address the one reported in this bug here, but I
couldn't reproduce it, instead hitting a different test failure
(consistently) which upstream said I could ignore.

I can do the following:

- first try to reproduce your issue and address it
- disable the test that upstream says shouldn't be a dealbreaker
- try to reproduce and work on the test failure that this bug is
  concerned about

However, my weekend is quite full already, so if I hit a wall with one
of them, I'm not sure of how much time I can dedicate. Any help would be
appreciated!

Cheers
Sascha

Bug#840974: [Debian-med-packaging] Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

[Sascha Steinbiss]

Hi Chris,

>> I would be very happy if an Autotools-savvy person could take another
>> closer look because admittedly I am not really sure about the cause
>> of the problem.
> […]
>> I also had to disable a test (test_usage) that otherwise also seems to
>> (mysteriously?) fail
> 
> These two comments make me a little nervous, alas. We should surely work
> out what was — at least roughly! — the issue instead of just patching
> them out, no?

I fully agree and that was why I was asking for some extra pair of eyeballs 
before uploading. Maybe someone from the team can share some insight or maybe a 
better solution, and my patch could simply serve as a pointer.

Cheers
Sascha

Bug#840974: samtools: FTBFS: configure.ac:69: error: macro PKG_CHECK_EXISTS is not defined; is a m4 file missing?

[Sascha Steinbiss]

Hi all,

I have pushed a fix (9aac9cb) to Git, solving the FTBFS. Before doing an upload 
I would be very happy if an Autotools-savvy person could take another closer 
look because admittedly I am not really sure about the cause of the problem.

I also had to disable a test (test_usage) that otherwise also seems to 
(mysteriously?) fail in my building chroot, resulting in:

pty_allocate(nonfatal): posix_openpt(): Permission denied at 
/usr/lib/x86_64-linux-gnu/perl5/5.24/IO/Pty.pm line 24.
pty_allocate(nonfatal): getpt(): No such file or directory at 
/usr/lib/x86_64-linux-gnu/perl5/5.24/IO/Pty.pm line 24.
pty_allocate(nonfatal): openpty(): No such file or directory at 
/usr/lib/x86_64-linux-gnu/perl5/5.24/IO/Pty.pm line 24.
pty_allocate(nonfatal): open(/dev/ptmx): Permission denied at 
/usr/lib/x86_64-linux-gnu/perl5/5.24/IO/Pty.pm line 24.
Cannot open a pty at test/test.pl line 551.

Any comments welcome. Feel free to upload with any modifications if you want.

Cheers
Sascha


> On 16 Oct 2016, at 16:06, Chris Lamb  wrote:
> 
> Source: samtools
> Version: 1.3.1-2
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> samtools fails to build from source in unstable/amd64:
> 
>  […]
> 
> 
>  
> **
>  ** Starting build
>**
>  
> **
> 
>   Package:  samtools
>   Version:  1.3.1-2
>   Build architecture:   amd64
>   Date: Sun, 16 Oct 2016 16:05:23 +0200
>   Hostname: 80cae65f0728
>   Uname:Linux 80cae65f0728 4.7.0-1-amd64 #1 SMP Debian 
> 4.7.5-1 (2016-09-26) x86_64 GNU/Linux
>   /etc/timezone:Europe/Belgrade
> 
>  
> **
>  ** Installing build dependencies 
>**
>  
> **
> 
>  dh_testdir
>  dh_testroot
>  dh_prep
>  dh_testdir
>  dh_testroot
>  dh_install
>  dh_installdocs
>  dh_installchangelogs
>  dh_compress
>  dh_fixperms
>  dh_installdeb
>  dh_gencontrol
>  dh_md5sums
>  dh_builddeb
>  dpkg-deb: building package 'samtools-build-deps' in 
> '../samtools-build-deps_1.3.1-2_all.deb'.
> 
>  The package has been created.
>  Attention, the package has been created in the current directory,
>  not in ".." as indicated by the message above!
>  Selecting previously unselected package samtools-build-deps.
>  (Reading database ... 23458 files and directories currently installed.)
>  Preparing to unpack samtools-build-deps_1.3.1-2_all.deb ...
>  Unpacking samtools-build-deps (1.3.1-2) ...
>  Reading package lists...
>  Building dependency tree...
>  Reading state information...
>  Correcting dependencies... Done
>  The following additional packages will be installed:
>autoconf-archive bash-completion libhts-dev libhts1 libncurses5-dev
>libtinfo-dev tabix zlib1g-dev
>  Suggested packages:
>ncurses-doc
>  The following NEW packages will be installed:
>autoconf-archive bash-completion libhts-dev libhts1 libncurses5-dev
>libtinfo-dev tabix zlib1g-dev
>  0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded.
>  1 not fully installed or removed.
>  Need to get 2175 kB of archives.
>  After this operation, 12.3 MB of additional disk space will be used.
>  Get:1 http://httpredir.debian.org/debian sid/main amd64 bash-completion all 
> 1:2.1-4.3 [178 kB]
>  Get:2 http://httpredir.debian.org/debian sid/main amd64 libtinfo-dev amd64 
> 6.0+20160917-1 [77.3 kB]
>  Get:3 http://httpredir.debian.org/debian sid/main amd64 libncurses5-dev 
> amd64 6.0+20160917-1 [173 kB]
>  Get:4 http://httpredir.debian.org/debian sid/main amd64 libhts1 amd64 
> 1.3.1-3 [256 kB]
>  Get:5 http://httpredir.debian.org/debian sid/main amd64 libhts-dev amd64 
> 1.3.1-3 [315 kB]
>  Get:6 http://httpredir.debian.org/debian sid/main amd64 zlib1g-dev amd64 
> 1:1.2.8.dfsg-2+b1 [206 kB]
>  Get:7 http://httpredir.debian.org/debian sid/main amd64 autoconf-archive all 
> 20160916-1 [716 kB]
>  Get:8 http://httpredir.debian.org/debian sid/main amd64 tabix amd64 1.3.1-3 
> [254 kB]
>  Fetched 2175 kB in 0s (3409 kB/s)
>  Selecting previously unselected package bash-completion.
>  (Reading database ... 
> (Reading database ... 5%
> (Reading database ... 10%
> (Reading database ... 15%
> (Reading database ... 20%
> (Reading database ... 25%
> (Reading database ... 30%
> (Reading database ... 35%
> (Reading database ... 40%
> (Reading database ... 45%
> (Reading database ... 50%
> (Reading database ... 55%
> (Reading database ... 60%
> 

Bug#840826: marked as pending

[Sascha Steinbiss]

tag 840826 pending
thanks

Hello,

Bug #840826 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:


http://git.debian.org/?p=pkg-security/princeprocessor.git;a=commitdiff;h=75e5860

---
commit 75e58607c5d13c027f55015c19a495e26d9f7712
Author: Sascha Steinbiss <sa...@debian.org>
Date:   Sat Oct 15 11:52:55 2016 +

rename binary to avoid name clash

diff --git a/debian/changelog b/debian/changelog
index 9c5a6a5..021ff75 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+princeprocessor (0.21-3) UNRELEASED; urgency=medium
+
+  * Rename executable to avoid name clash with /usr/bin/pp64 from
+polylib-utils. Thanks to Andreas Beckmann for the hint.
+Closes: #840826
+
+ -- Sascha Steinbiss <sa...@debian.org>  Sat, 15 Oct 2016 11:39:50 +
+
 princeprocessor (0.21-2) unstable; urgency=medium
 
   * Restrict architectures to 64-bit ones.

Bug#840826: princeprocessor: /usr/bin/pp64 is already used by polylib-utils

[Sascha Steinbiss]

Hi Andreas,

thanks for noticing this and letting me know. I will make sure to rename the 
single binary in this package to avoid the name clash.

Cheers
Sascha

> On 15 Oct 2016, at 13:22, Andreas Beckmann  wrote:
> 
> Package: princeprocessor
> Version: 0.21-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files.
> 
>  Selecting previously unselected package princeprocessor.
>  Preparing to unpack .../princeprocessor_0.21-2_amd64.deb ...
>  Unpacking princeprocessor (0.21-2) ...
>  dpkg: error processing archive 
> /var/cache/apt/archives/princeprocessor_0.21-2_amd64.deb (--unpack):
>   trying to overwrite '/usr/bin/pp64', which is also in package polylib-utils 
> 5.22.5-3+dfsg
>  Errors were encountered while processing:
>   /var/cache/apt/archives/princeprocessor_0.21-2_amd64.deb
> 
> Probably the newly introduced packages should rename that binary.
> 
> 
> cheers,
> 
> Andreas
> 
> 

Bug#839320: [Debian-med-packaging] Bug#839320: gubbins: FTBFS: Tests failures

[Sascha Steinbiss]

Hi all,

can anyone reproduce the failure as indicated in the bug submitter’s build log? 
My own cowbuilder build (unstable amd64) succeeds at ‘test_change_window_size' 
but fails at ‘test_robinson_foulds_convergence’ (the latter I have checked with 
upstream and they are happy to have this test simply disabled).

Cheers
Sascha


> On 1 Oct 2016, at 10:43, Lucas Nussbaum  wrote:
> 
> Source: gubbins
> Version: 2.1.0-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160930 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
>> 
>> ==
>> ERROR: test_change_window_size 
>> (test_external_dependancies.TestExternalDependancies)
>> --
>> Traceback (most recent call last):
>>  File "/<>/python/gubbins/tests/test_external_dependancies.py", 
>> line 34, in test_change_window_size
>>gubbins_runner.parse_and_run()
>>  File "/<>/python/gubbins/common.py", line 263, in parse_and_run
>>sys.exit("Failed while running RAxML internal sequence reconstruction")
>> SystemExit: Failed while running RAxML internal sequence reconstruction
>> 
>> --
>> Ran 77 tests in 9.197s
>> 
>> FAILED (errors=1)
>> debian/rules:23: recipe for target 'override_dh_auto_test' failed
> 
> If the failure looks somehow time/timezone related:
> Note that this rebuild was performed without the 'tzdata' package
> installed in the chroot. tzdata used be (transitively) part of
> build-essential, but it no longer is. If this package requires it to
> build, it should be added to build-depends. For the release team's
> opinion on this, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=836940#185
> 
> The full build log is available from:
>   http://aws-logs.debian.net/2016/09/30/gubbins_2.1.0-1_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#839309: [Debian-med-packaging] Bug#839309: orthanc-postgresql 2.0-3

[Sascha Steinbiss]

Hi Sebastien,

looks good to me, I'm on it.

Cheers
Sascha

> On 3 Oct 2016, at 10:54, Sébastien Jodogne  wrote:
> 
> Hello,
> 
> I have just updated the orthanc-postgresql package:
> https://anonscm.debian.org/viewvc/debian-med?view=revision=22821
> 
> This new version of the package solves the severe FTBFS Bug#839309 
> (orthanc-postgresql: Could NOT find PostgreSQL).
> 
> In the absence of Andreas, please someone could sponsor the upload? TIA!
> 
> Best regards,
> Sébastien-
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging

Bug#833965: tcsh: uses deprecated BSD union wait type

[Sascha Steinbiss]

Hi,

just a friendly ping whether this is still on anyone’s radar. I assume that 
#837026 [1]
is a direct consequence of this issue?

Cheers
Sascha

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837026

On Thu, 1 Sep 2016 13:02:17 +0200 Thomas Lange  
wrote:
> > On Thu, 1 Sep 2016 12:51:30 +0200, Aurelien Jarno  
> > said:
> 
> > bug to serious. If you don't have time to fix this bug, I can do a
> > non-maintainer upload with the patch which is in the bug log.
> Salut Aurelien,
> 
> feel free to do a NMU.
> 
> -- 
> regards Thomas
> 
> 

Bug#837276: python-mne: FTBFS: build-dependency not installable: mayavi2 (>= 4.4.3-1)

[Sascha Steinbiss]

Hi,

I am unable to reproduce this FTBFS in a current sid amd64 cowbuilder chroot.
See attached build log. I can see that the latest mayavi2 NMU (4.4.3-2.2) 
failed to build for amd64, but I was sure able to get 
4.4.3-2.1. 
I’m not sure I understand if this might be the reason for this failure you are 
reporting?

Thanks
Sascha

On Sat, 10 Sep 2016 09:37:14 +0200 Lucas Nussbaum  wrote:
> Source: python-mne
> Version: 0.12+dfsg-2
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20160910 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> > +--+
> > | Install package build dependencies
> >|
> > +--+
> > 
> > 
> > Setup apt archive
> > -
> > 
> > Merged Build-Depends: debhelper (>= 9), python-all, python-numpy, 
> > python-scipy, python-sphinx (>= 1.0~), python-nose, python-setuptools, 
> > python-matplotlib, python-joblib (>= 0.4.5), python-sklearn, mayavi2 (>= 
> > 4.4.3-1) | python-vtk6 | python-vtk, xvfb, xauth, libgl1-mesa-dri, 
> > python-coverage, libjs-jquery, libjs-jquery-ui, yui-compressor
> > Filtered Build-Depends: debhelper (>= 9), python-all, python-numpy, 
> > python-scipy, python-sphinx (>= 1.0~), python-nose, python-setuptools, 
> > python-matplotlib, python-joblib (>= 0.4.5), python-sklearn, mayavi2 (>= 
> > 4.4.3-1), xvfb, xauth, libgl1-mesa-dri, python-coverage, libjs-jquery, 
> > libjs-jquery-ui, yui-compressor
> > dpkg-deb: building package 'sbuild-build-depends-python-mne-dummy' in 
> > '/<>/resolver-6Al9S2/apt_archive/sbuild-build-depends-python-mne-dummy.deb'.
> > dpkg-scanpackages: warning: Packages in archive but missing from override 
> > file:
> > dpkg-scanpackages: warning:   sbuild-build-depends-python-mne-dummy
> > dpkg-scanpackages: info: Wrote 1 entries to output Packages file.
> > Ign:1 copy:/<>/resolver-6Al9S2/apt_archive ./ InRelease
> > Get:2 copy:/<>/resolver-6Al9S2/apt_archive ./ Release [957 B]
> > Ign:3 copy:/<>/resolver-6Al9S2/apt_archive ./ Release.gpg
> > Get:4 copy:/<>/resolver-6Al9S2/apt_archive ./ Sources [486 B]
> > Get:5 copy:/<>/resolver-6Al9S2/apt_archive ./ Packages [564 B]
> > Fetched 2007 B in 0s (0 B/s)
> > Reading package lists...
> > W: No sandbox user '_apt' on the system, can not drop privileges
> > Reading package lists...
> > 
> > Install python-mne build dependencies (apt-based resolver)
> > --
> > 
> > Installing build dependencies
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > Some packages could not be installed. This may mean that you have
> > requested an impossible situation or if you are using the unstable
> > distribution that some required packages have not yet been created
> > or been moved out of Incoming.
> > The following information may help to resolve the situation:
> > 
> > The following packages have unmet dependencies:
> >  sbuild-build-depends-python-mne-dummy : Depends: mayavi2 (>= 4.4.3-1) but 
> > it is not going to be installed
> > E: Unable to correct problems, you have held broken packages.
> > apt-get failed.
> 
> The full build log is available from:
>http://aws-logs.debian.net/2016/09/10/python-mne_0.12+dfsg-2_unstable.log
> (That DNS record was just updated. Use
> http://ec2-52-58-237-241.eu-central-1.compute.amazonaws.com if it

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

[Sascha Steinbiss]

Hi Andreas,

>> I’d rather get it to work for now and will try including the smallest 
>> necessary set of code needed to build salmon. It is definitely more than one 
>> file; currently I’m using trial and error to arrive at a minimal set. I have 
>> also opened https://github.com/COMBINE-lab/salmon/issues/87, let’s see what 
>> they say.
> 
> I guess you might be able to get the full set when checking my rapmap related 
> quilt patch which contains a list.

True. BTW it builds now with some RapMap code added back in (see git) but one 
of the unit tests fails ATM — I’ll take a look tomorrow.

Good night
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

[Sascha Steinbiss]

Hi Andreas,

>> However, the build still fails with:
>> 
>> In file included from 
>> /build/salmon-0.7.1+ds1/include/UtilityFunctions.hpp:5:0,
>>from /build/salmon-0.7.1+ds1/include/SBModel.hpp:7,
>>from /build/salmon-0.7.1+ds1/src/SBModel.cpp:1:
>> /build/salmon-0.7.1+ds1/include/SalmonUtils.hpp:32:27: fatal error: 
>> RapMapUtils.hpp: No such file or directory
>> 
>> which suggests that salmon also uses parts of the previous embedded or 
>> downloaded RapMap source tree to build salmon, not just the binary.
>> I’m not familiar enough with RapMap’s intended use to decide whether we 
>> should introduce a rapmap-dev package given that it doesn’t seem to build a 
>> library. Any hints?
> 
> Possible quick-n-dirty, solution: Just add a code copy of
> RapMapUtils.hpp either as quilt patch or in debian/rapmap and copy over
> in build process.

Sure, that’s always an option.

> This might help us whether the new version would
> really fix the original build issue of #835720.

Looking at the error message, the original build issue looks like something I 
had to fix in RapMap as well, as there was a mismatch between the version of 
spdlog whose API salmon and RapMap were using and the one packaged in Debian. 
So I guess this will be fixed if we include Debian’s patched copy of the 
required RapMap code or — if not -- I know how to fix it.

> Proper solution is probably to contact upstream (I think its the same
> for rapmap and salmon) how to sensibly solve this issue.

I’d rather get it to work for now and will try including the smallest necessary 
set of code needed to build salmon. It is definitely more than one file; 
currently I’m using trial and error to arrive at a minimal set. I have also 
opened https://github.com/COMBINE-lab/salmon/issues/87, let’s see what they say.

Cheers
Sascha



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

[Sascha Steinbiss]

Hi Andreas,

> I'm now
> facing the next configure issue which seems that BOOST_INCLUDEDIR and
> BOOST_LIBRARYDIR are not found.  Any clue how to get the latest state
> of salmon Git build?

It was a missing build-dependency on libboost-timer-dev. I also added the 
necessary build-deps on libdivsufsort and libsparsehash, see git.

However, the build still fails with:

In file included from /build/salmon-0.7.1+ds1/include/UtilityFunctions.hpp:5:0,
 from /build/salmon-0.7.1+ds1/include/SBModel.hpp:7,
 from /build/salmon-0.7.1+ds1/src/SBModel.cpp:1:
/build/salmon-0.7.1+ds1/include/SalmonUtils.hpp:32:27: fatal error: 
RapMapUtils.hpp: No such file or directory

which suggests that salmon also uses parts of the previous embedded or 
downloaded RapMap source tree to build salmon, not just the binary.
I’m not familiar enough with RapMap’s intended use to decide whether we should 
introduce a rapmap-dev package given that it doesn’t seem to build a library. 
Any hints?

Cheers
Sascha

> 
> Kind regards
> 
>  Andreas.
> 
> On Wed, Sep 07, 2016 at 10:31:17AM +0200, Andreas Tille wrote:
>> Hi,
>> 
>> thanks to Sascha's help I finalised rapmap, ITPed #836914 and uploaded.
>> 
>> Kind regards
>> 
>>   Andreas.
>> 
>> --
>> http://fam-tille.de
>> 
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>> 
> 
> --
> http://fam-tille.de



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

[Sascha Steinbiss]

Hi Andreas,

> Back to the salmon issue:  When using the just uploaded rapmap and
> trying to prevent salmon's cmake from downloading it in a patch I'm now
> facing the next configure issue which seems that BOOST_INCLUDEDIR and
> BOOST_LIBRARYDIR are not found.  Any clue how to get the latest state
> of salmon Git build?

I’ll look at it.

Cheers
Sascha

> 
> Kind regards
> 
>  Andreas.
> 
> On Wed, Sep 07, 2016 at 10:31:17AM +0200, Andreas Tille wrote:
>> Hi,
>> 
>> thanks to Sascha's help I finalised rapmap, ITPed #836914 and uploaded.
>> 
>> Kind regards
>> 
>>   Andreas.
>> 
>> --
>> http://fam-tille.de
>> 
>> ___
>> Debian-med-packaging mailing list
>> debian-med-packag...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
>> 
> 
> --
> http://fam-tille.de



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

[Sascha Steinbiss]

Hi Andreas,

> thanks to Sascha's help I finalised rapmap, ITPed #836914 and uploaded.

You’re welcome. I was going to finish it yesterday but I since I couldn’t find 
a explicit copyright statement I raised 
https://github.com/COMBINE-lab/RapMap/issues/31. It looks like I could also 
have just used the lab as copyright holder, good to know. Maybe I was overly 
cautious as my current employer has quite strict rules who to use as copyright 
holder ;)

Cheers
Sascha


signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#835720: [Debian-med-packaging] Bug#835720: salmon: FTBFS: BAMQueue.tpp:88:29: error: no matching function for call to 'spdlog::logger::warn()'

[Sascha Steinbiss]

Hi again,

>> It would be great if somebody could fix the build to bring this forward
>> since I personally do not have any interest in salmon (yet).
> 
> I’ll look at it. There will be some patching necessary to bring the spdlog 
> API use in RepMap up to speed with the current spdlog version in unstable.

Builds now and produces a working executable, see git. There’s no manpage, 
copyright file, etc. yet, I can try to get this finished later.
I won’t be a first hand user of this tool either, but if it’s useful...

Cheers
Sascha



signature.asc
Description: Message signed with OpenPGP using GPGMail