Bug#1067349: closed by Dima Kogan (Done)

[Dima Kogan]

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

[Dima Kogan]

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 falco ABIs weren't
obviously stable earlier, but that might be better now, so hopefully we
can get away without a versioned dependency. I'll ask falco upstream
about stability in a bit.

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

[Dima Kogan]

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 would get a different generated header file. So
there isn't a single generated header I can produce when building the
vnlog packages.

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

[Dima Kogan]

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 how I did it, and while it sounds odd, I believe this is right.
The public interface is

  vnl-gen-header ... > generated.h

and

  #include "generated.h"

The generated header contains some user-facing macros that call the
functions in vnlog.h with specific arguments. That's the API. From the
compiler's perspective, the functions declared in vnlog.h are the
interface, and the ABI in those symbols must be stable, and putting them
into the .symbols file is appropriate. Let me know if I'm doing
something wrong.

Thanks

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

[Dima Kogan]

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 vnlog.h directly. Instead you're supposed to use the
"vnl-gen-header" tool (also in the "libvnlog-dev" package) to produce
usable headers that themselves #include vnlog.h. For instance:

  vnl-gen-header 'int w' 'uint8_t x' 'char* y' 'double z' > 
vnlog_fields_generated.h

If you then run vnlog_fields_generated.h (which, again, #includes
vnlog.h) through abi-compliance-checker, you'll see that it passes.
vnl-gen-header doesn't support any time-related types, so this is y2k38
safe.

Thanks.

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

[Dima Kogan]

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, it would be good to bisect the gnuplot sources to find
the cause. Are you able to do that? I cannot reproduce at the moment, so
I cannot do it myself.

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

[Dima Kogan]

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 bug fix

So what should we do to get both the bug fix in -4 and the time64 stuff?

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

[Dima Kogan]

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"

[Dima Kogan]

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"

[Dima Kogan]

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;

  } dogleg_solverContext_t;

The existing "libdogleg2" package was built against libsuitesparse-dev
7.3, so it must be linked with packages that use that ABI. But in
suitesparse 7.4 the cholmod_common structure has a new member at the
end:

FILE *blas_dump ;  // only used if CHOLMOD is compiled with -DBLAS_DUMP

This is in CHOLMOD/Include/cholmod.h

This extra member changes sizeof(cholmod_common), which changes the ABI,
causing the crash. One way to fix this is to bump the SONAME of
libcholmod.

Thanks.

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

[Dima Kogan]

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

[Dima Kogan]

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 had to turn off
secure-boot and UEFI in the BIOS. I believe that the result of this is
the Debian partitioner defaulted to an MBR partition, not a GPT
partition.

The BIOS of this laptop only allows booting from the PCIe SSD in UEFI
mode (so I need to change the BIOS setting before even trying). But even
after that, the machine doesn't let me boot off that disk. Some
searching tells me this is because GPT partitions are required for UEFI
booting, but Debian made an MBR partition.

I'm not 100% sure of the exact cause. But I suspect strongly is that
booting the install media without UEFI broke installing to an UEFI-only
disk.

Thanks.

Bug#982864: More info

[Dima Kogan]

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 actual image load is being done by
libfreeimage. For whatever reason, on amd64 (and other non-breaking
platforms) FreeImage_Load() returns NULL when given this corrupt file,
which is what the test expects. But on the failing platforms it throws a
c++ exception instead. The test doesn't catch this exception and
crashes, causing this FTBFS.

I tried to catch this exception nicely with the attached patch, but for
some reason it doesn't work. Since this problem isn't in the main part
of the library, we should simply disable this particular test to resolve
the FTBFS and this RC bug.

If I don't hear back in a few days, I'm going to do an NMU with this
patch.

Thanks.

diff --git a/rgba_image.cpp b/rgba_image.cpp
index 2ba9a67..b91407c 100644
--- a/rgba_image.cpp
+++ b/rgba_image.cpp
@@ -147,10 +147,17 @@ namespace pdiff
 }
 
 FIBITMAP *free_image = nullptr;
-if (auto temporary = FreeImage_Load(file_type, filename.c_str(), 0))
+try
 {
-free_image = FreeImage_ConvertTo32Bits(temporary);
-FreeImage_Unload(temporary);
+if (auto temporary = FreeImage_Load(file_type, filename.c_str(), 0))
+{
+free_image = FreeImage_ConvertTo32Bits(temporary);
+FreeImage_Unload(temporary);
+}
+}
+catch (...)
+{
+throw RGBImageException("Failed to load the image " + filename);
 }
 if (not free_image)
 {
diff --git a/test/run_tests.bash b/test/run_tests.bash
index 757a164..2b25c29 100755
--- a/test/run_tests.bash
+++ b/test/run_tests.bash
@@ -84,10 +84,6 @@ rm -f diff.png
 ls ${tmpdir}/diff.png
 rm -f ${tmpdir}/diff.png
 
-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
-
 mkdir -p ${tmpdir}/unwritable.png
 "$pdiff" --output ${tmpdir}/unwritable.png --verbose fish{1,2}.png 2>&1 | grep -q 'Failed to save'
 rmdir ${tmpdir}/unwritable.png

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

[Dima Kogan]

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 going to upload the current release + your changes. Will do that
later today, hopefuly.

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

[Dima Kogan]

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 try to use it with my code:

  Reading debug-info
  ERROR: invalid debug_loc section of object, please fix your elf utils
  ERROR: missed type id 4202
  ERROR: missed type id 6541

Fortunately the upstream git repo already has a fix:

  
https://github.com/lvc/abi-dumper/commit/16bb467cd7d343dd3a16782b151b56cf15509594

But upstream went silent last year, and there's no new release that
includes this patch. Can we distro-patch it?

Upstream bug report asking for a new release, untoutched since Jan:

  https://github.com/lvc/abi-dumper/issues/34

Thanks!

Bug#1020375: closing 1020375

[Dima Kogan]

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

[Dima Kogan]

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 recent call last):
File "/usr/lib/python3.10/runpy.py", line 187, in _run_module_as_main
  mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.10/runpy.py", line 146, in _get_module_details
  return _get_module_details(pkg_main_name, error)
File "/usr/lib/python3.10/runpy.py", line 110, in _get_module_details
  __import__(pkg_name)
File "/usr/lib/python3/dist-packages/torch/__init__.py", line 196, in 

  from torch._C import *
  ImportError: /usr/lib/x86_64-linux-gnu/libtorch_cpu.so.1.8: undefined symbol: 
_ZN4onnx12optimization8OptimizeERKNS_10ModelProtoERKSt6vectorINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESaISA_EE

This symbol is missing. I looked around, and I can't figure out which
package was supposed to provide it. Without it the linking fails, and
the package is unusable. Am I missing some dependency?


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python3-torch depends on:
ii  libc6   2.33-7
ii  libdnnl22.6-1
ii  libgcc-s1   12.1.0-4
ii  libgloo00.0~git20220518.5b14351-1
ii  libgoogle-glog0v6   0.6.0-1
ii  libonnx11.12.0-1
ii  libprotobuf23   3.12.4-1+b2
ii  libstdc++6  12.1.0-4
ii  libtorch-test   1.8.1-5+b1
ii  libtorch1.8 1.8.1-5+b1
ii  python3 3.10.4-1+b1
ii  python3-future  0.18.2-5
ii  python3-numpy [python3-numpy-abi9]  1:1.21.5-1
ii  python3-pkg-resources   59.6.0-1
ii  python3-requests2.25.1+dfsg-2
ii  python3-six 1.15.0-2
ii  python3-typing-extensions   3.10.0.2-1
ii  python3-yaml5.4.1-1+b1
ii  python3.10  3.10.5-1

Versions of packages python3-torch recommends:
ii  build-essential  12.9
pn  libtorch-dev 
ii  ninja-build  1.10.1-1
pn  pybind11-dev 

Versions of packages python3-torch suggests:
ii  python3-hypothesis  5.43.3-1
ii  python3-pytest  6.2.5-1

-- no debconf information

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

[Dima Kogan]

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 and 
dynamically into this executable.

Thanks.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages colmap depends on:
ii  libc6  2.33-1
ii  libceres2  2.0.0+dfsg1-5
ii  libfreeimage3  3.18.0+ds2-6
ii  libgcc-s1  11.2.0-13
ii  libgl1 1.3.4-2+b1
ii  libglew2.2 2.2.0-4
ii  libgomp1   11.2.0-13
ii  libgoogle-glog0v6  0.6.0-1
ii  libqt5core5a   5.15.2+dfsg-14
ii  libqt5gui5 5.15.2+dfsg-14
ii  libqt5widgets5 5.15.2+dfsg-14
ii  libstdc++6 12-20220302-1

colmap recommends no packages.

colmap suggests no packages.

-- no debconf information

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

[Dima Kogan]

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 directory

  $ ldd `which Cutter`

  ...
  libr_core.so.5.0.0 => not found
  libr_fs.so.5.0.0 => not found
  libr_debug.so.5.0.0 => not found
  ...

So the Cutter tool is looking for the radare2 libraries version 5.0.0.
This package is called "libradare2-5.0.0", so it's a reasonable
expectation to find those libraries there. As expected, radare2-cutter
has Depends: libradare2-5.0.0

But this package doesn't contain those libraries. It has instead

  $ dpkg -L libradare2-5.0.0 | grep libr_

  /usr/lib/x86_64-linux-gnu/libr_anal.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_asm.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_bin.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_bp.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_config.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_cons.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_core.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_crypto.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_debug.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_egg.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_flag.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_fs.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_hash.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_io.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_lang.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_magic.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_main.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_parse.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_reg.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_search.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_socket.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_syscall.so.5.5.0
  /usr/lib/x86_64-linux-gnu/libr_util.so.5.5.0

I.e. it has packages version 5.5.0, not 5.0.0. I'm filing this bug here
and not against radare2-cutter, because THIS package has "5.0.0" in the
package name and "5.5.0" in the filenames.

Thanks




-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (800, 'unstable'), (700, 'testing'), (500, 'unstable-debug'), 
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf

Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf-8, LC_CTYPE=en_US.utf-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.utf-8), LANGUAGE=en_US.utf-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libradare2-5.0.0 depends on:
ii  libc6  2.33-1
ii  libcapstone4   4.0.2-5
ii  liblz4-1   1.9.3-2
ii  libmagic1  1:5.41-2
ii  libradare2-common  5.5.0+dfsg-1
ii  libuv1 1.42.0-1
ii  libxxhash0 0.8.0-2
ii  libzip41.7.3-1
ii  zlib1g 1:1.2.11.dfsg-2

libradare2-5.0.0 recommends no packages.

libradare2-5.0.0 suggests no packages.

-- no debconf information

Bug#1001764: More info

[Dima Kogan]

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/core/_multiarray_tests.cpython-39-x86_64-linux-gnu.so

Strange. I had a new version installed (1:1.21.4-3), and it only had
python 3.9 files in there. An even newer python3-numpy ws just uploaded,
and it has both 3.9 and 3.10. So I'm good there.


>> What do I need to install to reproduce this bug?
>
> You should be able to reproduce this with all packages from unstable,
> or all packages from testing and only packages built from
> src:python3-defaults from unstable, e.g. python3, python3-all ,etc.
> Follow the links in the unstable and testing columns [2], and note the
> 'Trigger/Pinned packages' column on the testing page.

OK. mrgingham currently will build for only ONE python version: the one
that runs when you invoke "python3". You're saying that I should build
for ALL the versions that "py3versions" reports, yes? And all the
resulting binaries should go into the python3-mrgingham package, yes?

Thanks.

Bug#1001764: More info

[Dima Kogan]

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 makes sense.

What do I need to install to reproduce this bug?

Thanks.

Bug#997171: Patch

[Dima Kogan]

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());


diff --git a/userspace/libsinsp/cursescomponents.cpp b/userspace/libsinsp/cursescomponents.cpp
index 4003cb4e..9a9138d4 100644
--- a/userspace/libsinsp/cursescomponents.cpp
+++ b/userspace/libsinsp/cursescomponents.cpp
@@ -877,6 +877,7 @@ void curses_textbox::print_no_data()
 	string wstr = "No Data For This Selection";
 	mvprintw(m_parent->m_screenh / 2,
 		m_parent->m_screenw / 2 - wstr.size() / 2,
+"%s",
 		wstr.c_str());
 
 	refresh();
@@ -1100,6 +1101,7 @@ void curses_textbox::render()
 		attrset(m_parent->m_colors[sinsp_cursesui::LARGE_NUMBER]);
 		mvprintw(0,
 			m_parent->m_screenw / 2 - wstr.size() / 2,
+"%s",
 			wstr.c_str());
 	}
 
diff --git a/userspace/libsinsp/cursesspectro.cpp b/userspace/libsinsp/cursesspectro.cpp
index 6858bc95..fddc09cf 100644
--- a/userspace/libsinsp/cursesspectro.cpp
+++ b/userspace/libsinsp/cursesspectro.cpp
@@ -227,6 +227,7 @@ void curses_spectro::print_error(string wstr)
 	mvwprintw(m_tblwin, 
 		m_parent->m_screenh / 2,
 		m_parent->m_screenw / 2 - wstr.size() / 2, 
+"%s",
 		wstr.c_str());	
 }
 
diff --git a/userspace/libsinsp/cursestable.cpp b/userspace/libsinsp/cursestable.cpp
index 69c2aa32..6fef5a4c 100644
--- a/userspace/libsinsp/cursestable.cpp
+++ b/userspace/libsinsp/cursestable.cpp
@@ -254,6 +254,7 @@ void curses_table::print_line_centered(string line, int32_t off)
 		mvwprintw(m_tblwin, 
 			m_parent->m_screenh / 2 + off,
 			m_parent->m_screenw / 2 - line.size() / 2, 
+"%s",
 			line.c_str());
 	}
 	else
@@ -268,6 +269,7 @@ glogf("2, %d %s\n", spos, ss.c_str());
 			mvwprintw(m_tblwin, 
 m_parent->m_screenh / 2 + off + j,
 0,
+"%s",
 ss.c_str());
 
 			spos += m_parent->m_screenw;
@@ -328,6 +330,7 @@ void curses_table::print_error(string wstr)
 	mvwprintw(m_tblwin, 
 		m_parent->m_screenh / 2,
 		m_parent->m_screenw / 2 - wstr.size() / 2, 
+"%s",
 		wstr.c_str());	
 }
 
diff --git a/userspace/libsinsp/cursesui.cpp b/userspace/libsinsp/cursesui.cpp
index 1eeb0864..2427e54d 100644
--- a/userspace/libsinsp/cursesui.cpp
+++ b/userspace/libsinsp/cursesui.cpp
@@ -825,6 +825,7 @@ void sinsp_cursesui::render_header()
 		attrset(m_colors[sinsp_cursesui::LARGE_NUMBER]);
 		mvprintw(0,
 			m_screenw / 2 - wstr.size() / 2, 
+"%s",
 			wstr.c_str());	
 	}
 
@@ -1123,7 +1124,7 @@ void sinsp_cursesui::render_filtersearch_main_menu()
 
 		m_cursor_pos = cursor_pos;
 
-		mvprintw(m_screenh - 1, m_cursor_pos, str->c_str());
+		mvprintw(m_screenh - 1, m_cursor_pos, "%s", str->c_str());
 
 		m_cursor_pos += str->size();
 	}
@@ -2189,6 +2190,7 @@ void sinsp_cursesui::print_progress(double progress)
 	string wstr = "Processing File";
 	mvprintw(m_screenh / 2,
 		m_screenw / 2 - wstr.size() / 2, 
+"%s",
 		wstr.c_str());	
 
 	//
@@ -2199,6 +2201,7 @@ void sinsp_cursesui::print_progress(double progress)
 	wstr = "Progress: " + string(numbuf);
 	mvprintw(m_screenh / 2 + 1,
 		m_screenw / 2 - wstr.size() / 2, 
+"%s",
 		wstr.c_str());
 
 	refresh();
@@ -2308,6 +2311,7 @@ sysdig_table_action sinsp_cursesui::handle_textbox_input(int ch)
 		attrset(m_colors[sinsp_cursesui::FAILED_SEARCH]);
 		mvprintw(m_screenh / 2,
 			m_screenw / 2 - wstr.size() / 2, 
+"%s",
 			wstr.c_str());	
 
 		//
@@ -2363,6 +2367,7 @@ sysdig_table_action sinsp_cursesui::handle_textbox_input(int ch)
 
 	mvprintw(m_screenh / 2,
 		m_screenw / 2 - wstr.size() / 2, 
+"%s",
 		wstr.c_str());
 
 	render();
@@ -2436,6 +2441,7 @@ sysdig_table_action sinsp_cursesui::handle_textbox_input(int ch)
 
 mvprintw(m_screenh / 2,
 	m_screenw / 2 - wstr.size() / 2, 
+"%s",
 	wstr.c_str());
 
 render();

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

[Dima Kogan]

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

[Dima Kogan]

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

[Dima Kogan]

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

[Dima Kogan]

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 the app or the 
app won't accept more data */
 } mawk_vio_fifo_t;
 
-const mawk_vio_imp_t mawk_vio_fifo_imp;
+extern const mawk_vio_imp_t mawk_vio_fifo_imp;
 
 mawk_vio_t *mawk_vio_fifo_open(mawk_state_t *MAWK, const char *name, 
mawk_vio_open_mode_t mode);
 

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

[Dima Kogan]

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 state information... Done
  You might want to run 'apt --fix-broken install' to correct these.
  The following packages have unmet dependencies:
   at : Depends: libfl2 (>= 2.5.33) but it is not going to be installed
  E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or 
specify a solution).

  root@snarky:/home/dima# apt install libfl2
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  The following package was automatically installed and is no longer required:
linux-image-4.9.0-8-amd64
  Use 'sudo apt autoremove' to remove it.
  The following additional packages will be installed:
at
  The following NEW packages will be installed:
libfl2
  The following packages will be upgraded:
at
  1 upgraded, 1 newly installed, 0 to remove and 41 not upgraded.
  30 not fully installed or removed.
  Need to get 0 B/152 kB of archives.
  After this operation, 153 kB of additional disk space will be used.
  Do you want to continue? [Y/n] y
  Reading changelogs... Done
  Selecting previously unselected package libfl2:amd64.
  (Reading database ... 208134 files and directories currently installed.)
  Preparing to unpack .../libfl2_2.6.4-8_amd64.deb ...
  Unpacking libfl2:amd64 (2.6.4-8) ...
  Preparing to unpack .../at_3.1.23-1+b1_amd64.deb ...
  Failed to reload daemon: Access denied
  Failed to retrieve unit state: Access denied
  Failed to stop atd.service: Access denied
  See system logs and 'systemctl status atd.service' for details.
  invoke-rc.d: initscript atd, action "stop" failed.
  dpkg: warning: old at package pre-removal script subprocess returned error 
exit status 1
  dpkg: trying script from the new package instead ...
  Failed to reload daemon: Access denied
  Failed to retrieve unit state: Access denied
  Failed to stop atd.service: Access denied
  See system logs and 'systemctl status atd.service' for details.
  invoke-rc.d: initscript atd, action "stop" failed.
  dpkg: error processing archive 
/var/cache/apt/archives/at_3.1.23-1+b1_amd64.deb (--unpack):
   new at package pre-removal script subprocess returned error exit status 1
  Failed to reload daemon: Access denied
  Failed to reload daemon: Access denied
  Failed to retrieve unit state: Access denied
  Failed to start atd.service: Access denied
  See system logs and 'systemctl status atd.service' for details.
  invoke-rc.d: initscript atd, action "start" failed.
  Failed to get properties: Access denied
  dpkg: error while cleaning up:
   installed at package post-installation script subprocess returned error exit 
status 1
  Errors were encountered while processing:
   /var/cache/apt/archives/at_3.1.23-1+b1_amd64.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  dima@snarky:~$ sudo apt remove at
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  The following package was automatically installed and is no longer required:
linux-image-4.9.0-8-amd64
  Use 'sudo apt autoremove' to remove it.
  The following packages will be REMOVED:
at
  0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
  30 not fully installed or removed.
  After this operation, 161 kB disk space will be freed.
  Do you want to continue? [Y/n] 
  dpkg: error processing package at (--remove):
   package is in a very bad inconsistent state; you should
   reinstall it before attempting a removal
  dpkg: too many errors, stopping
  Errors were encountered while processing:
   at
  Processing was halted because there were too many errors.
  E: Sub-process /usr/bin/dpkg returned an error code (1)

  dima@snarky:~# dpkg -r at
  dpkg: error processing package at (--remove):
   package is in a very bad inconsistent state; you should
   reinstall it before attempting a removal
  Errors were encountered while processing:
   at

  dima@snarky:~# dpkg -r --force-all at
  dpkg: warning: overriding problem because --force enabled:
  dpkg: warning: package is in a very bad inconsistent state; you should
   reinstall it before attempting a removal
  (Reading database ... 208134 files and directories currently installed.)
  Removing at (3.1.23-1) ...
  Failed to reload daemon: Access denied
  Failed to retrieve unit state: Access denied
  Failed to stop atd.service: Access denied
  See system logs and 'systemctl status atd.service' for details.
  invoke-rc.d: initscript atd, action "stop" failed.
  dpkg: error processing package at (--remove):
   installed at package pre-removal script subprocess returned error exit 
status 1
  Failed to reload daemon: Access denied
  Failed to reload

Bug#963583: sysdig: sysdig segfaults on start

[Dima Kogan]

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 sid box with libc downgraded to the
> same version as on your machine, but I can't recreate the error.

Well, this isn't satisfying. I just ran an experiment, trying to see if
gcc-10 had any hand in this. The kernel module is compiled locally on
the user's box (gcc-10 here, presumably), but the userspace is built by
the Debian boxes (gcc-9) presumably. I just did this:

1. Check out the sysdig sources from upstream. Same tag as the version
   of the Debian package I have.

2. Build sysdig (userspace + kernel) from source with my default
   compiler (gcc-10). This takes forever because it insists on building
   all of its dependencies. There was a small build issue with the
   bundled libgrpc++ that I fixed; it isn't interesting.

3. I installed the just-built kernel module, and ran the just-built
   sysdig tool. No segfault

4. I installed the built-from-package kernel module, that was part of
   the crashing runs earlier, and ran the just-built sysdig tool. No
   segfault

5. I installed the built-from-package kernel module, that was part of
   the crashing runs earlier, and ran the packaged sysdig tool. No
   segfault

#5 is this bug report, but this thing works now. I can't break it
anymore. I haven't installed or removed any packages between now and
when it was broken, so I can't explain this. I should also say that
sysdig was unusable on this box for months, AND I confirmed the segfault
before filing this report, so this bug report wasn't based on a one-off
failure or anything. During those months I did rebuild/rmmod/modprobe
the kernel module several times, and that didn't fix anything.

Let me dogfood this for a few days, and if I consistently can't
reproduce the failure I'll close this bug.

Sorry for the noise

Bug#963583: sysdig: sysdig segfaults on start

[Dima Kogan]

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 sysdig
package I had installed. I just upgraded sysdig and sysdig-dkms to the
latest version available:

  $ dpkg -l 'sysdig*'

  ii  sysdig 0.26.7-2 amd64 ...
  ii  sysdig-dkms0.26.7-2 all   ...

And then I got this:

  $ sudo sysdig ...
  sysdig: symbol lookup error: sysdig: undefined symbol: 
_ZN9grpc_impl23CreateCustomChannelImplERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEERKSt10shared_ptrINS_18ChannelCredentialsEERKNS_16ChannelArgumentsE

This sounds like #955279, but even if it is, there should be a
Conflicts, or something, to prevent me from getting into that state. In
any case, I just

  $ sudo apt install libgrpc++-dev

and also upgraded everything that sysdig explicitly depends on, except libc6.

And now it segfaults again:

  $ sudo sysdig
  zsh: segmentation fault  sudo sysdig

The backtrace looks like this:

  #0  0x5575c7cdd210 in sinsp_parser::reset (this=0x5575c8474ac0, 
evt=0x5575c8454ce0) at ./userspace/libsinsp/parsers.cpp:717
  #1  0x5575c7ce3f3d in sinsp_parser::process_event (this=0x5575c8474ac0, 
evt=evt@entry=0x5575c8454ce0) at ./userspace/libsinsp/parsers.cpp:125
  #2  0x5575c7cfa8c9 in sinsp::next (this=0x5575c8454c50, 
puevt=0x7ffd28e5b0b8) at ./userspace/libsinsp/sinsp.cpp:1290
  #3  0x5575c7c016fc in do_inspect (inspector=0x5575c8454c50, 
cnt=18446744073709551615, duration_to_tot_ns=0, quiet=false, json=, do_flush=false, print_progress=false, display_filter=0x0, 
summary_table=std::vector of length 0, capacity 0, 
  formatter=0x7ffd28e5b4e0) at ./userspace/sysdig/sysdig.cpp:604
  #4  0x5575c7c04877 in sysdig_init (argc=, argv=) at ./userspace/sysdig/sysdig.cpp:1596
  #5  0x5575c7bf1fcc in main (argc=, argv=0x7ffd28e5b788) at 
./userspace/sysdig/sysdig.cpp:1694

This is inside the sysdig binary itself. No obvious cause. We're doing
this:

 0x5575c7cdd208 <+920>:   callq  0x5575c7c2dd20 

 0x5575c7cdd20d <+925>:   mov(%rax),%rax
  => 0x5575c7cdd210 <+928>:   mov(%rax),%rax
 0x5575c7cdd213 <+931>:   test   %rax,%rax
 0x5575c7cdd216 <+934>:   jns0x5575c7cdd220 


$rax isn't too crazy-looking, but we can't reference it:

  (gdb) p /x $rax
  $3 = 0x7f3406bcb6ba

  (gdb) x /32xb $rax
  0x7f3406bcb6ba: Cannot access memory at address 0x7f3406bcb6ba

I don't know if $rip is AT the offending instruction of the instruction
right after the offending instruction. So not entirely sure if rax is
parinfo or parinfo->m_val. Anyway...

Notes:

1. I upgraded everything sysdig Depends: on except libc6. Upgrading that
   would force me to upgrade my python, and that makes me touch stuff
   I'd rather not touch right now

2. I have gcc-10 installed, so that's where the libgcc... and
   libstdc++... are coming from

Is this enough info?

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64, armhf

Kernel: Linux 4.17.0-1-amd64 (SMP w/20 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages sysdig depends on:
ii  libb64-0d1.2-5+b1
ii  libc62.30-2
ii  libcurl4 7.68.0-1
ii  libelf1  0.176-1.1
ii  libgcc-s110.1.0-4
ii  libgrpc++1   1.26.0-3
ii  libjq1   1.6-1
ii  libjsoncpp1  1.7.4-3.1
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.1
ii  libncurses6  6.2-1
ii  libprotobuf223.11.4-5
ii  libssl1.11.1.1g-1
ii  libstdc++6   10.1.0-4
ii  libtbb2  2020.2-2
ii  libtinfo66.2-1
ii  zlib1g   1:1.2.11.dfsg-2

Versions of packages sysdig recommends:
ii  sysdig-dkms  0.26.7-2

sysdig suggests no packages.

-- no debconf information

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

[Dima Kogan]

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? You can then get rights to write to the repo. And if you want
to, you can prepare the final package that I'll then upload for you.

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

[Dima Kogan]

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 your patches somewhere we can see them?

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

[Dima Kogan]

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-gnuplot-mode.el

I don't think this is being evaluated, however. Is it working for you?
Do you know at which point in the emacs startup sequence this is
sourced? Is it always supposed to be sourced? What about 'emacs -q'? Or
'emacs -Q'?

Thanks

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

[Dima Kogan]

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 delighted if you fix this. Thanks for stepping up! I
don't think you need to do any NMUs to become a DD. Those happen when a
package needs to be fixed, but its maintainer is not available for
whatever reason (NMU = non-maintainer upload). And until you're a DD you
can't upload anything yourself anyway.

You should work on the issue, and when you're done, let me know. I'll
take a look, and then I can do the upload for you.

The location of this package is a historical artifact. It was originally
team-maintained in collab-maint. Then when it was converted (as it turns
out unsuccessfully) to a debian elpa-... package, it was moved to the
emacs team (by changing the Maintainer field). But we didn't move the
repo. I'd rather leave it where it is: there's little downside to
leaving it, and if we do move it, there're a lot of little things 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

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

[Dima Kogan]

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 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

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

[Dima Kogan]

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 usable package:

  debcheckout cross-gcc-dev
  cd cross-gcc-dev
  dpkg-buildpackage

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.

Thanks for the report.

Bug#895320: Prototype fix

[Dima Kogan]

A prototype patch is attached. This splits up the offending .dot file
into two separate .dot files, each with a single graph. The package then
builds. Please double-check this. You'd need to ship this as a patch in
debian/patches. Let me know if you'd like me to finish this as an nmu.


>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 
 presentation/my_prjs2.dot  | 7 +++
 presentation/presentation.tex  | 5 -
 4 files changed, 13 insertions(+), 11 deletions(-)
 rename presentation/{my_prjs.dot => my_prjs1.dot} (85%)
 create mode 100644 presentation/my_prjs2.dot

diff --git a/presentation/Makefile b/presentation/Makefile
index cdafd80..fb621dc 100644
--- a/presentation/Makefile
+++ b/presentation/Makefile
@@ -13,7 +13,7 @@ dvi : presentation.dvi
 
 .SUFFIXES: .ps .eps .pdf .dvi .tex .dot
 
-presentation.ps presentation.pdf presentation.dvi: my_prjs.eps dep_graph.eps
+presentation.ps presentation.pdf presentation.dvi: my_prjs1.eps my_prjs2.eps dep_graph.eps
 
 .ps.pdf:
 	${PROG.${PS2PDF}} "$<" "$@"
@@ -44,6 +44,6 @@ clean-garbage:
 myprojects.tex : presentation.tex
 	awk '/^%%%begin-myprojects/, /^%%%end-myprojects/' \
 		${.ALLSRC} > ${.TARGET}
-myprojects.ps myprojects.pdf myprojects.dvi: my_prjs.eps
+myprojects.ps myprojects.pdf myprojects.dvi: my_prjs1.eps my_prjs2.eps
 
 .include 
diff --git a/presentation/my_prjs.dot b/presentation/my_prjs1.dot
similarity index 85%
rename from presentation/my_prjs.dot
rename to presentation/my_prjs1.dot
index e2bcfe0..14a799c 100644
--- a/presentation/my_prjs.dot
+++ b/presentation/my_prjs1.dot
@@ -42,11 +42,3 @@ digraph FSA {
"pipestatus" -> "pkg_summary-utils";
 
 }
-
-digraph FSA {
- graph [ ratio=compress layout=dot rankdir=UB ratio=0.4 ];
-
- node [ shape = hexagon style=filled fontsize=20 ];
-   "lua-alt-getopt";
-   "judyhash";
-}
diff --git a/presentation/my_prjs2.dot b/presentation/my_prjs2.dot
new file mode 100644
index 000..d4639cc
--- /dev/null
+++ b/presentation/my_prjs2.dot
@@ -0,0 +1,7 @@
+digraph FSA {
+ graph [ ratio=compress layout=dot rankdir=UB ratio=0.4 ];
+
+ node [ shape = hexagon style=filled fontsize=20 ];
+   "lua-alt-getopt";
+   "judyhash";
+}
diff --git a/presentation/presentation.tex b/presentation/presentation.tex
index 0a388f3..449dc44 100644
--- a/presentation/presentation.tex
+++ b/presentation/presentation.tex
@@ -1256,7 +1256,10 @@ hello: ELF 64-bit MSB executable, SPARC V9, relaxed
   \begin{block}{My opensource projects using
   mk-configure (filled hexagon), Mk files (box) and others (oval)}
 \begin{figure}
-  \includegraphics[width=\textwidth, height=0.60\textheight, keepaspectratio=false]{my_prjs.eps}
+  \includegraphics[width=\textwidth, height=0.60\textheight, keepaspectratio=false]{my_prjs1.eps}
+\end{figure}
+\begin{figure}
+  \includegraphics[width=\textwidth, height=0.60\textheight, keepaspectratio=false]{my_prjs1.eps}
 \end{figure}
 %\begin{figure}
 %  \includegraphics[width=0.7\textwidth, height=0.10\textwidth, keepaspectratio=false]{my_prjs2.eps}
-- 
2.20.0.rc2

Bug#895320: (no subject)

[Dima Kogan]

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 postscript

- This is an upstream bug in graphviz. I have a prototype patch that
  fixes it. We need a workaround for mk-configure, and I'll try to get
  something working in the near future. If somebody wants to beat me to
  it, please feel free.


Description of bug and patch:

Let's say you have my_prjs.dot, attached in an earlier post in this
report. You run

  dot -Tps my_prjs.dot > my_prjs.eps

As reported earlier, my_prjs.eps is bogus because gs barfs at it:

  $ ps2pdf my_prjs-sid.eps
  Error: /undefined in setupLatin1
  Operand stack:

  Execution stack:
 %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1999   1   3   %oparray_pop   
1998   1   3   %oparray_pop   1982   1   3   %oparray_pop   1868   1   3   
%oparray_pop   --nostringval--   %errorexec_pop   .runexec2   --nostringval--   
--nostringval--   --nostringval--   2   %stopped_push   --nostringval--
  Dictionary stack:
 --dict:982/1684(ro)(G)--   --dict:0/20(G)--   --dict:78/200(L)--
  Current allocation mode is local
  Current file position is 15221
  GPL Ghostscript 9.20: Unrecoverable error, exit code 1


Looking at the my_projs.eps file, its structure is

1. A chunk written by psgen_begin_job() in
plugin/core/gvrender_core_ps.c:

  %!PS-Adobe-3.0
  %%Creator: graphviz version ...
  ...

2. A chunk that comes from plugin/core/ps.txt, written by
psgen_begin_graph() in plugin/core/gvrender_core_ps.c:

  %%Title: ...
  ...
  %%BeginProlog
  /DotDict 200 dict def
  DotDict begin

  /setupLatin1 { ... } bind def
  ...

  setupLatin1


Note that this defines the setupLatin1 function, and it then calls this
function

3. There is no psgen_end_graph()

4. A chunk that comes from psgen_end_job()

  %%Trailer
  %%Pages: 1
  %%BoundingBox: 36 36 975 418
  end
  restore
  %%EOF

Note that this undefineds the setupLatin1 function

5. At this point steps 2,3,4 repeat for each page, with some omissions.
The immediate next chunk is

  setupLatin1

This comes from psgen_begin_graph() again, but it doesn't re-define
setupLatin1

This is the source of the complaint: we're calling an undefined
function.



This is only an issue when touching .dot files that have more than one
graph. Two solutions are possible:

1. Don't clean up as much after each page, so that the setupLatin1
   function remains defined

2. Perform more initialization at the start of each page, to redefine
   setupLatin1 each time

A simple proof-of-concept fix to implement solution 2 is to modify
psgen_begin_graph() in plugin/core/gvrender_core_ps.c to change

  if (job->common->viewNum == 0) {

to

  if (true) {

This if() statement served to prevent redefining setupLatin1 (and a
whole lotta other stuff), and this fix redefines it each time.

Solution 1 is probably better, but it involves touching more code, and
I'd rather upstream did that. Laszlo: as the graphviz Debian maintainer,
can you please forward this upstream?

Thanks.

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

[Dima Kogan]

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:
  libauthen-sasl-perl{a} libdata-dump-perl{a} libencode-locale-perl{a} 
libfile-listing-perl{a} libfont-afm-perl{a} libgdbm-compat4{a} 
libhtml-form-perl{a} libhtml-format-perl{a} libhtml-parser-perl{a} 
libhtml-tagset-perl{a} 
  libhtml-tree-perl{a} libhttp-cookies-perl{a} libhttp-daemon-perl{a} 
libhttp-date-perl{a} libhttp-message-perl{a} libhttp-negotiate-perl{a} 
libio-html-perl{a} libio-socket-ssl-perl{a} liblwp-mediatypes-perl{a} 
  liblwp-protocol-https-perl{a} libmailtools-perl{a} libnet-http-perl{a} 
libnet-smtp-ssl-perl{a} libnet-ssleay-perl{a} libperl5.28{a} 
libtext-unidecode-perl{a} libtry-tiny-perl{a} libwww-perl{a} 
libwww-robotrules-perl{a} 
  libxml-libxml-perl{a} libxml-namespacesupport-perl{a} 
libxml-parser-perl{a} libxml-sax-base-perl{a} libxml-sax-expat-perl{a} 
libxml-sax-perl{a} perl-modules-5.28{ab} perl-openssl-defaults{a} 
python3-apt{a} python3-debconf{a} 
  tex-common{a} 
The following packages will be upgraded:
  apt-listchanges debconf perl perl-base{b} texinfo 
5 packages upgraded, 40 newly installed, 0 to remove and 37 not upgraded.
Need to get 0 B/12.8 MB of archives. After unpacking 49.9 MB will be used.
The following packages have unmet dependencies:
 perl-base : Breaks: perl-modules (< 5.28.1~) but 5.20.1-1 is installed
 debconf-i18n : Depends: debconf (= 1.5.59) but 1.5.69 is to be installed
 perl-modules-5.28 : Conflicts: perl-modules (< 5.22.0~) but 5.20.1-1 is 
installed
 libfcgi-perl : Depends: perlapi-5.20.0 which is a virtual package, 
provided by:
 - perl-base (5.20.1-1), but 5.28.1-3 is to be 
installed

 liblocale-gettext-perl : PreDepends: perlapi-5.20.0 which is a virtual 
package, provided by:
  - perl-base (5.20.1-1), but 5.28.1-3 
is to be installed

 libperl5.20 : Depends: perl-base (= 5.20.1-1) but 5.28.1-3 is to be 
installed
 libtext-soundex-perl : Depends: perlapi-5.20.0 which is a virtual package, 
provided by:
 - perl-base (5.20.1-1), but 5.28.1-3 is to 
be installed

 libio-pty-perl : Depends: perlapi-5.20.0 which is a virtual package, 
provided by:
   - perl-base (5.20.1-1), but 5.28.1-3 is to be 
installed

 libtext-iconv-perl : Depends: perlapi-5.20.0 which is a virtual package, 
provided by:
   - perl-base (5.20.1-1), but 5.28.1-3 is to 
be installed

 libtext-charwidth-perl : Depends: perlapi-5.20.0 which is a virtual 
package, provided by:
   - perl-base (5.20.1-1), but 5.28.1-3 is 
to be installed

The following actions will resolve these dependencies:

  Remove the following packages:  
1)  libperl5.20 [5.20.1-1 (now)]  
2)  perl-modules [5.20.1-1 (now)] 

  Install the following packages: 
3)  libpython3.7 [3.7.2-1 (unstable)] 
4)  libtcl8.6 [8.6.9+dfsg-1 (unstable)]   

  Upgrade the following packages: 
5)  debconf-i18n [1.5.59 (now) -> 1.5.69 (unstable)]  
6)  libfcgi-perl [0.77-1+b1 (now) -> 0.78-2+b3 (unstable)]
7)  libio-pty-perl [1:1.08-1+b4 (now) -> 1:1.08-1.1+b5 (unstable)]
8)  liblocale-gettext-perl [1.05-8+b1 (now) -> 1.07-3+b4 (unstable)]  
9)  libtext-charwidth-perl [0.04-7+b3 (now) -> 0.04-7.1+b1 (unstable)]
10) libtext-iconv-perl [1.7-5+b2 (now) -> 1.7-5+b7 (unstable)]
11) libtext-soundex-perl [3.4-1+b2 (now) -> 3.4-1+b7 (unstable)]  
12) znc [1.4-1+b2 (now) -> 1.7.1-2+b3 (unstable)] 
13) znc-perl [1.4-1+b2 (now) -> 1.7.1-2+b3 (unstable)]
14) znc-python [1.4-1+b2 (now) -> 1.7.1-2+b3 (unstable)]  
15) znc-tcl [1.4-1+b2 (now) -> 1.7.1-2+b3 (unstable)] 



Accept this solution? [Y/n/q/?] 
The following NEW packages will be installed:
  libauthen-sasl-perl{a} libdata-dump-perl{a} libencode-locale-perl{a} 
libfile-listing-perl{a} libfont-afm-perl{a} libgdbm-compat4{a} 
libhtml-form-perl{a} libhtml-format-perl{a} libhtml-parser-perl{a} 
libhtml-tagset-perl{a} 
  libhtml-tree-perl{a} libhttp-cookies-perl{a} libhttp-daemon-perl{a} 
libhttp-date-perl{a} libhttp-message-perl{a} libhttp-negotiate-perl{a} 
libio-html-perl{a} libio-socket-ssl-perl{a} liblwp-mediatypes-perl{a} 

Bug#908553: more info

[Dima Kogan]

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

[Dima Kogan]

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 -I . ./run_make_tests.pl -srcdir 
> /<>/remake-4.1+dbg1.3~dfsg.1 -make ../make
> --
>Running tests for GNU make on Linux zandonai 4.9.0-4-s390x s390x
>  GNU Make 4.1+dbg1.3
> --
>
> Finding tests...
>
> features/archives ... N/A
> features/comments ... ok (1 passed)
> features/conditionals ... ok (4 passed)
> features/default_names .. ok (3 passed)
> features/double_colon ...
> Test timed out after 5 seconds
> Error running /<>/remake-4.1+dbg1.3~dfsg.1/tests/../make (expected 
> 0; got 14): /<>/remake-4.1+dbg1.3~dfsg.1/tests/../make -f 
> work/features/double_colon.mk bar

I just tried a number of times on zelenka, another s390x porterbox. I
can't reproduce this failure. Any pointers?

Bug#882934: Crash debugging

[Dima Kogan]

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
> graphics on a Gigabyte MB, about seven years old.

I found a machine with a radeon gpu. Like yours it's a desktop with an
onboard gpu, and it's about the same vintage even. I tried running with
the "ati" X driver and the "radeon" kernel driver, and things appear to
work ok; nothing crashes.

My GPU is

  01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] Park [Mobility Radeon HD 5430] [1002:68e1]

X happily loads the drivers, and things work for me, but our
configurations probably don't match up. What does your 'lspci -nn' say,
and do you have the "radeon" kernel module loaded, and what does
'glxinfo' say, and what does 'dpkg -l "xserver-xorg-video-*"' say and
can I get a copy of the /var/log/Xorg.0.log ?

If you don't care anymore, and want me to go away, tell me that too :)

Bug#882934: Crash debugging

[Dima Kogan]

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
>
> Yes, that fixes it. A quick test suggests it is running OK.
>
> 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
> graphics on a Gigabyte MB, about seven years old.

That's interesting; glad we narrowed down the problem. I don't have any
ATI hardware, so can't reproduce this. I'm assuming no other
applications crash like this? I'm wondering if pcb is doing something
different from other programs.

Can I please get the versions of your graphics driver packages (ones you
mentioned above), and the hardware IDs:

  lspci -nn | grep VGA

Not entirely sure what I can do with that, but it'd be good to have.
I'll try to chase down some ATI hardware. Otherwise you'll be running
experiments for me for a long time.

Bug#882934: Crash debugging

[Dima Kogan]

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 Debian. Can you please try to rename your ~/.gtkrc-2.0 file to
   something else to see if that makes the crash go away? I'm guessing
   this doesn't matter, but checking would be good.

2. The crash makes me suspect that something related to graphics is at
   fault. You have a radeon graphics card of some sort it looks like,
   which could explain why I can't reproduce (my hardware is different).
   How old/new is your graphics drivers? Can you try to run pcb without
   hardware acceleration? You can do this with

 LIBGL_ALWAYS_SOFTWARE=true pcb-gtk

   Also please try

 LIBGL_ALWAYS_INDIRECT=true pcb-gtk

Hopefully one of these resolves the crash, which would tell us where to
look next.

Thanks!

Bug#882934: pcb-gtk crash

[Dima Kogan]

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 is depending
on. What does this say:

  ldd /usr/bin/pcb-gtk

It'd also be interesting to get the list of all the packages that
provide those dependencies. What does this say:

  ldd /usr/bin/pcb-gtk | awk '{print $3}' | sort | uniq | xargs dpkg -S | awk 
-F: '!/diversion/ {print $1}' | xargs dpkg -l

Past that, I'd like to get a core. If that doesn't work, we can bring
out bigger guns, but hopefully this would be enough. Please do this:

1. ulimit -c unlimited
2. cat /proc/sys/kernel/core_pattern
   This should be "core" or "core.something". If it isn't, please write
   "core" into that file, as root. This is non-permanent and would be
   reset to whatever it was when you reboot.
3. In the same shell, invoke pcb-gtk, and trigger the crash

The kernel should dump a file named "core" into your 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

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

[Dima Kogan]

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:lbs-core even though this package is no
longer a part of Debian. Removing this, I can make a googleearth package
that I can install.

At that point I can't run the application though. To make it work, I
needed to

1. install libqtcore4:i386 libqtgui4:i386 libqt4-network:i386 libqtwebkit4:i386 
libglu1-mesa:i386
   This list is likely incomplete; it's just what I was missing

2. The i386 linker the application requires is /lib/ld-lsb.so.3. This
   presumably lived in lsb-core at one point, but it no longer does. I
   can fake it with

 sudo ln -fs /lib/ld-linux.so.2 /lib/ld-lsb.so.3

Then I can run googleearth. I'm not sure what the best way is to provide
the linker. Is this worth fixing? Is there some other googleearth build
that we should be using instead?

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

[Dima Kogan]

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

[Dima Kogan]

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...
>> Traceback (most recent call last):
>…
>> return codecs.ascii_decode(input, self.errors)[0]
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in
>position 327: ordinal not in range(128)
>
>The package has "أحمد المحمودي (Ahmed El-Mahmoudy)
>" as uploader.
>And that is not parsable by your non Unicode environment.
>
>> Presumably there's some non-ascii something somewhere that's tripping
>it
>> up. It is 100% reproducible, and as you can see I'm using the latest
>> available reportbug. Thanks.
>
>I can reproduce it with LC_ALL=C, but not with C.UTF-8.
>
>I would argue that reportbug can't do anything here, as your
>environment just can't display the string correctly.

Hi. Reportbug can do some set of these:

1. Tell me what is wrong and how I can make it work instead of throwing an 
opaque exception. I never did report that bug

2. Turn on whatever setting it needs. Is it just an incompatible environment 
setting? If I set LC_ALL to C.UTF-8 then this will magically work? What does 
this setting mean? Can reportbug set this?

3. If reportbug can't display some unicode string, can it simply not display 
it, or display an ascii version of it (this was available here)? The bug report 
it generates can still contain the unicode.

Any of these would be an improvement. Thanks

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

[Dima Kogan]

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


Hi. I just tried to send an unblock, and reportbug crashed. Session:

dima@scrawny:~$ sudo apt install reportbug
...
Setting up reportbug (7.1.5) ...


dima@scrawny:~$ reportbug
Please enter the name of the package in which you have found a problem, or 
type 'other' to report a more
general problem. If you don't know what package the bug is in, please 
contact debian-u...@lists.debian.org for
assistance.
> release.debian.org
Are you sure you want to file a bug on release.debian.org? [y|N|q|?]? y
*** Welcome to reportbug.  Use ? for help at 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 <dko...@debian.org>' as your from address.
Will send report to Debian (per lsb_release).
What sort of request is this? (If none of these things mean anything to 
you, or you are trying to report a bug
in an existing package, please press Enter to exit reportbug.)

1 binnmu  binNMU requests
2 britney testing migration script bugs
3 jessie-pu   jessie proposed updates requests
4 other   None of the other options
5 rm  Stable/Testing removal requests
6 transition  transition tracking
7 unblock unblock requests
8 wheezy-pu   wheezy proposed updates requests

Choose the request type: 7
Please enter the name of the package: geda-gaf
Checking status database...
Traceback (most recent call last):
  File "/usr/bin/reportbug", line 2234, in 
main()
  File "/usr/bin/reportbug", line 1107, in main
return iface.user_interface()
  File "/usr/bin/reportbug", line 1698, in user_interface
self.options.http_proxy)
  File "/usr/bin/reportbug", line 540, in special_prompts
return pkgprompts(package, bts, ui, fromaddr, timeout, online, 
http_proxy)
  File "/usr/lib/python3/dist-packages/reportbug/debbugs.py", line 450, in 
handle_debian_release
info = utils.get_source_package(package)
  File "/usr/lib/python3/dist-packages/reportbug/utils.py", line 540, in 
get_source_package
data = subprocess.getoutput('apt-cache showsrc ' + pipes.quote(package))
  File "/usr/lib/python3.5/subprocess.py", line 514, in getoutput
return getstatusoutput(cmd)[1]
  File "/usr/lib/python3.5/subprocess.py", line 495, in getstatusoutput
data = check_output(cmd, shell=True, universal_newlines=True, 
stderr=STDOUT)
  File "/usr/lib/python3.5/subprocess.py", line 316, in check_output
**kwargs).stdout
  File "/usr/lib/python3.5/subprocess.py", line 385, in run
stdout, stderr = process.communicate(input, timeout=timeout)
  File "/usr/lib/python3.5/subprocess.py", line 788, in communicate
stdout = self.stdout.read()
  File "/usr/lib/python3.5/encodings/ascii.py", line 26, in decode
return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd8 in position 327: 
ordinal not in range(128)


Presumably there's some non-ascii something somewhere that's tripping it
up. It is 100% reproducible, and as you can see I'm using the latest
available reportbug. Thanks.




-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.5
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
pn  debsums
ii  dlocate1.07
ii  emacs24-bin-common 24.5+1-7.1
ii  exim4  4.88-2
ii  exim4-daemon-light [mail-transport-agent]  4.88-2
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.8-1
pn  gir1.2-vte-2.91
ii  gnupg  2.1.17-2
ii  python3-gi 3.22.0-2
pn  python3-gi-cairo   

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

[Dima Kogan]

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.
>  * Compat 10 and later will forbid possibly broken setups.  We tried to
>retro fit it into compat 9 and earlier, but it broke in unintended
>ways (we could not reliably detect the issues).

Hi. Thanks for the reply. Like you say, "at first glance" (pkg =
${source:Version}) would work for this specific case, and that's what
the second patch here does.

Clearly I haven't thought about this as much as you have, and if it
really looks unfixable, it'd be great if

- An attempt to make a broken binNMU would hard-fail instead of throwing
  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

Bug#747141: ping

[Dima Kogan]

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..4e6ba5d5 100755
--- a/dh_installdocs
+++ b/dh_installdocs
@@ -200,7 +200,11 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 			# Policy says that if you make your documentation
 			# directory a symlink, then you have to depend on
 			# the target.
-			addsubstvar($package, 'misc:Depends', "$dh{LINK_DOC} (= \${binary:Version})");
+			addsubstvar($package,
+		'misc:Depends',
+		package_arch($dh{LINK_DOC}) eq 'all' ?
+			"$dh{LINK_DOC} (= \${source:Version})" :
+			"$dh{LINK_DOC} (= \${binary:Version})");
 		}
 	}
 	else {

Bug#747141: ping

[Dima Kogan]

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 how do we feel about the attached patch to debhelper?

diff --git a/dh_installdocs b/dh_installdocs
index 9c82b5b4..d063fcbb 100755
--- a/dh_installdocs
+++ b/dh_installdocs
@@ -200,7 +200,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
 			# Policy says that if you make your documentation
 			# directory a symlink, then you have to depend on
 			# the target.
-			addsubstvar($package, 'misc:Depends', "$dh{LINK_DOC} (= \${binary:Version})");
+			addsubstvar($package, 'misc:Depends', "$dh{LINK_DOC} (= \${source:Version})");
 		}
 	}
 	else {

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

[Dima Kogan]

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.

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

[Dima Kogan]

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 Scientific Library and
> should be reasonably easy to substitute.

Hi. Yeah, there're plenty of other (and better) SVD implementations.
They won't be a drop-in replacement, however because numerical recipes
uses a ridiculous matrix storage scheme:

typedef struct {
INTrows ;
INTcolumns ;
DOUBLE **m ;
} YMBOX, *YMPTR ;

I.e. each row (or column) of a matrix is stored in a separate chunk of
(usually dynamically-allocated) memory. This is stupid, and no other
library would do it this way. So to use other implementations you might
need to write a shim to convert formats. If you find a better way,
please let me know.


>  However, it feeds back into other matrix manipulation routines, so I
> cannot be sure how much of that was pulled from Numerical Recipies.
> This looks like finding a needle in a haystack to me. How did you find
> that bit of plaigerized code, and how would I go about flushing out
> any additional plaigerized sections of code?

I came across some other libraries that were doing a similar thing, and
then searched the Debian codebase (http://codesearch.debian.net) for
some unique-looking comments. Here I searched for

You must augment A with extra zero rows

I also searched for some other things that caught some other libraries,
but the above chunk of text is the only one I found in graywolf. What
you can do is to look at functions that use that YMPTR matrix
representation: anything that uses it is a candidate for being plucked
from the book.

Note that for some reason the utility code to support this matrix
representation IS in the public domain, as indicated in numerical
recipes copyright page linked in the bug report.


> I definitely want these out of the code base, especially as GNU
> alternatives are readily available.

Thank you very much.

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

[Dima Kogan]

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 they stop violating copyrights also.

Look at sinfo_svd_compare() in

  sinfoni/sinfo_svd.c

A later version of the book chapter this function came from lives here:

  http://numerical.recipes/webnotes/nr3web2.pdf

You can see many similarities. If you look at the older version of the
book, you will see 100% similarities.

The copyright statement is here:

  http://numerical.recipes/public-domain.html


I haven't done a thorough search, and it's possible SVD implementation
isn't the only violation here. It would be great if you looked more
thoroughly.

Thanks

Bug#856705: graywolf: License violation

[Dima Kogan]

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 violating copyrights also.

Look at Ysvd_decompose) in

  src/Ylib/svd.c

A later version of the book chapter this function came from lives here:

  http://numerical.recipes/webnotes/nr3web2.pdf

You can see many similarities. If you look at the older version of the
book, you will see 100% similarities.

The copyright statement is here:

  http://numerical.recipes/public-domain.html

I haven't done a thorough search, and I can imagine the SVD
implementation isn't the only violation here. It would be great if you
looked more thoroughly.

Thanks

Bug#856703: visp: License violation

[Dima Kogan]

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 copyrights also.

Look at vpMatrix::svdNr() in

  modules/core/src/math/matrix/vpMatrix_svd.cpp

A later version of the book chapter this function came from lives here:

  http://numerical.recipes/webnotes/nr3web2.pdf

You can see many similarities. If you look at the older version of the
book, you will see 100% similarities.

The copyright statement is here:

  http://numerical.recipes/public-domain.html


I haven't done a thorough search, and the SVD implementation isn't the
only violation here. For instance I also see

  vpMatrix::LUBksb() and vpMatrix::LUDcmp()

but it would be great if you looked more thoroughly.

Thanks

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

[Dima Kogan]

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

[Dima Kogan]

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)
 depchains:
  -
   depchain:
-
 package: sbuild-build-depends-sundials-dummy
 version: 0.invalid.0
 architecture: amd64
 depends: libpetsc3.7-dev:amd64
-
 package: libpetsc3.7-dev
 version: 3.7.5+dfsg1-4
 architecture: amd64
 depends: libpetsc3.7.5-dev:amd64
 

Which is true, because libpetsc3.7.5-dev has

Depends: libopenmpi-dev (>= 2.0.2~git.20161225),
 libopenmpi-dev (<< 2.0.2~git.20161226)

But the only available libopenmpi-dev is 2.0.2-2

Bug#806092: proposed fix

[Dima Kogan]

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>
Date: Sun, 25 Dec 2016 14:55:05 -0800
Subject: [PATCH 1/2] We can now build arch-dependent and arch-independent
 packages only

I.e. "dpkg-buildpackage -A" and "dpkg-buildpackage -B" works. Closes: #806092
---
 debian/rules | 32 ++--
 1 file changed, 22 insertions(+), 10 deletions(-)

diff --git a/debian/rules b/debian/rules
index 759ed3d..e7df4c7 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,26 +10,31 @@ CONFIGURE_OPTS=--disable-rpath --enable-dbus --disable-update-desktop-database -
 %:
 	dh $@ --with=autotools_dev
 
+# I configure build-gtk unconditionally (arch-dependent and arch-independent)
+# because I need a single configure invocation in both cases
 override_dh_auto_configure:
-	dh_auto_configure --builddirectory build_gtk -- $(CONFIGURE_OPTS) --with-gui=gtk
-	dh_auto_configure --builddirectory build_lesstif -- $(CONFIGURE_OPTS) --with-gui=lesstif
+	dh_auto_configure--builddirectory build_gtk -- $(CONFIGURE_OPTS) --with-gui=gtk
+	dh_auto_configure -a --builddirectory build_lesstif -- $(CONFIGURE_OPTS) --with-gui=lesstif
 
 override_dh_auto_build:
-	dh_auto_build --builddirectory build_gtk
-	dh_auto_build --builddirectory build_lesstif
+	dh_auto_build -a --builddirectory build_gtk
+	dh_auto_build -a --builddirectory build_lesstif
 
 override_dh_auto_test:
-	dh_auto_test --builddirectory build_gtk
-	dh_auto_test --builddirectory build_lesstif
+	dh_auto_test -a --builddirectory build_gtk
+	dh_auto_test -a --builddirectory build_lesstif
 
-override_dh_auto_install:
-	dh_auto_install --builddirectory build_gtk
+override_dh_auto_install-arch:
+	make -C build_gtk install-exec DESTDIR=$$PWD/debian/tmp AM_UPDATE_INFO_DIR=no
+
+override_dh_auto_install-indep:
+	make -C build_gtk install-data DESTDIR=$$PWD/debian/tmp AM_UPDATE_INFO_DIR=no
 
 override_dh_auto_clean:
 	dh_auto_clean --builddirectory build_gtk
 	dh_auto_clean --builddirectory build_lesstif
 
-override_dh_install:
+override_dh_install-arch:
 	# Remove needlessly installed static library and header file before
 	# installing common files:
 	rm -rf $(CURDIR)/debian/tmp/usr/lib
@@ -42,6 +47,13 @@ override_dh_install:
 	# Install pcb-lesstif binary:
 	install build_lesstif/src/pcb debian/$(package)-lesstif/usr/bin/pcb-lesstif
 
+override_dh_install-indep:
+	# Remove needlessly installed static library and header file before
+	# installing common files:
+	rm -rf $(CURDIR)/debian/tmp/usr/lib
+	rm -rf $(CURDIR)/debian/tmp/usr/include
+	dh_install -Xusr/bin -Xusr/share/pcb- -Xusr/share/doc -Xexamples -Xtutorial -Xusr/share/info
+
 	# Set executable bit for pcb tools:
 	[ ! -d debian/$(package)-common ] || chmod a+x debian/$(package)-common/usr/share/pcb/tools/MergePCBPS
 	[ ! -d debian/$(package)-common ] || chmod a+x debian/$(package)-common/usr/share/pcb/tools/Merge_dimPCBPS
@@ -52,7 +64,7 @@ override_dh_install:
 	# Remove empty dirs:
 	[ ! -d debian/$(package)-common ] || find debian/$(package)-common -type d -empty -delete
 
-override_dh_fixperms:
+override_dh_fixperms-indep:
 	dh_fixperms
 	# Fix permissions of a couple of example files:
 	[ ! -d debian/$(package)-common ] || chmod -x debian/$(package)-common/usr/share/doc/$(package)-common/examples/LED.pcb
-- 
2.10.1

>From 77ee5069c455bd3458a20875c328c9642ded0fdf Mon Sep 17 00:00:00 2001
From: Dima Kogan <dko...@debian.org>
Date: Sun, 25 Dec 2016 14:56:11 -0800
Subject: [PATCH 2/2] changelog bump

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 1fa754f..62c65c5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+pcb (20140316-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Closes: #806092
+
+ -- Dima Kogan <dko...@debian.org>  Sun, 25 Dec 2016 14:56:02 -0800
+
 pcb (20140316-3) unstable; urgency=medium
 
   * (Build-)Depend on unversioned tcl/tk
-- 
2.10.1

Bug#774149: Cannot reproduce

[Dima Kogan]

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 remain in Debian. Can
anybody confirm that sid fixes the issue?

Bug#774149: Cannot reproduce

[Dima Kogan]

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

[Dima Kogan]

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 gcc-4.9-source (= 4.9.3-5)
>   Tried versions: 4.9.3-11
>-> Does not satisfy version, not trying
> E: Could not satisfy build-dependency.

Hi. This is due to cross-gcc-dev being updated, but cross-gcc-4.9-xxx
not having been updated yet. I'll do that shortly.

Bug#784446: Fix pending

[Dima Kogan]

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

[Dima Kogan]

close 789430 
thanks

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

Bug#766619: Popularity counts

[Dima Kogan]

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
- mipsel
- powerpc
- arm64

I built these frontends:

- C
- C++
- Fortran
- Java
- Go
- Objective C
- Objective C++


armhf:
 69 cpp-4.9-arm-linux-gnueabihf
 68 gcc-4.9-arm-linux-gnueabihf
 37 g++-4.9-arm-linux-gnueabihf
  3 gobjc-4.9-arm-linux-gnueabihf
  2 gobjc++-4.9-arm-linux-gnueabihf
  2 gfortran-4.9-arm-linux-gnueabihf
  2 gcj-4.9-arm-linux-gnueabihf
  2 gccgo-4.9-arm-linux-gnueabihf
  2 gcc-4.9-plugin-dev-arm-linux-gnueabihf

armel:
 47 gcc-4.9-arm-linux-gnueabi
 44 cpp-4.9-arm-linux-gnueabi
 16 g++-4.9-arm-linux-gnueabi
  2 gobjc++-4.9-arm-linux-gnueabi
  2 gfortran-4.9-arm-linux-gnueabi
  2 gcj-4.9-arm-linux-gnueabi
  2 gccgo-4.9-arm-linux-gnueabi
  2 gcc-4.9-plugin-dev-arm-linux-gnueabi
  1 gobjc-4.9-arm-linux-gnueabi

arm64 (Not available as long as arm32*)
  5 gcc-4.9-aarch64-linux-gnu
  5 g++-4.9-aarch64-linux-gnu
  5 cpp-4.9-aarch64-linux-gnu
  2 gobjc-4.9-aarch64-linux-gnu
  2 gobjc++-4.9-aarch64-linux-gnu
  2 gfortran-4.9-aarch64-linux-gnu
  2 gcj-4.9-aarch64-linux-gnu
  2 gccgo-4.9-aarch64-linux-gnu
  2 gcc-4.9-plugin-dev-aarch64-linux-gnu

Everything else
  7 cpp-4.9-mipsel-linux-gnu
  6 gcc-4.9-powerpc-linux-gnu
  6 gcc-4.9-mipsel-linux-gnu
  6 g++-4.9-mipsel-linux-gnu
  6 cpp-4.9-powerpc-linux-gnu
  5 g++-4.9-powerpc-linux-gnu
  4 g++-4.9-mips-linux-gnu
  4 cpp-4.9-mips-linux-gnu
  3 gobjc-4.9-mipsel-linux-gnu
  3 gobjc++-4.9-mipsel-linux-gnu
  3 gfortran-4.9-mipsel-linux-gnu
  3 gcj-4.9-mipsel-linux-gnu
  3 gccgo-4.9-mipsel-linux-gnu
  3 gcc-4.9-plugin-dev-mipsel-linux-gnu
  3 gcc-4.9-mips-linux-gnu
  2 gobjc-4.9-powerpc-linux-gnu
  2 gobjc-4.9-mips-linux-gnu
  2 gobjc++-4.9-powerpc-linux-gnu
  2 gobjc++-4.9-mips-linux-gnu
  2 gfortran-4.9-powerpc-linux-gnu
  2 gfortran-4.9-mips-linux-gnu
  2 gcj-4.9-powerpc-linux-gnu
  2 gcj-4.9-mips-linux-gnu
  2 gccgo-4.9-powerpc-linux-gnu
  2 gccgo-4.9-mips-linux-gnu
  2 gcc-4.9-plugin-dev-powerpc-linux-gnu
  2 gcc-4.9-plugin-dev-mips-linux-gnu


The counts for the frontends that aren't C or C++ are so low, they are
likely ALL from people testing stuff, rather than actual users.

Doko: can you tell us what the specific problem is? So far all I'm
getting from the discussions is that you don't like it, but that's not
actionable, and I'm certain there are more specific problems that we can
try to resolve. Is there a maintenance burden on you to support this? If
so, I'm sure some of us can step in to help maintain this. Let's try to
find 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

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

[Dima Kogan]

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/numptyphysics/paper.jpg
 loaded log=0
 active: 0
 active: 0
 active: 0
 active: 1
 active: 1
 active: 1
 active: 0
 STATS:  time=5016ms
 strokes=1 (0 paused, 0 undone)
 saving demo of level 0 to 
/home/dima/.numptyphysics/Recordings//usr/share/numptyphysics/C00_Title/L00_title.npd
 saving to 
/home/dima/.numptyphysics/Recordings//usr/share/numptyphysics/C00_Title/L00_title.npd
 active: 1
 *** Error in `numptyphysics': munmap_chunk(): invalid pointer: 
0x00fde830 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x00fdea30 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102e4f0 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102dfa0 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102da40 ***
 *** Error in `numptyphysics': double free or corruption (out): 
0x0102e2d0 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102d830 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102e4f0 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102dfa0 ***
 *** Error in `numptyphysics': double free or corruption (!prev): 
0x0102da40 ***
 *** Error in `numptyphysics': double free or corruption (out): 
0x0102e2d0 ***


This issue makes the program more or less unusable. Note that there are
later versions upstream, but the one I tried (harmattan 3.3 release) has
the same issue.




-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: armel

Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages numptyphysics depends on:
ii  libc62.18-5
ii  libfontconfig1   2.11.0-5
ii  libfreetype6 2.5.2-1
ii  libgcc1  1:4.9.0-3
ii  libsdl-image1.2  1.2.12-5+b2
ii  libsdl-ttf2.0-0  2.0.11-3
ii  libsdl1.2debian  1.2.15-9
ii  libstdc++6   4.9.0-3
ii  libx11-6 2:1.6.2-2
ii  ttf-femkeklaver  1.0-1
ii  zlib1g   1:1.2.8.dfsg-1

numptyphysics recommends no packages.

numptyphysics suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#739215: More info

[Dima Kogan]

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 subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#731673: update

[Dima Kogan]

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. Trouble? Contact listmas...@lists.debian.org

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

[Dima Kogan]

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 subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#729328: update

[Dima Kogan]

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

[Dima Kogan]

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 debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#725660: patch

[Dima Kogan]

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

[Dima Kogan]

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'

[Dima Kogan]

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 issue is unrelated and I made a new bug for it.


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

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

[Dima Kogan]

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 unless the user rebuilds this
package themselves. I have the following trivial program:

#include stdio.h
int dgetrf_(int *m, int *n, double *a, int *lda, int *ipiv, int *info);
int main(void)
{
  int three = 3;
  int ipiv[3];
  int info;
  double A[9] = {1,2,5,2,3,4,5,4,3};
  dgetrf_(three, 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 dumped)  ./tst
dima@shorty:/tmp$ ldd tst
linux-vdso.so.1 =  (0x7fff3bbff000)
liblapack.so.3 = /usr/lib/liblapack.so.3 (0x7f3ff4f8e000)
libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f3ff4c07000)
libblas.so.3 = /usr/lib/libblas.so.3 (0x7f3ff453d000)
libgfortran.so.3 = /usr/lib/x86_64-linux-gnu/libgfortran.so.3 
(0x7f3ff4227000)
libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 
(0x7f3ff4011000)
libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f3ff3df4000)
libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f3ff3b72000)
/lib64/ld-linux-x86-64.so.2 (0x7f3ff5caf000)
libquadmath.so.0 = /usr/lib/x86_64-linux-gnu/libquadmath.so.0 
(0x7f3ff393d000)
dima@shorty:/tmp$ update-alternatives --display liblapack.so.3
liblapack.so.3 - auto mode
  link currently points to /usr/lib/atlas-base/atlas/liblapack.so.3
/usr/lib/atlas-base/atlas/liblapack.so.3 - priority 35
  slave liblapack.so.3gf: /usr/lib/atlas-base/atlas/liblapack.so.3
/usr/lib/lapack/liblapack.so.3 - priority 10
  slave liblapack.so.3gf: /usr/lib/lapack/liblapack.so.3
Current 'best' version is '/usr/lib/atlas-base/atlas/liblapack.so.3'.
dima@shorty:/tmp$ dpkg -S /usr/lib/atlas-base/atlas/liblapack.so.3
libatlas3-base: /usr/lib/atlas-base/atlas/liblapack.so.3
dima@shorty:/tmp$ dpkg -l libatlas3-base
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ NameVersion Description
+++-===-===-==
ii  libatlas3-base  3.8.4-6 Automatically Tuned Linear 
Algebra Software, generic shared
dima@shorty:/tmp$ gdb tst core
GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type show copying
and show warranty for details.
This GDB was configured as x86_64-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /tmp/tst...(no debugging symbols found)...done.
[New LWP 30474]

warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
Core was generated by `./tst'.
Program terminated with signal 4, Illegal instruction.
#0  0x7fa03d281bb7 in ATL_dgetrfC () from /usr/lib/liblapack.so.3
(gdb) disass
Dump of assembler code for function ATL_dgetrfC:
   0x7fa03d281950 +0: mov%rbx,-0x30(%rsp)
   0x7fa03d281955 +5: mov%rbp,-0x28(%rsp)
..
   0x7fa03d281bb3 +611:   lea(%r12,%rax,8),%rbx
= 0x7fa03d281bb7 +615:   vmovsd (%rbx),%xmm1
   0x7fa03d281bbb +619:   vucomisd 0x996ced(%rip),%xmm1# 
0x7fa03dc188b0
   0x7fa03d281bc3 +627:   mov0x38(%rsp),%r10d
..
dima@shorty:/tmp$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 15
model name  : Intel(R) Core(TM)2 CPU T7400  @ 2.16GHz
stepping: 6
cpu MHz : 2167.000
cache size  : 4096 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 10
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm 
constant_tsc arch_perfmon pebs bts rep_good nopl aperfmperf pni dtes64 monitor 
ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm dts tpr_shadow
bogomips: 4322.43
clflush size: 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:



-- System Information: