Jochen Sprickerhof writes:
> There is also:
>
> https://github.com/PointCloudLibrary/clang-bind
> https://pypi.org/project/pcl-py/
> https://github.com/davidcaron/pclpy
Thank you for those links. They all look unmaintained and quite
unfriendly. Do you (or anybody else?) have plans to package any
Package: python3-pcl
Version: 0.3.0~rc1+dfsg-14+b2
Severity: serious
Hello!
python3-pcl doesn't build with Python3.12: it throws many Cython errors.
I looked briefly, and fixing them appears non-trivial, at least to those
with no prior cython experience.
Upstream is dead:
https://github.com/st
I just looked at the python3-numpy = 1:2.1.1+ds-1 currently in
experimental.
Overall it works! Thanks for doing that.
I built these packages for amd64 and arm64 (natively; want to think
about one thing at a time). Then I installed python3-numpy-dev:amd64 and
python3-numpy-dev:arm64 on my amd64 ma
Hi. Thanks for replying. I don't disagree with anything you said, but I
still think this would be good at least as a commented-out-by-default
bit of config.
In my day-to-day use of the machine I routinely use
/var/cache/apt/archives to, for instance, access the previouly-installed
packages; older
Hi Timo.
I have a mostly-working prototype of a python3-numpy package that is
Multi-Arch:same. Looks like you can ALMOST avoid splitting the package,
so let's see if we can follow that path. The branch (with a single
commit at this time) is here:
https://salsa.debian.org/python-team/packages/n
Hi Timo.
> I'm not opposed to splitting the package per se, but I want to point
> out that long before I became NumPy maintainer, there used to be a
> separate python-numpy-dev package already, and I'd like to find out
> why it was discontinued and if the reason is still relevant before I
> go ah
> I THINK this is currently impossible, or at least I can't figure out a
> set of Build-Depends that would achive this result. It maybe would be
> enough to add a Multi-Arch tag, but it would be clearer to split the dev
> stuff (*.h and *.pc) into a separate package, and that package should be
> Mu
Package: schroot
Version: 1.6.13-3+b2
Severity: wishlist
Hi. This isn't a "bug", but a question/feature request.
To speed up package installs in schroots (both with sbuild and without)
I usually add /var/cache/apt/archives to the set of bind-mounts in the
fstab of most profiles. This creates a gl
t have the rights to do that. Maybe at least all DDs should
be allowed to push to their own branches?
Thanks!
>From 155d9c964f5c7ba661c7fca7e80bc004b858d520 Mon Sep 17 00:00:00 2001
From: Dima Kogan
Date: Thu, 1 Aug 2024 12:14:33 +0900
Subject: [PATCH 1/2] Documented --debug
---
bin/li
Package: python3-numpy
Version: 1:1.26.4+ds-6
Severity: normal
Hello. Currently the python3-numpy package serves at least two
independent purposes:
- To make it possible to run numpy Python code
- To support building extension modules using the C numpy API
It should be possible to install the f
Package: wnpp
Owner: Dima Kogan
Severity: wishlist
* Package name: rosbags
Version : 0.10.3
Upstream Author : Ternaris
* URL or Web page : https://gitlab.com/ternaris/rosbags
* License : Apache-2.0
Description : The pure python library for everything rosbag
It
solved yet. So
I reverted that logic, and the bug is back.
The relevant commit from git:
commit 793391d31ecd700a0913773c70591824c8e7d519
Author: Dima Kogan
Date: Fri May 24 21:18:18 2024 -0700
Reverted the use-group-to-access-scap-device patches
These patches:
5682cde Dima Kogan
I have these:
bpftrace 0.20.2-1 amd64
libbpfcc:amd640.29.1+ds-1.1 amd64
libbpfcc-dev:amd640.29.1+ds-1.1 amd64
I'm seeing this problem as well, but my error message is slightly
different.
I have a tst.c:
#include
#include
void f(int x)
{
print
Package: bpftrace
Version: 0.20.2-1
Severity: normal
Hi. This happens with "bpftrace" and "bpftrace-dbgsym" installed:
dima@shorty:~$ gdb /usr/bin/bpftrace
GNU gdb (Debian 13.2-1) 13.2
...
Reading symbols from /usr/bin/bpftrace...
(No debugging symbols found in /usr/bin/bpftrace)
(
Package: bpftrace
Version: 0.20.2-1
Severity: normal
Hi. I'm running Debian/sid. I just "apt build-dep bpftrace" and I tried
building the latest bpftrace from git. This is at the latest tag:
dima@shorty:~/debianstuff/bpftrace$ git describe --tags
debian/0.20.2-1
The build fails during the cm
Hi. Sorry it took so late to reply. I've been busy.
> I created 2 tags (v0.34 and v0.34-2, the later for some corrections I
> had to make in the debian-directory).
One minor note: there's nothing inherently wrong here, but your life
will be a bit easier if you avoid - in your upstream version st
This is this bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067398
You need both of
python3-numpy 1:1.26.4+ds-6
mrbuild 1.9
This failing build you have has the former but not the latter (you have mrbuild
1.8). What is being built? Is this Ubuntu's version of experimental? I believ
Thanks for the report, but I cannot reproduce. I upgraded my python3
install to what's currently in experimental: "python3" starts up 3.12.3,
and mrcal builds just fine.
Can I get the version of these packages please:
- mrbuild
- python3-numpy
Any other specific suggestions would be good too.
T
Hi. It looks like the current 3.18.0 release is at r1806. Are there
features in r1909 that you want that aren't in our 3.18.0?
If there are useful things there, I think it would be best to talk to
upstream about releasing a 3.19. Is upstream completely gone, or just
slow?
I added the requested profile, and fixed a few build bugs I encountered
in the process. The patch series is here:
https://salsa.debian.org/science-team/gnuplot/-/commits/bug-1067582
Anton: can you please review and upload, if it looks good? Or let me
know, and I'll make a Team upload.
OK. I see what you're saying. I can do this today or tomorrow. Anton:
are you good with that? I'd make a profile "nox-only" that elides the
gnuplot-x11 and gnuplot-qt packages.
Hi.
I might be misunderstanding what you're asking specifically, but two
notes:
- Today leptonlib Build-Depends on gnuplot-nox only if !nocheck. So if
you build leptonlib with testing disabled, there's no dependency on
gnuplot
- Today the gnuplot source package has a hard Build-Depends on wx
"Dr. Burkard Lutz" writes:
> The actual version ("0.34") is the first which contains all desired
> functions, and after extensive testing I hope that there are only
> minor bugs left.
Thanks for explaining.
> Therfore I decided to make an attempt for publishing it on debian.
> Should I rename
Thanks for pointing this out. There was a missing Depends, and I just
pushed mrbuild=1.9-2 to fix that. Works for me in sbuild now.
> You wrote: "- Each release of "galvani" should have a git tag". Does
> that mean, that every file in the release should have a tag "v_0.34"
> or similar?
Tags apply to the whole repository, not to individual files.
I'm still confused, though. Are you the author of this software? Is
there versio
I just pushed mrbuild 1.9 to use the .pc file. Thank you!
> Backporting sounds like a reasonable approach. If that does not work
> as expected, I'll restore the symlink.
Excellent. Let me know when this is done, and I'll then update mrbuild
to use it, and the builds will then work again.
I see you just tagged 1:1.26.4+ds-6 in git with the .pc stuff. I'l
Hi Timo. Thanks for replying.
My feeling is that being confused by that symlink is a bug, but I didn't
read #998084 in great detail, so maybe I'm missing some nuance. So let's
make this work.
** Short version **
Proposal: if pkg-config files will be added in the near future, can we
wait until th
Package: python3-numpy
Version: 1:1.26.4+ds-5
Severity: important
X-Debbugs-Cc: none, Dima Kogan
Hi.
Many of my packages just started to FTBFS. For instance this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067270
This is due to the
/usr/include/python3.11/numpy (and/or other
Gianfranco Costamagna writes:
> Hello, for some reasons sysdig has an hardcoded runtime dependency on
> libfalcosecurity0, now renamed in libfalcosecurity0t64. You can remove
> it and let debhelper create it via shlibs:Depends automatically
Thank you very much for catching and fixing this. The f
"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 progra
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). sal
Steve Langasek writes:
> What I'm unclear on is why you don't run vnl-gen-header at build time
> and output the "generated" header in the -dev package with a
> comprehensive description of all the ABI entry points?
Each user of libvnlog-dev would give different arguments to
vnl-gen-header, and w
Thanks for replying. I'll revert the changes.
> ... however, I will say it's very strange to ship a shared library,
> that has a public shlibs file, and has a -dev package that depends on
> it, but the headers shipped in that -dev package are NOT the
> authoritative api for that library?
That's
Hi. vnlog does not depend on time_t. Is it too late to stop this
update?
The abi-compliance-checker failure is here:
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libvnlog-dev/base/log.txt
That error message says what the problem is: you are not supposed to
#include vn
Can you see if other wxt applications work on a system that's exhibiting
this problem?
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,
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 Eige
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
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
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
Oops. I was trying to save yall time, but I guess I didn't do it right.
Please advise. Here's what happened, in order:
- 0.14.1-3 was in the archive
- 0.14.1-3.1 the NMU in experimental
- 0.14.1-4 I fixed an unrelated bug; no time64 changes
- 0.14.1-5 I added the time64 stuff to my unrelated
Thanks for the note. 0.14.1-2 makes the build work on arm64, and I
wanted to get that done, before thinking of other arches. I' about to
apply your suggested patches.
Thanks.
In case you're unaware, there're tools that can report ABI and API
breaks. I usually use abi-compliance-checker (works great). And there's
also abigail (have't tried it myself, but supposedly works well). Both
are in Debian.
Cheers.
Package: libsuitesparse-dev
Version: 1:7.3.1+dfsg-2
Severity: serious
X-Debbugs-Cc: none, Dima Kogan
Hi. I'm chasing down
http://bugs.debian.org/1060986
The problem is that mrcal uses libdogleg, which contains
typedef struct
{
cholmod_common c
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
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 u
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 jus
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 a
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
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 ca
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.
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 woul
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
Thank you very much for the report. I completely forgot about these.
Fixed just now.
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.
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" i
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
Hi. I'll gladly accept help on this. If you can do this yourself, that
would be great!
Thanks
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
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-
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-ru
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
>
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 pro
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).
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).
> 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 d
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
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-cach
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?
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, wh
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 somet
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 devic
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 dow
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
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
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
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/mave
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
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.o
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=u
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 exa
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 ru
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
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
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
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
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 ni
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 $
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
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 frag
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 differen
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
>> t
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
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 suggest
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
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?
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
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
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
1 - 100 of 476 matches
Mail list logo
