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)
{
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
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
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
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.
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
"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
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.
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
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
"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
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).
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
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
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 Eigen that can
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
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
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 common
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
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
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
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
-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
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
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" is pro
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
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:
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
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 problems. It would
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
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
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,
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
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
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
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
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
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
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
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
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
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 nicely
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
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
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
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
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
>>
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
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
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/ARCH
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
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
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
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 mo
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
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
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
thi
> 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
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
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:
/u
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
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
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
1 - 100 of 464 matches
Mail list logo
