Bug#1027962: dget: download binary packages that only come from the requested source package
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 can be fixed with a following change:
[~] > diff -Nur /usr/bin/dget /usr/bin/dget.patched
--- /usr/bin/dget 2021-08-18 18:02:14.0 +0300
+++ /usr/bin/dget.patched 2023-01-05 09:59:35.730472903 +0200
@@ -516,7 +516,7 @@
and $arg =~ /^([a-z0-9.+-:]{2,})(?:=([a-zA-Z0-9.:~+-]+))?$/) {
my ($source, $version, $arch) = ($1, $2);
($source, $arch) = split(/:/, $source, 2);
-my $cmd = "apt-cache showsrc $source";
+my $cmd = "apt-cache showsrc --only-source $source";
# unfortunately =version doesn't work here, and even if it did, was the
# user referring to the source version or the binary version? The code
# assumes binary version.
[~] > uname -a
Linux juno 5.10.0-19-amd64 #1 SMP Debian 5.10.149-2 (2022-10-21)
x86_64 GNU/Linux
[~] > ls -l /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 elo27 00:32
/lib/x86_64-linux-gnu/libc.so.6 -> libc-2.31.so
Bug#700884:
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 version string for uname. The generated version is always 2.6.x which will - in some cases - go to a completely different branch in a (buggy) libc6 preinst script. And eglibc is most likely not the only package now or in the future with problems like this. Would strongly recommend fixing this somehow, if nothing else, then incorporating the use of setarch with appropriate, additional command line option. It could be refined later if and when situation occurs. Regards, Jussi
Bug#646688: libpoppler-dev: missing dependencies
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 from the dev package? + libcurl4-gnutls-dev | libcurl-dev, where is curl used in the installed headers? poppler-0.16.7/poppler/CurlCachedFile.h + libpng12-dev, where is libpng used in the installed headers? poppler-0.16.7/poppler-0.16.7/goo/PNGWriter.h + libxml2-dev, where is libxml2 used in the installed headers? poppler-0.16.7/poppler/ABWOutputDev.h However, none of them seem to be installed in the latest version of the actual dev package, some of them have been before, but for example ABWOutputDev.h was dropped in 0.16.7-1 according to the changelog. + libxt-dev, that's because of XpdfPluginAPI.h? I'm not sure you would ever need to use it (and I doubt it would be of any use) -- hence no + libjpeg62-dev, + libopenjpeg-dev, these are for DCTStream.h and JPEG2000Stream.h, I guess? Usually they are not used directly even in applications using the poppler core library -- not worth more than a suggest (or they could be dropped from libpoppler-dev, since we install them while upstream doesn't) Suggesting sounds fine to me. Or just dropping everything that's not used. Regards, Jussi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646688: libpoppler-dev: missing dependencies
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 suggestion) in place for those headers that cannot be removed then? Or are these 16 sources, that are using the core api, pulling in themselves the additional dev packages they need? That's why I said installed for all of them (I suspected you were doing such search in the headers in the sources). My original patch was against earlier version of the source package in which some of those files were installed in the dev package, it seems I didn't notice all the changes between that and the latest one in sid... Regards, Jussi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#646688: libpoppler-dev: missing dependencies
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 include at least some of the dev packages which have
their headers #included. However, I'm unsure whether the added
dependency of virtual package libcurl-dev in the patch should be to
gnutls variant (like it is in the patch) or the openssl one.
Regards,
Jussi
diff -Nur old/poppler-0.16.7/debian/control new/poppler-0.16.7/debian/control
--- old/poppler-0.16.7/debian/control 2011-06-30 19:01:33.0 +0300
+++ new/poppler-0.16.7/debian/control 2011-10-26 11:31:40.461436217 +0300
@@ -41,7 +41,13 @@
Architecture: any
Section: libdevel
Depends: libpoppler13 (= ${binary:Version}),
+ libcurl4-gnutls-dev | libcurl-dev,
libfontconfig1-dev,
+ libjpeg62-dev,
+ libpng12-dev,
+ libopenjpeg-dev,
+ libxml2-dev,
+ libxt-dev,
${shlibs:Depends},
${misc:Depends}
Description: PDF rendering library -- development files
Bug#600577: eglibc: libfakeroot not found during build time
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 the same environment variable for preloading libfakeroot and thus preloading fails when that library is not found printing a number of ERROR: ld.so: object 'libfakeroot-sysv.so' from LD_PRELOAD cannot be preloaded: ignored. on the build log. It would be nice if either yearistype is not run from under fakeroot (there shouldn't be no need, but it might be easier on terms of packaging) or the libfakeroot location would be preserved with additional --library-path option given, etc. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571420: dpkg-buildpackage: issue with default compiler flags
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 compilation to fail. The old version set nothing, so there was no environment variable such as LDFLAGS present. With new dpkg, it's always present, although empty. This may cause problems in the submakes. Here's a trivial example of the problem: % env | grep FOO % make echo topmake foo: 'bar' topmake foo: bar make -C sub make[1]: Entering directory `/tmp/jhakala/make/sub' echo submake foo: '' submake foo: make[1]: Leaving directory `/tmp/jhakala/make/sub' % export FOO= % make echo topmake foo: 'bar' topmake foo: bar make -C sub make[1]: Entering directory `/tmp/jhakala/make/sub' echo submake foo: 'bar' submake foo: bar make[1]: Leaving directory `/tmp/jhakala/make/sub' So, in a case like above, if any compiler flag is set as empty as default, it will introduce any compiler flags appearing in a single makefile in their submakes. The change seems pretty fundamental shift in how dpkg-buildpackage works, right? I was able to catch this as the expanded values broke my compilation but how many packages are there that get extra flags due to this but just don't happen to choke on them? Of course, this can be labeled just as bad packaging (or in the case of the upstream software - bad design), but I feel somewhat uncomfortable about this behavioral change as it potentially gives unexpected, seemingly random results. Here's the dump of the makefiles I used: % cat Makefile FOO = bar default: echo topmake foo: '$(FOO)' make -C sub % cat sub/Makefile default: echo submake foo: '$(FOO)' Regards, Jussi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571420: (no subject)
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
Bug#556637: dpkg: support for getting architecture from DEB_HOST_ARCH
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 example to user a
chance to override this if needed.
Patch included.
diff -Nur dpkg-1.15.4.1+maemo2+0m6/src/main.c dpkg-1.15.4.1+maemo2.1/src/main.c
--- dpkg-1.15.4.1+maemo2+0m6/src/main.c 2009-11-11 21:45:25.0 +0200
+++ dpkg-1.15.4.1+maemo2.1/src/main.c 2009-11-16 14:39:59.0 +0200
@@ -155,7 +155,8 @@
}
const char thisname[]= dpkg;
-const char architecture[]= ARCHITECTURE;
+const char buildarchitecture[]= ARCHITECTURE;
+char *architecture = NULL;
const char printforhelp[]= N_(
Type dpkg --help for help about installing and deinstalling packages [*];\n
Use `dselect' or `aptitude' for user-friendly package management;\n
@@ -694,6 +695,9 @@
jmp_buf ejbuf;
static void (*actionfunction)(const char *const *argv);
+ architecture = getenv(DEB_HOST_ARCH);
+ if (!architecture) architecture = buildarchitecture;
+
setlocale(LC_ALL, );
bindtextdomain(PACKAGE, LOCALEDIR);
textdomain(PACKAGE);
diff -Nur dpkg-1.15.4.1+maemo2+0m6/src/main.h dpkg-1.15.4.1+maemo2.1/src/main.h
--- dpkg-1.15.4.1+maemo2+0m6/src/main.h 2009-11-11 21:45:25.0 +0200
+++ dpkg-1.15.4.1+maemo2.1/src/main.h 2009-11-16 14:39:15.0 +0200
@@ -131,7 +131,8 @@
extern const char *admindir;
extern const char *instdir;
extern struct pkginqueue *ignoredependss;
-extern const char architecture[];
+extern const char buildarchitecture[];
+extern char *architecture;
struct invoke_hook {
struct invoke_hook *next;
Bug#531569: (no subject)
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 warnings and errors if they actually would have some unique identifier. As it is now fmtutil will search lines that start with '! ' (applies to warnings and errors) and will return exit code different than 0, claiming that there is a potential error in the format files. I'd reckon the easiest way to change this would be to patch tex macros to output unique formatted warnings and patch fmtutil to react accordingly. Regards, Jussi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531569: (no subject)
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/latex/base/latex.ltx 2004-03-14
04:19:52.0 +0200
+++ tetex-base-3.0.dfsg.3/tex/latex/base/latex.ltx 2009-06-03
12:56:44.0 +0300
@@ -527,17 +527,17 @@
\expandafter\reser...@a\fmtversion\@nil
\ifnum\count@65
\typeout{^^J%
-!!^^J%
-! You are attempting to make a LaTeX format from a source file^^J%
-! That is more than five years old.^^J%
-!^^J%
-! If you enter return to scroll past this message then the format^^J%
-! will be built, but please consider obtaining newer source files^^J%
-! before continuing to build LaTeX.^^J%
-!!^^J%
++=^^J%
+| You are attempting to make a LaTeX format from a source file^^J%
+| That is more than five years old.^^J%
+|^^J%
+| If you enter return to scroll past this message then the format^^J%
+| will be built, but please consider obtaining newer source files^^J%
+| before continuing to build LaTeX.^^J%
++=^^J%
}
- \errhelp{To avoid this error message, obtain new LaTeX sources.}
- \errmessage{LaTeX source files more than 5 years old!}
+ \typeout{To avoid this error message, obtain new LaTeX sources.}
+ \typeout{LaTeX source files more than 5 years old!}
\fi
\let\reser...@a\relax
\fi
Bug#531569: (no subject)
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 accordingly [1]. The solution is to change the latex.ltx file so that either the warning is displayed using different format, or the time the files are considered old is changed (however, making it double makes you have the same problem after next five years). For me, something like [2] seems to solve the problem. Regards, Jussi [1] if test -f $fmtfile; then grep '^! ' $format.log /dev/null 21 log_failure \`$engine -ini $tcxflag $jobswitch $prgswitch $texargs' possibly failed. else log_failure \`$engine -ini $tcxflag $jobswitch $prgswitch $texargs' failed fi [2] http://scratchbox.org/cgi-bin/darcsweb.cgi?r=1.0/sb-doctools-devkit;a=annotate_plain;f=doctools/tetex/files/reformat-warning-old-sources.patch;h=20090602131054-902ad-469817845078f6e9328c4ed91cd7262e2df7e7be.gz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#406715: dpkg: should stop (or at least warn) when installing /usr/foobar both as dir and symlink
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 lot of files and subdirectories, any software that is unaware of the directory hierarchy changes in package a tries to search stuff from the empty directory b and will horribly break. In these cases, upgrading via removing and reinstalling package a will give a desired result (symlink b instead of empty directory b). In my opinion, dpkg should *at least* warn about this. Regards, Jussi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518473: Support for netrc
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, scratchbox environment, etc ...) And for those cases the username:password is written cleartext in the repository url in sources.list. Still in cleartext with netrc, however, but at least in a different file. Patch should be applicable as-is for apt 0.7.20.2 (lenny), but probably it needs some rethinking, something like an option in apt.conf to enable this feature or enabling this only for user-mode apt in situations like described above. diff -Nur org/apt-0.7.6/methods/https.cc new/apt-0.7.6/methods/https.cc --- org/apt-0.7.6/methods/https.cc 2008-12-15 15:58:05.0 +0200 +++ new/apt-0.7.6/methods/https.cc 2008-12-15 15:59:35.0 +0200 @@ -130,6 +130,7 @@ curl_easy_setopt(curl, CURLOPT_NOPROGRESS, false); curl_easy_setopt(curl, CURLOPT_FAILONERROR, true); curl_easy_setopt(curl, CURLOPT_FILETIME, true); + curl_easy_setopt(curl, CURLOPT_NETRC, CURL_NETRC_OPTIONAL); // FIXME: https: offer various options of verification bool peer_verify = _config-FindB(Acquire::https::Verify-Peer, false);
Bug#406715: dpkg: should stop (or at least warn) when installing /usr/foobar both as dir and symlink
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 I would've expected the install process to halt right there. The preinst solution could work with moving the old directories elsewhere and remove them on postinst after a successful installation (to support rolling back to earlier version). But is this something we want to do in all packages that have this problem? Regards, Jussi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#445985: Setting http_proxy discards proxy information altogether for https
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
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
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 naming scheme, this can be implemented properly. The proper fix (if desired) is to create a name for this supposed uclibc based architecture. Then those warnings go away by themselves. Agreed. The patch was only intended as a temporary solution. I'd rather see a working package with somewhat conflicting architecture, than no package at all and an error message when trying to build the package. I'm tempted to close this bug report unless there's someone starting a real Debian arm eabi uclibc port. Sure. However, the core problem is not entirely armel related. When we want to use something else than glibc (uClibc, Newlib, dietlibc, Klibc, ...) in any architecture, we want (generally) those packages to be of different arch than the ones built against vanilla glibc. Therefore, it would be reasonable that a uniform naming scheme would exist in the architecture names. When we have an idea what that scheme could be, we can reimplement the patch properly. Regards, Jussi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
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 itself as an uclibc toolchain. Given other conversations, I take this is for Maemo. And my same concerns apply, why do you need a new architecture? And do you realize this would imply having two different dpkg db (there's no multiarch support yet anyway)? Yes, I know. You're correct, the patch is for maemo. The bug however, is about debian. However it will be handled in maemo, is, in the end, not relevant here. Meanwhile, made this horrid patch to get the architecture recognized as armel, as with the ordinary arm+glibc equivalent. This is the completely wrong approach, I'd recommend you don't do that in Maemo either. I realize that. As I said earlier, the patch here is a quick (and ugly) fix to circumvent a problem with dpkg-architecture searching specifically for -gnueabi in architecture strings. It's not intended as a solution. It was a way to create armel packages which are built against uclibc instead of breaking down completely. Regards, Jussi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#455501: dpkg-architecture doesn't recognize arm-none-linux-uclibcgnueabi
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 a separate architecture for armel+uclibc.
Meanwhile, made this horrid patch to get the architecture recognized as
armel, as with the ordinary arm+glibc equivalent.
diff -Nur old/dpkg-1.13.25/scripts/controllib.pl new/dpkg-1.13.25/scripts/controllib.pl
--- old/dpkg-1.13.25/scripts/controllib.pl 2007-08-29 16:35:03.0 +0300
+++ new/dpkg-1.13.25/scripts/controllib.pl 2007-11-20 17:47:34.0 +0200
@@ -95,7 +95,7 @@
return $cpu;
} elsif ($os =~ /^(none|gnu)-(.*)/) {
return $2-$cpu;
-} elsif ($os-$cpu eq gnueabi-linux-arm) {
+} elsif ($cpu eq arm $os =~ /gnueabi/) {
return armel;
} else {
return $os-$cpu;
diff -Nur old/dpkg-1.13.25/ostable new/dpkg-1.13.25/ostable
--- old/dpkg-1.13.25/ostable 2007-08-29 16:35:05.0 +0300
+++ new/dpkg-1.13.25/ostable 2007-11-20 17:57:11.0 +0200
@@ -13,7 +13,7 @@
# system part of the output of the GNU config.guess script.
#
# Debian name GNU name config.guess regex
-gnueabi-linux linux-gnueabi linux[^-]*-gnueabi
+gnueabi-linux linux-gnueabi linux[^-]*-[^-]*gnueabi
gnu-linux linux-gnu linux[^-]*(-gnu)?
none-darwin darwin darwin[^-]*
none-freebsd freebsd freebsd[^-]*
Bug#157759: Bug#445985: environment proxy settings
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 -- large, and likely to be updated on a lot of machines. So if you are using apt-cacher, and all of your machines use apt-cacher for the apt proxy, then you can set it as the proxy for apt only, and everything else can keep using your squid proxy. Then the correct alternative would be to ignore http_proxy altogether. Not to ignore proxy setting in apt.conf because http_proxy is set. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439915: [Build-common-hackers] Bug#439915: Warning about Python policy breaks build process
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 a function will result in error. To reproduce this, you can do the following: $ cat /tmp/foo 'EOF' bar = $(shell echo #) all: %TAB%echo $(bar) EOF $ sed -i s/%TAB%/\t/ /tmp/foo $ make -f /tmp/foo all Regards, Jussi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439915: [Build-common-hackers] Bug#439915: Warning about Python policy breaks build process
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: *** unterminated call to function `warning': missing `)'. Stop. 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. Even though this won't be a problem for etch and beyond (sarge has 3.80), it would be nice if the cdbs makefiles would be compatible with older versions of make. I came across this problem when using Scratchbox, which is using the sarge version of make. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445985: Setting http_proxy discards proxy information altogether for https
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 apt.conf (see also
#157759) or use the one specified in the configuration, regardless
what's in the environment variable.
The issue is https only.
Included a patch to use the http_proxy whenever it's set, overriding the
apt.conf value.
--- orig/apt-0.7.6/methods/https.cc 2007-07-24 15:33:30.0 +0300
+++ new/apt-0.7.6/methods/https.cc 2007-10-09 17:16:50.0 +0300
@@ -75,6 +75,10 @@
else
Proxy = DefProxy;
}
+ else
+ {
+ Proxy = getenv(http_proxy);
+ }
// Parse no_proxy, a , separated list of domains
if (getenv(no_proxy) != 0)
Bug#439915: [Build-common-hackers] Bug#439915: Warning about Python policy breaks build process
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 provided crashes with both versions of make. When including python-distutils.mk, it crashes with the old version of make only. Why this happens, I don't know. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439915: Warning about Python policy breaks build process
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 included. Here is a transcript of the problem: $ fakeroot debian/rules clean /usr/share/cdbs/1/class/python-distutils.mk:104: *** unterminated call to function `warning': missing `)'. Stop. --- /tmp/python-distutils.mk.in 2007-08-28 14:09:41.0 +0300 +++ 1/class/python-distutils.mk.in 2007-08-28 14:10:09.0 +0300 @@ -99,12 +99,12 @@ ifndef DEB_PYTHON_SYSTEM ### old policy method ### -$(warning ) +$(warning ) $(warning Your package does not conform to the new Python policy.) $(warning Please consider updating. Here is some documentation:) $(warning http://wiki.debian.org/DebianPython/NewPolicy) $(warning http://wiki.debian.org/DebianPythonFAQ) -$(warning ) +$(warning ) # make: *** No rule to make target `voodoo'. Stop. DEB_PYTHON_REAL_LIB_PACKAGES = $(strip $(filter $(patsubst %,python%%,$(DEB_PYTHON_VERSIONS)),$(filter-out $(DEB_PYTHON_PACKAGES_EXCLUDE),$(DEB_ALL_PACKAGES
