I just tried to revert from builds at
https://snapshot.debian.org/package/ipython/
8.29.0-1 is broken, but 8.20.0-1 works.
Package: ipython3
Version: 8.30.0-2
Severity: grave
Hi. I use ipython3 regularly. After a recent update it does not work
anymore:
dima@fatty:~$ ipython3
Traceback (most recent call last):
File "/usr/bin/ipython3", line 5, in
from IPython import start_ipython
File
Upstream fixed the issue, and I just uploaded a new package with the fix
https://github.com/falcosecurity/libs/issues/2333
https://github.com/falcosecurity/libs/pull/2337
close 1091157 20.39.4+dfsg-2
thanks
Bálint Réczey writes:
> How about marking i386 as unsupported and making this a wishlist bug?
> I'd be interested in building logray in wireshark, but can't until
> falcosecurity-libs migrates to testing and stays in good shape.
Hello. Done in 0.18.1-2.
In the latest release (0.18.1) the i386 tests don't crash anymore, but
some of them do fail:
https://buildd.debian.org/status/fetch.php?pkg=falcosecurity-libs&arch=i386&ver=0.18.1-1&stamp=1727846180&raw=0
Upstream is aware:
https://github.com/falcosecurity/libs/issues/1203#issuecomment-2387
Jochen Sprickerhof writes:
> There is also:
>
> https://github.com/PointCloudLibrary/clang-bind
> https://pypi.org/project/pcl-py/
> https://github.com/davidcaron/pclpy
Thank you for those links. They all look unmaintained and quite
unfriendly. Do you (or anybody else?) have plans to package any
Package: python3-pcl
Version: 0.3.0~rc1+dfsg-14+b2
Severity: serious
Hello!
python3-pcl doesn't build with Python3.12: it throws many Cython errors.
I looked briefly, and fixing them appears non-trivial, at least to those
with no prior cython experience.
Upstream is dead:
https://github.com/st
close 1074271
thanks
I built and uploaded i386 binaries.
close 1074271
thanks
Rebuilt and re-uploaded for amd64 in version 1.4.3-6
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.
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 f
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 w
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
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 vn
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,
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 unrelated
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.
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.
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 c
Thank you very much for the report. I completely forgot about these.
Fixed just now.
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
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
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 g
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 t
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
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
Trace
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' i
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 or
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
> /usr/lib/python3/dist-packages/numpy/co
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 m
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());
dif
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.
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.
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
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 from
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
Re
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
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 older
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? Yo
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
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:
/etc/emacs/site-start.d/50elpa-gn
ings that
could be messed up, and then we'd have to fix them. It's not worth the
effort, I think.
Feel free to add yourself to the Uploaders, if you want to.
dima
your package to DELAYED/10. Let me know if I should
> accelerate it or if I should remove it from the DELAYED queue.
Hi Tobias. Helmut (Cc-ed) is the main user of these packages, so he's
the person to ask. I suspect that it doesn't matter a whole lot.
Thanks for the upload.
dima
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 us
u.
>From 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
prese
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 po
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:
libau
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.
Adrian Bunk writes:
> Source: remake
> Version: 4.1+dbg1.3~dfsg.1-1
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=remake&arch=s390x&ver=4.1%2Bdbg1.3~dfsg.1-1&stamp=1508104983&raw=0
>
> ...
> make check-local
> make[3]: Entering directory '/<>/remake-4.1+dbg1.3~dfsg.1'
>
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 driver? It's onboard
> graph
Joe writes:
> On Fri, 16 Mar 2018 16:42:43 -0700
> Dima Kogan wrote:
>
>> Can you try to run pcb without hardware acceleration? You can do this
>> with
>>
>> LIBGL_ALWAYS_SOFTWARE=true pcb-gtk
>
> Yes, that fixes it. A quick test suggests it is ru
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 Debia
current directory.
If I could get a copy of that file, that'd be very useful. It might be
quite large so maybe emailing that wouldn't be ideal. Maybe hold off on
this, and just send me the output of the two ldd commands above.
Thanks much for helping us debug!
dima
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 Depends:l
This actually applied to gcc-5,6,7 and 8. Fixed in version 154, just
uploaded
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
Package: reportbug
Version: 7.1.5
Severity: grave
Dear Maintainer,
-- Package-specific info:
** Environment settings:
EDITOR="emacs"
PAGER="less"
DEBEMAIL="dko...@debian.org"
** /home/dima/.reportbugrc:
reportbug_version "7.1.1"
mode standard
ui text
an easily-missed warning
- The error message has a link to this and related bugs
Currently dh_installdocs throws an error if compat != 9. Is it
acceptable to make it fail even for compat == 9?
Thanks for your work on this.
dima
Dima Kogan 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..4e6ba5d5 100755
--- a/dh_installdo
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, so
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 taking care of this. You rock.
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 be found in the GNU Scientif
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 th
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 violatin
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 copyrig
I should say that this is uninstallable in unstable only. stretch is
fine.
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)
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
Da
On 15/11/16 21:01, Dmitry Smirnov wrote:
On Monday, 31 October 2016 8:48:30 AM AEDT Dima Barsky wrote:
Thanks for your help, I'm going to apply your changes to the newly
released esniper 2.32.0. I'll upload it a couple of days.
More than two weeks passed... Would you like me to
On 29/10/16 15:52, Dmitry Smirnov wrote:
Hi Dima,
I've prepared esniper updates for to upload:
https://anonscm.debian.org/cgit/collab-maint/esniper.git
I intend to upload soon... Please review. Thanks.
Hi Dmitry,
Thanks for your help, I'm going to apply your changes to
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 allow usbmount to r
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?
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.
>
> [...]
> -> Considering build-dep
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
close 789430
thanks
We update the toolchains as the libraries they use are updated. This was fixed a
while back
d a solution that makes everybody happy, INCLUDING users.
dima
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
3
package, I'll investigate.
Regards,
Dima.
On Sat, Oct 18, 2014 at 09:28:15PM +0200, martin f krafft wrote:
> Package: esniper
> Version: 2.30.0-1
> Severity: grave
>
> esniper no longer works and if it stays this way, it should not be
> part of jessie, hence grave bu
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
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
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".
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 s
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
gregor herrmann 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 UNSUBS
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
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
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 issu
ree, &three, A, &three,
ipiv, &info);
printf("info: %d\n", info);
return 0;
}
Session that shows the issue, with some useful diagnostics:
dima@shorty:/tmp$ gcc-4.7 -llapack -o tst tst.c
dima@shorty:/tmp$ ./tst
zsh: illegal hardware instruction (core dump
> As you wrote that you are still logged into it you should be able to do
> the following:
>
> $ cd /lib
> $ echo ld*
>
>
Here is is:
$ echo ld*
ld-2.2.5.so ld-linux.so.1.8.10 ld-linux.so.2 ld.so ld.so.1.8.10
ftp.de.debian.org
> But the system has been updated on Debian Unstable since Debian Woody
> (and moved from PC to PC, from harddisk to harddisk, without reinstall).
>
Mine is also quite old, I've been running unstable for the last 10 years.
Regards,
Dima.
> Thanks. To be clear, that means you are also on i386 and also trigger
> the "! "bad dynamic tag"" assertion on upgrade from 2.13-4 to 2.13-5?
That's right.
I'm still logged into the box remotely, but I can not start any new
processes.
Regards,
Dima.
Just to confirm that Sven is not alone, I was hit by the same bug.
in /usr/local/bin? Assuming you are using bash, could you run
"type esniper" and show me the result?
Regards,
Dima.
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
h...@s:~$ esniper -v
> esniper version 2.18.1
>
Is it possible the you have an older version of esniper installed somewhere,
for example in /usr/local/bin? Assuming you are using bash, could you run
"type esniper" and show me the result?
Regards,
Dima.
--
To UNSUBSCRIBE, em
94 matches
Mail list logo
