All these links points to names like foobar.png, but what's important
that they point to locations excluded by the policy (actually, the same
directory where the links reside!).
As long as the policy is in force, nothing can be installed to locations
they point to - besides more broken links, of c
In this case the links are not pointing to directories, they are
pointing to files in the same directory. So there is no excuse to
install them.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1960749
T
Sure, when I was filing the report I had no idea what's really going on
- the only indications were `dpkg -V` reporting missing files, and
broken links in /usr/share/doc.
** Description changed:
Also reported on https://github.com/tianon/docker-brew-ubuntu-
core/issues/230
Using official
And if you want to keep this behaviour, at least make sure `dpkg -V`
reports that files are missing due to a policy, not cause it's a bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1960749
Title:
This was discovered during the run of a CI, and interactive steps are
provided for the ease of reproduction, not because it's the way it was
found. If you don't know how to use Docker images interactively, it
doesn't mean they are not used this way.
Also, even if I'd agree that Docker containers a
Public bug reported:
Also reported on https://github.com/tianon/docker-brew-ubuntu-
core/issues/230
Using official Jammy image in Docker (macOS) and Podman (Fedora).
In both cases, using CLI in the image and running
apt install singular-doc
dpkg -V singular-doc
reports a lot of missing files. In
What's unusual about singular-doc_4.2.1-p3+ds-1_all.deb ? I suppose
* data.tar is compressed using zst
* it contains symbolic links within the tarball.
The data.tar.zst tarball extracted from .deb works fine in Docker image
CLI (assuming zstd is installed), so I presume it's something to do with
** Description changed:
- This option leads to various issues, see the upstream discussion on
+ This option leads to various issues, see the upstream discussion on
https://github.com/ivmai/bdwgc/issues/321
Steps to reproduction are given there.
We ran into it in Sagemath, see https://tra
Public bug reported:
This option leads to various issues, see the upstream discussion on
https://github.com/ivmai/bdwgc/issues/321
Steps to reproduction are given there.
We ran into it in Sagemath, see https://trac.sagemath.org/ticket/30629
Basically, ecl built with this libgc is broken.
** Aff
It would be great to know in more details how to get the fix mentioned
on an armhfl Ubuntu 12.10 (no, we cannot upgrade the system,
unfortunately).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/713985
This boils down to eglibc working with 8-byte floats on ARM, even if it's
declared long double.
To see this behaviour on x86, build and run the following:
#include
#include
int main ()
{
double x = 6.0;
printf("sizof(double)=%d\n",sizeof(double));
printf("lgamma (%.20f)=%.20f\n", x, lgamm
The bug is in fact in lgammal, as tgammal(x) simply takes expl(lgammal(x));
namely, lgammal(6.0) produces 4.78749174278204581157 on armel,
while it should be closer to 4.7874917427820459942477, i.e. armel gives
relative error of about 3.8e-17
--
You received this bug notification becaus
Public bug reported:
When installing the current Oneiric version (Ubuntu 11.10)
on ARM AC100 (Japanese model AZ/05M PDN01N-00H01C), as described on
https://wiki.ubuntu.com/ARM/TEGRA/AC100, choosing the Japanese keyboard hangs
the installer, as well as attempts to use keyboard recognition hang it
13 matches
Mail list logo
