Bug#1069145: RM: vast -- RoQA; FTBFS since 2021, not part of bookworm or trixie, low popcon
Hi, I request removal of vast from Debian unstable for the following reasons: * FTBFS since 2021 * Not part of bookworm or trixie * No maintainer upload since 2021 * Low popcon (2) * No reverse dependencies * Requires changes for the /usr-move transition As the original packager, I in fact second that. The package (which has also been renamed by upstream in the meantime) is also unlikely to be updatable to newer releases anytime soon since it now requires Apache Arrow, which is not in Debian (yet). Thanks Sascha 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#1067413: RFP: keydb -- persistent key-value database with network interface
Hi Guillem, [RFP] I'll try to do this during this week or next one, but if someone would like to package this right ahead, I can speed this up. Cool. If my old packaging helps in any way, feel free to steal anything from it! [0] [...] I'm also CCing Sascha who might be interested (given the keydb packaging repo in salsa). That was a one-off that never made it from a testing prototype into anything upload-worthy, let alone into production. We used it to evaluate KeyDB internally within my organization as a potentially faster Redis replacement, but we found out that it didn't help in our particular use case. I just packaged it for Debian to allow for easier installation/removal, so really simply for our convenience. I didn't polish the packaging, did not do time-consuming things like checking licenses, looking for the presence of code copies, etc. like I would for something to be uploaded to the official archive. You can also see that I just copied the debian directory from a different project (e.g. in d/upstream/metadata). I also wouldn't want to support KeyDB in Debian long-term, given that I already have >100 packages on my list and, as I said, I don't use KeyDB myself anymore. So please feel free to salvage the (unfortunately quite old) repo. Just fork, remove me from the maintainer list and upload at will Best regards Sascha [0] https://salsa.debian.org/satta/keydb 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=7=false [2] https://github.com/Debian/ratt OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1064291: ITP: python-awkward -- manipulate JSON-like data with NumPy-like idioms
Package: wnpp Severity: wishlist Owner: debian-...@lists.debian.org X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-awkward Version : 2.6.1 Upstream Contact: Jim Pivarski * URL : https://github.com/scikit-hep/awkward * License : BSD-3-clause Programming Lang: Python, C++ Description : manipulate JSON-like data with NumPy-like idioms Awkward Array is a library for nested, variable-sized data, including arbitrary-length lists, records, mixed types, and missing data, using NumPy-like idioms. Arrays are dynamically typed, but operations on them are compiled and fast. Their behavior coincides with NumPy when array dimensions are regular and generalizes when they're not. This is packaged as a dependency for another package under the umbrella of the Debian Med packaging team.
Bug#1063602: seqan-needle: FTBFS on amd64: test/api/insert_delete_test (Failed)
Hi, https://buildd.debian.org/status/fetch.php?pkg=seqan-needle=amd64=1.0.2%2Bds-2=1707394988=0 2: [ RUN ] insert.ibfmin 2: unknown file: Failure 2: C++ exception with description "std::bad_alloc" thrown in the test body. 2: 2: [ FAILED ] insert.ibfmin (0 ms) [...] 2: [ FAILED ] 1 test, listed below: 2: [ FAILED ] insert.ibfmin 2: 2: 1 FAILED TEST 2/13 Test #2: test/api/insert_delete_test ...***Failed0.03 sec Unfortunately, I cannot reproduce this on my amd64 machine in a current sid chroot. Maybe the test tried to allocate more memory than temporarily available on the buildd? I'll take another look. Cheers S OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061762: suricata: please enable dpdk
Hi, apt-cache policy dpdk-dev dpdk-dev: Installed: 23.11-1 Candidate: 23.11-1 Version table: *** 23.11-1 500 500 http://deb.debian.org/debian unstable/main riscv64 Packages 100 /var/lib/dpkg/status riscv64 is not a release architecture, so it is not in bullseye. Totally right, my bad, sorry! No idea why I had bullseye selected there. I will try to maximize the supported archs on sid first and then narrow things down for backports. Cheers Sascha OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061762: suricata: please enable dpdk
On 2/2/24 16:14, Alexandra N. Kossovsky wrote: On 02/02/2024 17:19, Sascha Steinbiss wrote: Will look into adding DPDK support in the binaries on platforms that support it on Debian (i.e. amd64, arm64, i386, ppc64el). and riscv64, please. Unfortunately, riscv64 does not have a dpdk-dev package available, which would be a dependency [1]. I looked at all dependencies (libnuma-dev, dpdk-dev etc) and used the intersection of their available architectures. Cheers S [1] https://packages.debian.org/bullseye/dpdk-dev OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1061762: suricata: please enable dpdk
Hi, thanks for the notification. Suricata can work with DPDK, but this feature is not enabled in the Debian package. Could you enable it, please? True. I assumed DPDK and the other methods (like AF_PACKET/AF_XDP) were mutually exclusive, but looks like they are not! Will look into adding DPDK support in the binaries on platforms that support it on Debian (i.e. amd64, arm64, i386, ppc64el). Cheers S OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1050861: [pkg-go] Bug#1050861: RM: golang-github-twstrike-gotk3adapter -- RoQA; FTBFS since 2021, coyim leaf library
Hi all, golang-github-twstrike-gotk3adapter was introduced to build coyim, which is already removed in 2021, see #994195. FYI, as the person who introduced that package I very much agree it can and should be removed if nothing else depends on it besides coyim. A lot has changed with these projects and I don't see much benefit from keeping it in Debian for now. Thanks for taking care too Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#1039931: suricata: Outdated Homepage: filed
tags 1039931 + fixed pending thanks Hi Adrian, thanks for letting me know. [...] debian/control:Homepage: https://www.suricata-ids.org/ This location does no longer exist, the new location is https://oisf.net/ Actually, that's the organization that runs the project -- Suricata's new homepage location is: https://suricata.io I will update this field in Git and upload it with the next regular upload. Cheers Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#856649: suricata: IPv4 defrag evasion issue
Hi Salvatore, (re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856649) Can we just close this bug? This has been addressed for years, and I am not sure we need to keep these open forever. Can you pin point the upstream version where this was fixed? Sure, you did so yourself in your original bug report from 2017 [1] :) It's upstream version 3.2.1, which is confirmed by the tags listed in the commit on GitHub and the target version of the fix in upstream's Redmine. That version was uploaded to unstable later in March 2017 [2]. Just FYI: we're at 6.0.10 now. Best regards Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856649#5 [2] https://tracker.debian.org/news/841144/accepted-suricata-321-1-source-into-unstable/ OpenPGP_signature Description: OpenPGP digital signature
Bug#856649: suricata: IPv4 defrag evasion issue
Hi, (re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856649) Can we just close this bug? This has been addressed for years, and I am not sure we need to keep these open forever. Thanks and best regards Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#856648: suricata: dns: out of bound memory read
Can we just close this bug? This has been fixed for years, and AFAICS no CVE has ever been assigned. Thanks and best regards Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#853154: configuration broken out of the box
Hi Hamish, thanks for the reminder. The default configuration still seems to be broken. The provided suricata.yaml refers to /etc/suricata/rules/suricata.rules as the rules file, but none is provided. suricata-update writes rules to /var/lib/suricata, so even after running suricata-update, the config is invalid. You are right. This seems to be because we're not installing suricata-update with Suricata on Debian [0], which causes the "ruledirprefix" variable in the configure script to be left at the default of "sysconfdir", which is /etc. This leads to the "e_defaultruledir" being /etc/suricata/rules, which ends up in the default configuration. I think the best option we have to address this issue is to force the default rule path in the suricata.yaml that is installed in Debian to be /var/lib/suricata/rules. Then provide an empty file by default. This would address your immediate concern, and also keeps compatibility with suricata-update, should the user decide to use it. That writes into the same location, so the new rules are picked up automatically (/var/lib/suricata/rules/suricata.rules). Any comments? If not I'll implement this in an upcoming package update. Note that the 'default installation' (i.e. completely unconfigured by the user) is likely to be 'broken' still because one still needs to at least define an actual inspection interface to use so Suricata can start. The default is "eth0" which is unlikely to exist on modern systems (also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895342). Best Sascha [0] By passing --disable-suricata-update and patching the Makefile. 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 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#970021: Provisional packaging for Aoache Arrow available
Hi Nilesh, On 20 December 2021 9:17:40 pm IST, Sascha Steinbiss wrote: TLDR: I have prepared a package to cover as much of Arrow as is possible with what we have in Debian, dependency-wise. There is still a review of d/copyright missing, and some bundled code might need some extra love or removal. [...] It's quite an old mail but I can give you a hand with it, however I can't maintain this alone. Yeah, same here. It's big. I'm seeing this as a dependency in increasing number of packages and it'd be good to have this in the archive. I agree. At the moment, though, I must admit I don't really need it anymore since the package that I originally needed it for as a dependency (vast) is no longer a priority for me. So for me there would be little motivation to keep it updated (and also only little insight into version progress and impact of changes). Moreover, it seems like upstream are doing major releases rather frequently [0] for which I have no idea of how potentially ABI breaking they are, but I expect them to be [1]. That means that there might be a danger of frequent transitions if we want to keep up-to-date with upstream's versions. I have little experience with handling transitions, TBH, and I am not sure I can dedicate much time to that in the future. If that's OK then I wouldn't mind investing some more time to help make a current version in Debian possible, as long as update work can be shared across team members. I'd suggest we disable some features that would require packaging even more dependencies though (e.g. aws-sdk-cpp etc.). What do you think? Cheers Sascha [0]https://arrow.apache.org/release/ [1] https://arrow.apache.org/docs/format/Versioning.html OpenPGP_signature Description: OpenPGP digital signature
Bug#1010653: [Debian-med-packaging] Bug#1010653: busco: add autopkgtest to check integration with hmmer and prodigal
Hi again, [...] So it looks like metaeuk is not found -- is this even packaged? Did I do something wrong (note: busco 5.4.4 from unstable)? Quick update: filed an ITP for it [0] and also started packaging [1]. Cheers Sascha [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029432 [1] https://salsa.debian.org/med-team/metaeuk OpenPGP_signature Description: OpenPGP digital signature
Bug#1029432: ITP: metaeuk -- sensitive, high-throughput gene discovery and annotation for metagenomics
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org * Package name: metaeuk Version : 6-a5d39d9 Upstream Author : Eli Levy Karin and co-authors * URL : https://github.com/soedinglab/metaeuk * License : GPL3 Programming Lang: C++ Description : sensitive, high-throughput gene discovery and annotation for metagenomics MetaEuk is a modular toolkit designed for large-scale gene discovery and annotation in eukaryotic metagenomic contigs. MetaEuk combines the fast and sensitive homology search capabilities of MMseqs2 with a dynamic programming procedure to recover optimal exons sets. It reduces redundancies in multiple discoveries of the same gene and resolves conflicting gene predictions on the same strand. This is packaged as a dependency of busco and will be maintained by the Debian Med team.
Bug#1010653: [Debian-med-packaging] Bug#1010653: busco: add autopkgtest to check integration with hmmer and prodigal
Hi all, We might still download one of them at autopkgtest time but I am not sure that's a good idea. Any comments? BTW datasets are regularly downloaded anyway by the busco tool when specifying a lineage on the command line. So if that's the way it's usually done with the installed version, then I would suggest to also do it like that in the autopkgtest. This way we won't have to distribute files with a ND license as Debian, and would also be testing the intended mode of use. I wonder why Andrius explicitly asked for the `--offline` option which would disable that option. IIRC autopkgtests are expected to have Internet available. However, I noticed that doing something like $ busco -l euglenozoa_odb10 -i foo.fasta -o out -m genome already fails with 2023-01-21 16:44:08 INFO: * Start a BUSCO v5.4.4 analysis, current time: 01/21/2023 16:44:08 * 2023-01-21 16:44:08 INFO: Configuring BUSCO with local environment 2023-01-21 16:44:08 INFO: Mode is genome 2023-01-21 16:44:08 INFO: Downloading information on latest versions of BUSCO data... 2023-01-21 16:44:11 INFO: Input file is /tmp/foo.fasta 2023-01-21 16:44:11 ERROR: metaeuk tool cannot be found. Please check the 'path' and 'command' parameters provided in the config file or make sure the tool is available in your working environment. 2023-01-21 16:44:11 ERROR: BUSCO analysis failed! 2023-01-21 16:44:11 ERROR: Check the logs, read the user guide (https://busco.ezlab.org/busco_userguide.html), and check the BUSCO issue board on https://gitlab.com/ezlab/busco/issues So it looks like metaeuk is not found -- is this even packaged? Did I do something wrong (note: busco 5.4.4 from unstable)? Thanks Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#1010653: busco: add autopkgtest to check integration with hmmer and prodigal
Hi, I'm at the Debian Med sprint and currently taking a look at various things to take care of. [...] To have BUSCO lineages in the archive their licensing details have to be clarified as the data does not contain any explicit statements. The website [0] states that The BUSCO datasets are licensed under the Creative Commons Attribution-NoDerivatives 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by-nd/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. The lineages and the URL you mention are referenced as the "datasets" so that seems to be the license statement. Consequently I guess including them in the package for the autopkgtest is not an option as the ND clause in their license is incompatible with DFSG. We might still download one of them at autopkgtest time but I am not sure that's a good idea. Any comments? Best Sascha [0] https://busco.ezlab.org/#license OpenPGP_signature Description: OpenPGP digital signature
Bug#1025538: RM: pktanon [s390x] -- ANAIS; does not work on s390x
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: 1012...@bugs.debian.org Hi, recently added autopkgtests showed that pktanon does not work correctly on s390x, while it builds there. This might be due to endianness issues. Reported to upstream, but in order to keep the package in testing I would like to have s390x removed as an architecture for now. If there are any more questions please let me know. Thanks Sascha
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#967603: ltrsift: depends on deprecated GTK 2
tags 967603 wontfix thanks Hi smcv, [...] This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces binary packages with a Depends on GTK 2. Unfortunately, LTRsift is currently unmaintained (by me, I am also upstream). My career has moved into a different direction and it does not look like anyone else picked up the project upstream in the meantime. So: it is unlikely that LTRsift will be ported to GTK3 in the near future or even in the medium term. I am truly sorry but that's how it is. I am prepared to accept removal of LTRsift as a consequence of potential removal of GTK2 from Debian, should it ever happen. Best regards Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#1018914: suricata: FTBFS with libbpf 1.0.0
Hi Sudip, suricata FTBFS with libbpf 1.0.0 (available in experimental). This is the first error from the build log: util-ebpf.c: In function 'EBPFLoadFile': util-ebpf.c:375:17: error: implicit declaration of function 'bpf_program__set_socket_filter'; did you mean 'bpf_program__set_log_level'? [-Werror=implicit-function-declaration] 375 | bpf_program__set_socket_filter(bpfprog); | ^~ | bpf_program__set_log_level util-ebpf.c:377:17: error: implicit declaration of function 'bpf_program__set_xdp'; did you mean 'bpf_program__set_type'? [-Werror=implicit-function-declaration] 377 | bpf_program__set_xdp(bpfprog); | ^~~~ | bpf_program__set_type Thanks for reporting this. This issue is likely due to libbpf 1.0.0 removing previously deprecated functions, which are still used in Suricata's eBPF code. I have found a backwards-compatible fix and am currently in contact with upstream. Best regards Sascha
Bug#1018370: gnome-keysign: build-depends on python3-nose or uses it for autopkgtest
tags 1018370 upstream forwarded 1018370 https://github.com/gnome-keysign/gnome-keysign/issues/115 thanks
Bug#1013801: gopsutil and slinkwatch/ifplugo
fixed 1013801 golang-github-satta-ifplugo/0.0~git20200508.ca679be-6 reassign 1013818 golang-github-satta-ifplugo fixed 1013818 golang-github-satta-ifplugo/0.0~git20200508.ca679be-6 thanks Setting these bugs to fixed. * golang-github-satta-ifplugo is ready for gopsutil v3. * slinkwatch does not need to depend on gopsutil at all; it uses golang-github-satta-ifplugo, which until the latest version did not state a dependency in its -dev package on gopsutil to be pulled in transitively in the slinkwatch build. Will upload a version of the slinkwatch package that drops the gopsutil dependency altogether soon. Cheers Sascha 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#1012031: suricata: ftbfs on riscv64 arch, but it is ok on unmatche board
Hi, this issue seems to be the one I fixed upstream a while ago in: https://github.com/OISF/suricata/pull/7350 Looks like this just wasn't added as a patch to the packaging yet. Maybe adding fixes the build on the other machine. Will add the patch soon and keep an eye on the build status to see if that eliminates this problem for good. Cheers Sascha On 29.05.22 07:07, Bo YU wrote: Package: suricata Version: 1:6.0.5-2 Severity: minor Tags: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Justification: fails on some buildd machines (but built successfully on real riscv64 machine) Dear Maintainer, I am verfiy the suricata package is build ok on real riscv64 boards(Unmatched board): ``` ... Build Architecture: riscv64 Build Type: binary Build-Space: 1363208 Build-Time: 1266 Distribution: unstable Host Architecture: riscv64 Install-Time: 172 Job: /home/vimer/05/33_suricata/suricata_6.0.5-2.dsc Lintian: warn Machine Architecture: riscv64 Package: suricata Package-Time: 1567 Source-Version: 1:6.0.5-2 Space: 1363208 Status: successful Version: 1:6.0.5-2 Finished at 2022-05-29T03:45:05Z Build needed 00:26:07, 1363208k disk space ``` But it fails on rv-mullvad-03(Unleashed boards), the full buildd log is here: ``` In file included from suricata-plugin.h:21, from decode.h:31, from detect-engine-alert.h:28, from suricata-common.h:503, from alert-fastlog.c:27: autoconf.h:23:13: error: ‘undefined’ undeclared here (not in a function) ``` https://buildd.debian.org/status/fetch.php?pkg=suricata=riscv64=1%3A6.0.5-2=1651322558=0 So if we can try build it on some unmatched boards? Bo
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#1010722: RM: pktanon [armel armhf] -- ANAIS; binaries broken on some archs
Package: ftp.debian.org Severity: normal As the maintainer for pktanon, I would like to have old arm binary packages removed from unstable and testing. They are bult but do not work on these architectures due to alignment problems. See [0]. I have already removed the architectures with my latest source updates and would like to make sure that can migrate to testing again. Thanks and best regards Sascha [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999620
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
Bug#1004998: python3-filelock: version 0.0.0
forwarded 1004998 https://github.com/tox-dev/py-filelock/issues/133 thanks > the packaging makes it look like it is version 0.0.0. We have the path > /usr/lib/python3/dist-packages/filelock-0.0.0.egg-info, the file > PKG-INFO says "Version: 0.0.0", etc. Ah, upstream now uses setuptools-scm to get the version from the SCM, see upstream's WONTFIX in https://github.com/tox-dev/py-filelock/issues/133. Since we can't do that, I guess we'll need to patch it. I'll take a look soon. Thanks Sascha
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#970021: Provisional packaging for Aoache Arrow available
Hi, just for the record in this RFP and to move this a bit into the spotlight: I have moved my packaging repository for Apache Arrow to the Debian Science project in Salsa [1]. See the corresponding thread in the Debian Med mailing list for more context [2]. TLDR: I have prepared a package to cover as much of Arrow as is possible with what we have in Debian, dependency-wise. There is still a review of d/copyright missing, and some bundled code might need some extra love or removal. If someone wants to work on this and wants to maintain it for longer, feel free to let me know and I might help get it finished. :) I just feel I won't be able to keep this updated in time on my own given how busy upstream seems to be. Cheers Sascha [1] https://salsa.debian.org/science-team/arrow [2] https://lists.debian.org/debian-med/2021/08/msg00066.html
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#1000257: golang-github-pierrec-lz4: please package new upstream version v4
Package: golang-github-pierrec-lz4 Severity: wishlist Dear Maintainer, it looks like upstream has made the v4 branch the new default and some updates of my Go packages have started importing github.com/pierrec/lz4/v4, e.g. gocql. It would be useful to have this version packaged. Thanks and best regards Sascha
Bug#999952: suricata: depends on obsolete pcre3 library
Hi Matthew, thanks for letting us know. > Your package still depends on the old, obsolete PCRE3[0] libraries > (i.e. libpcre3-dev). This has been end of life for a while now, and > upstream do not intend to fix any further bugs in it. Accordingly, I > would like to remove the pcre3 libraries from Debian, preferably in > time for the release of Bookworm. [...] Suricata upstream is aware of this [0] and have merged support for PCRE2 [1] into the latest upstream version 7.0 which hopefully will be in Debian before the bookworm release. I will make sure to update the dependencies as soon as this hits unstable, so you will have one package less to worry about. Cheers Sascha [0] https://redmine.openinfosecfoundation.org/issues/3194 [1] https://github.com/OISF/suricata/pull/6414
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#900808: python-pika: New version available
Hi, [...] >> I would also like to have a new version in unstable but as I said I >> never tested if the rdeps still properly work with the new version. I >> just expected trouble when upgrading due to the API change that was >> mentioned in the upstream changelog. > > We rebuilt the rdeps again against python-pika 1.2.0. > > The only one that broke was python3-pika-pool, during autopkgtests. > We are working on it (#999500 and #999557). Great, so many thanks for your work! :) Good to know that there is less breakage than I expected. > Sergio Durigan (not me) will upload python-pika 1.2.0 to unstable when > python-pika-pool is removed from archive. I see -- looking forward to that, thanks! Cheers Sascha
Bug#900808: python-pika: New version available
Hi, > > There is even 1.x.x available now, which broke API :( [1] > > Is this problem still a thing? > I have rebuilt the rdependencies locally, but I haven't been able to > reproduce this. I just read in the upstream changelog that the API is different, not tried it with a newer package. See the link [1] in my message. > Here is an update of the existing reverse deps: > > $ apt-rdepends -r python3-pika > Reading package lists... Done > Building dependency tree... Done > Reading state information... Done > python3-pika > Reverse Depends: python3-biomaj3-download (3.2.4-1) > Reverse Depends: python3-biomaj3-process (3.0.16-2) > Reverse Depends: python3-pika-pool (>= 0.1.3-4) > python3-biomaj3-download > Reverse Depends: python3-biomaj3 (3.1.18-2) > python3-biomaj3 > Reverse Depends: python3-biomaj3-daemon (3.0.22-2) > python3-biomaj3-daemon > python3-biomaj3-process > Reverse Depends: python3-biomaj3 (3.1.18-2) > python3-pika-pool So these all actually work with the new version (> 1.0)? I was expecting these to still use the API of the current version in unstable (< 1.0) > > Should we introduce a new source package, python-pika1, to reflect that > > and preserve the old API for the existing reverse deps: > > Is this option still necessary? > We need to upgrade python-pika in order to upgrade pagure to the latest > version. > So, If this problem doesn't happen anymore, we intend to take the changes to > unstable. I would also like to have a new version in unstable but as I said I never tested if the rdeps still properly work with the new version. I just expected trouble when upgrading due to the API change that was mentioned in the upstream changelog. Cheers Sascha
Bug#994195: RM: coyim/0.3.8+ds-6
Hi Sebastian, >>> coyim is not in bookworm. Did you want request removal from unstable? >> >> Correct. Just wanting to clean up my packages as at least coyim would >> surely just be accumulating bug reports from now :) > > Removals from unstable are handled by the FTP team. Reassigning. Oh, I see. Sorry for the noise! Cheers Sascha
Bug#994195: RM: coyim/0.3.8+ds-6
Hi Sebastian, [...] >> Coyim has not made it into buster and bullseye and I as the maintainer do not >> intend to invest more work into it. A RFA has been without response since >> January 2021 [1]. >> >> Hence I suggest to remove it and, once it is gone, also get rid of the >> obsolete >> dependencies that coyim currently is the only reverse dependency of in >> unstable. > > coyim is not in bookworm. Did you want request removal from unstable? Correct. Just wanting to clean up my packages as at least coyim would surely just be accumulating bug reports from now :) Cheers Sascha
Bug#994195: RM: coyim/0.3.8+ds-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove coyim. It has an RC bug [0] that will require various new dependencies and transitive dependencies, as upstream moved repositories and requires new versions. Some dependencies also do not build anymore when updated to newer upstream versions (e.g. gotk3). Coyim has not made it into buster and bullseye and I as the maintainer do not intend to invest more work into it. A RFA has been without response since January 2021 [1]. Hence I suggest to remove it and, once it is gone, also get rid of the obsolete dependencies that coyim currently is the only reverse dependency of in unstable. Cheers Sascha [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930332 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979755
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#991270: unblock: suricata/6.0.1-3
tags 991270 - moreinfo thanks Hi Graham, [...] > Please go ahead and upload to unstable, then remove the moreinfo tag > once it has built. Done. 6.0.1-3 is now built in unstable on all of the official archs that the previous version was built on. Cheers Sascha OpenPGP_signature Description: OpenPGP digital signature
Bug#991270: unblock: suricata/6.0.1-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package suricata
This minimal patch that I added fixes CVE-2021-35063 by backporting the
corresponding fix commit from upstream [1]. By doing so it addresses
#990835.
I have added a debdiff to this bugreport that illustrates the
situation. I could upload to unstable anytime. Please let me know if the
fix is appropriate and I will initiate an upload if confirmed.
Thanks
Sascha
[1]
https://github.com/OISF/suricata/commit/556570f7dd7f21f11cffda5ebcb72738a29cbb90
unblock suricata/6.0.1-3
diff -Nru suricata-6.0.1/debian/changelog suricata-6.0.1/debian/changelog
--- suricata-6.0.1/debian/changelog 2020-12-11 09:35:57.0 +0100
+++ suricata-6.0.1/debian/changelog 2021-07-19 13:26:22.0 +0200
@@ -1,3 +1,10 @@
+suricata (1:6.0.1-3) unstable; urgency=medium
+
+ * Address CVE-2021-35063 by backporting upstream fix.
+Closes: #990835
+
+ -- Sascha Steinbiss Mon, 19 Jul 2021 13:26:22 +0200
+
suricata (1:6.0.1-2) unstable; urgency=medium
* Also specify explicit separate '-latomic' reference on mipsel.
diff -Nru suricata-6.0.1/debian/patches/series
suricata-6.0.1/debian/patches/series
--- suricata-6.0.1/debian/patches/series2020-12-09 23:02:55.0
+0100
+++ suricata-6.0.1/debian/patches/series2021-07-19 13:26:22.0
+0200
@@ -9,3 +9,4 @@
remove-conflicting-python-file.patch
avoid-to-include-if_tunnel-h.patch
llc.patch
+stream-no-reject-bad-ack.patch
diff -Nru suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
--- suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
1970-01-01 01:00:00.0 +0100
+++ suricata-6.0.1/debian/patches/stream-no-reject-bad-ack.patch
2021-07-19 13:26:22.0 +0200
@@ -0,0 +1,30 @@
+From 556570f7dd7f21f11cffda5ebcb72738a29cbb90 Mon Sep 17 00:00:00 2001
+From: Eric Leblond
+Date: Fri, 28 May 2021 12:19:38 +0200
+Subject: [PATCH] stream/tcp: don't reject on bad ack
+
+Not using a packet for the streaming analysis when a non zero
+ACK value and ACK bit was unset was leading to evasion as it was
+possible to start a session with a SYN packet with a non zero ACK
+value to see the full TCP stream to escape all stream and application
+layer detection.
+
+This addresses CVE-2021-35063.
+
+Fixes: fa692df37 ("stream: reject broken ACK packets")
+
+Ticket: #4504.
+---
+ src/stream-tcp.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/src/stream-tcp.c
b/src/stream-tcp.c
+@@ -4789,7 +4789,6 @@
+ /* broken TCP
http://ask.wireshark.org/questions/3183/acknowledgment-number-broken-tcp-the-acknowledge-field-is-nonzero-while-the-ack-flag-is-not-set
*/
+ if (!(p->tcph->th_flags & TH_ACK) && TCP_GET_ACK(p) != 0) {
+ StreamTcpSetEvent(p, STREAM_PKT_BROKEN_ACK);
+-goto error;
+ }
+
+ /* If we are on IPS mode, and got a drop action triggered from
Bug#987297: [Debian-med-packaging] Bug#987297: Dependency to libpth20
Hi Yutaka and Andreas, thanks for bringing this to our attention. I'll take a look. Best regards Sascha On 21.04.21 08:51, Andreas Tille wrote: > Hi Yutaka, > > thanks for your verbose explanation. I think we'll do nothing in > current freeze time. But once freeze is over we can deal with this > quickly. In case we might forget simply raise severity of the bug > to create some signal. ;-) > > Kind regards > > Andreas. >
Bug#931477: Re: libhtp: Please replace Priority: extra with Priority: optional
> I will file a ticket to change the override soon. See #985816 [1] [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985816
Bug#985816: override: libhtp2:libs/optional
Package: ftp.debian.org Severity: normal This is in response to bug #931477 [1] dealing with libhtp being priority extra despite having set the Priority field in d/control years ago. Please change/remove the override to make libhtp compliant with the current policy and establish libhtp2 as priority optional. Thanks! Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931477
Bug#931477: (no subject)
Ahh, I think I see the issue now. There is an override that forces libhtp2 to be extra, in [1]. I think it will take a ftp.debian.org ticket to change it, there's nothing I can do in a simple upload. In the package itself the optional definition has already been done years ago. I will file a ticket to change the override soon. Cheers Sascha [1] http://ftp.debian.org/debian/indices/override.buster.main.gz
Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Hi, If you are wondering why there haven't been any updates lately, I am sad to announce that current versions of datatables.js does not build anymore with the old version of closure-compiler in Debian. >>> >>> Looks like it does not really need to use closure-compiler, so I >>> would suggest to instead use uglifyjs. >> >> I see. Do you think that would be safe to use as a replacement? Both >> would generate functionally equivalent minified JS, right? Ignoring >> slight size differences, of course -- the uglifyjs output is ~50KB >> larger than the closure-compiler one in a previous version. > > In theory closure-compiler and uglify-js perform same type of task, yes. [...] > Only way to know for sure is to test that resulting uglified code does > what it is supposed do to. Difficult, because the tool I initially needed it as a dependency for (aegean) does not use the minified version. But I can tweak the output to use that and see if the behaviour breaks -- it doesn't seem to really use much of the datatables functionality with the non-minified version anyway. So if it breaks in subtle ways I won't catch it. [...] >> So I think it would be quite doable to scrap closure-compiler here and >> switch to uglifyjs and sassc if you don't see any obvious reasons to >> abandon upstream's choice of tools. Given my limited expertise in JS >> best practices I would be happy to trust your advice :) > > I sure think uglifyjs is safer to use than *outdated* closure-compiler. > Just make sure to test the result as best you can. I wonder if there is anything that would allow me to easily test the behaviour without really knowing much about what is possible with datatables. I'll look at the other reverse deps when I find the time. > I even think that switching from outdated closure-compiler to uglifyjs > is a noble thing to do during soft-freeze - but that's your call! I think I'd rather stick with a not-so-fresh version that is built traditionally than shipping one I have not tested and does not use upstream's recommended tools. I'd prefer to postpone this till the next release. Unless there are volunteers... Cheers Sascha
Bug#983190: [Pkg-javascript-devel] Bug#983190: Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Hi again,
> However, I noticed that uglifyjs complains about the same line
> closure-compiler did:
>
> JS compressing dataTables.bulma.js
> Parse error at /tmp/jquery-datatables.23860.03SeC/dataTables.bulma.js:170,5
> let nav = $(' aria-label="pagination">
> ^
> SyntaxError: Unexpected token: name (nav)
> at JS_Parse_Error.get (eval at
> (/usr/lib/nodejs/uglify-js/tools/node.js:33:1), :84:23)
> at /usr/lib/nodejs/uglify-js/bin/uglifyjs:384:40
> at time_it (/usr/lib/nodejs/uglify-js/bin/uglifyjs:620:15)
> at /usr/lib/nodejs/uglify-js/bin/uglifyjs:345:9
> at FSReqCallback.readFileAfterClose [as oncomplete]
> (internal/fs/read_file_context.js:63:3)
Sorry, nevermind... I used the old "node-uglify" package instead of the
newer "uglifyjs" package. After switching to the latter to provide the
uglifyjs executable, I can process this file with no problems.
So looks like we've sorted this out :) I don't assume uploading and
updating with such changes would be acceptable in the soft freeze, would
it?
Cheers
Sascha
Bug#983190: [Pkg-javascript-devel] Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Hi Jonas,
great, thanks for your quick reply and the patch.
>> If you are wondering why there haven't been any updates lately, I am
>> sad to announce that current versions of datatables.js does not build
>> anymore with the old version of closure-compiler in Debian.
>
> Looks like it does not really need to use closure-compiler, so I would
> suggest to instead use uglifyjs.
I see. Do you think that would be safe to use as a replacement? Both
would generate functionally equivalent minified JS, right? Ignoring
slight size differences, of course -- the uglifyjs output is ~50KB
larger than the closure-compiler one in a previous version.
I also switched the old 'ruby-sass' dependency (which I understand is
deprecated) to sassc, which seems to work nicely.
However, I noticed that uglifyjs complains about the same line
closure-compiler did:
JS compressing dataTables.bulma.js
Parse error at /tmp/jquery-datatables.23860.03SeC/dataTables.bulma.js:170,5
let nav = $('
^
SyntaxError: Unexpected token: name (nav)
at JS_Parse_Error.get (eval at
(/usr/lib/nodejs/uglify-js/tools/node.js:33:1), :84:23)
at /usr/lib/nodejs/uglify-js/bin/uglifyjs:384:40
at time_it (/usr/lib/nodejs/uglify-js/bin/uglifyjs:620:15)
at /usr/lib/nodejs/uglify-js/bin/uglifyjs:345:9
at FSReqCallback.readFileAfterClose [as oncomplete]
(internal/fs/read_file_context.js:63:3)
Changing the 'let' to a 'var' here fixes the error, but I fail to see
why 'let' would be a problem here, syntactically. Any ideas?
So I think it would be quite doable to scrap closure-compiler here and
switch to uglifyjs and sassc if you don't see any obvious reasons to
abandon upstream's choice of tools. Given my limited expertise in JS
best practices I would be happy to trust your advice :)
Thanks and best wishes from the Debian Med sprint
Sascha
Bug#983190: datatables.js: upstream versions >1.10.21 do not build with Debian's closure-compiler
Source: datatables.js
Severity: normal
If you are wondering why there haven't been any updates lately, I am sad
to announce that
current versions of datatables.js does not build anymore with the old
version of
closure-compiler in Debian. So far (up to 1.10.21) I managed to keep it
building
but we now have reached a point where some of the features used by
upstream start
to confuse the parser to the point of bailing out.
This is a log of the build for the current latest upstream version:
DataTables build (1.10.23) - branch: master
JS
JSHint not installed at /usr/bin/jshint - skipping
JS compressing jquery.dataTables.js
File size: 83936
JS compressing dataTables.bootstrap5.js
File size: 2058
JS compressing dataTables.bootstrap4.js
File size: 2098
JS compressing dataTables.bootstrap.js
File size: 1979
JS compressing dataTables.bulma.js
/tmp/jquery-datatables.2247.HN3wa/dataTables.bulma.js:170: ERROR - Parse
error. missing ; before statement
let nav = $('');
^
[...]
CSS
CSS compressing dataTables.bootstrap5.css
Error: Invalid CSS after "both": expected expression (e.g. 1px, bold),
was ";"
on line 7 of
/build/datatables.js-1.10.23+dfsg/build/../built/css/dataTables.bootstrap5.css
Use --trace for backtrace.
File size: 0
I have seen #916145 and I am wondering what to do. Since I'm not a JS guy I
can't say if (or for how long) we might be able to patch our way around
this.
Otherwise it looks like we're going to be stuck with 1.10.21 for the
time being.
Cheers
Sascha
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916145
Bug#913227: dcmqrcbm.cc:319:38: warning: '%d' directive writing between 1 and 11 bytes into a region of size between 0 and 128
I assume this bug is obsolete, right? We already have 3.6.5 in testing and I do not see these warnings anymore in the i386 build logs. Cheers Sascha
Bug#913585: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'Sint32' {aka 'int'} [-Wformat=]
I assume this bug is obsolete, right? We already have 3.6.5 in testing and I do not see these warnings anymore in the i386 build logs. Cheers Sascha
Bug#970875: Bug#970875: mash: inconsistent results on 32 vs 64 bits architectures
Hi, >>> Should we tag this 'upstream'? >> >> Ah, good finding! Yes, I believe it would make sense to tag it >> upstream. > > Probably. However, what about providing it for 64bit architectures > only? I mean the practical relevance for 32 bit architectures is > very limited and I consider it burned developer time if we care > for something where we know it provides different results than > expected and is not used anyway. Yes, agreed. I would always be in favour of restricting archs and RM the rest -- but then again I don't have any stakes in anything non-amd64. Any other opinions? Cheers Sascha
Bug#980765: [Debian-med-packaging] Bug#980765: eigensoft: absolute path to fixgreen in /usr/bin/ploteig
Hi, > The bug system works by email, so I am forwarding this for filing there. > I'll also mark the bug fixed in a certain version because it looks like > the ploteig script disappeared at that point. Can this bug be closed then? I just checked the latest version (which is even in buster) and there seems to be no sign of ploteig script; I also did a quick grep through the source to confirm there are no more hard-coded references to np29's home directory. Cheers Sascha
Bug#970875: [Debian-med-packaging] Bug#970875: mash: inconsistent results on 32 vs 64 bits architectures
Hi, > While investigating FTBFS of `kleborate' on i386 and armhf, I > found out that `mash' seemed to output inconsistent results > depending on the underlying CPU architecture it is running on. [...] > Since the output obtained on amd64 is considered appropriate by > `kleborate' test suite, I heavily suspect that the result on > i386 should correspond to the results on amd64. The issue may > be repeatable on armhf, but haven't checked yet. It looks like, in general, results are known to be different between 64bit and 32bit archs. I've looked at reported issues upstream and found: https://github.com/marbl/Mash/issues/109 So I don't think this is necessarily a bug in Debian, we even address it in https://salsa.debian.org/med-team/mash/-/blob/master/debian/ Should we tag this 'upstream'? Cheers Sascha
Bug#980159: RFA: peframe -- open source tool to perform static analysis on PE malware
Package: wnpp Severity: normal I would like to put the peframe package up for adoption. PEframe is a tool to perform static analysis on Portable Executable (PE) malware and malicious MS Office documents. I myself am not longer a peframe user and with increasing work load recently I can not find the time to package the dependencies added by upstream in the latest version. That new version is required to add Python 3 support, the lack of which is also the reason why peframe is not in testing anymore (see #937269) In terms of dependencies, I have newly packaged python-virustotal-api (now in testing) but, for instance, python-oletools was a bit much due to its dependencies (I only did python-msoffcrypto-tool, which is also in testing now, others are still missing) and some embedded third-party code that still needs working out. I would be happy if someone who cares could take over. If no one speaks up in a couple of weeks or so, I will move on with orphaning peframe. 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#979871: RM: vast [arm64 ppc64el s390x] -- ROM; Builds but does not work on some archs
Package: ftp.debian.org Severity: normal Please remove the existing old (< 2020.12.16-4) packages for vast on non-amd64 architectures from unstable. I am the maintainer of that package. The code builds but will not work in a stable fashion. I have made upstream aware of this but they do not see it as a high priority issue as their current focus is amd64. Let's focus on the supported arch and get rid of the others to facilitate testing migration. Thanks Sascha
Bug#979755: RFA: coyim
Package: wnpp Severity: normal I would like to put the coyim package up for adoption. CoyIM is a XMPP (Jabber) chat client with built-in Tor support and privacy/security features. I myself am not longer a CoyIM user and with increasing work load recently I can not find the time to incorporate upstream's not-sooo-recent restructuring of their dependency repositories, which would require packaging new Go libraries and deprecating the old ones. This is golang-github-twstrike-gotk3adapter-dev and golang-github-twstrike-otr3-dev, whose newest versions (needed for the new coyim version) have been moved to different GitHub repos under the coyim organization instead of twstrike. This has led to coyim not even being in buster due to an unfixed RC bug (#930332) which would likely be fixed by updating to the latest upstream version (0.3.11). I would be happy if someone who cares can take over. If no one speaks up in a couple of weeks or so, I will move on with orphaning the package. Thanks Sascha
Bug#976601: rustc: version in buster fails to build Rust code, aborting with "undefined symbol: llvm.x86.subborrow.64"
Package: rustc Version: 1.41.1+dfsg1-1~deb10u1 Severity: normal Dear Maintainer, while trying to build the new 6.0.1 version of Suricata [1] with the current Rust toolchain in buster, I noticed that one of the Rust components in this project [2] fails to build. This can be reproduced on buster simply by: $ git clone https://github.com/rusticata/der-parser -b der-parser-4.x Cloning into 'der-parser'... remote: Enumerating objects: 61, done. remote: Counting objects: 100% (61/61), done. remote: Compressing objects: 100% (38/38), done. remote: Total 2154 (delta 31), reused 48 (delta 23), pack-reused 2093 Receiving objects: 100% (2154/2154), 516.92 KiB | 1.29 MiB/s, done. Resolving deltas: 100% (1396/1396), done. $ cd der-parser [satta@BLN04NB0421:~/der-parser] $ [satta@BLN04NB0421:~/der-parser] $ cargo build [der-parser-4.x] [0] Updating crates.io index Downloaded proc-macro-hack v0.5.19 Downloaded num-bigint v0.3.1 Downloaded nom v5.1.2 Downloaded num-integer v0.1.44 Downloaded lexical-core v0.7.4 Compiling autocfg v1.0.1 Compiling ryu v1.0.5 Compiling bitflags v1.2.1 Compiling memchr v2.3.4 Compiling lexical-core v0.7.4 Compiling version_check v0.9.2 Compiling cfg-if v0.1.10 Compiling arrayvec v0.5.2 Compiling static_assertions v1.1.0 Compiling proc-macro-hack v0.5.19 Compiling num-traits v0.2.14 Compiling num-integer v0.1.44 Compiling num-bigint v0.3.1 Compiling nom v5.1.2 Compiling rusticata-macros v2.1.0 Compiling der-oid-macro v0.2.0 (/home/satta/der-parser/der-oid-macro) Compiling der-parser v4.1.0 (/home/satta/der-parser) warning: unknown lint: `broken_intra_doc_links` --> src/lib.rs:142:9 | 142 | #![deny(broken_intra_doc_links)] | ^^ | = note: `#[warn(unknown_lints)]` on by default error: /home/satta/der-parser/target/debug/deps/libder_oid_macro-b8b90f0c61ae3277.so: undefined symbol: llvm.x86.subborrow.64 --> src/lib.rs:173:9 | 173 | pub use der_oid_macro::oid; | ^ error: aborting due to previous error error: could not compile `der-parser`. To learn more, run the command again with --verbose. Here's an upstream bug ticket regarding this issue: https://github.com/rusticata/der-parser/issues/36 Interestingly, the der-parser code mentioned above builds with the Debian Rust compiler package when built as part of the Suricata 6.0.0 tarball [3], in which it is vendored in the rust/ subdirectory, but fails with the above mentioned error when built as part of the vendored code in the Suricata 6.0.1 tarball [4]. No changes have been made to the vendored der-parser code between those two versions, so it might also be dependent on the mix of vendored crates in this context and how they might interact. Also, ARM builds do not seem to be affected, according to the upstream ticket. Could the recent move to 1.41.1+dfsg1-1~deb10u1 and the switch to LLVM 7 (see changelog) [5] be related? We also notice a mismatch between the cargo and Rust versions: $ which rustc /usr/bin/rustc $ rustc -V rustc 1.41.1 $ which cargo /usr/bin/cargo $ cargo -V cargo 1.42.1 If you have any more questions and I can help to clear them up, feel free to let me know! This currently blocks backporting Suricata 6.0.1 to buster with the current Rust version, and I start to suspect that some quirk in the current buster Rust package might be the problem. (Yes , there are some other things to sort out to get 6.0.x into unstable/testing first before this becomes an issue, but I just wanted to test the waters regarding the Rust ecosystem that is usually a bit sensitive when it comes to versions.) Thanks Sascha [1] https://suricata-ids.org [2] https://github.com/rusticata/der-parser [3] https://www.openinfosecfoundation.org/download/suricata-6.0.0.tar.gz [4] https://www.openinfosecfoundation.org/download/suricata-6.0.1.tar.gz [5] https://tracker.debian.org/news/1175959/accepted-rustc-1411dfsg1-1deb10u1-source-amd64-all-into-proposed-updates-stable-new-proposed-updates/ Versions of packages rustc depends on: ii binutils 2.34-5 ii gcc 4:8.3.0-1 ii libc6 2.30-4 ii libc6-dev [libc-dev] 2.30-4 ii libgcc-s1 [libgcc1] 10-20200411-1 ii libgcc1 1:8.3.0-6 ii libstd-rust-dev 1.41.1+dfsg1-1~deb10u1 Versions of packages rustc recommends: ii cargo 0.43.1-3~deb10u1 ii rust-gdb 1.41.1+dfsg1-1~deb10u1 Versions of packages rustc suggests: pn lld-7 pn rust-doc pn rust-src -- no debconf information
Bug#976183: ITP: golang-github-godbus-dbus -- Native Go bindings for D-Bus
Hi, > * Package name : golang-github-godbus-dbus > Version : 5.0.3-1 I believe this is already in Debian, via golang-dbus [1] Cheers Sascha [1] https://packages.debian.org/source/sid/golang-dbus
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#900808: python-pika: New version available
Hi all, > Version 0.11.2 is available. There is even 1.x.x available now, which broke API :( [1] Should we introduce a new source package, python-pika1, to reflect that and preserve the old API for the existing reverse deps: $ apt-rdepends -r python3-pika Reading package lists... Done Building dependency tree Reading state information... Done python3-pika Reverse Depends: python3-biomaj3-download (3.0.19-1) Reverse Depends: python3-biomaj3-process (3.0.11-1) Reverse Depends: python3-pika-pool (>= 0.1.3-4) Reverse Depends: threatbus-rabbitmq (2020.11.26-1) python3-biomaj3-download Reverse Depends: python3-biomaj3 (3.1.14-3) python3-biomaj3 Reverse Depends: python3-biomaj3-daemon (3.0.20-1) python3-biomaj3-daemon python3-biomaj3-process Reverse Depends: python3-biomaj3 (3.1.14-3) python3-pika-pool Any other ideas? Cheers Sascha [1] https://pika.readthedocs.io/en/stable/version_history.html
Bug#974925: actor-framework: Please provide a backport for buster
Source: actor-framework Severity: wishlist Dear Maintainer, in order to build VAST (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970505) for buster, I would like to request a backport of version 0.17.6. If you are not interested in doing it, I'd also be happy to upload such a backport. Just asking before... :) Cheers Sascha
Bug#973512: [Pkg-privacy-maintainers] Bug#973512: RuntimeError: dictionary keys changed during iteration
Hi Kingsley, Thanks for reporting this. I did some research and I assume this is referring to upstream ticket https://trac.torproject.org/projects/tor/ticket/32552, which seems to suggest that this deals with some issue touching Python 3.8+ and stem 1.7.x. […] > The main reason I'm writing is to suggest > improving the dependency info for the > onioncircuits package to specify at least version > 1.8.0-2 of the python3-stem package. I’d be happy to adjust the dependency since unstable recently adopted a new Python version and this makes it more likely for this issue to come up when sticking to 1.7.1. Cheers Sascha signature.asc Description: Message signed with OpenPGP
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#970505: ITP: vast -- network telemetry engine for data-driven security investigations
Package: wnpp Severity: wishlist Owner: Sascha Steinbiss * Package name: vast Version : 2020.08.28 Upstream Author : Tenzir GmbH * URL : https://github.com/tenzir/vast * License : BSD-3-clause Programming Lang: C++ Description : network telemetry engine for data-driven security investigations VAST is a distributed platform for high-performance network forensics and incident response that provides both continuous ingestion of voluminous event streams and interactive query performance. VAST leverages a native implementation of the actor model to scale both intra-machine across available CPU cores, and inter-machine over a cluster of commodity systems.
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#970284: flatbuffers: please backport flatbuffers to buster-backports
Source: flatbuffers Severity: wishlist Dear Maintainer, I would like to request a buster backport of flatbuffers. Thanks and best regards 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#970021: RFP: apache-arrow -- cross-language development platform for in-memory analytics
Package: wnpp Severity: wishlist * Package name: apache-arrow Version : 1.0.1 Upstream Author : The Apache Software Foundation * URL : https://arrow.apache.org * License : Apache 2.0 Programming Lang: C, C++, Java, Go, Python, ... Description : cross-language development platform for in-memory analytics Apache Arrow defines a language-independent columnar memory format for flat and hierarchical data, organized for efficient analytic operations on modern hardware. The Arrow memory format also supports zero-copy reads for fast data access without serialization overhead. Arrow's libraries implement the format and provide building blocks for a range of use cases, including high performance analytics.
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#962954: RM: fever [mipsel] -- ICE; FTBFS; Go compiler is broken on mipsel
Package: ftp.debian.org Severity: normal Please remove the old version of the fever binary package from testing for the mipsel architecture. Due to #960674, it currently does not build on mipsel as there is a deeper problem with the Go compiler on this architecture. Please see the corresponding bug report for more information [1]. I would like to remove this arch that currently blocks testing migration for upstream version updates. It is very unlikely that the package will be used on MIPS systems. Thanks! Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960674
Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel
Hi, first of all thanks for putting some energy into this issue! > FTR, after giving back golang-1.14 mipsel several times, it's finally > built, by a longson builder. > So I guess it only occurs on octeon. Since the porterbox eller is also > octeon, it also can't build any go program. So what does that mean for package building -- will the Octeon builders still be used long or short term? This impacts testing migration :/ Thanks Sascha
Bug#960674: golang-go: "fatal error: gc_trigger underflow" on mipsel
Package: golang-go Version: 2:1.14~1 Severity: important Dear Maintainer, the current go binary crashes on mipsel when running non-trivial calls (a trivial call would be like 'go version', which succeeds) with the message 'fatal error: gc_trigger underflow'. Here's an example from the mipsel porterbox: (sid_mipsel-dchroot)satta@eller:~$ go get github.com/satta/ethflux runtime: next_gc=5259264 heap_marked=292800 heap_live=292800 initialHeapLive=4210688triggerRatio=+0.00e+000 minTrigger=4194304 fatal error: gc_trigger underflow goroutine 20 [running]: runtime.throw(0xa3ebd3, 0x14) /usr/lib/go-1.14/src/runtime/panic.go:1116 +0x60 fp=0x1430578 sp=0x1430564 pc=0x43dfec runtime.gcSetTriggerRatio(0x0, 0x) /usr/lib/go-1.14/src/runtime/mgc.go:834 +0x804 fp=0x14305f4 sp=0x1430578 pc=0x41f208 runtime.gcMarkTermination(0x, 0x) /usr/lib/go-1.14/src/runtime/mgc.go:1686 +0x26c fp=0x1430770 sp=0x14305f4 pc=0x4203dc runtime.gcMarkDone() /usr/lib/go-1.14/src/runtime/mgc.go:1610 +0x240 fp=0x143079c sp=0x1430770 pc=0x4200a0 runtime.gcBgMarkWorker(0x1424000) /usr/lib/go-1.14/src/runtime/mgc.go:2000 +0x2d4 fp=0x14307e4 sp=0x143079c pc=0x4215bc runtime.goexit() /usr/lib/go-1.14/src/runtime/asm_mipsx.s:651 +0x4 fp=0x14307e4 sp=0x14307e4 pc=0x476fdc created by runtime.gcBgMarkStartWorkers /usr/lib/go-1.14/src/runtime/mgc.go:1821 +0xb0 goroutine 1 [runnable]: cmd/go/internal/str.FoldDup(0x190a000, 0x1a5, 0x300, 0x300, 0x9dec00, 0x15eb0a0, 0x9dec00) /usr/lib/go-1.14/src/cmd/go/internal/str/str.go:84 +0x140 cmd/go/internal/load.(*Package).load(0x18cc280, 0x15ebed4, 0x14ae820, 0x0, 0x0) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:1673 +0x6d4 cmd/go/internal/load.loadImport(0x0, 0x14b1171, 0x7, 0x14b33e0, 0x29, 0x14c6a00, 0x15ebed4, 0x16929e0, 0x1, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:578 +0xd88 cmd/go/internal/load.LoadImport(0x14b1171, 0x7, 0x14b33e0, 0x29, 0x14c6a00, 0x15ebed4, 0x16929e0, 0x1, 0x1, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:531 +0x88 cmd/go/internal/load.(*Package).load(0x14c6a00, 0x15ebed4, 0x14ae680, 0x0, 0x0) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:1707 +0x1a2c cmd/go/internal/load.loadImport(0x0, 0x14b6e21, 0x14, 0x14b6b00, 0x1b, 0x14c6780, 0x15ebed4, 0x1491b20, 0x1, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:578 +0xd88 cmd/go/internal/load.LoadImport(0x14b6e21, 0x14, 0x14b6b00, 0x1b, 0x14c6780, 0x15ebed4, 0x1491b20, 0x1, 0x1, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:531 +0x88 cmd/go/internal/load.(*Package).load(0x14c6780, 0x15ebed4, 0x14ae340, 0x0, 0x0) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:1707 +0x1a2c cmd/go/internal/load.loadImport(0x0, 0x14b0341, 0x6, 0x14b63a0, 0x1a, 0x14c6280, 0x15ebed4, 0x14ac6c0, 0x2, 0x2, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:578 +0xd88 cmd/go/internal/load.LoadImport(0x14b0341, 0x6, 0x14b63a0, 0x1a, 0x14c6280, 0x15ebed4, 0x14ac6c0, 0x2, 0x2, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:531 +0x88 cmd/go/internal/load.(*Package).load(0x14c6280, 0x15ebed4, 0x14ae1a0, 0x0, 0x0) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:1707 +0x1a2c cmd/go/internal/load.loadImport(0x0, 0x14b00a1, 0x5, 0x14b2090, 0x2b, 0x14c6000, 0x15ebed4, 0x1490360, 0x1, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:578 +0xd88 cmd/go/internal/load.LoadImport(0x14b00a1, 0x5, 0x14b2090, 0x2b, 0x14c6000, 0x15ebed4, 0x1490360, 0x1, 0x1, 0x1, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:531 +0x88 cmd/go/internal/load.(*Package).load(0x14c6000, 0x15ebed4, 0x14ae000, 0x0, 0x0) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:1707 +0x1a2c cmd/go/internal/load.loadImport(0x0, 0x7f6fb885, 0x18, 0x141a014, 0xb, 0x0, 0x15ebed4, 0x0, 0x0, 0x0, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:578 +0xd88 cmd/go/internal/load.LoadImport(0x7f6fb885, 0x18, 0x141a014, 0xb, 0x0, 0x15ebed4, 0x0, 0x0, 0x0, 0x0, ...) /usr/lib/go-1.14/src/cmd/go/internal/load/pkg.go:531 +0x88 cmd/go/internal/get.download.func1(0x7f6fb885, 0x18, 0x0, 0x3) /usr/lib/go-1.14/src/cmd/go/internal/get/get.go:233 +0xe4 cmd/go/internal/get.download(0x7f6fb885, 0x18, 0x0, 0x15ebed4, 0x0) /usr/lib/go-1.14/src/cmd/go/internal/get/get.go:305 +0xd84 cmd/go/internal/get.runGet(0xe36fa0, 0x1416110, 0x1, 0x2) /usr/lib/go-1.14/src/cmd/go/internal/get/get.go:162 +0x174 main.main() /usr/lib/go-1.14/src/cmd/go/main.go:189 +0x7a0 This also impacts mipsel builds of packages based on Go. I have tested this on three of my own packages, e.g. slinkwatch (see https://paste.debian.net/1146869/). Best regards Sascha
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#957811: slinkwatch: ftbfs with GCC-10
reassign 957811 golang-github-satta-ifplugo thanks On 17.04.20 13:11, Matthias Klose wrote: > Package: src:slinkwatch > Version: 1.1-2 > Severity: normal > Tags: sid bullseye > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-10 > [...] > # github.com/satta/ifplugo > /usr/bin/ld: > $WORK/b077/_x003.o:./obj-x86_64-linux-gnu/src/github.com/satta/ifplugo/interface.h:25: > multiple definition of `interface_do_message'; > $WORK/b077/_x002.o:/tmp/go-build/./obj-x86_64-linux-gnu/src/github.com/satta/ifplugo/interface.h:25: > first defined here > /usr/bin/ld: > $WORK/b077/_x003.o:./obj-x86_64-linux-gnu/src/github.com/satta/ifplugo/interface.h:24: > multiple definition of `interface_auto_up'; > $WORK/b077/_x002.o:/tmp/go-build/./obj-x86_64-linux-gnu/src/github.com/satta/ifplugo/interface.h:24: > first defined here > collect2: error: ld returned 1 exit status This is actually a cgo issue in another dependency, ifplugo. Reassigning bug report, fix to be uploaded. Thanks for noticing Sascha
Bug#954716: buster-pu: package suricata/1:4.1.2-2
fixed 951181 1:5.0.2-1 thanks Hi Adam, >> When you talk about bug metadata, are you just referring to a missing >> 'fixed' tag for #951181 along the lines of: >> >>fixed 951181 1:5.0.2-1 >> >> If so, I would be happy to provide that. > > Yes, exactly that. Sorry if it seems insignificant, but it provides a > much clearer view of what the state is across the suites. Sure, no problem. Done! Best regards Sascha
Bug#954716: buster-pu: package suricata/1:4.1.2-2
Hi Adam, thanks for taking a look at my proposed update. [...] >> Upstream has merged this patch already [1] and it has been included >> in the current version in unstable (5.0.2) [2] which the original >> patch author backported to 4.1.2 to allow fixing it in buster as >> well. >> >> The correponding bug in Debian is #951181 [3] -- it has the required >> severity of important and describes the issue in more detail. > > The metadata for that bug suggests that it still affects unstable, > which is contrary to your earlier comment above. Please could you > confirm the status of the issue in unstable, and add relevant fixed > versions to the bug if appropriate. I see. From my point of view it was clearly stated that the patch author (Timo Sigurdsson) had his fix accepted by upstream in version 5.0.2 (according to the changelog linked here [1]) which is currently in unstable [2]. When you talk about bug metadata, are you just referring to a missing 'fixed' tag for #951181 along the lines of: fixed 951181 1:5.0.2-1 If so, I would be happy to provide that. Thanks again and best regards Sascha [1] https://suricata-ids.org/2020/02/13/suricata-5-0-2-released/ [2] https://packages.debian.org/source/unstable/suricata signature.asc Description: OpenPGP digital signature
Bug#951181: suricata: Dropping privileges fails in nflog runmode - patch available
Hi Timo, [...] > I would appreciate if you could consider adding this patch to the suricata > package in the current stable release (buster) as the inabilitiy to drop root > privileges may have severe security implications and the patch itself is > trivial. Thanks for taking the time to think of stable! I have filed a bug report with the release team in regard to that [1]. Cheers Sascha [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954716
