This bug bites quite often when debootstrapping older Debian and/or Ubuntu
releases when trying to create chroot for testing backwards compatibility
of whatever software. It's very annoying.
Of course, either uname26 or setarch will work but both of them lack the
ability to specify a custom versio
Package: libpoppler-dev
Version: 0.16.7-2
Tags: patch
The headers in libpoppler-dev package #include headers from other dev
packages, yet these packages are not included in libpoppler-dev's
dependencies.
I think they should be at least suggested, if not depended from.
Added a patch to includ
On 10/31/2011 02:10 PM, Pino Toscano wrote:
The headers in libpoppler-dev are considered private and internal (and
unsupported), just like the libpoppler.so core library is private. If
you are using them, you are already on your own troubles.
If they are not used at all, should we remove them f
On 10/31/2011 05:03 PM, Pino Toscano wrote:
If they are not used at all, should we remove them from the dev
package?
No, given there are 16 or so sources using the poppler core API (most
were using an embedded xpdf source in the past).
I'm confused, should there not be a dependency (or sugges
Package: devscripts
Version: 2.21.3+deb11u1
Tags: patch
When I invoke `dget -a serf', I get packages not only related to
serf but also golang-github-hashicorp-serf.
This is due to dget using `apt-cache showsrc ' in its
code when it should rather use `apt-cache showsrc --only-source
'.
The issue
Guillem Jover wrote:
Just to clarify, the version in etch is not going to be updated for
this anyway, that's Debian release policy.
Didn't expect it would.
I issued a bug because I thought it would be nice to have a record of
etch dpkg-architecture breaking when the toolchain advertises itsel
Any update on this?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The error message about the source files being too old is just a
warning, everything will be generated as they should be.
Unfortunately fmtutil does not see it that way, the warning format in
the logs is identical to error messages and fmtutil interprets that as a
possible error and will act a
Frank Küster wrote:
Yes, and thanks for the patch - however, it might be easier to
convince the authors of fmtutil and add a check whether an error was
the "5 year old" warning, than to convice the LaTeX team. Or at least
faster.
That works too.
However, it would be much easier to distinguish
Here is the same patch with correct file names.
Just copy it in the debian/patches directory and include it in the
series file.
Regards,
Jussi
diff -Nur tetex-base-3.0.dfsg.3.orig/tex/latex/base/latex.ltx
tetex-base-3.0.dfsg.3/tex/latex/base/latex.ltx
--- tetex-base-3.0.dfsg.3.orig/tex/lat
Peter Eisentraut wrote:
I can't reproduce this. Can you point out a package where this happens?
Basically any package which is using old python policy.
From the diff attached to the original report, the problem can be seen
clearly. Hash (#) starts a comment in a Makefile and passing that to
Peter Eisentraut wrote:
I got that far, but I couldn't reproduce it. Please show a real example.
$ apt-get source python-cddb=1.4-3
$ cd python-cddb-1.4
$ fakeroot debian/rules clean && debian/rules build && fakeroot
debian/rules binary
/usr/share/cdbs/1/class/python-distutils.mk:104: *** unt
Package: apt-transport-https
Version: 0.7.6
When http_proxy environment variable is set, all information about proxy
is discarded. Both the information present in the environment variable
and the information in apt.conf (Acquire::http::Proxy).
It should either honor the http_proxy over the ap
Jussi Hakala wrote:
I did a little further digging and it seems that this won't happen with
etch's version of make (3.81). However, if you use older version of make
(3.80), the build will crash with the error above.
Just to clarify things a bit more, the example about the problem I
Package: cdbs
Version: 0.4.48
When a warning about not confirming to new Python policy is raised, the
build will break. This is due to the fact that hashes (#) are present in
the warning string.
Changing these to other characters, such as equal signs (=), fixes the
issue.
A patch is includ
Tim Connors <[EMAIL PROTECTED]> wrote:
> I strongly object to the proxy environment variable overriding that in
> the conf file, because the apt.conf setting is more specific and is
> purely for apt, and has likely been set by the sysadmin specifically
> to suite the properties of debian packages
Guillem Jover wrote:
Sure, no problem with that, it's always good to have bugs on file, but
the only problem here is trying to overload the meaning of armel for a
different architecture.
I understand. But surely we can choose a different name (uarmel?) and
after we've agreed with the arch nami
Package: dpkg
Version: 1.13.25
Etch's dpkg does not recognize arm-none-linux-uclibcgnueabi as a valid
architecture. Don't know if this architecture string is exactly a proper
one to begin with, but at compile time it seemed like the most
reasonable one from all the options...
Anyway, we need
Package: dpkg
Version: 1.15.0
Since version 1.15.0 version of dpkg, dpkg-buildpackage sets default
compiler flags.
This breaks some packages that used to build fine with older versions of
dpkg. The issue is basically that extra flags get expanded in the
compiler lines, causing the compilatio
A bug related to the change can be found from:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465282
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Just to clarify, when I have a package a which contains a directory b
and I release a new version from it in which I've replaced directory b
with a symlink, the user who upgrades package a from old version doesn't
get a symlink b but an empty directory b.
Assuming the directory b contained a l
Package: apt
Version: 0.7.6
Apt does not support netrc in authentication.
Although I'm unsure this is a wanted feature as-is for Debian itself, it
helps in situations when you're accessing repositories for packages not
related to the host you're using but some other target system (chroot,
scr
I'd disagree on the severity of this bug.
Tried to create a package with a compatibility symlinks on legacy
pathnames. That proved to be a poor idea, since now I'm getting empty
directories on legacy pathnames instead of symlinks when upgrading the
packages.
No even a warning about this and
Package: eglic
Version: 2.11.2-6
There's a shell script (yearistype) run during installation of time zone
specific data. Script is run through ld.so explicitly setting the
library path, thus overriding LD_LIBRARY_PATH.
Problem is that that particular command is run under fakeroot, which
uses
Package: dpkg
Version: 1.15.4.1
The dpkg determines the architecture in which it's in from a build time
constant. This makes things difficult if we use host's dpkg to operate
on packages non-native to host, for example, with scratchbox2.
It would be nice if dpkg would read DEB_HOST_ARCH for e
25 matches
Mail list logo
