Bug#1067349: closed by Dima Kogan (Done)

Thanks for pointing this out. There was a missing Depends, and I just pushed mrbuild=1.9-2 to fix that. Works for me in sbuild now.

Bug#1066959: sysdig: wrong runtime dependency on old falcosecurity binary

Gianfranco Costamagna writes: > Hello, for some reasons sysdig has an hardcoded runtime dependency on > libfalcosecurity0, now renamed in libfalcosecurity0t64. You can remove > it and let debhelper create it via shlibs:Depends automatically Thank you very much for catching and fixing this. The

Bug#1063051: vnlog: NMU diff for 64-bit time_t transition

Steve Langasek writes: > What I'm unclear on is why you don't run vnl-gen-header at build time > and output the "generated" header in the -dev package with a > comprehensive description of all the ABI entry points? Each user of libvnlog-dev would give different arguments to vnl-gen-header, and

Bug#1063051: vnlog: NMU diff for 64-bit time_t transition

Thanks for replying. I'll revert the changes. > ... however, I will say it's very strange to ship a shared library, > that has a public shlibs file, and has a -dev package that depends on > it, but the headers shipped in that -dev package are NOT the > authoritative api for that library? That's

Bug#1063051: vnlog: NMU diff for 64-bit time_t transition

Hi. vnlog does not depend on time_t. Is it too late to stop this update? The abi-compliance-checker failure is here: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libvnlog-dev/base/log.txt That error message says what the problem is: you are not supposed to #include

Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it

Hi. I'd like to get more clarity. - You see the issue when you try to plot anything at all? - You say "plot x" and you get a plot window, but it's all white, or something? - Only with the "qt" terminal? You can try to change your window manager, qt versions, etc, etc. If no trigger is found,

Bug#1062545: Processed: Re: falcosecurity-libs: NMU diff for 64-bit time_t transition

Oops. I was trying to save yall time, but I guess I didn't do it right. Please advise. Here's what happened, in order: - 0.14.1-3 was in the archive - 0.14.1-3.1 the NMU in experimental - 0.14.1-4 I fixed an unrelated bug; no time64 changes - 0.14.1-5 I added the time64 stuff to my

Bug#1061646: falcosecurity-libs: build-depends on unavailable libluajit-5.1-dev

Thanks for the note. 0.14.1-2 makes the build work on arm64, and I wanted to get that done, before thinking of other arches. I' about to apply your suggested patches.

Bug#1061049: libsuitesparse-dev: libsuitesparse-dev 7.4.0 has an ABI break in libcholmod5 without bumping to "libcholmod6"

Thanks. In case you're unaware, there're tools that can report ABI and API breaks. I usually use abi-compliance-checker (works great). And there's also abigail (have't tried it myself, but supposedly works well). Both are in Debian. Cheers.

Bug#1061049: libsuitesparse-dev: libsuitesparse-dev 7.4.0 has an ABI break in libcholmod5 without bumping to "libcholmod6"

Package: libsuitesparse-dev Version: 1:7.3.1+dfsg-2 Severity: serious X-Debbugs-Cc: none, Dima Kogan Hi. I'm chasing down http://bugs.debian.org/1060986 The problem is that mrcal uses libdogleg, which contains typedef struct { cholmod_common common

Bug#1041410: libdogleg-dev: missing Breaks+Replaces: libdogleg-doc (<< 0.16-2)

Thank you very much for the report. I completely forgot about these. Fixed just now.

Bug#1033678: installation-reports: Unbootable install: MBR partition unusable with UEFI

Package: installation-reports Severity: grave Hi. I just installed a bookworm candidate. This worked OK through partitioning and reboot, but I cannot boot into the system. This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA. I'm installing from a USB drive. To make this work, I

Bug#982864: More info

The issue is a failing test in test/run_tests.bash: head fish1.png > ${tmpdir}/fake.png "$pdiff" --verbose fish1.png ${tmpdir}/fake.png 2>&1 | grep -q 'Failed to load' rm -f ${tmpdir}/fake.png Here it's making sure that we are able to detect a corrupt .png file, and to throw an error. The

Bug#1027872: falcosecurity-libs: please switch to B-D: dh-sequence-dkms (or dh-dkms)

Hi. I was planning to get the new upstream release going, but I hit a bug in their build system that I don't have time to fix. The bug: shared objects are being built, but their "install" step tries to install static ones. I'm unlikely to have the time to fix this in the near future, so I'm just

Bug#1020818: abi-dumper: abi-dumper 1.2 doesn't work with today's binaries

Package: abi-dumper Version: 1.2-1 Severity: serious X-Debbugs-Cc: none, Dima Kogan Hi. abi-dumper doesn't work anymore. Build tools we ship today use DWARF 5, which abi-dumper 1.2 doesn't work with. There are reports about it: https://github.com/lvc/abi-dumper/issues/33 I see this when I

Bug#1020375: closing 1020375

close 1020375 thanks I uploaded 1.0+1git91f4b1-4 that explicitly state that no arch-indep tests are defined. This appears to have made the arch-indep builds happy

Bug#1014491: python3-torch: import fails: undefined symbol

Package: python3-torch Version: 1.8.1-5+b1 Severity: grave X-Debbugs-Cc: none, Dima Kogan Hi. Thanks for maintaining pytorch. I can't imagine the pain it took to get this packaged. Currently it doesn't work, unfortunately: $ python3 -mtorch Traceback (most

Bug#1014068: colmap: Application errors out at the start. Complains about logging

Package: colmap Version: 3.7-2+b1 Severity: grave X-Debbugs-Cc: Dima Kogan Hi. I just installed colmap. This happens: dima@shorty:$ colmap ERROR: something wrong with flag 'logtostderr' in file './src/logging.cc'. One possibility: file './src/logging.cc' is being linked both statically

Bug#1009173: libradare2-5.0.0: Missing (or maybe misnamed) shared objects make cutter not work

Package: libradare2-5.0.0 Version: 5.5.0+dfsg-1 Severity: grave X-Debbugs-Cc: Dima Kogan Hi. I have the latest radare2-cutter installed (1.12.0-1). It does this: $ Cutter Cutter: error while loading shared libraries: libr_core.so.5.0.0: cannot open shared object file: No such file

Bug#1001764: More info

Hi. Graham Inggs writes: > numpy 1:1.21.4-2 in testing is already built for python3.9 and 3.10 > [1]. Search for 'cpython-3' and you should find files like: > > /usr/lib/python3/dist-packages/numpy/core/_multiarray_tests.cpython-310-x86_64-linux-gnu.so >

Bug#1001764: More info

Hi. Thanks for the bug report. I'm not clear on how to reproduce this so that I can fix it. I installed python3.10, and asked the build system to use it. Instead of the error you're reporting, I get a build error: it can't find the numpy headers because python3-numpy is built for python3.9. This

Bug#997171: Patch

Here's a patch. After applying this I see the build complete successfully on sid. The patch is simple. Each failure was complaining about something like this: string xxx; printf(xxx.c_str()); The attached patch changes each failing instance to string xxx; printf("%s", xxx.c_str());

Bug#976053: Info received (sysdig-dkms is buildable with the latest upstream sources)

This bug makes sysdig unusable with the kernel in Bullseye. I'm going to do an NMU this coming weekend if I don't hear from you.

Bug#943512: closing 943512

close 943512 thanks I just tested the build of the latest release (4.0.1+dfsg-2) on i386, and it appears to build ok. I'm closing the bug. Please re-open if you continue to see it fail on your end.

Bug#957847: Fixed in git

I just fixed this in version control, but there's more to do, and I'm not releasing anything into the archive. https://salsa.debian.org/science-team/sundials/-/commit/dc8951dabd913d2cc4c259b5c5e59f90f4c60f26

Bug#957451: Patch

Here's a patch to fix the issue: diff --git a/src/libmawk/vio_fifo.h b/src/libmawk/vio_fifo.h index f170c22..a2d751d 100644 --- a/src/libmawk/vio_fifo.h +++ b/src/libmawk/vio_fifo.h @@ -14,7 +14,7 @@ typedef struct mawk_vio_fifo_s { int eof_from_app; /* 1 if there won't be more

Bug#966098: systemd: 'systemctl status' reports "access denied" after upgrade

Package: systemd Version: 245.6-3 Severity: grave X-Debbugs-Cc: none, Dima Kogan Hi. I'm running Debian/sid. Updating all the packages on my system put apt into a broken state: root@snarky:/home/dima# apt install at Reading package lists... Done Building dependency tree Reading

Bug#963583: sysdig: sysdig segfaults on start

Harlan Lieberman-Berg writes: > Would it be possible for you to use rr to capture a dump of the > segfault for me? I tried before filing the report; rr doesn't work with sysdig, apparently > Hm, this is strange. I've tested this a couple of different ways, > including on a clean sid box and a

Bug#963583: sysdig: sysdig segfaults on start

Package: sysdig Version: 0.26.7-2 Severity: grave Hi. sysdig used to work, but now it doesn't. I'm running Debian/sid, so probably something about my set of dependencies doesn't agree with sysdig, but we should figure out what that is. Earlier today I was seeing a segfault when running some

Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26

OK. I went through all the patches, and pushed a tree to git. Nicholas: I took most of your stuff, except I don't want to rename the package again. I'll move the repo to the emacs team this week, and we can do an upload. Nicholas: do you want to be an Uploader? And are you an emacs team member?

Bug#944249: [Pkg-emacsen-addons] Bug#944249: gnuplot-mode does not work with emacs26

Nicholas D Steeves writes: > Is that an official NACK for Augustin's patch for the autoloads? I > included it in the patch series I just sent... Hi. I tried out Augustin's update to the autoloads, and it works for me (thanks, Augustin!) Nicholas: you wanted to review and to improve things. Are

Bug#944249: gnuplot-mode does not work with emacs26

Thanks for the patches, Agustin. I just tried it out. Works for the most part. One thing that doesn't work for me is (gnuplot-mode) being executed when opening a .gp file. You added this to the package, and the dh-elpa machinery is creating the appropriate file:

Bug#944249: gnuplot-mode does not work with emacs26

Hi. It looks like the elpa-gnuplot-mode package is missing some of the debiany emacs machinery: the files in /usr/lib/emacsen-common/packages/... Somebody should look at the packaging, and figure out what we're missing and add it. Likely it's just a line or two somewhere. Nicholas: I'd be

Bug#925950: patches no longer apply for gcc-8 and gcc-9

Tobias Frost writes: > Control: tags -1 pending > >> My key situation should be resolved with the next keyring update, but >> this will take a few weeks probably. If it's useful to you, you >> should push the new package into the archive. > > I've uploaded your package to DELAYED/10. Let me know

Bug#925950: patches no longer apply for gcc-8 and gcc-9

close -1 thx Helmut Grohne writes: > Package: cross-gcc-dev > Version: 226 > Severity: serious > Tags: patch Hi Helmut. I had pushed updates that fixed this days ago, but apparently there were issues with my key, so the upload was silently ignored. If you build from source, you should get a

Bug#895320: Prototype fix

rom 307cd1529334cd4759fd7d4afd56ec279616f4f4 Mon Sep 17 00:00:00 2001 From: Dima Kogan Date: Sun, 10 Mar 2019 13:15:20 -0700 Subject: [PATCH] prototype fix for 895320 --- presentation/Makefile | 4 ++-- presentation/{my_prjs.dot => my_prjs1.dot} | 8 presentation/my

Bug#895320: (no subject)

reassign -1 mk-configure thanks Hi. I looked into this, and the conclusions are: - This is not an FTBFS for graphviz, but rather for mk-configure. The graphviz package builds just fine, but ... - The "dot" executable it produces has a bug: graphs spanning multiple pages contain incorrect

Bug#918855: debconf: Impossible to upgrade from 1.5.59 -> 1.5.69

Package: debconf Version: 1.5.69 Severity: serious Hi. I'm running a mostly-up-to-date Debian/sid system. I just tried updating it, and it barf at me when I ask it to update debconf: root@machine:~# aptitude install debconf The following NEW packages will be installed:

Bug#908553: more info

Hi. I cannot reproduce this. I talked to upstream. He can't reproduce it either, but he thinks this is related to the locale somehow. Can you try to run LANG=C pcb-rnd If you do that, does it still crash? Are you doing anything special with locales that would help us reproduce? Thanks.

Bug#878775: remake FTBFS on s390x: test failure

Adrian Bunk writes: > Source: remake > Version: 4.1+dbg1.3~dfsg.1-1 > Severity: serious > > https://buildd.debian.org/status/fetch.php?pkg=remake=s390x=4.1%2Bdbg1.3~dfsg.1-1=1508104983=0 > > ... > make check-local > make[3]: Entering directory '/<>/remake-4.1+dbg1.3~dfsg.1' > cd tests && perl

Bug#882934: Crash debugging

Joe writes: > OK, it does look like the graphics driver, then. I don't play games, so > I've never worried about it, and it looks like I'm using the > xserver-xorg-video-radeon driver. firmware-amd-graphics is installed. > > Should I try getting hold of the AMD binary

Bug#882934: Crash debugging

Joe <j...@jretrading.com> writes: > On Fri, 16 Mar 2018 16:42:43 -0700 > Dima Kogan <d...@secretsauce.net> wrote: > >> Can you try to run pcb without hardware acceleration? You can do this >> with >> >> LIBGL_ALWAYS_SOFTWARE=true pcb-gtk

Bug#882934: Crash debugging

Let's move this back to the bug list. Thanks for the debugging traces. I didn't see any smoking gun, but there're things I'd like to follow-up on to isolate the issue and then to hopefully allow me to reproduce it. 1. You have a customized gtk configuration that uses a theme no longer in

Bug#882934: pcb-gtk crash

Hi. Let's try to get to the bottom of this. Are you still experiencing the crash? My suspicion is that you have some shared library installed that's incompatible with some other component. You say you upgrade the whole system regularly? I'd like to see the list of shared libraries your pcb-gtk

Bug#881580: googleearth-package: Generated package is uninstallable, and application unrunnable

Package: googleearth-package Version: 1.2.2dima1 Severity: grave Hi. I'm installing googleearth on a recent Debian/sid on amd64. Clearly I need to have the i386 foreign arch enabled. It'd be nice if the install explicitly told unsuspecting users this, but whatever. The generated package

Bug#879774: cross-gcc-dev patches no longer apply to gcc-7 nor gcc-8

This actually applied to gcc-5,6,7 and 8. Fixed in version 154, just uploaded

Bug#857794: reportbug: crash when encountering some non-ASCII characters

On March 18, 2017 12:24:12 PM PDT, Evgeni Golov wrote: >Hi Dima, > >> Hi. I just tried to send an unblock, and reportbug crashed. Session: >> >> dima@scrawny:~$ sudo apt install reportbug >> ... >> Please enter the name of the package: geda-gaf >> Checking

Bug#857794: reportbug: crash when encountering some non-ASCII characters

Note: bug reports are publicly archived (including the email address of the submitter). Detected character set: us-ascii Please change your locale if this is incorrect. Using 'Dima Kogan <dko...@debian.org>' as your from address. Will send report to Debian (per lsb_rel

Bug#747141: [debhelper-devel] Bug#747141: ping

Niels Thykier writes: > The issue in geda-gaf cannot be solved in debhelper correctly. Please > have a look at #766711 to understand the reasoning. > > Basically: > * We can only support two style of binNMUs: arch:all -> arch:all OR >arch:any -> arch: any. Anything else

Bug#747141: ping

Dima Kogan <d...@secretsauce.net> writes: > how do we feel about the attached patch to debhelper? Here's a better patch: we use ${source:Version} for arch:all packages, but ${binary:Version} for arch:any packages diff --git a/dh_installdocs b/dh_installdocs index 9c82b5b4..4e6ba5

Bug#747141: ping

Hi. I just hit this with the geda-gaf source package, and it would be great if this was fixed, rather than remaining the hidden pitfall that it is now. The debian binNMU wiki page (https://wiki.debian.org/binNMU) suggests using ${source:Version} instead of ${binary:Version} to avoid this issue,

Bug#856705: closed by Ruben Undheim <ruben.undh...@gmail.com> (Bug#856705: fixed in graywolf 0.1.4+20170306gitecee764-1)

Debian Bug Tracking System writes: > This is an automatic notification regarding your Bug report > which was filed against the src:graywolf package: > > #856705: graywolf: License violation > > It has been closed by Ruben Undheim . Thanks for

Bug#856705: [dko...@debian.org: Bug#856705: graywolf: License violation]

Tim Edwards writes: > Well, it's pretty clear that the TimberWolf authors at Yale unabashedly > plaigerized out of Numerical Recipes for their thesis work. What you > found is not particularly difficult to work around, as the single-value > decomposition routines can

Bug#856706: cpl-plugin-sinfo: copyright violation

Source: cpl-plugin-sinfo Severity: serious Hi. cpl-plugin-sinfo is using some numerical routines from numerical recipes. These are NOT free software and may not be used in a free software project. For Debian, you can elide these sources. It would also be great if you talked to upstream so that

Bug#856705: graywolf: License violation

Source: graywolf Severity: serious Hi. graywolf is using some numerical routines from numerical recipes. These are NOT free software and may not be used in a free software project. For Debian, you can elide these sources. It would also be great if you talked to upstream so that they stop

Bug#856703: visp: License violation

Source: visp Severity: serious Hi. visp is using some numerical routines from numerical recipes. These are NOT free software and may not be used in a free software project. For Debian, you can elide these sources. It would also be great if you talked to upstream so that they stop violating

Bug#854905: Acknowledgement (libpetsc3.7.5-dev: Package uninstallable: libopenmpi-dev dependency unsatisfiable)

I should say that this is uninstallable in unstable only. stretch is fine.

Bug#854905: libpetsc3.7.5-dev: Package uninstallable: libopenmpi-dev dependency unsatisfiable

Package: libpetsc3.7.5-dev Severity: grave Hi. Currently libpetsc3.7.5-dev is uninstallable. Sbuild resolver says: missing: pkg: package: libpetsc3.7.5-dev version: 3.7.5+dfsg1-4 architecture: amd64 unsat-dependency: libopenmpi-dev:amd64 (< 2.0.2~git.20161226)

Bug#806092: proposed fix

I'm attaching two patches to fix this. Please review soon if possible. If I don't hear back by Dec 26, I'll NMU this. That's the latest possible day to meet the cutoff for stretch. >From 65bd793529cc6aae5f6f1946396cde03e55a2620 Mon Sep 17 00:00:00 2001 From: Dima Kogan <dko...@debian.org

Bug#774149: Cannot reproduce

Jürgen Braun writes: > I'm using Debian/Stable only, therefore I cannot test this on Debian/Sid. > My guess is, that there might be a change in ntfs-3g or systemd to fix this. Hmmm. If that is the case, then this bug can be closed, or at least reduced in severity, which would

Bug#774149: Cannot reproduce

Can somebody help me reproduce this bug? I'm using systemd (debian/sid) and am mounting an ntfs usb disk using ntfs-3g. It works fine and reliably with usbmount. Why am I not seeing breakage?

Bug#812636: cross-gcc-4.9-ppc64el: FTBFS - build-depends gcc-4.9-source (= 4.9.3-5) when 4.9.3-11 is current

Michael Tautschnig writes: > Package: cross-gcc-4.9-ppc64el > Version: 54 > Severity: serious > Usertags: goto-cc > > During a rebuild of all Debian packages in a clean sid chroot (using > cowbuilder > and pbuilder) the build failed with the following error. > > [...] > ->

Bug#784446: Fix pending

tags 784446 pending thanks Please see here for the fix: http://github.com/sukria/Backup-Manager/issues/67 An upload should hopefully happen in the new few weeks

Bug#789430: closing 789430

close 789430 thanks We update the toolchains as the libraries they use are updated. This was fixed a while back

Bug#766619: Popularity counts

Here're some numbers to support Wookey's point that the huge majority of users only care about gcc,g++ on arm*. Since July I've been running an unofficieal APT server to host these packages until they could make it into Debian proper. I built packages for these arches: - armel - armhf - mips -

Bug#749025: numptyphysics: Memory corruption at start of every level

Package: numptyphysics Version: 0.2+svn157-0.2 Severity: serious Hi. When finishing any level (clicking next in the dialog box), the application corrupts its memory and freezes. This is very consistent. I get something like this: dima@shorty:~$ numptyphysics loaded image

Bug#739215: More info

This has been reported in ubuntu and upstream: https://bugs.launchpad.net/ubuntu/+source/flumotion/+bug/1200954 https://code.flumotion.com/trac/ticket/1561 It sounds like upstream should stop using the deprecated API -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a

Bug#731673: update

I cannot reproduce the armel failure in a qemu chroot. I also cannot reproduce this failure on real armel hardware. I requested access to a Debian porterbox to see if the failure shows up there. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe.

Bug#731673: tcpflow: FTBFS: test failures on armel, sparc

Package: src:tcpflow Version: 1.4.0+repack1-1 Severity: serious As of tcpflow 1.4.3+repack1-1, everything builds except armel and sparc, which have test failures: https://buildd.debian.org/status/package.php?p=tcpflow -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a

Bug#729328: update

tags 729328 pending thanks The 1.4.3 upstream release has resolved this. Tested in a qemu chroot. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#730909: libpdl-linearalgebra-perl: FTBFS: Tests failed

gregor herrmann gre...@debian.org writes: Seems to be fixed in git with Dima's patch. Dima, is the package ready for upload (besides the lintian complaints about manpage problems)? It's almost ready. I'll ask you for an upload within the next day or two. dima -- To UNSUBSCRIBE, email to

Bug#725660: patch

I patched this and sent it upstream: https://github.com/simsong/be13_api/issues/5 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#701335: fix

This has been fixed upstream: http://sourceforge.net/p/pdl/code/ci/bc864bc43e1d04169d742c5c3c9015d04b75b374/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725630: tcpflow: FTBFS on all archs: error: impossible constraint in 'asm'

Thanks for catching this. The x86-only-asm issue has been fixed upstream in a not-yet-released tree. I cherry-picked the appropriate patches into debian/patches here: http://anonscm.debian.org/gitweb/?p=collab-maint/tcpflow.git;a=commit;h=7ee744dae5153cfa27b6464ac0d35b915dcc39d2 The kfreebsd

Bug#676885: libatlas3-base: Illegal instruction in dgetrf

Package: libatlas3-base Version: 3.8.4-6 Severity: grave Justification: renders package unusable I have a Core2 machine that doesn't have the latest FMA4 instructions. My understanding that the libatlas3-base package from unstable shouldn't be doing anything fancy and potentially cpu-specific