Bug#1073069: magic-wormhole new upstream packaging
Hi, I would like to let you know that I am going to NMU magic-wormhole 0.14 which fixes #1073069 and #1073799. I have packaged python-iterable-io as a dependency and can verify that magic-wormhole builds fine and tests succeed. Since Antoine has low threshold NMU declared, I will upload directly without delay in the next couple days. If there are any objections, please let me know. Thanks Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1075859: stenographer provides certificates in /etc/stenographer for 127.0.0.1 without subjectAltName
Hi Charles, many thanks (and to Sergio) for reporting this and for providing such a deep insight into the issue. I have added a patch to stenokeys.sh (the script that creates the CA, certs, etc.) so it sets sensible subjectAltNames [1]. Just uploaded a new version containing this patch. Let's see if that fixes the problem with the new curl version. Cheers Sascha [1] https://salsa.debian.org/go-team/packages/stenographer/-/blob/master/debian/patches/0006-Enable-Subject-Alt-Name.patch?ref_type=heads OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1068401: Pending uplad (Was: Bug#1068401: ltrsift dependencies unsatisfiable on 32-bit non-i386 architectures.)
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)
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&page=7&straight=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)
Hi, https://buildd.debian.org/status/fetch.php?pkg=seqan-needle&arch=amd64&ver=1.0.2%2Bds-2&stamp=1707394988&raw=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
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
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
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
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
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
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
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
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
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
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
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
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 /build/relion-cuda-3.1.3/src/ac
Bug#999806: pygattlib: Misbuild with multiple supported python versions
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'
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'
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
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
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]
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]
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
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
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
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
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
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
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.
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
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
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
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
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
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
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'; ../rust/target/release/libsuricata.a(compiler_builtins-d2631cd9ed1
Bug#950211: python-virustotal-api fails autopkg test
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
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
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
> 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
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
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
> 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
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)
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)
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
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
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'
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
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
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
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&arch=armhf&ver=2.1-2&stamp=1545838322&raw=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
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
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?
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:
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:
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
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
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_*)
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
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
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
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
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" <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&arch=amd64&ver=2.0%2Bdfsg-10%2Bb1&stamp=1498774574&raw=0 > > <https://buildd.debian.org/status/fetch.php?pkg=khmer&arch=amd64&ver=2.0%2Bdfsg-10%2Bb1&stamp=1498774574&raw=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
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&arch=amd64&ver=2.0%2Bdfsg-10%2Bb1&stamp=1498774574&raw=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
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
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
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
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
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
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
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
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.
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.
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
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
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
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)
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
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 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))]
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))]
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
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(&algorithm, 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, &e, 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), &n, NULL, NULL); + return BN_num_bits(n); case EVP_PKEY_DSA: - return BN
Bug#839320: Would you upload with disabled test?
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?
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?
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?
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?
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?
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% > (Reading database ..
Bug#840826: marked as pending
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 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 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
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
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
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&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
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)
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()'
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()'
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()'
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()'
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