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 "/usr/lib/pyth
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
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 del
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
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
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 i
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-gaf
>> Checking status database...
>>
t prompts. ***
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 ' as your from address.
Will send report to Debian (per lsb_relea
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 will break.
> * Co
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
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
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
- mip
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 /usr/share/numptyphys
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 UNSUBSCRIBE, email to debian-bugs-rc
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
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 unle
85 matches
Mail list logo
