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

2024-03-18 Thread 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#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

2024-03-18 Thread Dima Kogan
"Dr. Burkard Lutz"  writes:

> there is no other upstream source except salsa.debian.org
> Is that sufficient?

Hi. This is certainly sufficient, but it raises more questions. These
tools weren't available to the public before this, I'm guessing, and
this is the initial public release?

Most programs in Debian (and every other distro) are separated into the
"upstream" part that contains the program being packaged, and the
"debianization": the packaging logic. While not strictly required, it
would be good to do that here as well. What if somebody finds these
tools, and wants to use them in some other distro? Hosting the sources
on salsa implies that there's something debian-specific in galvani, and
from reading the description, it sounds like there isn't.

So, unless you really feel strongly about doing it this way, I would
suggest that you

- Create a new "galvani" project someplace non-debian-specific (github,
  gitlab, etc...) with a README that tells people how to get the
  software. It can say "please use Debian and 'apt install galvani'" if
  that's what you want to communicate.

- Each release of "galvani" should have a git tag

- The repo on salsa should have the canonical structure used by most
  packages: an "upstream" branch containing the upstream sources from a
  release tarball and a "master" branch containing these sources + the
  debianization. One can debate about the technical pros/cons of doing
  this, but it's the standard, and will make it easier for you and
  others to manage this package.

Look at other packages for examples of how to structure this. You want
to have a debian/watch file that points to your repo; something like
this:

  https://salsa.debian.org/science-team/mrcal/-/blob/master/debian/watch

And you want to use the "uscan" program to read this file, to download
the sources. And you want to use the "gbp import-orig" tool to ingest
new tarballs.

Furthermore, I would encourage you to do this as part of a team. For
instance, the debian-science team:

  https://salsa.debian.org/science-team/

Doing this sends a signal that you are OK with other people helping
maintain this package. Their policies are described here:

  https://wiki.debian.org/Teams/DebianScience

I would suggest that you subscribe to their mailing list, and ask for
help there, if you need it. Or feel free to talk to me further on this
bug.



Bug#1067096: ITP: galvani -- reads data from a device with graphical plots and evaluation

2024-03-18 Thread Dima Kogan
Hi. Where's the upstream source for this? I would expect to see a link
here:

- debian/copyright (Source field)
- debian/control (Copyright field)
- debian/upstream/metadata

Usually the upstream source would live somewher outside of Debian (for
any non-debian-specific programs, like this one). salsa.debian.org would
contain the debianized sources.

Thanks



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

2024-02-28 Thread 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

2024-02-28 Thread 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

2024-02-28 Thread 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

2024-02-28 Thread Dima Kogan
Can you see if other wxt applications work on a system that's exhibiting
this problem?



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

2024-02-28 Thread 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#1064320: libeigen3-dev: linking objects compiled with different flags may cause crashes

2024-02-19 Thread Dima Kogan
Package: libeigen3-dev
Version: 3.4.0-4
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hello. I'm making this report to track the report in this mailing list
thread:

  https://www.mail-archive.com/debian-science@lists.debian.org/msg13666.html

In short: there's a known issue in Eigen that can create crashing
binaries when using a very reasonable workflow. A description of the
issue and minimized reproducer are here:

  https://www.mail-archive.com/debian-science@lists.debian.org/msg13710.html

I propose to patch this in Debian and/or talk to Eigen upstream to
eliminate the cause of the crash. A proposed patch appears here:

  https://www.mail-archive.com/debian-science@lists.debian.org/msg13857.html

In my view, a questionable design choice in C++ allows the user to
create crashing code, and Eigen expoloits this design choice to make
this crashing possible.

We cannot fix C++, but we can fix Eigen. The issue is that a templated
function defined in a header generates a (weak symbol) copy of this
function in EACH compile unit, and the linker then picks an arbitrary
copy from the many compile units it is given. It is thus imperative that
each copy is compatible with every other copy. Eigen breaks this
requirement by using the preprocessor to select incompatible behaviors
that might crash when linked together. The proposed patch eliminates
this preprocessor-based variability.



Bug#1062952: This package is not affected by time_t

2024-02-11 Thread Dima Kogan
Hi.

libmrcal-dev does not use time_t. I'm seeing the abi-compliance-checker
failure here:

  
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libmrcal-dev/base/log.txt

The cause is that the tool takes all the headers in /usr/include/mrcal
in an arbitrary order, and tries to #include them. That does not work
here. "mrcal-internal.h" should not be #included explicitly since it is
already #included by mrcal.h. Removing that header from the command in
the error log above makes the errors disappear.

Let me know what needs to happen to ingest that logic, to exclude mrcal
from this transition. This will make my life easier.

Thanks.



Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

2024-02-07 Thread Dima Kogan
Hi. Thanks for your contribution. I looked at the upstream code a tiny
bit, and it looks like it might have portability bug, at least on
big-endian architectures. For instance:

  
https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78

This assumes that sizeof(long)==4. Maybe this is benign, but it would be
nice to fix. Are you upstream or do you know upstream? Can yall fix
these?

Thanks!



Bug#1037136: How to fix a-c-c for this package?

2024-02-07 Thread Dima Kogan
Hi.

libmrcal-dev does not use time_t. I'm seeing the abi-compliance-checker
failure here:

  
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libmrcal-dev/base/log.txt

The cause is that the tool takes all the headers in /usr/include/mrcal
in an arbitrary order, and tries to #include them. That does not work
here. "mrcal-internal.h" should not be #included explicitly since it is
already #included by mrcal.h. Removing that header from the command in
the error log above makes the errors disappear.

Can we do that, and remove libmrcal-dev from this transition?

Thanks.



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

2024-02-03 Thread 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

2024-01-27 Thread 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"

2024-01-17 Thread 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"

2024-01-16 Thread 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#1059342: live-build: Can we please install net-tools?

2023-12-22 Thread Dima Kogan
Package: live-build
Severity: normal
Hi. This is a feature request. Can we please include net-tools in the
set of packages we ship with debian-live? It is small, and would make
many people's lives easier. I personally use this as a rescue disk, and
configuring the network is a common need for such an application. And
like many, I prefer the older net-tools tools.

Thanks.

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

Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)



Bug#1056556: Debugging techniques

2023-12-04 Thread Dima Kogan
Hi

Johannes Schauer Marin Rodrigues  writes:

> By default, mmdebstrap does not print the output of the commands it runs. It
> does that though when something goes wrong. So if "apt install" fails, then 
> you
> get its output. In your case, you missed a "note" (not even a warning) in the
> "apt update" output. You would've seen that if you had run mmdebstrap with the
> --verbose option.

No. I was running mmdebstrap --verbose, and the note wasn't in the
output. I only saw the note when I set up a similar situation in a real
arm64 install (no schroot, no mmdebstrap), and tried to "apt update"
there. mmdebstrap passing on the note would have helped.


> You initially suggested mmdebstrap to drop down to a shell and print a command
> for the user to re-run. Lets assume that this were possible (I don't think it
> is feasible). In that case, you still would not've known how to proceed or 
> that
> it is the apt pinning that is at fault.
> 

If a shell was available, you can do lots of quick experiments quickly,
and narrow down the problem quickly. I routinely use tools like sysdig
to report all system-wide syscalls, and that output is enough to figure
out lots of problems. You can use it without the shell too, without
reproducing the problem in isolation, but it's harder to interpret the
logs.


> So given all of this, I don't think your initial suggestion of adding a
> facility to drop to a shell and re-run a command in shell would've fixed your
> problem.

Maybe. Maybe not. Can we agree that the capability to do this in sbuild
is extremely useful, at least? I find it extremely valuable.


> I have no problem helping you with this and it doesn't bother me but I
> also don't see anything that is to be learned from all of this.

OK. Hopefully I don't need to bug you many more times.

Thanks a lot for the help!



Bug#1056556: Debugging techniques

2023-11-30 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

>> > mmdebstrap ... --variant=apt --chrooted-customize-hook=bash unstable 
>> > /dev/null
>> 
>> Would that work, though?
> Yes. Did you try it and it did not work? What was the error message?

No :) I wanted to read about what it did first. I tried it just now,
though. With the --included metapackage it has the same behavior as
before: complains that it can't install libopencv-dev.

If I don't ask it to --install the problematic package, intending to
manually poke apt, then I can't do that: the problematic package is
nowhere to be found. It was originally on disk locally, but without
--include, it was never copied into the bind mount.

I do want to have a metapackage: this allows the metapackage to be
updated in the future, and have users be able to "apt update && apt
upgrade".

I guess I could do this differently for testing. By making the
metapackage available in an apt server, and using an undocumented
option. That's a heavy lift though. If I was so expert to know to do
these things, I probably wouldn't need to debug stuff in the first place



>> In any case, I figured out my specific problem by creating a similar
>> scenario on a native arm64 box. I was naming the pinning file .conf
>> instead of .pref which apparently matters.
>
> Yes, in the man page of apt_preferences it says: "The files have either no or
> "pref" as filename extension". In one of my last mails to you I also suggested
> you add:
>
> --setup-hook='{ echo "Package: XXX"; echo "Pin: origin \"YYY\""; echo
> "Pin-Priority: 1"; } > "$1"/etc/apt/preferences.d/mypinnings.pref'
>
> Notice that I used the correct filename extension.

Yep. I liked my extension better, but didn't realize that the name was
significant.


>> On the arm64 box this produced a clear error message ("apt" told me to
>> rename the file). But with mmdebstrap there was no specific error at all, as
>> you saw. Any idea why?
>
> Which apt command produced the error? I also don't think it was an error. It
> was only a warning, right? Did you get it for "apt-get update" or for "apt-get
> install"?

Great questions. I just tried it again:

  $ sudo apt update  

  
  N: Ignoring file 'mypinnings.conf' in directory '/etc/apt/preferences.d/' as 
it has an invalid filename extension

So I don't know what the answer is. But this felt undebuggable, and I
wish I could figure this stuff without sinking many hours into it or
asking you every time.

Thanks for the help, as always.



Bug#1056556: Debugging techniques

2023-11-28 Thread Dima Kogan
Hi josch.

I sorta expected that there was extra complexity here that made
debugging difficult. It's unfortunate.


> mmdebstrap ... --variant=apt --chrooted-customize-hook=bash unstable /dev/null

Would that work, though?

  --chrooted-customize-hook isn't in the manpage

  --customize-hook runs after everything was installed (so past where
the failure was happening here)

  --essential-hook was running at the right time, but the "apt-get"
executable wasn't available

In any case, I figured out my specific problem by creating a similar
scenario on a native arm64 box. I was naming the pinning file .conf
instead of .pref which apparently matters. On the arm64 box this
produced a clear error message ("apt" told me to rename the file). But
with mmdebstrap there was no specific error at all, as you saw. Any idea
why?

Thanks for all the help.



Bug#1056556: Debugging techniques

2023-11-27 Thread Dima Kogan
Hi. I tried to do that apt pinning today, as you suggested. It still
fails in the same way as before:

  $ mmdebstrap 
  
  I: installing remaining packages inside the chroot...
  
  Some packages could not be installed. This may mean that you have
  requested an impossible situation or if you are using the unstable
  distribution that some required packages have not yet been created
  or been moved out of Incoming.
  The following information may help to resolve the situation:

  The following packages have unmet dependencies:
   ros-noetic-cv-bridge : Depends: libopencv-dev but it is not installable
   ros-noetic-grid-map-filters : Depends: libopencv-dev but it is not 
installable
   ros-noetic-image-geometry : Depends: libopencv-dev but it is not installable
  E: Unable to correct problems, you have held broken packages.

The preferences file is there, but it isn't obviously doing anything. I
did some debugging just now to try to figure out why, and I'm reminded
of

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036929

Ideally the workflow I would like is

1. mmdebstrap does stuff. When it runs a command, it prints out EXACTLY
   what it does, in a way that I can copy/paste it, and get the same
   output

2. If it fails to do something, it drops me into a shell. Where I can
   paste the command to reproduce the problem, and then poke around to
   fix it

This probably isn't 100% possible here; but how would you debug this
otherwise?

I'm attaching a patch that does some of (1.) above. This uses
String::ShellQuote to quote all the arguments so that the command string
can be pasted. I'm guessing you'd want to do some of that differently,
so it isn't super thorough.

OK. Then I gave myself a shell in a spot that (I think?) sits right
before the failing "apt-get install":

  mmdebstrap \
--essential-hook 'echo $$1; bash -i' \


And pasting the command didn't work as I had hoped:

  root@fatty:# apt-get -o Dir::Bin::dpkg=env -o DPkg::Options::=--unset=TMPDIR 
-o DPkg::Options::=dpkg -o DPkg::Chroot-Directory=/tmp/mmdebstrap.i1wpW0WLMS 
--yes install -oDpkg::Use-Pty=false tst-libopoencv 
'?narrow(?or(?archive(^focal$),?codename(^focal$)),?architecture(arm64),?and(?or(?priority(required),?priority(important)),?not(?essential)))'

  E: Could not open lock file /var/lib/dpkg/lock-frontend - open (13: 
Permission denied)
  E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), 
are you root?

Any idea what the difference is? Here I'm running the external
"apt-get". Is the "apt-get install" supposed to happen inside the
chroot? There is no "apt-get" binary there yet.

If I can quickly and repeatedly reproduce the failure, I can "apt-cache
policy libopencv-dev", and I can see if it's trying to use the
preferences file and such. Maybe I mistyped something.

If the above diagnostic sequence cannot work, what would?

Thanks much

diff --git a/debian/control b/debian/control
index c82cdb3..e3f56a8 100644
--- a/debian/control
+++ b/debian/control
@@ -17,6 +17,7 @@ Architecture: all
 Depends:
  apt (>= 2.3.14),
  python3 (>= 3.10),
+ libstring-shellquote-perl,
  ${misc:Depends},
  ${perl:Depends},
 Recommends:
diff --git a/mmdebstrap b/mmdebstrap
index 0abdfc3..d52496d 100755
--- a/mmdebstrap
+++ b/mmdebstrap
@@ -46,6 +46,7 @@ use Socket;
 use Time::HiRes;
 use Math::BigInt;
 use Text::ParseWords;
+use String::ShellQuote qw(shell_quote);
 use version;
 
 ## no critic (InputOutput::RequireBriefOpen)
@@ -815,8 +816,6 @@ sub run_progress {
 info "run_progress() received signal $_[0]: waiting for child...";
 };
 
-debug("run_progress: exec " . (join ' ', ($get_exec->('${FD}';
-
 # delay signals so that we can fork and change behaviour of the signal
 # handler in parent and child without getting interrupted
 my $sigset = POSIX::SigSet->new(SIGINT, SIGHUP, SIGPIPE, SIGTERM);
@@ -845,6 +844,8 @@ sub run_progress {
 # redirect stderr to stdout so that we can capture it
 open(STDERR, '>&', STDOUT) or error "cannot open STDOUT: $!";
 my @execargs = $get_exec->($fd);
+my $cmd_string = shell_quote(@execargs);
+
 # before apt 1.5, "apt-get update" attempted to chdir() into the
 # working directory. This will fail if the current working directory
 # is not accessible by the user (for example in unshare mode). See
@@ -853,8 +854,11 @@ sub run_progress {
 chdir $chdir or error "failed chdir() to $chdir: $!";
 }
 eval { Devel::Cover::set_coverage("none") } if $is_covering;
+
+info("run_progress: running $cmd_string");
+
 exec { $execargs[0] } @execargs
-  or error 'cannot exec() ' . (join ' ', @execargs);
+  or error 'cannot exec() $cmd_string';
 }
 close $wfh;
 
@@ -947,7 +951,7 @@ sub run_progress {
 if ($verbosity_level >= 1) {
 print STDERR $output;
 }
-error((join ' ', $get_exec->('<$fd>')) . 

Bug#1056556: mmdebstrap: mmdebstrap error resolving installed packages

2023-11-22 Thread Dima Kogan
Package: mmdebstrap
Version: 1.4.0-1
Severity: normal

Hi. I'm seeing a failure that I understand very well, but yet don't know
how to debug or fix. Any suggestions would be appreciated.

I'm making an Ubuntu/focal image that has a bunch of stuff installed,
and can serve as a base for development. This runs on arm64. There're a
number of ugly external APT repos that have semi-broken packages, but it
should all still work.

I define the stuff I want to install into the image with a meta-package.
tst-libopencv.equivs:

  Source: tst-libopencv
  Section: misc
  Priority: optional
  Standards-Version: 3.9.2

  Package: tst-libopencv
  Version: 1
  Maintainer: Dima Kogan 

  Depends: ros-noetic-cv-bridge,
   libopencv-dev (<< 4.5)

  Architecture: arm64
  Description: Test

And I build the meta-package:

  equivs-build -aarm64 tst-libopencv.equivs

And I can use mmdebstrap to create a base image with this package
installed:

  mmdebstrap
  \
--verbose   
  \
--architectures=arm64   
  \
--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount
  \
--include ./tst-libopencv_1_arm64.deb   
  \
focal   
  \
tst.tar.gz  
  \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal   
main restricted universe multiverse" \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal-updates   
main restricted universe multiverse" \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal-backports 
main restricted universe multiverse" \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal-security  
main restricted universe multiverse" \
"deb [trusted=yes] http://packages.ros.org/ros/ubuntu focal main"

This works great. ros-noetic-cv-bridge is an external-apt-repo package.
It Depends: libopencv-dev. Ubuntu/focal ships 4.2, so the requirement
libopencv-dev (<< 4.5) in the meta-package is satisfied.

OK. But let's say I want to add another, also-heinous external repo into
the mix, and I do this:

  mmdebstrap
  \
--verbose   
  \
--architectures=arm64   
  \
--hook-dir=/usr/share/mmdebstrap/hooks/file-mirror-automount
  \
--include ./tst-libopencv_1_arm64.deb   
  \
focal   
  \
tst.tar.gz  
  \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal   
main restricted universe multiverse" \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal-updates   
main restricted universe multiverse" \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal-backports 
main restricted universe multiverse" \
"deb [trusted=yes] http://ports.ubuntu.com/ubuntu-ports/ focal-security  
main restricted universe multiverse" \
"deb [trusted=yes] https://repo.download.nvidia.com/jetson/common r35.4 
main" \
"deb [trusted=yes] https://repo.download.nvidia.com/jetson/t234 r35.4 main" 
  \
"deb [trusted=yes] http://packages.ros.org/ros/ubuntu focal main"

This is the same command, but I also make some nvidia packages
available. THAT repo ships its own copy of libopencv-dev: version
4.5.x. When building the image I explicitly do NOT want it to pick
up that version, but to use the normal Ubuntu/focal ones: that
restriction in the meta-package should do that for me. There's no reason
this shouldn't work, and I can easily create this situation with some
apt commands after I chroot into the image. But mmdebstrap cannot create
this image: the above command fails:

  The following packages have unmet dependencies:
   tst-libopencv : Depends: libopencv-dev (< 4.5) but 4.5.4-8-g3e4c170df4 is to 
be installed
  E: Una

Bug#1056157: libfalcosecurity0-dev: libsinsp.pc lists wrong libs: -lgRPC::grpc++ -lgRPC::grpc -lgRPC::gpr

2023-11-20 Thread Dima Kogan
Hello. Thanks for the report. I fixed the original issue you reported in
git, but haven't tested it yet, or released the fixed packages.

I'll look at this in a bit.

This package has bigger problems, unfortunately. Let me know if you
want to help fix them.



Bug#1053729: RFP: SAIL image decoding library

2023-10-19 Thread Dima Kogan
Andrius Merkys  writes:

> Do you know any software already in Debian which would benefit from
> having SAIL in Debian?

There aren't many C image-reading libraries. libfreeimage is mostly-dead
upstream, and is kinda weird. If SAIL was in Debian and is all the
things that its website claims, I would consider moving my upstream
software to use it instead of libfreeimage. So I'd like to see this in
Debian, but have too much of a backlog to do the packaging myself,
sadly.



Bug#1051499: ITP: ros-image-transport-plugins -- ROS1 plugins to the image transport system

2023-09-08 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: ros-image-transport-plugins
  Version : 1.15.0
  Upstream Author : Willow garage
* URL or Web page : https://github.com/ros-perception/image_transport_plugins
* License : BSD-3
  Description : ROS1 plugins to the image transport system



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

2023-07-18 Thread Dima Kogan
Thank you very much for the report. I completely forgot about these.
Fixed just now.



Bug#1041059: FTBFS against suitesparse 7

2023-07-14 Thread Dima Kogan
Hello. Thank you for the report. This is already fixed in the libdogleg
upstream repo. I will push a new package when a new libdogleg is
released or when the new suitesparse moves to unstable, whichever comes first.



Bug#1040942: rosbash: Most binary tools (roscd, rosd, rosls, ....) are unavailable in this package

2023-07-12 Thread Dima Kogan
Package: rosbash
Version: 1.15.8-5
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hello. I'm using the package from bookworm. rosbash 

The "rosbash" package should provide several commandline tools,
documented here:

  http://wiki.ros.org/rosbash

But only "rosrun" is provided in the package.

This is because most of the tools are not binaries, but are shell
functions. These are supposed to be defined in
/usr/share/rosbash/rosbash, but our rosbash package does not ship this
file. This file exists in the package sources in tools/rosbash/rosbash,
but it is not installed anywhere. This is the bug.

Our package does reference the tools (we include all the tab
completions). And the package scripts ask for it:

  dima@fatty:$ source /usr/share/rosbash/catkin_env_hook/15.rosbash.bash

  bash: /usr/share/rosbash/rosbash: No such file or directory

So if we install that file, that would probably fix this bug.

Thanks



Bug#773385: Ping

2023-06-23 Thread Dima Kogan
Niels Thykier  writes:

> From my PoV, what you experience here with find is a complete different 
> problem.
>
> By default, apt-file uses the `APT::Architectures` configuration variable to
> determine which architectures to search for[1].  If APT's default is not 
> correct
> here and you do not APT to see arm64, then please add the corrected
> `APT::Architectures` to `/etc/apt/apt-file.conf`.

Well yeah. I totally get that this is what it's doing, I'm just
unconvinced that it should be doing this.

I can give you patches, but let's agree on what the patch should do
before I do any work.

apt-cache has databases for every enabled architecture. So the proposal
is to search ALL of them and report ALL the results. If the user wants
to limit the search, they can pass -a or grep the output, or whatever.

Would you accept such a patch?

Thanks for working on apt-file!



Bug#1037200: please consider backporting valijson to Bullseye

2023-06-07 Thread Dima Kogan
Hi. I'll gladly accept help on this. If you can do this yourself, that
would be great!

Thanks



Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

2023-06-01 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> let me tell you about another trick. Instead of running
>
> --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'
>
> you can also run:
>
> --chrooted-customize-hook='i-might-fail || bash'
>
> In contrast to the --X-hook options, the --chrooted-X-hook options run their
> arguments inside the chroot and thus save you quite a bit of typing. The
> --chrooted-X-hook options do a bit more than that but those things are not
> relevant here. The options are currently undocumented but I think I'll make
> them official with the next release.

Good to know. Thanks. Not relevant to me today because I don't have any
customization hooks, but I'm sure I will at some point.


> To give you an idea of why it's really far from simple to just re-run a 
> command
> run by mmdebstrap have a look at this:
>
> https://sources.debian.org/src/mmdebstrap/1.3.5-7/mmdebstrap/#L486
>
> If any of that fails, what good is an interactive shell going to do?

Yeah. Certainly for some things there isn't a simple command you can
give to an interactive shell. But for some other things, there is, like
my apt server failure. I don't have a good sense of which case is more
common.


>> > The commands should be printed if you increase verbosity with --verbose or 
>> > even
>> > with --debug. If the command is not printed, then that is a bug that I will
>> > fix.
>> 
>> Good to know. I admittedly haven't spent a ton of time working on it.
>
> I think what you ultimately want with the interactive bash shell is to figure
> out why the stuff that broke for you did break. But I can get you the same
> information by increasing either the --verbose or --debug output as necessary.

Yes and no. I can imagine that my apt server is misconfigured, and the
server will need a change to make this work. And to test potential
server fixes it would be much easier to run "apt update" repeatedly in
an interactive shell than doing a full mmdebstrap run. Doing a full run
each time can be much slower if the failing thing doesn't happen right
at the start. --verbose or --debug are good to diagnose problems, but
not to test potential fixes.


> Could you run your mmdebstrap invocation with --debug and paste(bin)
> the error you get?

Let me try to get that tomorrow.



Bug#773385: Ping

2023-05-30 Thread Dima Kogan
This really should work. It's maybe sorta ok for "apt-file list", but it
also affects "apt-file find". Look:

  dima@fatty:~$ apt-file find /usr/lib/aarch64-linux-gnu/libOpenCL.so


  dima@fatty:~$ apt-file -aarm64 find /usr/lib/aarch64-linux-gnu/libOpenCL.so

  nvidia-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1
  nvidia-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1.0.0
  ocl-icd-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1
  ocl-icd-libopencl1: /usr/lib/aarch64-linux-gnu/libOpenCL.so.1.0.0
  ocl-icd-opencl-dev: /usr/lib/aarch64-linux-gnu/libOpenCL.so

I.e. I asked it to tell me what package provides a file, and I had to
tell it which architecture to look at.

The whole point of apt-file is to look up the package name from a path,
and if I have to tell IT things like the architecture, it loses a lot of
its utility.

Thanks.



Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

2023-05-30 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> ah I see our main difference might be that I run mmdebstrap mostly
> from other scripts whereas you are running it interactively and thus
> you want a shell if something goes wrong.

I usually run it from scripts too. But if something goes wrong, I re-run
it manually, and having an easy way to get a shell at the failing point
would be nice.


>> > I'd also like to add that you can already emulate this behaviour by
>> > running a hook like this:
>> >
>> > --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'
>> 
>> I would want to add the '|| chroot "$1" bash' to everything mmdebstrap
>> does: downloading packages, installing them, doing customization hooks,
>> etc, etc. The above just applies to customization hooks, right?
>
> Oh, so you want the interactive shell on other things than failing hooks? You
> also want that shell when any command run by mmdebstrap failed?

Yessir. A shell where the failure is quickly reproduced makes fixing
problems MUCH faster. That's what sbuild does, and I've used this
countless times.


>> The actual failure I'd like to fix today is a failing "apt update"
>> trying to talk to my apt-cacher-ng server (for some reason the server
>> returns 502 only when mmdebstrap tries to talk to it). I don't believe
>> there's a nice way to debug this with mmdebstrap today, right? I tried
>> to use --SOMETHING-hook (don't remember what SOMETHING was), but it
>> wasn't clear what the exact failing command was, so I moved on to
>> something else. Printing the exact failing command for easy
>> reproducibility would be important. Maybe there's already a verbosity
>> level that does this?
>
> The commands should be printed if you increase verbosity with --verbose or 
> even
> with --debug. If the command is not printed, then that is a bug that I will
> fix.

Good to know. I admittedly haven't spent a ton of time working on it.


> For your specific problem I would first try to take mmdebstrap out of the loop
> and see if the problem can be replicated with plain apt as well.

I did that. The problem only shows up with mmdebstrap. I doubt it's a
bug in mmdebstrap, but that's the only place I see this.


> The man page contains a small shell snippet that does the essential things 
> that
> mmdebstrap does but without mmdebstrap in the section OPERATION:
>
> https://manpages.debian.org/unstable/mmdebstrap/mmdebstrap.1.en.html#OPERATION
>
> You could try if that script with your apt-cacher-ng setup produces the same
> error and then you've already reduced the number of moving parts.

I can do that. But fixing this hasn't been very high priority for me
today, so I haven't put in the work. I'm just using this as an example
of a case where the --failure-hook option would be useful.

Thanks much.



Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

2023-05-29 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> how about an option like this:
>
> --failure-hook='chroot "$1" bash'

I don't care about the exact command, as long as it's documented. This
suggestion sounds reasonable.


> Since all hooks have the MMDEBSTRAP_HOOK variable set, whatever is run in the
> hook would have access to the type of hook that failed.
>
> The information that would be missing would be *which* hook of a certain type
> was the one failing. I do not see a good way to communicate this information.

Ideally, mmdebstrap will tell you which command failed, so the user can
cut/paste the failing command to reproduce the failure. This maybe is
the most important thing to communicate? I might be missing the
subtleties of what you're thinking.


> Another question: what should be done if the failure-hook failed?

Hmmm. The obvious thing to say would be "It doesn't matter; we failed,
so mmdebstrap should just exit regardless". But maybe the hook can fix
whatever the failure was, and if the hook callback succeeds, mmdebstrap
can try again? In my usage of these in sbuild I'm always debugging
failures, so just exiting regardless is the right thing. But maybe
something smarter would be good too.


> Do you know of another software besides sbuild that has a similar interface?
> I'd like to get some more ideas first before I add another interface that
> mmdebstrap would have to support forever.

I can only thing of sbuild off the top of my head. But mmdebstrap
already has a hook system, so extending that in the way you suggested
above sounds like a self-consistent way to do it.


> I would rather not add the percent escapes from sbuild as that would
> mean that any percent sign in the hooks has to be escaped as well.
> This would break existing users of hooks.

Yeah. Let's conform to the existing mmdebstrap conventions


> I'd also like to add that you can already emulate this behaviour by
> running a hook like this:
>
> --customize-hook='chroot "$1" i-might-fail || chroot "$1" bash'

I would want to add the '|| chroot "$1" bash' to everything mmdebstrap
does: downloading packages, installing them, doing customization hooks,
etc, etc. The above just applies to customization hooks, right?

The actual failure I'd like to fix today is a failing "apt update"
trying to talk to my apt-cacher-ng server (for some reason the server
returns 502 only when mmdebstrap tries to talk to it). I don't believe
there's a nice way to debug this with mmdebstrap today, right? I tried
to use --SOMETHING-hook (don't remember what SOMETHING was), but it
wasn't clear what the exact failing command was, so I moved on to
something else. Printing the exact failing command for easy
reproducibility would be important. Maybe there's already a verbosity
level that does this?

Thanks much!



Bug#1036929: mmdebstrap: Feature request: "mmdebstrap --anything-failed-commands '%s'" should exist, like in sbuild

2023-05-29 Thread Dima Kogan
Package: mmdebstrap
Version: 1.3.3-6.1
Severity: wishlist
X-Debbugs-Cc: none, Dima Kogan 

Hi. Currently it's possible to do

  sbuild --anything-failed-commands '%s'

to get an interactive shell in response to any step of the process
failing. This makes it much easier to debug problems. It would be great
if mmdebstrap had a similar function.

I'm currently trying to debug an issue with an apt-cacher-based server
failing when mmdebstrap is pulling from it (but not when anything else
is pulling from it), and that option would make this process much
easier.

Thanks



Bug#1034881: falcosecurity-scap-dkms: Cannot compile linux kernel 6.2.12 due to failure with scap dkms

2023-04-26 Thread Dima Kogan
Hi. Thanks for the report. Debian is currently in a freeze while the
bookworm release is being prepared. bookworm is unaffected (it ships
with linux 6.1). I will look at this after the release is out (in a few
months probably).



Bug#1034414: libspectra-dev: libspectra-dev should be Multi-Arch:foreign

2023-04-14 Thread Dima Kogan
Package: libspectra-dev
Version: 1.0.1-2
Severity: normal
X-Debbugs-Cc: Dima Kogan 

Ading the "Multi-Arch:foreign" to this package would allow
cross-building for packages that depend on it. I'm hitting this when
trying to cross-build the gtsam package (not in Debian yet, but in
progress).



Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

2023-04-05 Thread Dima Kogan
> How would a resolution to this bug look like from your point of view?

An extra line in the error message that reiterates that "dh clean" runs
outside the chroot, and needs manual Build-Depends would be sufficient I
think. Then the user knows it's not a bug, and can go read the manpage
for more detail.

Even better (but more work) would be to identify the missing package.
It's almost always dh-SOMETHING. Is it easy to grep the Build-Depends
for all packages that match ^dh-.*, and say "try installing THIS and
THAT"?



Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

2023-04-03 Thread Dima Kogan
Hi


> Note though, that in the sbuild.conf man page it already says:
>
>> When running sbuild from within an unpacked source tree, run the
>> 'clean' target before generating the source package. This might
>> require some of the build dependencies necessary for running the
>> 'clean' target to be installed on the host machine. Only disable if
>> you start from a clean check‐ out and you know what you are doing.
>
> Does that paragraph say everything you would've liked to know or is
> there anything you'd add there?

That paragraph says what I would have liked to know, yes. But I never
went looking for it in the docs. If one thinks of sbuild as handling all
of the Build-Depends for you, then those failures just look like weird
bugs, and I wouldn't expect the manpage to say anything about it. Maybe
it's all fine. I don't know.



Bug#1028623: apt: "apt info" should report Multi-Arch fields

2023-04-01 Thread Dima Kogan
Thanks for replying. I get the rationale, but I'd like to find some kind
of better solution here.

DonKult just pointed out to me on IRC that I can get the output I want
with an "apt-cache show" instead of "apt show". Which is great. But it
exposes a different problem: "apt" and "apt-get","apt-cache" and friends
act VERY similarly, but have unclear differences. Before DonKult told me
about "apt-cache show" just now, I had assumed that "apt show" was a
synonym. And if I, a Debian user for decades and a DD am confused by
this, we can probably assume that almost everybody else is too.

This is probably a bigger discussion than this bug. There are ways to
improve this. For instance, you can have "apt show package" limit itself
to commonly-used fields (what it does today), with an extra note at the
bottom:

  N: Additional fields are displayed with -v

And "apt show -v package" would show everything (this is what "apt-cache
show" does?). "apt show" already has N: notes at the bottom, so this
would be consistent with the way it works today.

Adding more docs to the manpage wouldn't help: the tools take identical
options and produce 99% identical output. Anybody who sees that would
just assume the tools are the same.

Thanks



Bug#1028623: apt: "apt info" should report Multi-Arch fields

2023-04-01 Thread Dima Kogan
I just realized that it also doesn't report the Architecture field, so
it's impossible to tell if a given package is Architecture:all or not.
This info is there in /var/lib/apt/lists, so it's available to the tool.

Can we please make "apt info PACKAGE" and "apt show PACKAGE" report
these fields?

Thanks



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

2023-03-31 Thread Dima Kogan
Hi all. Thanks for the replies. I was just able to get it installed. And
here are some notes about what happened, and about how we can do better.

I got it running by using a friend's usb installer. HIS usb disk was a
valid UEFI boot disk, so I could boot in UEFI mode, and do the normal
install, which completed successfully.

As stated earlier, I made my USB install disk like this:

>  I downloaded this:
>
>debian-bookworm-DI-alpha2-amd64-netinst.iso
>
>  from here:
>
>https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/
>
>  and I wrote that .iso to /dev/sde
>
>cp debian-bookworm-DI-alpha2-amd64-netinst.iso /dev/sde

This worked, but apparently this was not a valid UEFI thing. Which I
didn't know. Maybe some clearer instructions on the website would help.
I was here:

  https://www.debian.org/devel/debian-installer/

Clicking on "amd64" under "other images (netboot, USB stick, etc.)"
gives me listings of files that I don't know what to do with. I ended up
getting the "CD" image, which gave me an .iso file that I did know what
to do with. The iso-cd page:

  https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/

has some quick instructions which maybe would be helpful for those that
don't know what to do with an .iso. It does mention UEFI, but only when
describing the "mac" image. So better UEFI notes on the iso-cd page. And
any kind of notes on the USB page would be good.


Next. Steve McIntyre suggested installing in "expert mode", and then
explicitly creating a GPT partition table. This worked, but I didn't
read his suggestion closely enough, and didn't add an ESP partition.
Because I didn't know anything about it. The installer allowed me to do
that, and once again, created an unbootable installation. Should the
installer have yelled at me? Just because I was in "expert mode" doesn't
mean I know what I'm doing :)

I guess that's it. In the default path where the installer just picks
the partition kind (MBR, GPT, ) I don't think it ever said anything
about that being a choice at all. If it at least had text somewhere
about creating an "MBR", or something, that would probably be good.

Thanks.



Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

2023-03-31 Thread Dima Kogan
Hi. Thanks for all the explanations. I just re-read this whole sequence
of emails, and I'm mostly clear on this now.

First off, I think the last email confused things a little bit. I run
sbuild on modified source, as you expect. The sequence in the previous
email was just a simple example of something that surprisingly to me
doesn't work in sbuild.

All packages I ever work on live in git. So the "clean" state is defined
as the result of "git clean -fdx && git reset --hard". I know that
sbuild can't assume git

So my workflow is usually something like

- git clean -fdx && git reset --hard
- sbuild

If I forgot the clean step above, dpkg usually yells at me. That feels
like enough, without needing a "dh clean" also.

If there's no way to make this always work in all cases, can we make the
error message better somehow? How about

  "dh clean" failed. Note: this runs outside the chroot, so the required
  Build-Depends may not be installed

Or something like that. This bit of info would have saved me some time:
I spent time looking around before filing this report. Is that
reasonable? Can we do even better?

Thanks much



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

2023-03-30 Thread Dima Kogan
Pascal Hambourg  writes:

> On 30/03/2023 at 01:21, Dima Kogan wrote:
>> I had to turn off
>> secure-boot and UEFI in the BIOS.
>
> Why ? What happens if UEFI boot is enabled ?

If UEFI was enabled, the USB device isn't seen by the machine in its
list of valid boot devices


> How did you prepare the USB drive ? What installation image did you
> use (full file name and URL please) ?

>From yesterday's email:

  I downloaded this:

debian-bookworm-DI-alpha2-amd64-netinst.iso

  from here:

https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/

  and I wrote that .iso to /dev/sde

I did "cp debian-bookworm-DI-alpha2-amd64-netinst.iso /dev/sde"


>> 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.
>
> If the installer was booted in BIOS/legacy mode, it installed GRUB for
> legacy boot.

Was this a choice the installer made, or was it the only option? I don't
actually have a workaround yet. And if the installer had a check box to
ask for a GPT even though the install media was booted without UEFI,
then I could at least get this working after some fiddling.



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

2023-03-29 Thread Dima Kogan
Hi. Thank you both for replying.


Tim Bell  writes:

> Just to confirm - you were not able to configure the USB Drive for EFI
> boot?

Correct. For whatever reason this wasn't possible in this BIOS, at least
not in any way I could figure out. Possibly I created the install media
incorrectly? I downloaded this:

  debian-bookworm-DI-alpha2-amd64-netinst.iso

from here:

  https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/

and I wrote that .iso to /dev/sde. There was no obvious "usb image", but
just using the CD image appeared to work. I could boot and run the
installer, at least with UEFI turned off.



Cyril Brulebois  writes:

> For the avoidance of doubt: which one? Alpha 1 or Alpha 2.
> Also, which image did you use?

Alpha 2. The link is above.


>> This is an amd64 recent-ish laptop. The disk is a PCIe SSD, not SATA.
>
> You have not given a single detail about that machine.

I'm trying to give relevant detail. This is a Dell Latitude 5420 rugged.
What else do you want to know?


>> I'm installing from a USB drive. To make this work, I had to turn off
>> secure-boot and UEFI in the BIOS.
>
> Why did you need that in the first place? How did you put the
> installation image onto that USB drive?

See above. Even if I didn't do this properly, installing an unbootable
OS is not very nice.


> In a nutshell, BIOS means MBR, UEFI means GPT. (This is a very gross
> oversimplification though.)

OK. Sorry, I managed to be blissfully ignorant for decades, and this is
the first time I'm touching GPT or UEFI. So I'm not well-versed in this
at all.


> I'm not sure why the firmware would allow running an installer in BIOS
> mode and not boot off from the installed system… in BIOS mode too.

You would expect the Debian installer to write an MBR partition and then
you would expect the machine (running with UEFI disabled) to be able to
use this MBR partition? I would expect this too, I think.

I'm reading Dell's notes a bit. This suggests that PICe SSD devices are
UEFI-only:

  
https://www.dell.com/support/kbdoc/en-us/000132410/what-are-pcie-ssds-and-how-to-use-them-as-a-boot-drive-for-a-dell-pc

This makes me think that installing to an MBR on the SSD on this machine
is never correct. It also makes me think that creating my install media
in a way that would make UEFI boot with it would have avoided this. But
this failure mode isn't great. Can we detect these UEFI-only drives in
any way? Can I ask the installer create a GPT instead of an MBR somehow?

Thanks



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

2023-03-29 Thread 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#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

2023-03-28 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> I fear I do not quite understand what kind of feature you are asking for. Do
> you really think it would be a good idea if sbuild, every time you run it,
> first locates a .dsc, unpacks the .dsc, compares the unpacked .dsc to your
> current directory and only invokes the clean target if it finds differences?
> Would there not almost always be differences because you only invoke sbuild
> *after* you've made some changes to the unpacked source directory? And what
> should sbuild do if it has detected changes? It would still need to run the
> clean target before it can create the new source package.
>
>> Other than that, can we run "dh clean" inside the chroot?
>
> What would that accomplish? At the point where the .dsc is unpacked
> inside the chroot, it already is clean. You need a clean unpacked
> source directory, so that you can build a .dsc so that it can be
> copied into the chroot. So this cleaning has to happen on the outside.

Those questions are all valid, of course, if you think of the .dsc as
the input to sbuild. Up until today I was not even aware that this is
how it works.

The feature I'm asking for is that on a brand-new Debian install I
think I should be able to

  1. apt install sbuild

  2. create schroot for sbuild in whatever way

  3. apt source package

  4. cd package

  5. sbuild

Today this doesn't always work, because sbuild wants to "dh clean"
outside the chroot. Omitting the "dh clean" (by relying on dpkg
complaining) would be one way to get this working. Doing the "dh clean"
inside the chroot after the Build-Depends have been installed is
another.

Maybe the above sequence shouldn't be expected to work, but that makes
sbuild less useful in my view. I can make --no-clean the default in my
config, I suppose. Probably others use sbuild in this way too? I guess I
have no way of knowing.



Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

2023-03-28 Thread Dima Kogan
Hi. Thanks for the explanation.

I have never once in my life ran sbuild from a .dsc file. In fact I
don't think I've ever done anything with .dsc files directly. I'm always
sitting on the sources, with a ../whatever.orig.tar.gz on disk.

If I've been using it wrong this whole time, I guess that's on me. But
starting from sources feels like the natural flow to me, so can we make
this work a bit better?

If we wanted to make the clean step optional, sbuild can check for
source differences, and barf if any are detected. It mostly does that
already. I believe it doesn't complain if there are extra files on disk,
but we could make it do that too.

Other than that, can we run "dh clean" inside the chroot?

Thanks!



Bug#1033626: sbuild: Dependencies should not be required outside the chroot (--no-clean should be the default)

2023-03-28 Thread Dima Kogan
Package: sbuild
Version: 0.85.2
Severity: normal

Hi. This just happened:

  dima@shorty:/tmp/opencv-4.6.0+dfsg$ sbuild -c sid-amd64 -d unstable -s -A 
--anything-failed-commands '%s'  

  dh clean
  dh: error: unable to load addon maven-repo-helper: Can't locate 
Debian/Debhelper/Sequence/maven_repo_helper.pm in @INC (you may need to install 
the Debian::Debhelper::Sequence::maven_repo_helper module) (@INC contains: 
/etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.36.0 
/usr/local/share/perl/5.36.0 /usr/lib/x86_64-linux-gnu/perl5/5.36 
/usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base 
/usr/lib/x86_64-linux-gnu/perl/5.36 /usr/share/perl/5.36 
/usr/local/lib/site_perl) at (eval 14) line 1.
  BEGIN failed--compilation aborted at (eval 14) line 1.

  make: *** [debian/rules:126: clean] Error 255
  E: Failed to clean source directory /tmp/opencv-4.6.0+dfsg 
(/tmp/opencv_4.6.0+dfsg-11.dsc)

The user expectation is that sbuild takes care of all the Build-Depends
(by installing them in the chroot), but this apparently isn't 100% true:
it runs "dh clean" outside the chroot, so any extra debhelper bits must
be installed outside.

Can we fix this by not doing anything outside the chroot that sbuild
itself doesn't Depend on? The simplest way to do that is to make
--no-clean the default. Of we can run "dh clean" inside the chroot. Can
we do something like that?

Thanks



Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

2023-03-16 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> I recently (with version 1.3.2) extended the documentation for unshare mode in
> the mmdebstrap  manual page to also cover these two files:
>
> https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/46fc269b549abe89d99e63addba0813bcbc938ac
>
> Does this answer some of the questions you had or do you think I should add
> more?

I like the docs. When debugging problems it's helpful to

- have a clear error message that says what the problem is

- have a clear connection between the error message, and a chunk of the
  docs that talks about that failure

Here I had:

W: no entry in /etc/subuid for dima
E: invalid idmap

and with the older mmdebstrap:

newuidmap: uid range [1-2) -> [10-11) not allowed
E: newuidmap 2086656  0 60017 1 1 10 1 failed: 
E: child had a non-zero exit status: 1
E: chown failed

Can we change "W: no entry in /etc/subuid for dima" to something like
"W: no entry in /etc/subuid for dima: mode=unshare will fail; see THIS
section of the docs", or maybe make it an error? If the docs contained
the exact error message we would see with this issue, that would be
super helpful too. Do you know why the older mmdebstrap has a different
error message? Is it something you changed in the code, or is there
something about that machine that's causing it?


> There are two problems:
>
>  2) whatever method you use to create new users does not create these
>  entries

I don't know why they're missing. It's an old install of sid,
continually being updated: /etc goes back to 2006! I don't think I ever
did anything funky with the users, but who knows. It's not an mmdebstrap
problem, in any case.


> I have a patch for you that should fix this problem in the sense that
> mmdebstrap should not choose the unshare mode anymore. If you like, apply the
> following to mmdebstrap from unstable:
>
> https://mister-muffin.de/p/ZwXV.diff

Neither of your patches apply to the current mmdebstrap from unstable
(I'm at 5d24b65 in the git tree). If you want me to test, you should
give me another patch. But I trust you to fix it, and I don't NEED the
patch, since I now know to fix the /etc/subuid and /etc/subgid. So you
can just apply the patch to the tree and close this bug.

Thank you very much for your help!



Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

2023-03-16 Thread Dima Kogan
I see this on a machine where the user is missing from /etc/subuid:

  dima@shorty:~$ /tmp/mmdebstrap bookworm /tmp/tst.tar.gz 
http://deb.debian.org/debian

  E: unable to pick chroot mode automatically


  dima@shorty:~$ /tmp/mmdebstrap --mode=unshare bookworm /tmp/tst.tar.gz 
http://deb.debian.org/debian

  W: no entry in /etc/subuid for dima
  E: failed to parse /etc/subuid and /etc/subgid

Is this right? Can we get better error messages? The "normal" command a
user would type is the first one, and "unable to pick chroot mode
automatically" is unhelpful. It tells the user nothing about what went
wrong, or how to even look for a solution.

Thanks.



Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

2023-03-16 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> Thank you for your feedback! How about:
>
> E: unable to pick chroot mode automatically (use --mode for manual selection)
>
> This will make the user look up the --mode argument and its possible values in
> the man page. If the user then selects --mode=unshare, the error message
> indicates what is wrong.

That's better. What's the internal logic? I guess mmdebstrap tried
"unshare", and it didn't work. Did it try all the others too, and they
didn't work also? It doesn't hurt to have ridiculously long error
messages. We COULD say

  E: unable to pick chroot mode automatically (use --mode for manual
  selection). Tried A, which didn't work because X; tried B, which
  didn't work because Y...

So if mmdebstrap already knows that --mode=unshare would produce

  W: no entry in /etc/subuid for dima
  E: failed to parse /etc/subuid and /etc/subgid

It could say that initially. Maybe that's overkill and too much typing
for you. What you have already already tells the user what to read about
and play with (--mode), so maybe that's fine.

Thanks!



Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

2023-03-16 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> The problem with ridiculously long error messages is, that mmdebstrap
> currently has no way to wrap long error messages after 80 columns or
> so. A very long error message is hard to read if it doesn't get
> wrapped similar to how you did it in your example.

I don't think this is something that mmdebstrap should be thinking
about. Error messages aren't something that needs to be immediately
fully consumable at a glance. Debugging takes time, and if we can save
the user even a bit of debugging time, then the extra minute it takes
for them to wrap the line is worth it. And does it really take any time
at all? I use either xterm or the emacs shell 100% of the time, and both
of those will wrap long lines to make them legible, without me having to
ask.


> The second reason is, that it would not be easy to store and forward
> the reason why the other modes failed. Especially the unshare mode can
> fail for 26 different reasons if I counted correctly. Letting the
> test-function silently fail when checking for the mode but extracting
> the error message would turn the code even more into spagetti.

Yeah. I was wondering if this was the case.

I think what you have is great. Ship it!

And thanks.



Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

2023-03-15 Thread Dima Kogan
Hi Josch. Thanks for replying. Notes inline



Johannes Schauer Marin Rodrigues  writes:

> Quoting Dima Kogan (2023-03-08 00:46:18)
>> Package: mmdebstrap
>> Version: 1.3.1-2
>
> where is this version from? Debian stable has 0.7.5 and testing is at
> 1.3.3.

I run sid, manually updating periodically. I guess I last updated at
1.3.1-2. The breakage doesn't appear to be version-dependent, although I
see different behaviors. I tried it on 3 machines:

- My workstation (amd64, sid, mmdebstrap=1.3.3-6.1). Works fine. It has
  this:

dima@fatty:~$ id
uid=60017(dima) gid=60017(dima) 
groups=60017(dima),4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),33(www-data),44(video),46(plugdev),108(netdev),110(lpadmin),112(x),113(scanner),119(bluetooth),131(sbuild),1002(yumsters),1003(mock),1004(pub)

dima@fatty:~$ cat /etc/subuid
systemd-timesync:10:65536
systemd-network:165536:65536
systemd-resolve:231072:65536
:296608:65536
messagebus:362144:65536
avahi:427680:65536
uuidd:493216:65536
Debian-exim:558752:65536
statd:624288:65536
avahi-autoipd:689824:65536
colord:755360:65536
dnsmasq:820896:65536
geoclue:886432:65536
rtkit:951968:65536
pulse:1017504:65536
sshd:1083040:65536
sbuild:1148576:65536
saned:1214112:65536
usbmux:1279648:65536
hplip:1345184:65536
Debian-gdm:1410720:65536
dima:1476256:65536
_apt:1541792:65536
BBB:1607328:65536
pub:1672864:65536
bitlbee:1738400:65536
testman:1803936:65536
C:1869472:65536
mysql:1935008:65536
tftp:2000544:65536
DD:2066080:65536
EE:2131616:65536
:2197152:65536
G:2262688:65536
:2328224:65536
I:2393760:65536
JJJ:2459296:65536
KK:2524832:65536
L:2590368:65536
M:2655904:65536
NNN:2721440:65536
OOO:2786976:65536
PP:2852512:65536
Q:2918048:65536
:2983584:65536
:3049120:65536
:3114656:65536
U:3180192:65536
:3245728:65536
WWW:3311264:65536
:3376800:65536


- My laptop (amd64, sid, mmdebstrap=1.3.3-6.1; same as the workstation).
  Does NOT work fine:

dima@shorty:~$ mmdebstrap bookworm /tmp/tst.tar.gz 
http://deb.debian.org/debian

I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: finding correct signed-by value...
done
I: automatically chosen format: tar
I: using /tmp/mmdebstrap.VLwVKQsx19 as tempdir
W: no entry in /etc/subuid for dima
E: invalid idmap

  The user id situation is different:

dima@shorty:~$ id
uid=1000(dima) gid=1000(dima) 
groups=1000(dima),4(adm),5(tty),6(disk),7(lp),12(man),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),44(video),50(staff),100(users),107(netdev),111(nvram),112(fuse),120(stapdev),125(postgres),129(davfs2),132(motion),137(systemd-journal),140(sbuild),145(input)

dima@shorty:~$ cat /etc/subuid
bitlbee:10:65536
stunnel4:165536:65536
sbuild:231072:65536
iodine:296608:65536
systemd-timesync:362144:65536
systemd-network:427680:65536
systemd-resolve:493216:65536
pulse:624288:65536
AAA:689824:65536
debian-tor:755360:65536
_apt:820896:65536
pub:886432:65536
BBB:558752:65536


- The server (amd64, Ubuntu 20.04, mmdebstrap=0.4.1-6). Also does not
  work fine:

kogan@cadredev:~$ mmdebstrap bookworm /tmp/tst.tar.gz 
http://deb.debian.org/debian

I: automatically chosen mode: unshare
I: chroot architecture amd64 is equal to the host's architecture
I: using /tmp/mmdebstrap.42KXYMZJtF as tempdir
newuidmap: uid range [1-2) -> [10-11) not allowed
E: newuidmap 2086656  0 60017 1 1 10 1 failed: 
E: child had a non-zero exit status: 1
E: chown failed

kogan@cadredev:~$ id
uid=60017(kogan) gid=1000(AAA) groups=1000(AAA),10773(perf),22373(BBB)

kogan@cadredev:~$ cat /etc/subuid
ssa:10:65536

  This is clearly running a much older mmdebstrap. It's also a more
  complex beast regarding users, since it's a shared server with LDAP.
  This is the machine I was complaining about originally; I had
  forgotten that it's an old distro when making the report; sorry. But
  it looks like similar failures are happening on other boxes too.

In all cases the "unshare" mode was selected. I'm guessing I need to add
an entry for my user to /etc/subuid? How is this managed? I've never
heard of this file before today, and I've certainly never added anything
to it. Why am I listed in it on one machine, but not on the other two?


>> but I don't understand the
>> problem, and would like ask here. For a little while now I've been using
>> mmdebstrap to create bookworm tarballs. This works very nicely. As a
>> non-root user I would do this:
>> 
>>   mmdebstrap  

Bug#1032809: ITP: python3-cogapp -- Cog content generation tool. Small bits of computation for static files

2023-03-11 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: python3-cogapp
  Version : 3.3.0
  Upstream Author : Ned Batchelder
* URL or Web page : https://github.com/nedbat/cog
* License : MIT
  Description : python3-cogapp



Bug#1032691: rinse: fedora-37 is not installable

2023-03-10 Thread Dima Kogan
Package: rinse
Version: 4.1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. 

This might not be a RINSE bug, but an issue with the fedora servers.
Nevertheless...

Today I can use rinse to reliably create a fedora-36 install. Just tried
it twice; worked both times.

The same command reliably fails with fedora-37. The exact failure mode
varies. Sometimes it does this:

  $ sudo rinse --distribution fedora-37 --directory root_fedora2 --arch amd64

  Failed to fetch : 
http://download.fedoraproject.org/pub/fedora/linux/releases/37/Everything/x86_64/os/Packages//z/
404 Not Found

Which is odd because navigating there with a browser works.

Sometimes it does this instead:

  $ sudo rinse --distribution fedora-37 --directory root_fedora2 --arch amd64

  [Harmless] Failed to find download link for acl
  [Harmless] Failed to find download link for alternatives
  [Harmless] Failed to find download link for audit-libs
  [Harmless] Failed to find download link for basesystem
  
  [Harmless] Failed to find download link for xz-libs
  [Harmless] Failed to find download link for zchunk-libs
  [Harmless] Failed to find download link for zlib


  Running post-install script /usr/lib/rinse/common/10-resolv.conf.sh:
  Running post-install script /usr/lib/rinse/common/15-mount-proc.sh:
  Running post-install script /usr/lib/rinse/common/20-dev-zero.sh:
  Running post-install script /usr/lib/rinse/fedora-37/post-install.sh:
Setting up DNF cache
  mv: cannot stat 'root_fedora2/*.rpm': No such file or directory
  cp: cannot stat '/var/cache/rinse//fedora-37.amd64/*': No such file or 
directory
  mv: cannot stat 'root_fedora2/etc/yum.repos.d': No such file or directory
Bootstrapping DNF
  chroot: failed to run command '/usr/bin/dnf': No such file or directory
  mv: cannot stat 'root_fedora2/etc/yum.repos.d.orig': No such file or directory
  chroot: failed to run command 'update-ca-trust': No such file or directory
Updating packages
  chroot: failed to run command '/usr/bin/dnf': No such file or directory
  chroot: failed to run command '/usr/bin/dnf': No such file or directory
  Installation complete.


It claims to have succeeded successfully, but it did not at all. This is
a bug too (it should know that it failed).

Thanks


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

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

Versions of packages rinse depends on:
ii  cpio   2.13+dfsg-7
ii  libterm-size-perl  0.211-1+b2
ii  libwww-perl6.67-1
ii  perl   5.36.0-4
ii  rpm4.17.0+dfsg1-4+b1
ii  rpm2cpio   4.17.0+dfsg1-4+b1
ii  wget   1.21.3-1+b2

rinse recommends no packages.

rinse suggests no packages.

-- no debconf information



Bug#1032689: rinse: Manpage is incorrect

2023-03-10 Thread Dima Kogan
Package: rinse
Version: 4.1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. The manpage says

  Basic usage is as simple as:

   rinse --distribution fedora-core-6 --directory /tmp/test

  This will download the required RPM files and unpack them into
  a minimal installation of Fedora Core 6.

This is incorrect. This just happened:

  $ sudo rinse --distribution fedora-37 --directory root_fedora

  The name of the architecture is mandatory.
  Please specify i386, amd64 or arm64.

So the architecture is a required argument, and the manpage should
include that in its example.

Thanks!



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

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

Versions of packages rinse depends on:
ii  cpio   2.13+dfsg-7
ii  libterm-size-perl  0.211-1+b2
ii  libwww-perl6.67-1
ii  perl   5.36.0-4
ii  rpm4.17.0+dfsg1-4+b1
ii  rpm2cpio   4.17.0+dfsg1-4+b1
ii  wget   1.21.3-1+b2

rinse recommends no packages.

rinse suggests no packages.

-- no debconf information



Bug#1032606: ITP: etlcpp -- Embedded template library: a C++ template library for embedded applications

2023-03-09 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: etlcpp
  Version : 20.35.14
  Upstream Author : John Wellbelove
* URL or Web page : https://www.etlcpp.com/
* License : MIT
  Description : Embedded template library: a C++ template library for 
embedded applications



Bug#1032489: mmdebstrap without root: newuidmap: write to uid_map failed: Operation not permitted

2023-03-07 Thread Dima Kogan
Package: mmdebstrap
Version: 1.3.1-2
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. This is almost certainly not a bug, but I don't understand the
problem, and would like ask here. For a little while now I've been using
mmdebstrap to create bookworm tarballs. This works very nicely. As a
non-root user I would do this:

  mmdebstrap   \   
bookworm   \
image.tar.gz \
http://deb.debian.org/debian

Today I tried this on a different machine. It's also running Debian, but
something is different about it, because this happens:

  mmdebstrap   \   
bookworm   \
image.tar.gz \
http://deb.debian.org/debian

  I: automatically chosen mode: unshare
  I: chroot architecture amd64 is equal to the host's architecture
  I: finding correct signed-by value...
  done
  I: automatically chosen format: tar
  I: using /tmp/mmdebstrap.hu5TsS_2_C as tempdir
  newuidmap: write to uid_map failed: Operation not permitted
  E: newuidmap 1474581  0 60017 1 1 1476256 1 failed: 
  E: child had a non-zero exit status: 1
  E: chown failed

I'm reading the "newuidmap" manpage, but the issue isn't clear to me. In
an attempt to debug, I did this on the working machine:

  strace -f -o /tmp/stlog mmdebstrap 

Doing that makes it fail with that error! So adding strace to a working
mmdebstrap invocation causes this error too.

If I just run the failing "newuidmap" command all by itself in the
shell, it consistently produces that error. This makes me think that
when mmdebstrap is working for me, it's somehow not actually running
newuidmap. I don't know why.

In all cases I see this:

  I: automatically chosen mode: unshare

The mmdebstrap manpage talks about this option, but it's still not clear
to me. Can you please comment? Is the above supposed to work? If so, any
idea why it would fail on some machines and not others? Does it make
sense that strace breaks it?

Thanks!



Bug#1032478: qemu-user-static: Python intermittently segfaults when emulating amd64 from arm64

2023-03-07 Thread Dima Kogan
Package: qemu-user-static
Version: 1:7.2+dfsg-4
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. I'm running bookworm on an arm64 machine. I have an amd64 foreign
arch enabled, and running python3:amd64 in a loop sometimes segfaults.
I'm doing this:

  for i in {1..400}; do echo $i; python3 -c "exit()"; done

I see 1-2 crashes usually. The symptoms look exactly like:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=988174

But this is emulating arm64->amd64, not the other way, like in that bug.
And the issue in that bug was /proc not being mounted, while it doesn't
appear to make a difference here.

I cannot debug deeper right now, but it appears to be very reproducible.
If nobody beats me to it in the next few weeks, I'll try to dig into it.

Thanks!



Bug#1032275: gcc-12-cross: gfortran-12-ARCH is missing Provides: virtual packages

2023-03-02 Thread Dima Kogan
Package: gfortran-12-aarch64-linux-gnu
Severity: normal
X-Debbugs-Cc: debian-cr...@lists.debian.org, Dima Kogan 
Control: affects 983600

Hi. This is the underlying cause of

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983600

Installing libopenmpi-dev:foreign is impossible because it depends on
some virtual gfortran packages that the cross-compiler is not providing.
I see this:

  # dpkg --print-architecture
  amd64

  # dpkg --print-foreign-architectures
  arm64

  # apt install libopenmpi-dev:arm64
  ...
  The following packages have unmet dependencies:
   libopenmpi-dev:arm64 : Depends: gfortran-12:arm64 but it is not going to be 
installed or
   gfortran-mod-15:arm64

  # apt show libopenmpi-dev:arm64
  Package: libopenmpi-dev:arm64
  Depends: gfortran-12 | gfortran-mod-15, ...

So to install libopenmpi-dev:arm64 we need gfortran-mod-15. This is
provided by the native compiler:

  # apt show gfortran-12 | grep Provides
  Provides: fortran95-compiler, gfortran-mod-15

But not by the cross compiler:

  # apt show gfortran-12-aarch64-linux-gnu | grep Provides
   nothing printed 

Should the cross-compiler Provide this? Or is libopenmpi-dev wrong to
Depend on it?

Thanks



Bug#1031800: mmdebstrap: --keyring doesn't work properly

2023-03-02 Thread Dima Kogan
Hi.

Johannes Schauer Marin Rodrigues  writes:

> It seems that /etc/apt/trusted.gpg is a historic relic and keys from it are
> removed by the postinst of debian-archive-keyring with the following code
> comment next to it:
>
> # remove keys from the trusted.gpg file as they are now shipped in fragment
> # files in trusted.gpg.d

OK. Good to know. Thanks for looking it up


> I probably never should've added the --keyring argument. Its documentation
> already states:
>
>> Since apt only supports a single keyring file and directory, respectively,
>> you can not use this option to pass multiple files and/or directories.

I did see that note. But for most other stuff in /etc the main config
lives in /etc/thing, and optional extra stuff lives in /etc/thing.d/ so
my (incorrect!) assumption was that the main keys live in
/etc/apt/trusted.gpg and if I added my extra thing to
/etc/apt/trusted.gpg.d/ then I'd have the full set of stuff. If we
transitioned to /etc/apt/trusted.gpg.d/ being the main set of keys, we
REALLY should delete /etc/apt/trusted.gpg to avoid any confusion.

I do think --keyring can be useful if we change what it does. mmdebstrap
can gather all the keys in all the --keyring arguments, put them all
into a new directory, feed that to Dir::Etc::TrustedParts, and put that
into /etc/apt/trusted.gpg.d/ in the final chroot. You can say that
without any --keyring arguments it uses /etc/apt/trusted.gpg and
/etc/apt/trusted.gpg.d/, but with any --keyring you have to specify them
all explicitly, including /etc/apt/


> You can create a directory and copy your keys into it, yes. But the docs for
> --keyring also suggest that you use signed-by instead. Is that not a better
> solution than copying keys from debian-archive-keyring around? If you use
> signed-by you also do not need the --keyring argument anymore.

I saw that too. I had a reason to not do that, but I now think that
reason is wrong. I was concerned that I could have different keys for
signing the repository (InRelease file) and for signing the various
packages inside it. But the only key I care about here is the
repo-signing key, so that signed-by would have been just fine, I think.

I like your documentation patch. And now that I realize that the
repository key is the main one to care about, maybe --keyring isn't
needed most of the time, as you say.

Thanks for looking at this.



Bug#1031800: mmdebstrap: --keyring doesn't work properly

2023-02-28 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> The weirdest thing about your bug is that copying your key to
> /etc/apt/trusted.gpg.d/ makes it work for you because when you changed the
> location of Dir::Etc::TrustedParts it just pointed to a different directory.
> Apt should not treat keys differently just because the path to them looks
> different...

Hi Josch. Thanks for looking into this. You're right, it sounds weird
that apt would care about the name of the directory, so I just poked at
it again.

It's not actually that weird; I just wasn't looking at the error
messages closely enough. The /etc/apt/sources.list has two repos:

- main bookworm repo. Signed with the Debian keys
- my repo. Signed with its own key

If I "mmdebstrap --keyring MY-KEY-DIRECTORY" then apt actually does find
the keys to my repo, and it's happy about it. The problem is that it
then doesn't look in /etc/apt/trusted.gpg.d and it thinks the main
bookworm repo is unverifiable. So there's no mystery here, but my use
case still doesn't work. Some questions, if I may:

- By default apt has /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/*.
  Which of these is expected to contain the keys for Debian?

- I want mmdebstrap to use the extra repo and the keys, so what's the
  right way to do that? I guess I need to:

  - Create new key directory

  - Copy /etc/apt/trusted.gpg and /etc/apt/trusted.gpg.d/* and my new
keys into it

  - Pass that to mmdebstrap --keyring

  - Add my new keys into the chroot with an mmdebstrap hook so that
these are available inside the chroot

Is that right? If so, can we make this explicit in the manpage?

Thank you very much!



Bug#1031800: mmdebstrap: --keyring doesn't work properly

2023-02-23 Thread Dima Kogan
Johannes Schauer Marin Rodrigues  writes:

> you were now able to reproduce the problem without mmdebstrap but with
> plain apt. This suggests that your problem is not an mmdebstrap
> problem.

OK. Good to know.


>> And I have another related question. I can workaround this by copying my keys
>> to /etc/apt/trusted.gpg.d/ on the host. This makes mmdebstrap happy, but the
>> resulting chroot doesn't have my keys in ITS /etc/apt/trusted.gpg.d. So an
>> "apt update" inside the chroot has the same problem as before: complaining
>> that my repo is unverifiable. The docs aren't clear on whether those keys are
>> supposed to be copied or not. Are they? If not, am I supposed to do that
>> manually via an mmdebstrap hook?
>
> mmdebstrap will not automatically copy the keys it needs to some location into
> the chroot. If your chroot needs extra key material for later "apt update" 
> runs
> it's up to you to copy the keys into the chroot at a location you like.

Thanks.




> I also think I found the source of your problem. I reproduced your issue
> locally like this:
>
> sq key generate --userid "" --export juliet.key.pgp
> sq key extract-cert --output juliet.cert.pgp juliet.key.pgp
> apt-ftparchive release . > Release
> sq sign --signer-key juliet.key.pgp --cleartext-signature --output=InRelease 
> Release
> mmdebstrap --keyring=/home/josch/repo/ --variant=apt unstable /dev/null 
> http://deb.debian.org/debian "deb copy:///home/josch/repo ./"
> [...]
> I: running apt-get update...
> done
> Get:1 copy:/home/josch/repo ./ InRelease [1190 B]
> Get:2 http://deb.debian.org/debian unstable InRelease [180 kB]
> Err:1 copy:/home/josch/repo ./ InRelease
>   The following signatures couldn't be verified because the public key is not 
> available: NO_PUBKEY FC8F3FACCD368D66
> Get:3 http://deb.debian.org/debian unstable/main arm64 Packages [9282 kB]
> Reading package lists...
> W: GPG error: copy:/home/josch/repo ./ InRelease: The following signatures 
> couldn't be verified because the public key is not available: NO_PUBKEY 
> FC8F3FACCD368D66
> E: The repository 'copy:/home/josch/repo ./ InRelease' is not signed.
>
>
> This is your problem, right?

This looks exactly like my problem, yes.


> mv juliet.cert.pgp juliet.cert.asc
>
> The clue can be found in the man page of apt-key:
>
>Alternatively, if all systems which should be using the created keyring
>have at least apt version >= 1.4 installed, you can use the ASCII
>armored format with the "asc" extension instead which can be created
>with gpg --armor --export.
>
> Can you confirm that you also had a ASCII armored key stored with the .gpg
> extension instead of .asc and that changing the extension makes apt happy?

Doesn't work for me. I exported the public key both in binary and ascii
formats, put them both in the keys/ directory (given to --keyring), and
I get the same error as before. The keys are there:

  $ file keys/KEY.{asc,gpg}

  keys/KEY.asc: PGP public key block Public-Key (old)
  keys/KEY.gpg: OpenPGP Public Key Version 4, Created Wed Feb 22 22:07:13 2023, 
RSA (Encrypt or Sign, 4096 bits); User ID; Signature; OpenPGP Certificate

And once again, I can confirm that the keys are right because copying
them (or just one) to /etc/apt/trusted.gpg.d/ makes it happy. Is there
no way to ask apt for diagnostics? Should I reassign this bug report to
apt?

Thanks



Bug#1031800: mmdebstrap: --keyring doesn't work properly

2023-02-23 Thread Dima Kogan
Hi josch. Thanks for replying!

I just ran your script up to the "apt update", having the shell
substitute $1 <- "bookworm" and $2 <- "DIRECTORY_FOR_CHROOT", and adding
my new repo:

  mkdir -p "$2/etc/apt" "$2/var/cache" "$2/var/lib"
  cat << END > "$2/apt.conf"
  Apt::Architecture "$(dpkg --print-architecture)";
  Apt::Architectures "$(dpkg --print-architecture)";
  Dir "$(cd "$2" && pwd)";
  Dir::Etc::Trusted "$(eval "$(apt-config shell v Dir::Etc::Trusted/f)"; printf 
"$v")";
  Dir::Etc::TrustedParts "$(eval "$(apt-config shell v 
Dir::Etc::TrustedParts/d)"; printf "$v")";
  END
  echo "deb http://deb.debian.org/debian/ $1 main" >  "$2/etc/apt/sources.list"
  echo "deb http://MYREPO $1 main" >> "$2/etc/apt/sources.list"

After I do this, DIRECTORY_FOR_CHROOT/apt.conf contains:

  Apt::Architecture "amd64";
  Apt::Architectures "amd64";
  Dir "/home/dima/cadre/packaging/bookworm2-tst";
  Dir::Etc::Trusted "/etc/apt/trusted.gpg";
  Dir::Etc::TrustedParts "/etc/apt/trusted.gpg.d/";

Note that the Trusted keys are in the host, NOT in the chroot, so
naturally the "apt update" complains about the missing keys. If I change
the last line to

  Dir::Etc::TrustedParts "MY_KEYRING_DIRECTORY";

then "apt update" still complains. And once again sysdig tells me that
it IS actually finding and using my keys. Suggestions?


And I have another related question. I can workaround this by copying my
keys to /etc/apt/trusted.gpg.d/ on the host. This makes mmdebstrap
happy, but the resulting chroot doesn't have my keys in ITS
/etc/apt/trusted.gpg.d. So an "apt update" inside the chroot has the
same problem as before: complaining that my repo is unverifiable. The
docs aren't clear on whether those keys are supposed to be copied or
not. Are they? If not, am I supposed to do that manually via an
mmdebstrap hook?

Thanks



Bug#1031800: mmdebstrap: --keyring doesn't work properly

2023-02-22 Thread Dima Kogan
Package: mmdebstrap
Version: 1.3.1-2
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 


Hi. I'm using mmdebstrap to bootstrap an install that uses the normal
Debian repos AND my own repo. My repo is signed with a key that lives in
$PWD/keys/something.gpg. I pass --keyring=$PWD/keys as suggested in the
docs, but this doesn't work for some mysterious reason. No clear
diagnostics are avaible, with --verbose saying nothing extra. This is
what I see:

  $ sudo mmdebstrap\
--architectures=arm64  \
--keyring=$PWD/keys\
--aptopt 'Acquire::https::MY_REPO_DOMAIN::Verify-Peer "false"' \
bookworm   \
bookworm-tst   \
http://deb.debian.org/debian   \
http://MY_REPO_DOMAIN/public/debian/bookworm

  I: automatically chosen mode: root
  I: arm64 cannot be executed natively, but transparently using qemu-user 
binfmt emulation
  I: finding correct signed-by value...
  I: automatically chosen format: directory
  I: running apt-get update...
  Get:1 https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease [5136 
B]
  Get:2 http://deb.debian.org/debian bookworm InRelease [177 kB]
  Err:1 https://MY_REPO_DOMAIN/public/debian/bookworm bookworm InRelease
The following signatures couldn't be verified because the public key is not 
available: NO_PUBKEY 221CA67104340B68
  Get:3 http://deb.debian.org/debian bookworm/main arm64 Packages [8909 kB]
  Reading package lists...
  W: GPG error: https://MY_REPO_DOMAIN/public/debian/bookworm bookworm 
InRelease: The following signatures couldn't be verified because the public key 
is not available: NO_PUBKEY 221CA67104340B68
  E: The repository 'http://MY_REPO_DOMAIN/public/debian/bookworm bookworm 
InRelease' is not signed.
  E: apt-get update --error-on=any -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false 
failed
  I: main() received signal PIPE: waiting for setup...
  E: mmdebstrap failed to run

This should work, but it doesn't. I used sysdig to confirm that
something is indeed looking in $PWD/keys/ and something is indeed
calling read() on the relevant key. I have also confirmed that if I copy
my keys to /etc/apt/trusted.gpg.d/ then it does work properly. But I
don't want to do that. Ideally I'd like mmdebstrap to grab all the keys
in $PWD/keys and add them to /etc/apt/trusted.gpg.d/ in the chroot, but
NOT on the host machine. Any clear way to do that? Any debugging tricks
I'm missing?

Thanks!

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

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

Versions of packages mmdebstrap depends on:
ii  apt  2.5.2
ii  perl 5.36.0-4
ii  python3  3.10.6-1

Versions of packages mmdebstrap recommends:
pn  arch-test
pn  fakechroot   
ii  fakeroot 1.29-1
ii  gpg  2.2.35-3
ii  libdistro-info-perl  1.1
ii  libdpkg-perl 1.21.19
ii  mount2.38.1-1
pn  uidmap   

Versions of packages mmdebstrap suggests:
pn  apt-transport-tor  
ii  apt-utils  2.5.2
ii  binfmt-support 2.2.2-1
ii  ca-certificates20211016
ii  debootstrap1.0.127
ii  distro-info-data   0.54
ii  dpkg-dev   1.21.19
pn  genext2fs  
ii  perl-doc   5.36.0-4
pn  qemu-user  
ii  qemu-user-static   1:7.0+dfsg-7+b1
pn  squashfs-tools-ng  

-- no debconf information



Bug#1031420: Acknowledgement (libgoogle-glog-dev: CMake config doesn't work out of the box)

2023-02-16 Thread Dima Kogan
Sorry for the repeated emails. I figured out the problem and fixed it.
This is a bug introduced by usrmerge. The necessary module path was
already being set, but it was trying to find /usr/share/. by a
relative traversal from /lib/. It was expecting /usr/lib, not /lib,
so the relative path had the wrong number of ../ in it. The attached
patch fixes the issue for us: Debian can just use the correct absolute
path. Upstream would presumably need to do something else, but they can
figure it out. Thanks.

--- a/CMakeLists.txt.original	2023-02-16 16:14:41.891485974 -0800
+++ b/CMakeLists.txt	2023-02-16 16:15:57.970855143 -0800
@@ -1034,24 +1034,14 @@
 
 get_filename_component (_PREFIX "${CMAKE_INSTALL_PREFIX}" ABSOLUTE)
 
-# Directory containing the find modules relative to the config install
-# directory.
-file (RELATIVE_PATH glog_REL_CMake_MODULES
-  ${_PREFIX}/${_glog_CMake_INSTALLDIR}
-  ${_PREFIX}/${_glog_CMake_DATADIR}/glog-modules.cmake)
-
-get_filename_component (glog_REL_CMake_DATADIR ${glog_REL_CMake_MODULES}
-  DIRECTORY)
-
-set (glog_FULL_CMake_DATADIR
-  ${CMAKE_CURRENT_BINARY_DIR}/${_glog_CMake_DATADIR})
+set (glog_FULL_CMake_DATADIR /usr/share/glog/cmake)
 
 configure_file (glog-modules.cmake.in
   ${CMAKE_CURRENT_BINARY_DIR}/glog-modules.cmake @ONLY)
 
 install (CODE
 "
-set (glog_FULL_CMake_DATADIR \"\\\${CMAKE_CURRENT_LIST_DIR}/${glog_REL_CMake_DATADIR}\")
+set (glog_FULL_CMake_DATADIR \"/usr/share/glog/cmake\")
 set (glog_DATADIR_DESTINATION ${_glog_CMake_INSTALLDIR})
 
 if (NOT IS_ABSOLUTE ${_glog_CMake_INSTALLDIR})


Bug#1031420: Acknowledgement (libgoogle-glog-dev: CMake config doesn't work out of the box)

2023-02-16 Thread Dima Kogan
I can "fix" this by adding to the top of
/usr/lib/x86_64-linux-gnu/cmake/glog/glog-config.cmake:

set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} /usr/share/glog/cmake/)

But this doesn't sound right. Maybe we should be shipping
/usr/share/glog/cmake/* someplace else?



Bug#1031420: libgoogle-glog-dev: CMake config doesn't work out of the box

2023-02-16 Thread Dima Kogan
Package: libgoogle-glog-dev
Version: 0.6.0-1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. I'm not a cmake expert, so this might not be a bug. It might also
not be a bug in THIS package. Apologies if that is the case.

The libgoogle-glog-dev package includes cmake scripts in

  /lib/ARCH/cmake/glog/

But they don't work by default. I have a tiny CMakeLists.txt:

  cmake_minimum_required(VERSION 3.14)
  project(test)
  find_package(glog REQUIRED)

This happens:

  /tmp/glog-test$ cmake .

  -- The C compiler identification is GNU 12.2.0
  -- The CXX compiler identification is GNU 12.2.0
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Check for working C compiler: /usr/lib/ccache/cc - skipped
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Check for working CXX compiler: /usr/lib/ccache/c++ - skipped
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  CMake Error at 
/usr/share/cmake-3.25/Modules/CMakeFindDependencyMacro.cmake:47 (find_package):
By not providing "FindUnwind.cmake" in CMAKE_MODULE_PATH this project has
asked CMake to find a package configuration file provided by "Unwind", but
CMake did not find one.

Could not find a package configuration file provided by "Unwind" (requested
version 1.3.2) with any of the following names:

  UnwindConfig.cmake
  unwind-config.cmake

Add the installation prefix of "Unwind" to CMAKE_PREFIX_PATH or set
"Unwind_DIR" to a directory containing one of the above files.  If "Unwind"
provides a separate development package or SDK, be sure it has been
installed.
  Call Stack (most recent call first):
/lib/x86_64-linux-gnu/cmake/glog/glog-config.cmake:35 (find_dependency)
CMakeLists.txt:3 (find_package)


  -- Configuring incomplete, errors occurred!
  See also "/tmp/glog-test/CMakeFiles/CMakeOutput.log".

It DOES work if I invoke it like this:

  $ cmake -DCMAKE_MODULE_PATH=/usr/share/glog/cmake/ .

I shouldn't need to do that. The package should configure everything by
itself.

Thanks!




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

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

Versions of packages libgoogle-glog-dev depends on:
ii  libgflags-dev  2.2.2-2
ii  libgoogle-glog0v6  0.6.0-1
ii  libunwind-dev  1.3.2-2

libgoogle-glog-dev recommends no packages.

libgoogle-glog-dev suggests no packages.

-- no debconf information



Bug#982864: More info

2023-02-16 Thread 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#1031098: Acknowledgement (ITP: gtsam -- sensor fusion using factor graphs)

2023-02-13 Thread Dima Kogan
A mostly complete packaging is available here:

  https://salsa.debian.org/science-team/gtsam

I still need to do a few things. Then I'll push it into experimental,
and to unstable once the bookworm transition is complete



Bug#1031099: ITP: g2o -- A General Framework for Graph Optimization

2023-02-11 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: g2o
  Version : 20201223_git
  Upstream Author : Rainer Kuemmerle
* URL or Web page : https://openslam-org.github.io/g2o.html
* License : BSD
  Description : A General Framework for Graph Optimization



Bug#1031098: ITP: gtsam -- sensor fusion using factor graphs

2023-02-11 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: gtsam
  Version : 4.2a9
  Upstream Author : frank.della...@gtsam.org
* URL or Web page : https://gtsam.org/
* License : BSD-3clause
  Description : Sensor fusion using factor graphs



Bug#1029985: devscripts: Missing Depends:python3-unidiff

2023-01-29 Thread Dima Kogan
Package: devscripts
Version: 2.22.2
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. This just happened:

  $ debdiff-apply something.debdiff

  Traceback (most recent call last):
File "/usr/bin/debdiff-apply", line 35, in 
  import unidiff
  ModuleNotFoundError: No module named 'unidiff'

Installing python3-unidiff fixes it.



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

2023-01-20 Thread 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#1029083: mrcal FTBFS with nocheck profile: ModuleNotFoundError: No module named 'numpy'

2023-01-17 Thread Dima Kogan
Thanks for checking, Helmut. After talking to you on the mailing list I
had already solved the problem, but haven't made an upload yet. Doing
that right now. Thanks.

https://lists.debian.org/debian-cross/2023/01/msg1.html



Bug#1028623: apt: "apt info" should report Multi-Arch fields

2023-01-13 Thread Dima Kogan
Package: apt
Version: 2.5.2
Severity: normal
X-Debbugs-Cc: Dima Kogan 

Hi. Currently "apt info" doesn't show all the fields describing a
package. In particular, the Multi-Arch fields are omitted, which makes
it challenging to debug issues involving those tags. Can we please add
this logic? I don't even see any other tools to do this, and I'm having
to 'apt source' the package and then look at the debian/control

Thanks!



Bug#1023692: gcc-arm-linux-gnueabihf: Compiling anything with fails: error: '_Float128' is not supported on this target

2022-11-14 Thread Dima Kogan
> No, this is totally broken. No package in Debian ships anything in
> /usr/include/bits/. If you have anything there, your system is broken
> rather than Debian.

That's exactly the kind of info I was looking for. Thank you!


> The interesting question now is where those files came from.

Easy enough.

  $ dpkg -S /usr/include/bits

  libc6-dev-i386: /usr/include/bits

That's the problematic package. I don't recall why I had this installed,
but it was there on all of my boxes.

I removed it:

  $ sudo apt remove libc6-dev-i386

  ...
  The following additional packages will be installed:
cpp-10 g++-10 gcc-10 gcc-10-base gfortran-10 lib32gcc-10-dev 
lib32stdc++-10-dev libgcc-10-dev libgfortran-10-dev
libstdc++-10-dev libx32gcc-10-dev libx32stdc++-10-dev
  The following packages will be REMOVED:
g++-10-multilib gcc-10-multilib libc6-dev-i386 libc6-dev-x32
  The following packages will be upgraded:
cpp-10 g++-10 gcc-10 gcc-10-base gfortran-10 lib32gcc-10-dev 
lib32stdc++-10-dev libgcc-10-dev libgfortran-10-dev
libstdc++-10-dev libx32gcc-10-dev libx32stdc++-10-dev

But the build still fails:

  $ arm-linux-gnueabihf-gcc-12 -c -o /tmp/tst.o /tmp/tst.c

  In file included from /tmp/tst.c:1:
  /usr/include/math.h:27:10: fatal error: bits/libc-header-start.h: No such 
file or directory
 27 | #include 
|  ^~
  compilation terminated.

Looking around, this was due to libc6-dev-armhf-cross not being
installed. I install it:

  $ sudo apt install libc6-dev-armhf-cross

  ...
  The following additional packages will be installed:
linux-libc-dev-armhf-cross
  The following NEW packages will be installed:
libc6-dev-armhf-cross linux-libc-dev-armhf-cross

And the test compile then works.

I then looked at the package relationships to see why
libc6-dev-armhf-cross wasn't pulled in. It looks like

  gcc-12-arm-linux-gnueabihf Recommends libc6-dev-armhf-cross

And for whatever reason this recommendation wasn't being satisfied on my
systems. I'm sure there's a reason this is Recommends and not Depends.
Would it break too much stuff to upgrade this to a Depends? This failure
was kinda fundamental.

Also, the libc6-dev-i386 was a red herring: I can reinstall that
package, and it can coexist nicely with the armhf-cross stuff without
breaking anything.

Thanks!



Bug#1023696: libfreeimage-dev: libfreeimage-dev should be Multi-arch:same

2022-11-08 Thread Dima Kogan
Package: libfreeimage-dev
Version: 3.18.0+ds2-8
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. This package can be marked Multi-arch:same since all the files
either are straight copies from the upstream repo (FreeImage.h) or live
in arch-specific directories:

  $ dpkg -L libfreeimage-dev

  /.
  /usr
  /usr/include
  /usr/include/FreeImage.h
  /usr/lib
  /usr/lib/x86_64-linux-gnu
  /usr/lib/x86_64-linux-gnu/libfreeimage.a
  /usr/lib/x86_64-linux-gnu/libfreeimageplus.a
  /usr/share
  /usr/share/doc
  /usr/share/doc/libfreeimage-dev
  /usr/share/doc/libfreeimage-dev/changelog.Debian.gz
  /usr/share/doc/libfreeimage-dev/changelog.gz
  /usr/share/doc/libfreeimage-dev/copyright
  /usr/lib/x86_64-linux-gnu/libfreeimage.so

Adding Multi-arch:same to that package will make it more convenient to
use.

Thanks!



Bug#1023692: gcc-arm-linux-gnueabihf: Compiling anything with fails: error: '_Float128' is not supported on this target

2022-11-08 Thread Dima Kogan
Package: gcc-arm-linux-gnueabihf
Version: 4:12.2.0-1
Severity: important
X-Debbugs-Cc: none, Dima Kogan 

Hi. I have a "tst.c" which has just one line:

  #include 

Cross-compiling it doesn't work:

  $ arm-linux-gnueabihf-gcc-12 -c -o tst.o tst.c

  In file included from tst.c:1:
  /usr/include/bits/mathcalls-helper-functions.h:20:40: error: '_Float128' is 
not supported on this target
 20 | __MATHDECL_ALIAS (int, __fpclassify,, (_Mdouble_ __value), fpclassify)
|^
  /usr/include/bits/mathcalls-helper-functions.h:24:37: error: '_Float128' is 
not supported on this target
 24 | __MATHDECL_ALIAS (int, __signbit,, (_Mdouble_ __value), signbit)
| ^
  /usr/include/bits/mathcalls-helper-functions.h:29:35: error: '_Float128' is 
not supported on this target
 29 | __MATHDECL_ALIAS (int, __isinf,, (_Mdouble_ __value), isinf)
|   ^
  /usr/include/bits/mathcalls-helper-functions.h:33:36: error: '_Float128' is 
not supported on this target
 33 | __MATHDECL_ALIAS (int, __finite,, (_Mdouble_ __value), finite)
|^
  /usr/include/bits/mathcalls-helper-functions.h:37:35: error: '_Float128' is 
not supported on this target
 37 | __MATHDECL_ALIAS (int, __isnan,, (_Mdouble_ __value), isnan)
|   ^
  /usr/include/bits/mathcalls-helper-functions.h:41:37: error: '_Float128' is 
not supported on this target
 41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y), 
iseqsig);
| ^
  /usr/include/bits/mathcalls-helper-functions.h:41:52: error: '_Float128' is 
not supported on this target
 41 | __MATHDECL_ALIAS (int, __iseqsig,, (_Mdouble_ __x, _Mdouble_ __y), 
iseqsig);
|^
  /usr/include/bits/mathcalls-helper-functions.h:44:41: error: '_Float128' is 
not supported on this target
 44 | __MATHDECL_ALIAS (int, __issignaling,, (_Mdouble_ __value), 
issignaling)
| ^

This should work.

Thanks


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

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
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 gcc-arm-linux-gnueabihf depends on:
ii  cpp-arm-linux-gnueabihf 4:12.2.0-1
ii  gcc-12-arm-linux-gnueabihf  12.2.0-3cross2

Versions of packages gcc-arm-linux-gnueabihf recommends:
pn  libc6-dev-armhf-cross | libc-dev-armhf-cross  

Versions of packages gcc-arm-linux-gnueabihf suggests:
ii  autoconf 2.71-2
ii  automake 1:1.16.5-1.3
ii  bison2:3.8.2+dfsg-1
ii  flex 2.6.4-8
ii  gcc-doc  5:12.1.0-1
pn  gdb-arm-linux-gnueabihf  
ii  libtool  2.4.7-4
ii  make 4.3-4.1
ii  manpages-dev 5.13-1

-- no debconf information



Bug#1023214: schroot: CMakeLists.txt: missing "gettext" library should be a fatal error

2022-10-31 Thread Dima Kogan
Package: schroot
Version: 1.6.13-1
Severity: normal
Hi. This is a bug in building schroot on non-Debian systems. It is NOT
an issues on Debian since we have Build-Depends: gettext

If the gettext dependency is missing, the "cmake" step succeeds with a
warning. You can still try to build, but the build fails because
gettext() is used by the code unconditionally. Thus the CMakeLists.txt
should treat a missing gettext as a fatal error, or the code should be
changed to work even without.

Thanks.



Bug#1021335: cloudcompare: GNOME applications issue a warning: "Desktop file '...' should not include extension in Icon key

2022-10-05 Thread Dima Kogan
Package: cloudcompare
Version: 2.11.3-6
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. This happens when I run unrelated applications. For instance, when
running geeqie, I see this on the console:

  Desktop file '/usr/share/applications/cloudcompare.desktop' should not 
include extension in Icon key: 'cloudcompare.png'
  Desktop file '/usr/share/applications/ccViewer.desktop' should not include 
extension in Icon key: 'ccViewer.png'

Removing the ".png" in the mentioned files makes the warning not happen.
Presumably removing the ".png" is correct? Can you please take a look?

Thanks



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

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 cloudcompare depends on:
ii  libavcodec597:5.1-3
ii  libavformat59   7:5.1-3
ii  libavutil57 7:5.1-3
ii  libc6   2.34-7
ii  libgcc-s1   12.2.0-1
ii  libgl1  1.5.0-1
ii  libglu1-mesa [libglu1]  9.0.2-1
ii  libgomp112.2.0-1
ii  libqt5concurrent5   5.15.4+dfsg-5
ii  libqt5core5a5.15.4+dfsg-5
ii  libqt5gui5  5.15.4+dfsg-5
ii  libqt5opengl5   5.15.4+dfsg-5
ii  libqt5printsupport5 5.15.4+dfsg-5
ii  libqt5widgets5  5.15.4+dfsg-5
ii  libstdc++6  12.2.0-1
ii  libswscale6 7:5.1-3
ii  zlib1g  1:1.2.11.dfsg-4.1

cloudcompare recommends no packages.

cloudcompare suggests no packages.

-- no debconf information

-- debsums errors found:
debsums: changed file /usr/share/applications/ccViewer.desktop (from 
cloudcompare package)
debsums: changed file /usr/share/applications/cloudcompare.desktop (from 
cloudcompare package)



Bug#1021158: ITP: mrbuild -- Simple build system

2022-10-02 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: mrbuild
  Version : 1.0
  Upstream Author : Dima Kogan 
* URL or Web page : https://github.com/dkogan/mrbuild
* License : MIT
  Description : Simple build system

This is the build system for mrcal, mrgingham and others



Bug#1020865: ntpsec-ntpdate: ntpdate-debian doesn't work due to missing dependency

2022-09-27 Thread Dima Kogan
Package: ntpsec-ntpdate
Version: 1.2.1+dfsg1-7+b1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. I see this:

  root@shorty:/home/dima# ntpdate-debian
  sed: can't read /etc/ntpsec/ntp.conf: No such file or directory
  ntpdig: no eligible servers

The missing file is in the "ntpsec" package, which is not in the
Depends, and maybe should be there. If I install this package I see
this:

  root@shorty:/home/dima# ntpdate-debian
  ntpdig: socket error on transmission: [Errno 99] Cannot assign requested 
address
  ntpdig: socket error on transmission: [Errno 99] Cannot assign requested 
address
  ntpdig: socket error on transmission: [Errno 99] Cannot assign requested 
address
  ntpdig: socket error on transmission: [Errno 99] Cannot assign requested 
address
  
{"time":"2022-09-27T11:54:36.227571-0700","offset":-0.001772,"precision":0.073811,"host":"0.debian.pool.ntp.org","ip":"79.133.44.139","stratum":1,"leap":"no-leap","adjusted":false}

This is probably the ipv6 bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=971523

The console output doesn't tell me if the errors were fatal or not. Were
they actually warnings? It should tell me.

Also, the output is qualitatively different from what it used to be not
very long ago. It used to be human-readable text, which told you the
time offset, and told you that the clock has been adjusted. Now it's
JSON, and I guess the clock isn't adjusted? "ntpdate-debian --help"
doesn't tell me how to make it adjust the clock. Can we make the
ntpdate-debian tool do what it did before? This is a breaking change in
behavior.

Thanks.


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

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 ntpsec-ntpdate depends on:
ii  netbase6.3
ii  ntpsec-ntpdig  1.2.1+dfsg1-7+b1

ntpsec-ntpdate recommends no packages.

ntpsec-ntpdate suggests no packages.

-- no debconf information



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

2022-09-26 Thread 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#1018809: davmail: Depends: are too weak

2022-09-02 Thread Dima Kogan
Alexandre Rossi  writes:

> The concept is:
> - for people who want to run headless, pull minimal dependencies
> - for people who want to run the graphical client, install more
> dependencies (see Suggests: default-jre, libswt-cairo-gtk-4-jni,
> libopenjfx-java)
>
> I do not see how to do it better, maybe switch to Recommends: ?

Hi. Can we produce two different packages with different depends? You
can have

  Package: davmail-headless
  Depends: default-jre-headless

  Package: davmail
  Depends: default-jre

As for what's actually in those packages, I don't know enough about java
to say. If this was normal C code, you could build two different
binaries: one that links against libgraphics-whatever and one that
doesn't.

If you can't do that, and you have only one binary, then you can use the
same binary in both pacakges, but you'd patch the sources to catch the
exceptions, and produce an error message telling the user about
installing the proper package. I think the only case to catch would be
running with the davmail-headless package without -server.

Does that sound reasonable? I don't know nearly enough about java
linking to say for sure.

Thanks



Bug#1018809: davmail: Depends: are too weak

2022-08-30 Thread Dima Kogan
Package: davmail
Version: 6.0.1.3390-1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. I'm running Debian/sid on amd64. I just did

  apt install davmail

Then this happens:

  $ davmail 

  Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load 
library: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so
  at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2633)
  

I don't have this file on my system. If this file is required for
davmail to work, then the dependencies should have pulled it in. I see:

  $ apt-file find /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so

  openjdk-11-jre: /usr/lib/jvm/java-11-openjdk-amd64/lib/libawt_xawt.so

So I guess we need

  Depends: openjdk-11-jre

Or something?

Thanks.


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

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 davmail depends on:
ii  adduser   3.118
ii  default-jre-headless [java9-runtime-headless] 2:1.11-72
ii  init-system-helpers   1.61
ii  libcommons-codec-java 1.15-1
ii  libcommons-logging-java   1.2-2
ii  libhtmlcleaner-java   2.26-1
ii  libhttpclient-java4.5.13-3
ii  libjackrabbit-java2.20.3-1
ii  libjcifs-java 1.3.19-2
ii  libjettison-java  1.4.1-1
ii  liblog4j1.2-java  1.2.17-10
ii  libmail-java  1.6.5-1
ii  libslf4j-java 1.7.32-1
ii  libstax2-api-java 4.1-1
ii  libwoodstox-java  1:6.2.1-1
ii  logrotate 3.18.1-2
ii  lsb-base  11.1.0
ii  openjdk-11-jre-headless [java9-runtime-headless]  11.0.14+9-1
ii  openjdk-15-jre-headless [java9-runtime-headless]  15.0.2+7-1

davmail recommends no packages.

Versions of packages davmail suggests:
ii  default-jre 2:1.11-72
ii  libopenjfx-java 11.0.11+0-1
pn  libswt-cairo-gtk-4-jni  

-- no debconf information



Bug#1017597: ITP: qt-advanced-docking-system -- Advanced Docking System for Qt

2022-08-18 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: qt-advanced-docking-system
  Version : 3.8.3
  Upstream Author : Uwe Kindler
* URL or Web page : 
https://github.com/githubuser0x/Qt-Advanced-Docking-System
* License : LGPL-2.1
  Description : Advanced Docking System for Qt 

Qt Advanced Docking System lets you create customizable layouts using a
full featured window docking system similar to what is found in many
popular integrated development environments (IDEs) such as Visual
Studio.



Bug#1017570: ITP: qt-color-widgets -- Qt widgets to manage color inputs

2022-08-17 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: qt-color-widgets
  Version : 2.2.0
  Upstream Author : Mattia Basaglia d...@dragon.best
* URL or Web page : https://gitlab.com/mattbas/Qt-Color-Widgets
* License : LGPL-3+
  Description : Qt widgets to manage color inputs



Bug#1017551: ITP: qcodeeditor -- A Qt widget for editing/viewing code

2022-08-17 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: qcodeeditor
  Version : 1.0+1gitdc644d
  Upstream Author : Megaxela
* URL or Web page : https://github.com/Megaxela/QCodeEditor
* License : MIT
  Description : A Qt widget for editing/viewing code.



Bug#1017500: ITP: plotjuggler -- Fast, intuitive and extensible time series visualization tool

2022-08-17 Thread Dima Kogan
Davide Faconti  writes:

> If you tell me more, maybe I can help to remove these dependencies
> (from 3rdparty I guess). Since I am embracing conan for dependencies,
> it should not be a big deal.

Hi. I think removing dependencies from the repo is a good thing to do,
but it would save me only a small bit of time. The biggest effort in
packaging is generally dependencies and copyrights.

I'm going to need to go through the dependency list, and make sure all
the dependencies are in Debian. Anything that's not tiny and not alrady
in Debian will need to be packaged. For PlogJuggler I see these
unpackaged dependencies:

- QCodeEditor
- Qt-Advanced-Docking
- color_widgets
- mcap
- sol

For the copyrights, I'd need to make sure that everything in the repo
has a clear copyright. You don't actually have a statement anywhere.
Somewhere (like in the README) you should say "Copyright YEAR
PlotJuggler contributors" or something. Then this copyright statement
and the LICENSE (that you already have) will apply to everything in your
repo, unless there are explicit notes to the contrary.

You're also shipping some stuff that clearly doesn't adhere to that
copyright statement or to your license: you have a bunch of memes in
plotjuggler_app/resources/memes. You have no idea who made these and
under what terms. I will strip those out. If you do that before I get to
it, I wouldn't need to.

I'm not going to get to this for a bit, since all the dependencies need
to be taken care of first, but it'd be great if the copyrights were
cleared up by the time I get to it.

Thanks!



Bug#1017501: ITP: sol2 -- A C++ <-> Lua API wrapper with advanced features and top notch performance

2022-08-16 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: sol2
  Version : 3.3.0
  Upstream Author : JeanHeyd Meneide 
* URL or Web page : https://github.com/ThePhD/sol2/tags
* License : MIT
  Description : A C++ <-> Lua API wrapper with advanced features and top 
notch performance



Bug#1017500: ITP: plotjuggler -- Fast, intuitive and extensible time series visualization tool

2022-08-16 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: plotjuggler
  Version : 3.6.0
  Upstream Author : Davide Faconti
* URL or Web page : https://www.plotjuggler.io/
* License : MPL-2
  Description : Fast, intuitive and extensible time series visualization 
tool

I will package this, but it will take a while for me to get to it: there
are a lot of bundled dependencies that will need to be un-bundled. If
you want to package this before me, please let me know, and please do
that!



Bug#1016516: notion: Notion fails on startup (in sid)

2022-08-15 Thread Dima Kogan
Thanks for the notes, Göran. I was mostly asking to confirm that you are
done investigating, and I should then do something to close this bug
(what, exactly, I haven't thought about very deeply yet). I'll look when
I get the chance, probably in a few weeks.



Bug#1016516: notion: Notion fails on startup (in sid)

2022-08-09 Thread Dima Kogan
Thanks, Göran and Jurij. So are we done? If we're confident, I'll upload
a new notion with the relevant Depends: and close this bug.

Thanks for your work on this!



Bug#1016516: notion: Notion fails on startup (in sid)

2022-08-03 Thread Dima Kogan
Jurij Smakov  writes:

> I tried launching notion under rr, and then this assertion does not
> trigger, unfortunately.

That's too bad. Thanks for trying it out.

This issue is a race condition, and rr inherently limits the process to
one core. Can you try "rr record --chaos"? This randomizes the thread
switching, and is often effective and triggering these kinds of failures
under rr.



Bug#1016516: notion: Notion fails on startup (in sid)

2022-08-02 Thread Dima Kogan
Jurij: thanks for the report. This issue is already tracked here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016363#15

and here:

  https://github.com/raboof/notion/issues/345

Arnout (upstream) can't reproduce it currently.

Jurij and Göran: since you can realiably see this breakage, can you get
a log to Arnout so that he can debug? One useful tool here would be the
rr debugger:

  http://rr-project.org

You can save a trace of the crashing process, which can then be replayed
forwards and backwards later. "rr pack" would make the traces portable
so that they can be replayed on another machine.



Bug#976805: Progress?

2022-07-30 Thread Dima Kogan
Hi. Is this coming along? What needs to happen to get this into the
repos? Do you need help?

Thanks!



Bug#1016134: mu4e: /usr/share/doc/mu4e/changelog.gz is not useful

2022-07-27 Thread Dima Kogan
Package: mu4e
Version: 1.8.6-1
Severity: normal
X-Debbugs-Cc: none, Dima Kogan 

Hi. With the latest mu4e package I see this:

  $ zcat /usr/share/doc/mu4e/changelog.gz

  See NEWS.org

But NEWS.org isn't shipped in the documentation. It should be shipped in
the docs instead of the changelog file. The related "maildir-utils"
package has the same problem.

Thanks!


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

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 mu4e depends on:
ii  emacsen-common  3.0.4
ii  maildir-utils   1.8.6-1

mu4e recommends no packages.

mu4e suggests no packages.

-- no debconf information



Bug#1015820: ITP: amgcl -- C header-only C++ library for solving large sparse linear systems with algebraic multigrid method

2022-07-21 Thread Dima Kogan
Package: wnpp
Owner: Dima Kogan 
Severity: wishlist

* Package name: amgcl
  Version : 1.4.3
  Upstream Author : Denis Demidov
* URL or Web page : https://github.com/ddemidov/amgcl
* License : MIT
  Description : C header-only C++ library for solving large sparse linear 
systems with algebraic multigrid method



  1   2   3   4   5   >