Bug#538639: ncurses: needlessly built twice
Package: ncurses Version: 5.7+20090613-1 Severity: normal Hi, when ncurses is built by a buildd, it is needlessly built twice. See e.g. the ia64 buildd log, where there are 8 occurences of "configure: creating ./config.status" while there should be only 4 (normal, wide, normal-dbg, wide-dbg). This is because all the "*/config.status" targets in debian/rules depend on the phony target "patch" instead of the non-phony "patch-stamp". So configure (and later make) is run one time for "debian/rules build" and another time for "debian/rules binary-arch". Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#365120: tic: undefined symbol: _tracef
Hi,
I'm porting Debian to Interix. See http://www.debian-interix.net
for details.
While porting ncurses I hit this bug.
Looking at the buildd logs for kfreebsd-i386 also shows it's appearing
there:
https://buildd.debian.org/fetch.cgi?pkg=ncurses&arch=kfreebsd-i386&ver=5.7%2B20090607-1&stamp=1247016486&file=log&as=raw
says:
dh_shlibdeps -s -Nlibncurses5 -Nlibncursesw5 \
-Nlib32ncurses5 -Nlib32ncursesw5 -Nlib64ncurses5 \
-ldebian/libncurses5/lib:debian/libncurses5/usr/lib:debian/libncursesw5/usr/lib
dpkg-shlibdeps: warning: debian/ncurses-bin/usr/bin/tic contains an
unresolvable reference to symbol _tracef: it's probably a plugin.
Looking at debian/rules, target "install" shows the problem:
# Install into our base directory
GZIP='-9' $(MAKE) -C $(objdir-debug) install
$(MAKE) -C $(wobjdir-debug) install.libs
# Copy libraries to the debug directory
[...]
# Install non -DTRACE versions.
$(MAKE) -C $(objdir) install.libs
$(MAKE) -C $(wobjdir) install.libs
So the debug version is distributed in the standard debian package,
used together with the non-debug libncurses.so. This is incorrect as
tic in the debug version uses the DEBUG macro and so the _tracef()
symbol:
progs/tic.c:check_termtype()
if (check_sgr0 != exit_attribute_mode) {
DEBUG(2,
("will trim sgr0\n\toriginal sgr0=%s\n\ttrimmed sgr0=%s",
_nc_visbuf2(1, exit_attribute_mode),
_nc_visbuf2(2, check_sgr0)));
free(check_sgr0);
} else {
DEBUG(2,
("will not trim sgr0\n\toriginal sgr0=%s",
_nc_visbuf(exit_attribute_mode)));
}
include/tic.h:
#ifdef TRACE
#define DEBUG(n, a) if (_nc_tracing >= DEBUG_LEVEL(n)) _tracef a
#else
#define DEBUG(n, a) /*nothing*/
#endif
but this is only available in the debug version of libncurses.so.
On Interix the dynamic loader isn't lazy, so I can't even start tic.
On Linux it is apparently lazy and so the error only occurs if tic is
used with a debug level high enough to call _tracef().
So instead of
$(MAKE) -C $(objdir) install.libs
debian/rules should read
GZIP='-9' $(MAKE) -C $(objdir) install
so that the non-debug non-lib programs are used.
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#500092: change breaks environments where /usr/bin is linked to /bin
Hi, on Interix (see http://www.debian-interix.net for details) /usr/bin is symlinked to /bin. In this scenario the new less package fails to install correctly as the symlink overwrites the binary. Would it be possible to take care of this situation? Thanks Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#524723: xutils-dev: Debian mkdirhier bug
Package: xutils-dev Version: 1:7.4+4 Severity: normal Hi, I'm porting Debian to Interix. See http://www.debian-interix.net for details. While porting xutils-dev I overlooked to #define MkdirHierCmd mkdir -p so the default Debian version of mkdirhier.sh was used. With mkdirhier.sh it is not possible to build - xcalendar-i18n - xcb - xpat2 - xsok - xxkb because mkdirhier fails on pathes ending in /. as in mkdirhier /build/interix601+Administrator/xsok-1.02/debian/xsok/usr/X11R6/lib/X11/. or shorter (and also on Linux): mkdirhier /tmp/mkdir1/mkdir2/. mkdir: cannot create directory `/tmp/mkdir1/mkdir2/.': File exists mkdirhier: could not create directory "/tmp/mkdir1/mkdir2/." With mkdir -p this works. Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#489430: [Build-common-hackers] Bug#489430: closed by Jonas Smedegaard (Bug#489430: fixed in cdbs 0.4.53)
On Wed, 18 Mar 2009, Frédéric Brière wrote:
On Wed, Mar 18, 2009 at 09:48:32PM +0100, Martin Koeppe wrote:
The behaviour still hasn't changed. time_1.7-23 can't still be built
Hmm, me thinks Jonas mistook r269 for something else. :)
with debhelper's dh_testroot, instead the hardcoded
test "`id -u`" = 0
is executed.
What intrigues me is that dh_testroot does (almost) just that:
if ($< != 0) {
error("You must run this as root (or use fakeroot).");
}
Why would one work but not the other?
That's not the point here. rules includes debhelper.mk, so the
maintainer apparently intends to use debhelper. If he had included
debhelper.mk first, this would be the case. Unfortunately, many
maintainers don't include debhelper.mk first as they should.
This bug is about 'wrong' inclusion order in rules, and
the current 0.4.53 still can't handle the 'wrong' order, so the bug
shouldn't be closed.
But FYI: On interix root does not have uid 0 (no POSIX requirement),
and I have patched debhelper for that. So for me it would be important
that dh_testroot is used (I think one could expect that from
debhelper.mk anyway), so I don't need to patch cdbs also and still
can use it with the many packages that use debhelper.mk, even if they
use the wrong inclusion order. For more details see also #416018 and
http://www.debian-interix.net
The post from Jonas on 2008-07-12 is about using functions, not
conditionals, but apparently this has not been done.
Notice that dh_testroot tests for the *real* UID, while buildcore.mk
tests for the *effective* UID. Does this explain the discrepancy?
(What does "id -ru" return for you?)
No, it doesn't matter, see above.
Martin
Bug#489430: closed by Jonas Smedegaard (Bug#489430: fixed in cdbs 0.4.53)
On Tue, 17 Mar 2009, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the cdbs package: #489430: cdbs: debhelper usage It has been closed by Jonas Smedegaard . The behaviour still hasn't changed. time_1.7-23 can't still be built with debhelper's dh_testroot, instead the hardcoded test "`id -u`" = 0 is executed. Martin Automatic build of time_1.7-23 on interix35 by sbuild/interix-i386 0.53 Build started at 20090318-2224 ** time_1.7-23.dsc exists in cwd ** Using build dependencies supplied by package: Build-Depends: debhelper (>> 4.1.0), texi2html, texinfo, automaken, cdbs Checking for already installed source dependencies... debhelper: already installed (7.0.13-0+interix.1 >> 4.1.0 is satisfied) texi2html: missing texinfo: already installed (4.8.dfsg.1-6) automaken: already installed (=*=PROVIDED=*=) cdbs: already installed (0.4.53) Checking for source dependency conflicts... Reading package lists... Building dependency tree... Suggested packages: latex2html The following NEW packages will be installed: texi2html 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0B/347kB of archives. After unpacking 1452kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! texi2html Authentication warning overridden. Selecting previously deselected package texi2html. (Reading database ... 7412 files and directories currently installed.) Unpacking texi2html (from .../texi2html_1.78-1+interix.1_all.deb) ... Setting up texi2html (1.78-1+interix.1) ... Checking correctness of source dependencies... Kernel: Interix 3.5 interix-i386 (x86) -- gpg: Please note that you don't have secure memory on this system gpg: Signature made Mon Jul 21 12:59:26 2008 Westeuropä using DSA key ID 817A996A gpg: Can't check signature: public key not found dpkg-source: extracting time in time-1.7 dpkg-source: info: unpacking time_1.7.orig.tar.gz dpkg-source: info: applying time_1.7-23.diff.gz dpkg-buildpackage: set CFLAGS to default value: -g -O2 dpkg-buildpackage: set CPPFLAGS to default value: dpkg-buildpackage: set LDFLAGS to default value: dpkg-buildpackage: set FFLAGS to default value: -g -O2 dpkg-buildpackage: set CXXFLAGS to default value: -g -O2 dpkg-buildpackage: source package time dpkg-buildpackage: source version 1.7-23 dpkg-buildpackage: host architecture interix-i386 /usr/local/bin/fakesudo debian/rules clean test -x debian/rules test "`id -u`" = 0 make: *** [testroot] Error 1 dpkg-buildpackage: failure: /usr/local/bin/fakesudo debian/rules clean gave error exit status 2 ** Build finished at 20090318-2225 FAILED [dpkg-buildpackage died] -- (Reading database ... 7516 files and directories currently installed.) Removing texi2html ... ** Finished at 20090318-2225 Build needed 00:00:08, 0k disk space
Bug#514762: quixote: packaging bug
Package: quixote Version: 2.5-3 Severity: normal When building quixote with sbuild, it reports: ERROR: Package builds python-quixote-doc_2.5-3_all.deb when binary-indep target is not called. This is a bug in the packaging. See e.g. ia64 buildd log for verification. Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514692: freespeak: should be arch all
Package: freespeak Version: 0.3.0-2 Severity: normal Is there a reason why the binary package from src pkg freespeak is not arch:all? I can't see any arch specific files in the package. Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514562: libmcrypt: new upstream version 2.5.8 available
Package: libmcrypt Version: 2.5.7-5.1 Severity: wishlist There is a new upstream version available (2.5.8). Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514522: cddlib: cdbs warning: remove config.{guess,sub}
Package: cddlib
Version: 094b.dfsg-4
Severity: normal
When building cddlib a warning is printed:
/usr/share/cdbs/1/rules/patchsys-quilt.mk:92: WARNING: The following
patches are modifying auto-updated files. This can result in serious
trouble:
/build/buildd/cddlib-094b.dfsg/debian/patches/cddlib-shared-library.patch:src/config.guess
/build/buildd/cddlib-094b.dfsg/debian/patches/cddlib-shared-library.patch:src/config.sub
See any buildd log for verification.
So probably config.{guess,sub} are not necessary in the patch and cdbs
can update them while building.
As the *.orig.tar.gz seems to be modified anyway, these files/dirs
should be removed also:
autom4te.cache/
aclocal.m4~
config.log
config.status
Thanks for consideration
Martin
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#309405: workaround
On Wed, 24 Dec 2008, Moritz Muehlenhoff wrote: reassign 309405 linux-2.6 thanks On Sat, Oct 01, 2005 at 02:50:48PM +0200, Martin Koeppe wrote: Hello, in between I managed to work around the problem. With cifs 1.34 compiled into 2.6.11 (and probably 2.6.12, too), a acceptable performance can be achieved with mount option "direct". For further plans and (hopefully) the final fix for the problem see: http://lists.samba.org/archive/linux-cifs-client/2005-September/000989.html http://lists.samba.org/archive/linux-cifs-client/2005-September/000991.html In between this bug should remain open. Has this been resolved in current kernels? I don't use linux-cifs any more since 2 years, instead I use MS NFS server on the server, which is much more reliable for me. But I have now tested this problem, and it is still there: Client: Debian lenny, 2.6.26, cifs 1.56 Server: Windows 2003 x64 SP2 Gigabit LAN # mount //server/scratch /mnt -o serverino,user=...,pass=... With this mount I still get decreasing performance while copying a large file (600MB) from client to server (i.e. write to the share). (I used Midnight Commander (mc) for copying, and its throughput measurement.) Apparently the file is cached locally first, and this cache is then swapped out, later swapped in, and then transferred, causing increasing delays while copying. No problem when adding "directio". Disk activity for the non-directio case is very high on the client, compared to the directio case. NFS read 18 MB/s NFS write 15 MB/s CIFS directio read 14 MB/s CIFS directio write 14 MB/s CIFS non-directio read 17 MB/s CIFS non-directio write 9 MB/s * * begins with 19 MB/s and then constantly decreases to 9 MB/s for the whole transfer in average. Martin Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#491090: kimwitu++: missing build dep
On Fri, 25 Jul 2008, Michael Piefel wrote: Martin Koeppe schrieb: Attached you find the log from sbuild. Maybe you see the problem immediately from that. I don't have more details currently, as the unpacked source has already been deleted automatically. The log looks very innocent to me, up to the point were bison is called. It should not, however, since the bison results in the distribution are newer than the bison source. One thing that can possibly go wrong is the preservation of attributes in the »cp -p« call. Assuming that it does not work, the copy order makes the source newer than the product. That should be fixable by swapping lines 199 and 200 with 201 and 202 in the Makefile. You are right. cp -p is indeed not working correctly. I need to look into it. However, your suggestion of swapping the lines in Makefile.in works ok, and as you happen to be the upstream author as well, I would vote for doing the line-swapping upstream. For getting a successful build on interix I had to do some more adjustments, which you might consider applying upstream as well: - configure.ac: use AC_USE_SYSTEM_EXTENSIONS (Interix needs -D_ALL_SOURCE for the strcasecmp() declaration to be visible) - use autoconf 2.62, as this one has an updated AC_USE_SYSTEM_EXTENSIONS for interix - recreate config.h.in - adjust k.h to include config.h first You can find my patch here: http://www.debian-interix.net/debian-interix/pool/unreleased35/main/k/kimwitu++/ See the *.interdiff.gz Martin
Bug#491090: kimwitu++: missing build dep
On Thu, 24 Jul 2008, Michael Piefel wrote:
kimwitu++ should build-dep on bison, as it uses it during build.
No, it doesnt normally. Apart from src/kimwy.y, Kimwitu++ comes with
src/Gen.boot/kimwy.{cc,h,output}, all of which are 5 minutes younger
than their source. Bison is not called if you did not touch
anything. I not only proved it, I actually tried it.
Please have a close look on the environment that you used and that
caused the build process to call Bison. If you can reproduce it, I
want to find a way to fix it (without the build-dep).
I tried to auto-build kimwitu++ for interix-i386, see
http://www.debian-interix.net/ for more details on that
architecture.
Attached you find the log from sbuild. Maybe you see the problem
immediately from that. I don't have more details currently, as the
unpacked source has already been deleted automatically.
Please ignore this line:
/dev/null: line 1: ./configure:: No such file or directory
Apparently all build logs have it, and I currently don't know what
causes it, and apparently it has no ill effects, at least none that I
know of. Hopefully this is not the same problem :-)
If you still can't figure out, what the problem is, I'll investigate
further to find it, but this will probably not happen before Aug 20,
2008.
Interix has several unusual properties, so this build might have hit
one of those.
Thanks for your cooperation
MartinAutomatic build of kimwitu++_2.3.12-1 on interix60 by sbuild/interix-i386 0.53
Build started at 20080716-1633
**
Checking available source versions...
Fetching source files...
Reading package lists...
Building dependency tree...
Need to get 570kB of source archives.
Get:1 http://ftp.de.debian.org unstable/main kimwitu++ 2.3.12-1 (dsc) [688B]
Get:2 http://ftp.de.debian.org unstable/main kimwitu++ 2.3.12-1 (tar) [565kB]
Get:3 http://ftp.de.debian.org unstable/main kimwitu++ 2.3.12-1 (diff) [4070B]
Fetched 570kB in 1s (349kB/s)
Download complete and in download only mode
** Using build dependencies supplied by package:
Build-Depends: debhelper (>= 5.0.0)
Build-Depends-Indep: docbook-xml, docbook-xsl, gs, texlive,
texlive-latex-extra, transfig, xsltproc
Checking for already installed source dependencies...
debhelper: already installed (7.0.13-0+interix.1 >= 5.0.0 is satisfied)
Checking for source dependency conflicts...
Checking correctness of source dependencies...
Kernel: Interix 6.0 interix-i386 (x86)
--
sh: gcc: command not found
dpkg-source: warning: Couldn't determine gcc system type, falling back to
default (native compilation)
gpg: Please note that you don't have secure memory on this system
gpg: Signature made Wed Feb 13 21:02:49 2008 WEST using DSA key ID 798DD95C
gpg: Can't check signature: public key not found
dpkg-source: extracting kimwitu++ in kimwitu++-2.3.12
dpkg-source: unpacking kimwitu++_2.3.12.orig.tar.gz
dpkg-source: applying
/srv/wanna-build/buildd-home/build/kimwitu++_2.3.12-1.diff.gz
dpkg-buildpackage: source package kimwitu++
dpkg-buildpackage: source version 2.3.12-1
dpkg-buildpackage: host architecture interix-i386
/usr/local/bin/fakesudo debian/rules clean
dh_testdir src/gen.k
dh_testroot
rm -f build-stamp build-doc-stamp
# Add here commands to clean up after the build process.
/usr/bin/make clean
make[1]: Entering directory `/build/interix60+Administrator/kimwitu++-2.3.12'
make[1]: *** No rule to make target `clean'. Stop.
make[1]: Leaving directory `/build/interix60+Administrator/kimwitu++-2.3.12'
make: [clean] Error 2 (ignored)
cd doc && /usr/bin/make veryclean
make[1]: Entering directory
`/build/interix60+Administrator/kimwitu++-2.3.12/doc'
rm -f *.aux *.log *.toc *.dvi *.out *.idx *.ind *.loe *.ilg *.fot *.fo
rm -f ._ ._
rm -rf imagesgen
rm -f manual.tex manual.pdf manual.html
make[1]: Leaving directory `/build/interix60+Administrator/kimwitu++-2.3.12/doc'
rm -f Makefile src/Makefile
rm -f config.log config.status src/config.h
dh_clean
debian/rules build
dh_testdir src/gen.k
# Add here commands to compile the package.
./configure --prefix=/usr --mandir=/usr/share/man
configure: loading cache /dev/null
/dev/null: line 1: ./configure:: No such file or directory
checking whether a universal binary is requested... no
checking for g++... g++
checking for C++ compiler default output file name... a.out
checking whether the C++ compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for flex... no
checking for lex... no
checking for bison... no
Bug#491090: kimwitu++: missing build dep
Package: kimwitu++ Version: 2.3.12-1 Severity: normal kimwitu++ should build-dep on bison, as it uses it during build. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#491031: debian-edu: should be arch all
Package: debian-edu Version: 0.836 Severity: normal Is there a reason why the binary packages from src pkg debian-edu are not arch:all? I can't see any arch specific files in the packages. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489430: cdbs: debhelper usage
Hi, I have done some more grepping in my buildd logs and found the following packages having problems with debhelper.mk not being included first, just for information. There are probably much more, but I haven't built all packages used as Build-Deps yet for my debian-interix port, see http://www.debian-interix.net for more info. Martin alevt 1:1.6.1-10 amideco 0.31e-3 asn1c 0.9.21.dfsg-3.1 autossh 1.4a-3 awardeco 0.2-3 bfbtester 2.0.1-7.1 biosquid 1.9g+cvs20050121-2 blktool 4-4 bluez-libs 3.33-1 cdtool 2.1.8-release-1 cfourcc 0.1.2-3 chase 0.5.2-3 chemtool 1.6.11-2 clucene-core 0.9.20-3 cxxtools 1.4.8-2 dgpsip 1.35-1 dns2tcp 0.4.dfsg-1 dvbackup 0.0.4rj1-6.1 epcr 2.3.10-1 fam 2.7.0-13.3 fastdnaml 1.2.2-7 fprobe-ulog 1.1-7 freecell-solver 2.8.10-1 ftpgrab 0.1.2r-9.1 garlic 1.6-1 gdpc 2.2.4-3 hdparm 8.9-1 irqbalance 0.55-2.1 jamvm 1.5.1-3 keynote 2.3-11 leafpad 0.8.13-1 libcapsinetwork 0.3.0-5 libgd-gd2-noxpm-perl 1:2.35-1 libgd-gd2-perl 1:2.35-1 libgfshare 1.0.2-1 libgksuui1.0 1.0.7-2 libmath++ 0.0.4-3 libmodelfile 0.1.92-2 libp11 0.2.3-2 libsexy 0.1.11-2 libspf2 1.2.5.dfsg-5 libsrs2 1.0.18-4 libsynaptics 0.14.6c-2 libtabe 0.2.6-1.1 libtextcat 2.2-2 libtsmux 0.2.0-1 link-grammar 4.2.5-1 lksctp-tools 1.0.8.dfsg-2 loadmeter 1.20-5 log4cpp 1.0-4 loki 2.4.7.4-4 lua-filesystem 1.4.1-1 lua-lpeg 0.8.1-1 lua-posix 5.1.2-3 lua-rings 1.2.1-1 m16c-flash 0.1-1 mdf2iso 0.3.0-1 mg 20070918-2 mozplugger 1.10.2-1 mpc 0.12.1-1 mtpaint 3.11-1 mummer 3.20-2 ndisc6 0.9.7-1 pcf2bdf 1.04-2 phalanx 22+d051004-6 phnxdeco 0.33-3 polipo 1.0.4-1 primer3 1.1.4-1 pscan 1.2-8 qpdf 2.0.1-3 radvd 1:1.1-2 sdparm 1.02-1 serveez 0.1.5-2.1 shared-mime-info 0.30-2 silgraphite2.0 1:2.2.1-2.1 simplelist 0.3.4-2 slang-slirp 1.9.5-1 slexpat 0.5.0-1 slgdbm 1.7.1-3 slhist 0.3.2a-2 slwildcard 0.5.0-1 soundtouch 1.3.1-2 sqlite3 3.5.9-2 sqlite 2.8.17-4 squashfs 1:3.3-7 starttls 0.10-3 sudoku 1.0.1-3 tigr-glimmer 3.02-1 time 1.7-21 ubuntulooks 0.9.12-2 vdmfec 1.0-2 vrflash 0.24-4 wavpack 4.41.0-2 windowlab 1.33-4 wmix 3.1-4 xbubble 0.5.11.2-1 xerces-c2 2.8.0-1 xmountains 2.7-8 xtron 1.1a-13 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489430: [Build-common-hackers] Bug#489430: cdbs: debhelper usage
On Sat, 12 Jul 2008, Jonas Smedegaard wrote: On Mon, Jul 07, 2008 at 01:25:38PM +0200, Peter Eisentraut wrote: Am Samstag, 5. Juli 2008 schrieb Martin Koeppe: See package time 1.7-21 as example. Its rules says: include /usr/share/cdbs/1/class/autotools.mk include /usr/share/cdbs/1/rules/debhelper.mk i.e. debhelper.mk is included after autotools.mk. In this configuration buildcore.mk doesn't know that debhelper is to use and so doesn't use dh_testroot. It is documented that you should include debhelper.mk first. If you don't, things will degrade, albeit smoothly. I don't know if there is anything more we need to do about it. Conditionals (like ifdef) are evaluated earlier than functions (like $(if ) ). I have now committed a change to SVN to use only functions (not conditional) so the evaluation is done after file inclusion, and changed the variable from "simply expanded" (:=) to "recursively expanded" (=), to postpone resolving until actually used. This has the drawback of executing the command every time it is used rather than only once, but I consider that acceptable. Thanks for changing that. It seems more intuitive that order of inclusion doesn't matter, just like with the standard C header files. I could identify 4 packages with this issue so far: - time 1.7-21 - libgd2 2.0.35.dfsg-3 - sqlite3 3.5.9-3 - tiff 3.8.2-8 I already thought about filing bugs against them, but now I wont do. :-) Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489525: libppd: ugly source package
Package: libppd Version: 2:0.10-6 Severity: normal Extracting the orig.tar.gz gives: libppd-0.10/src libppd-0.10/doc After unpacking the debian source package there is another dir "libppd-0.10" which also contains "src" and "doc": libppd-0.10/src libppd-0.10/doc libppd-0.10/libppd-0.10/src libppd-0.10/libppd-0.10/doc So the diff contains the whole orig.tar.gz again! Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489430: cdbs: debhelper usage
Package: cdbs Version: 0.4.52 Severity: normal In bug #416018 I requested to use debhelper's dh_testroot in cdbs. This has been done now, thank you. I encountered a problem with this implementation however: See package time 1.7-21 as example. Its rules says: include /usr/share/cdbs/1/class/autotools.mk include /usr/share/cdbs/1/rules/debhelper.mk i.e. debhelper.mk is included after autotools.mk. In this configuration buildcore.mk doesn't know that debhelper is to use and so doesn't use dh_testroot. When swapping these lines (so that they are in the order cdbs's docs mention it) then everything is fine: include /usr/share/cdbs/1/rules/debhelper.mk include /usr/share/cdbs/1/class/autotools.mk Now I'm asking me if that is a bug in the time package or something that could be fixed in cdbs? There are several such packages with this kind of bug, and I currently don't want to file a bug for all of those. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488586: giflib: packaging bug
Package: giflib Version: 4.1.6-4 Severity: normal When building giflib with sbuild, it reports: ERROR: Package builds libungif-bin_4.1.6-4_all.deb when binary-indep target is not called. This is a bug in the packaging. ERROR: Package builds libungif4g_4.1.6-4_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488585: argtable2: packaging bug
Package: argtable2 Version: 9-1 Severity: normal When building argtable2 with sbuild, it reports: ERROR: Package builds libargtable2-docs_9-1_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#488204: ample: make is successful even on error
Package: ample Version: 0.5.7-4 Severity: normal When building ample and compilation fails for some reason, then make ignores that and the package is built nevertheless, even if the binary hasn't been built. Makefile.in says: all: @for i in $(SUBDIRS); do \ echo "Making all in $$i ..."; \ cd $$i; $(MAKE) $(MDEFS) all; \ cd ..; \ done so errors from subdir make are ignored. In the for body ";" should be replaced with "&&" to fix that. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486418: libxmu: packaging bug
Package: libxmu Version: 2:1.0.4-1 Severity: normal When building libxmu with sbuild, it reports: ERROR: Package builds libxmu-headers_1.0.4-1_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486419: lzma: packaging bug
Package: lzma Version: 4.43-13 Severity: normal When building lzma with sbuild, it reports: ERROR: Package builds lzma-source_4.43-13_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#486415: libpng: packaging bug
Package: libpng Version: 1.2.27-1 Severity: normal When building libpng with sbuild, it reports: ERROR: Package builds libpng3_1.2.27-1_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#481805: dpkg: libcompat.a in wrong place in link cmd line
Package: dpkg Version: 1.14.19 Severity: normal Tags: patch I'm using dpkg on Interix, without glibc. See: http://www.debian-interix.net/ So I'm happy that libcompat has been created/fixed recently, it still has a bug, however: lib/tarfn.c uses strnlen(), so libcompat/libcompat.a, which possibly (on Interix it has to) provides strnlen(), should be placed after lib/libdpkg.a in the link invocation cmd. You might consider the attached patch. Martin--- dpkg-1.14.19.orig/dpkg-deb/Makefile.am +++ dpkg-1.14.19/dpkg-deb/Makefile.am @@ -17,5 +17,4 @@ main.c dpkg_deb_LDADD = \ - ../libcompat/libcompat.a \ - $(LIBINTL) ../lib/libdpkg.a $(ZLIB_LIBS) $(BZ2_LIBS) $(SELINUX_LIBS) + $(LIBINTL) ../lib/libdpkg.a ../libcompat/libcompat.a $(ZLIB_LIBS) $(BZ2_LIBS) $(SELINUX_LIBS) --- dpkg-1.14.19.orig/dpkg-split/Makefile.am +++ dpkg-1.14.19/dpkg-split/Makefile.am @@ -19,9 +19,9 @@ split.c dpkg_split_LDADD = \ - ../libcompat/libcompat.a \ $(LIBINTL) \ - ../lib/libdpkg.a + ../lib/libdpkg.a \ + ../libcompat/libcompat.a pkglib_SCRIPTS = mksplit --- dpkg-1.14.19.orig/dselect/Makefile.am +++ dpkg-1.14.19/dselect/Makefile.am @@ -35,10 +35,10 @@ pkgtop.cc dselect_LDADD = \ - ../libcompat/libcompat.a \ $(LIBINTL) \ $(CURSES_LIBS) \ - ../lib/libdpkg.a + ../lib/libdpkg.a \ + ../libcompat/libcompat.a EXTRA_DIST = keyoverride mkcurkeys.pl --- dpkg-1.14.19.orig/src/Makefile.am +++ dpkg-1.14.19/src/Makefile.am @@ -28,8 +28,7 @@ update.c dpkg_LDADD = \ - ../libcompat/libcompat.a \ - $(LIBINTL) ../lib/libdpkg.a $(ZLIB_LIBS) $(BZ2_LIBS) $(SELINUX_LIBS) + $(LIBINTL) ../lib/libdpkg.a ../libcompat/libcompat.a $(ZLIB_LIBS) $(BZ2_LIBS) $(SELINUX_LIBS) dpkg_query_SOURCES = \ errors.c \ @@ -37,17 +36,17 @@ query.c dpkg_query_LDADD = \ - ../libcompat/libcompat.a \ $(LIBINTL) \ - ../lib/libdpkg.a + ../lib/libdpkg.a \ + ../libcompat/libcompat.a dpkg_trigger_SOURCES = \ trigcmd.c dpkg_trigger_LDADD = \ - ../libcompat/libcompat.a \ $(LIBINTL) \ - ../lib/libdpkg.a + ../lib/libdpkg.a \ + ../libcompat/libcompat.a install-data-local: $(mkdir_p) $(DESTDIR)$(admindir)/alternatives
Bug#414827: improved magics for Windows EXE files
Hi, sorry, I overlooked your message. The attached license file doesn't seem to apply to the attached magic file; rather, it mentions the file program. I'm not a lawyer, I only thought that the magic file is part of the file program, and the file program package is responsible for maintaining the magic file. But anyway, if you now think the changes could be made, I welcome that of course. Also, you've attached what looks like an entire monolithic magic file. For the purposes of this bug, we're only interested in the Windows PE-specific bits; could you pull those out, please? I have already written in my original bug report, in which lines I'm mostly interested in, and these are the lines I included in my version of file for the Debian/Interix port, see: http://www.debian-interix.net/ http://www.debian-interix.net/debian-interix/pool/unreleased35/main/f/file/ and there the *.interdiff.gz file. I have attached the whole magic file for reference, but I think only lines 11 - 104 are interesting for a possible inclusion in file's magic. Thanks for picking up this issue again. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#475753: nrg2iso: unnecessarily Depends: on quilt
Package: nrg2iso Version: 0.4-2 Severity: normal Hi, nrg2iso now uses quilt for patches, so it should Build-Depends: quilt, which it does. But it need not and should not Depends: quilt, IMO. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441094: new mailing list debian-interix
Hi listmasters, hi Cord, I just want to refresh my wish for a new mailing list for debian-interix, see bug #441094. Are there still any missing preconditions from my side? Thanks for consideration Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#472458: dictionaries-common: adapt check for rootness to interix
Package: dictionaries-common Version: 0.98.2 Severity: wishlist Tags: patch Hi, I'm porting Debian to Interix, see http://debian-interix.net/ Unfortunately, on Interix, the root user doesn't have UID 0 (which isn't a POSIX requirement AFAIK). So installing dictionaries-common fails, because it checks for UID 0. I prepared a patch which factors this test for rootness out, checks for Interix and also unifies RUID or EUID usage for the check. Thanks for consideration Martin dictionaries-common_0.98.2-0.1.diff.gz Description: Binary data
Bug#462876: dialign-t: packaging bug
Package: dialign-t Version: 0.2.2.dfsg-1 Severity: normal When building dialign-t with sbuild, it reports: ERROR: Package builds dialign-t-data_0.2.2.dfsg-1_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#462874: libsmi: packaging bug
Package: libsmi Version: 0.4.5+dfsg0-0.1 Severity: normal When building libsmi with sbuild, it reports: ERROR: Package builds libsmi2-common_0.4.5+dfsg0-0.1_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#457921: t-coffee: packaging bug
Package: t-coffee Version: 5.05-1 Severity: normal When building t-coffee with sbuild, it reports: ERROR: Package builds t-coffee-examples_5.05-1_all.deb when binary-indep target is not called. This is a bug in the packaging. ERROR: Package builds t-coffee-doc_5.05-1_all.deb when binary-indep target is not called. This is a bug in the packaging. See any buildd log for verification. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#455080: bashdb: should be arch all
Package: bashdb Version: 3.1.0.8-2 Severity: normal Is there a reason why bashdb is not arch:all? I can't see any arch specific files in the package. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447771: icu: ugly debian/rules
Package: icu
Version: 3.6-7
Severity: normal
I wanted to apply a local patch to icu and put it into debian/patches.
But then I had to see that it is only partly applied (see any buildd
log for verify):
- first the source in extracted into
build-tree/icu/source
- then debian/rules target pre-build:: is executed
which copies over (look for "cp -a" in the logs) everything to
build-tree/icu/source-build
- then the patches are applied
- and finally for a second build the now patched
build-tree/icu/source is copied over to build-tree/icu/source-build
again.
So the first build is done without the patches, the second with the
patches applied. If that is intentional, it should be expressed more
clearly.
I also see that icu-3.8 doesn't need any patches for the official
package, but nevertheless this should be changed there, too, as
cdbs's simple-patchsys.mk is still included and one might (re-)start
using it (re-)introducing this ugliness again.
Another ugliness is that ./configure is run in build-tree/icu/source,
but later in build-tree/icu/source-build again, and for the second
build it's run the third time, again in build-tree/icu/source-build.
So probably it's unnecessary to run it in build-tree/icu/source.
For the 32/64 archs it's even worse: ./configure is run twice in a row
for build-tree/icu/source-build{,32}, resulting in 8 runs entirely,
see:
http://experimental.debian.net/fetch.php?&pkg=icu&ver=3.8-1&arch=amd64&stamp=1193018951&file=log&as=raw
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#447146: apr-util: new upstream version available
Package: libaprutil1 Version: 1.2.7+dfsg-2 Severity: wishlist There is a new upstream version available (1.2.10). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446375: libt1-dev: please remove Depends: libc6-dev
Package: libt1-dev Version: 5.1.0-3 Severity: normal Please remove the Depends: libc6-dev. libc6-dev is not available on every architecture and also it is in build-essentials, so no need to mention it. If you wish to mention it nevertheless, please use libc-dev instead. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#446068: libgc: new upstream version 7.0 available
Package: libgc Version: 1:6.8-1.1 Severity: wishlist There is a new upstream version available (7.0). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442878: coreutils: please guard the who-ips extension (fwd)
Forgot to CC the bug. Sorry. -- Forwarded message -- Date: Mon, 17 Sep 2007 23:09:31 +0200 (CEST) Subject: Re: Bug#442878: coreutils: please guard the who-ips extension On Mon, 17 Sep 2007, Michael Stone wrote: On Mon, Sep 17, 2007 at 05:33:52PM +0200, Martin Koeppe wrote: Please guard your who-ips extension so that it at least can be built on systems without IPv6. I successfully used the patch below, but it may unnecessarily remove too much. Which debian OS doesn't support IPV6? Yes, you're right. All official Debian architectures support IPv6. That's why I set the severity to wishlist. I'm trying to port Debian to a new architecture, which doesn't support IPv6. See http://www.debian-interix.net/ for more details. Thanks for consideration Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#442878: coreutils: please guard the who-ips extension
Package: coreutils Version: 6.10~20070907-3 Severity: wishlist Please guard your who-ips extension so that it at least can be built on systems without IPv6. I successfully used the patch below, but it may unnecessarily remove too much. Martin --- coreutils-6.10~20070907/src/who.c.orig Sat Sep 15 23:02:44 2007 +++ coreutils-6.10~20070907/src/who.c Sat Sep 15 23:38:16 2007 @@ -424,6 +424,7 @@ } #endif +#if HAVE_IPV6 /* Needs configure check for ut_addr_v6, etc */ if (do_ips && memcmp(utmp_ent->ut_addr_v6, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 16)) @@ -474,6 +475,7 @@ getnameinfo(sa, salen, hoststr, 256, NULL, 0, flags); } +#endif print_line (sizeof UT_USER (utmp_ent), UT_USER (utmp_ent), mesg, sizeof utmp_ent->ut_line, utmp_ent->ut_line, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441969: apr: new upstream version available
Package: libapr1 Version: 1.2.7-8.2 Severity: wishlist There is a new upstream version available (1.2.11). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#441094: new mailing list debian-interix
Package: lists.debian.org Severity: wishlist Name: debian-interix Rationale: This list would be used for porting Debian to the Interix Unix-like kernel (MS Services for Unix, now available for free), so it's a project similar to Debian kFreeBSD/GNU. More details about Interix and the current status of the port can be obtained here: http://www.debian-interix.net/ I also thought about using debian-win32, which is apparently no longer used, for this purpose, but it doesn't seem to be the right name, as technically win32 is in parallel to interix, both on top of the NT kernel. Long description: Discussion on the Interix port of Debian/GNU. For more information see: http://www.debian-interix.net/ Category: ports Subscription Policy: open Post Policy: open Web-Archive: yes Short description: Debian port to Interix Thanks for considering Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440877: refblas3-dev: should not depend on libc6-dev
Package: refblas3-dev Version: 1.2-8 Severity: normal refblas3-dev should not Depends: libc6-dev. libc6-dev is in build-essentials anyway, and not every architecture has a libc6 at all. That's what buils-essential takes care of. If you really must depend on a libc dev package, use the generic libc-dev please. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#440044: dpatch: fails when $HOME contains spaces
Package: dpatch
Version: 2.0.27
Severity: normal
Tags: patch
dpatch fails when $HOME contains spaces. Consider the patch below.
Martin
--- dpatch.orig 2007-08-03 14:32:04.0 +0200
+++ dpatch 2007-08-29 13:22:49.0 +0200
@@ -15,12 +15,12 @@
SYSCONFDIR='/etc'
-if [ -e ${SYSCONFDIR}/dpatch.conf ]; then
- . ${SYSCONFDIR}/dpatch.conf
+if [ -e "${SYSCONFDIR}/dpatch.conf" ]; then
+ . "${SYSCONFDIR}/dpatch.conf"
fi
-if [ -e ${HOME}/.dpatch.conf ]; then
- . ${HOME}/.dpatch.conf
+if [ -e "${HOME}/.dpatch.conf" ]; then
+ . "${HOME}/.dpatch.conf"
fi
# ( beginning of dpatch_help.shpp )
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439127: expat: wrong re-libtoolization
Package: expat Version: 1.95.8-4 Severity: wishlist In this version configure was generated with a wrong aclocal.m4, which contains libtool.m4 version 47, but with libtool 1.5.22 there comes libtool.m4 version 48, which even is included in the package. Only aclocal.m4 has not been generated with that version. With 1.95.8-3.4 everything was ok. You also might consider updating to libtool-1.5.24 and autoconf-2.61. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#432139: libtool: new upstream version available
Package: libtool Version: 1.5.22-4 Severity: wishlist There is a new upstream version available (1.5.24). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431620: bash: new upstream version available
Package: bash Version: 3.1dfsg-8 Severity: wishlist There is a new upstream version available (3.2). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431202: libpng: new upstream version available
Package: libpng Version: 1.2.15~beta5-2 Severity: wishlist There is a new upstream version available (1.2.18). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#431060: rrdtool: new upstream version available
Package: rrdtool Version: 1.2.19-1 Severity: wishlist There is a new upstream version available (1.2.23). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#427278: gcc-4.2-base: should it better be arch: all?
Package: gcc-4.2-base Version: 4.2-20070528-1 Severity: normal When I look at the content of gcc-4.2-base I wonder if it should better be arch: all instead of arch: any. Are there reasons for arch: any? I'm porting to a new architecture and for me it would be useful to have it arch: all, because gcc-4.2-source depends on it and is also arch: all. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418061: please use du -k
Package: sbuild
Version: 0.53
Severity: wishlist
Tags: patch
To increase portability, could you please consider using
"du -k -s" instead of just "du -s" when determinating needed build
space? I use a "du" which by default outputs the number of blocks, not
kilobytes. You might apply the following patch:
--- /usr/bin/sbuild.origThu Apr 5 13:48:52 2007
+++ /usr/bin/sbuild Thu Apr 5 14:08:20 2007
@@ -692,7 +692,7 @@
}
$main::pkg_fail_stage = "check-space";
- my $current_usage = `/usr/bin/du -s .`;
+ my $current_usage = `/usr/bin/du -k -s .`;
$current_usage =~ /^(\d+)/;
$current_usage = $1;
if ($current_usage) {
@@ -2473,9 +2473,9 @@
if (/^\Q$main::chroot_dir\E/) {
$_ =~ s/^\Q$main::chroot_dir\E//;
- $command = get_command("/usr/bin/du -s $_ 2>/dev/null",
"root", 1, 0);
+ $command = get_command("/usr/bin/du -k -s $_ 2>/dev/null",
"root", 1, 0);
} else {
- $command = get_command("/usr/bin/du -s $_ 2>/dev/null",
$main::username, 0, 0);
+ $command = get_command("/usr/bin/du -k -s $_
2>/dev/null", $main::username, 0, 0);
}
if (!open( PIPE, "$command |" )) {
Thanks for consideration
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418060: usage of %alternatives is broken
Package: sbuild Version: 0.53 Severity: normal Tags: patch The definition of %alternatives in the conf file doesn't work. I resolved this by adding "%alternatives" to @EXPORT in /usr/share/perl5/Sbuild/Conf.pm. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392063: portability patch
Hello,
I now have prepared a patch to increase the portability of apt. I
have built apt against a non-gnu libc, and this patch was necessary.
To further increase portability, you might also want to consider to
replace (not in the patch)
#include
by
#include
in apt-pkg/contrib/{md5.h,sha256.cc}
as apt has a fall-back inttypes.h in case the build system doesn't
have one (my system doesn't have one!), but doesn't have a fall-back
stdint.h, which my system doesn't have, either.
Martin--- apt-0.6.46.4.orig/buildlib/apti18n.h.in
+++ apt-0.6.46.4/buildlib/apti18n.h.in
@@ -18,6 +18,8 @@
#else
// apt will not use any gettext
# define setlocale(a, b)
+# define textdomain(a)
+# define bindtextdomain(a, b)
# define _(x) x
# define N_(x) x
#endif
--- apt-0.6.46.4.orig/buildlib/inttypes.h.in
+++ apt-0.6.46.4/buildlib/inttypes.h.in
@@ -4,6 +4,13 @@
#include
+#undef int32_t
+#undef uint32_t
+#undef int16_t
+#undef uint16_t
+#undef int8_t
+#undef uint8_t
+
/* Generate the fixed bit size types */
#if SIZEOF_INT == 4
typedef int int32_t;
--- apt-0.6.46.4.orig/cmdline/makefile
+++ apt-0.6.46.4/cmdline/makefile
@@ -7,42 +7,42 @@
# The apt-cache program
PROGRAM=apt-cache
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = apt-cache.cc
include $(PROGRAM_H)
# The apt-get program
PROGRAM=apt-get
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = apt-get.cc acqprogress.cc
include $(PROGRAM_H)
# The apt-config program
PROGRAM=apt-config
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = apt-config.cc
include $(PROGRAM_H)
# The apt-cdrom program
PROGRAM=apt-cdrom
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = apt-cdrom.cc
include $(PROGRAM_H)
# The apt-sortpkgs program
PROGRAM=apt-sortpkgs
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = apt-sortpkgs.cc
include $(PROGRAM_H)
# The apt-extracttemplates program
PROGRAM=apt-extracttemplates
-SLIBS = -lapt-pkg -lapt-inst
+SLIBS = -lapt-pkg -lapt-inst $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = apt-extracttemplates.cc
include $(PROGRAM_H)
--- apt-0.6.46.4.orig/ftparchive/makefile
+++ apt-0.6.46.4/ftparchive/makefile
@@ -8,10 +8,10 @@
# The apt-ftparchive program
ifdef BDBLIB
PROGRAM=apt-ftparchive
-SLIBS = -lapt-pkg -lapt-inst $(BDBLIB)
+SLIBS = -lapt-pkg -lapt-inst $(BDBLIB) $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile apt-inst/makefile
SOURCE = apt-ftparchive.cc cachedb.cc writer.cc contents.cc override.cc \
multicompress.cc
--- apt-0.6.46.4.orig/methods/makefile
+++ apt-0.6.46.4/methods/makefile
@@ -12,63 +12,63 @@
# The file method
PROGRAM=file
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = file.cc
include $(PROGRAM_H)
# The copy method
PROGRAM=copy
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = copy.cc
include $(PROGRAM_H)
# The gzip method
PROGRAM=gzip
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = gzip.cc
include $(PROGRAM_H)
# The gpgv method
PROGRAM=gpgv
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = gpgv.cc
include $(PROGRAM_H)
# The cdrom method
PROGRAM=cdrom
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = cdrom.cc
include $(PROGRAM_H)
# The http method
PROGRAM=http
-SLIBS = -lapt-pkg $(SOCKETLIBS)
+SLIBS = -lapt-pkg $(SOCKETLIBS) $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = http.cc rfc2553emu.cc connect.cc
include $(PROGRAM_H)
# The ftp method
PROGRAM=ftp
-SLIBS = -lapt-pkg $(SOCKETLIBS)
+SLIBS = -lapt-pkg $(SOCKETLIBS) $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = ftp.cc rfc2553emu.cc connect.cc
include $(PROGRAM_H)
# The rred method
PROGRAM=rred
-SLIBS = -lapt-pkg $(SOCKETLIBS)
+SLIBS = -lapt-pkg $(SOCKETLIBS) $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = rred.cc
include $(PROGRAM_H)
# The rsh method
PROGRAM=rsh
-SLIBS = -lapt-pkg
+SLIBS = -lapt-pkg $(INTLLIBS)
LIB_MAKES = apt-pkg/makefile
SOURCE = rsh.cc
include $(PROGRAM_H)
Bug#416018: consider using dh_testroot
Package: cdbs Version: 0.4.48 Severity: wishlist To increase portability, I would like to suggest to use 'dh_testroot' instead of 'test "`id -u`" = 0'. cdbs currently only Recommends: debhelper, then it would probably Depends: on it. OTOH, how many packages are there which Build-Depends: cdbs, but not debhelper? I really don't know. Is there a reverse Build-Depends: list anywhere? Motivation is, that I needed to change the test for rootness for a special architecture (POSIX doesn't say that root has necessarily id 0), and I would like to avoid doing that change twice. Thanks for consideration Martindiff -Naur cdbs.orig/buildcore.mk.in cdbs/buildcore.mk.in --- cdbs.orig/buildcore.mk.in 2006-10-26 12:57:53.0 +0200 +++ cdbs/buildcore.mk.in2007-03-24 02:05:14.0 +0100 @@ -31,7 +31,7 @@ test -x debian/rules testroot: - test "`id -u`" = 0 + dh_testroot $(patsubst %,makebuilddir/%,$(DEB_ALL_PACKAGES)) :: makebuilddir/% : $(if $(DEB_BUILDDIR_$(cdbs_curpkg)),mkdir -p "$(DEB_BUILDDIR_$(cdbs_curpkg))")
Bug#415988: new upstream version 5.21o available
Package: arc Version: 5.21m-1 Severity: wishlist There is arc-5.21o available. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#415754: new upstream version 1.18.1.4 available
Package: groff Version: 1.18.1.1-12 Severity: wishlist There is groff 1.18.1.4 available. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414827: improved magics for Windows EXE files / new upstream 4.20 available
On Thu, 15 Mar 2007, Michael Piefel wrote: Am Mittwoch, den 14.03.2007, 00:09 +0100 schrieb Martin Koeppe: I have attached the whole magic file for reference, but I think only lines 11 - 104 are interesting for a possible inclusion in file's magic. Well, certainly I cannot include it for licence reasons. So, what can be done about this? I have attached the licence document which has an extra chapter about the file program. I think according to this including the patch in debian is ok. Martin Copyrights Associated with Microsoft Windows Services for UNIX 3.5 Microsoft Corporation Portions of the source code and documentation for Services for UNIX 3.5 are derived from materials obtained from the University of California at Berkeley. Copyright (c) 1980, 1983, 1985, 1987, 1988, 1989, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: This product includes software developed by the University of California, Berkeley and its contributors. 4. Neither the name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. --- The version of awk included with Services for UNIX 3.5 is derived from AT&T source code. Copyright (c) AT&T 1993 All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that the copyright notice and this permission notice and warranty disclaimer appear in supporting documentation, and that the name of AT&T or any of its entities not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. AT&T DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL AT&T OR ANY OF ITS ENTITIES BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. --- The implementation of curses included with Services for UNIX 3.5 and linked with several of the utilities (including tic, toe, infocmp, clear, tput, and tset) is a port of ncurses. Ncurses carries the following copyright notice: Copyright (c) 1998 Free Software Foundation, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, distribute with modifications, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED &
Bug#400828: quinn-diff: link against glib2
Package: quinn-diff Version: 0.65.1 Severity: wishlist Tags: patch The attached patch allows to link quinn-diff against glib2 instead of glib1 which is now in section oldlibs. The patch also updates automake usage from 1.4 to 1.9. (The new automake is called from debian/rules, just to make the diff small.) Martin--- quinn-diff-0.65.1.orig/configure.in +++ quinn-diff-0.65.1/configure.in @@ -80,7 +80,8 @@ esac dnl Checks for libraries. -AC_CHECK_LIB(glib, g_hash_table_lookup) +dnl AC_CHECK_LIB(glib, g_hash_table_lookup) +AM_PATH_GLIB_2_0() dnl Checks for header files. AC_HEADER_STDC --- quinn-diff-0.65.1.orig/debian/control +++ quinn-diff-0.65.1/debian/control @@ -2,7 +2,7 @@ Section: devel Priority: extra Maintainer: James Troup <[EMAIL PROTECTED]> -Build-Depends: libglib1.2-dev, docbook-utils +Build-Depends: libglib2.0-dev, docbook-utils, automake-1.9, autoconf Standards-Version: 3.5.10.0 Package: quinn-diff --- quinn-diff-0.65.1.orig/debian/rules +++ quinn-diff-0.65.1/debian/rules @@ -16,7 +16,12 @@ build: $(checkdir) - ./configure --prefix=/usr --sysconfdir=/etc + rm -f scripts/* acconfig.h + aclocal-1.9 + autoconf + autoheader + automake-1.9 --copy --add-missing + ./configure --prefix=/usr --sysconfdir=/etc $(MAKE) touch build --- quinn-diff-0.65.1.orig/src/Makefile.am +++ quinn-diff-0.65.1/src/Makefile.am @@ -1,4 +1,4 @@ bin_PROGRAMS = quinn-diff quinn_diff_SOURCES = error.c nfmalloc.c xmalloc.c getopt.c getopt1.c init.c list.c arch_specific.c vercmp.c output.c utils.c parse_sources.c parse_packages.c main.c arch_specific.h common.h error.h getopt.h init.h list.h nfmalloc.h output.h parse_sources.h parse_packages.h utils.h vercmp.h xmalloc.h globals.h -quinn_diff_LDADD = @EFENCE@ @CCMALLOC@ -CPPFLAGS = $(shell glib-config --cflags) +quinn_diff_LDADD = @EFENCE@ @CCMALLOC@ @GLIB_LIBS@ +AM_CFLAGS = @GLIB_CFLAGS@
Bug#400820: tcl8.4: new upstream version available
Package: tcl8.4 Version: 8.4.12-1.1 Severity: wishlist There is a new upstream version available (8.4.14). Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397932: libgpg-error: ugly Depends:
Package: libgpg-error Version: 1.4 Severity: normal libgpg-error Build-Depends: on automake1.7; however, in debian/rules there are calls to aclocal-1.8. There are also calls to autoheader2.50, and autoconf isn't in Build-Depends:. automake is probably not required at all, either, as it is only conditionally called in debian/rules, and the condition is never true. Furthermore, libgpg-error-dev Depends: on libc6-dev, which is bad and should be removed, as (a) libc6-dev is in build-essentials and (b) it is not always libc6-dev, think of hurd-i386 (libc0.3-dev) or kfreebsd-i386 (libc0.1-dev). If at all, it should depend on libc-dev. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396756: bsdtar: needless(?) Depends on libarchive1
Package: bsdtar
Version: 1.2.53-2
Severity: normal
/usr/bin/bsdtar doesn't seem to depend on libarchive.so, at least on i386:
$ ldd /usr/bin/bsdtar
linux-gate.so.1 => (0xe000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7fce000)
libbz2.so.1.0 => /lib/libbz2.so.1.0 (0xb7fbe000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e8c000)
/lib/ld-linux.so.2 (0xb7feb000)
So maybe the debian/control file should be changed from
Package: bsdtar
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, libarchive1 (>= ${Source-Version})
to just
Package: bsdtar
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
as ${shlibs:Depends} should be enough, even if bsdtar was linked
against libarchive.so. debian/shlibs.local should probably be filled
in correctly, though.
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396742: libarchive: new upstream version available
Package: libarchive Version: 1.2.53-2 Severity: wishlist There are new upstream versions available: 1.2.57, 1.3.1, 2.0a1 Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392750: diffstat: FTBFS, bug in debian/control
Package: diffstat
Version: 1.43-1
Severity: normal
Tags: patch
I just encountered an error while building diffstat. I could correct
it by adding a "," to debian/control Depends: line:
old> Depends: ${shlibs:Depends} ${misc:Depends}
new> Depends: ${shlibs:Depends}, ${misc:Depends}
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392063: apt: build problem when configured with --disable-nls
Hello, as I just saw, # define bindtextdomain(a, b) should also be added to the non-NLS section. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392063: apt: build problem when configured with --disable-nls
Package: apt Version: 0.6.46 Severity: normal Tags: patch When configuring apt with "--disable-nls", textdomain(3) should not be called. This can be achived by modifying buildlib/apti18n.h.in to read: #ifdef USE_NLS // apt will use the gettext implementation of the C library # include # ifdef APT_DOMAIN # define _(x) dgettext(APT_DOMAIN,x) # else # define _(x) gettext(x) # endif #else // apt will not use any gettext # define setlocale(a, b) # define textdomain(a) // <--- this line added # define _(x) x #endif -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373593: seems to work since 2.6.17
Wake on lan seems to work again since 2.6.17, i.e. I successfully tested: linux-image-2.6.17-2-686_2.6.17-8_i386.deb Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#373593: kernel: e1000 wake on lan (wol) does not work after 2.6.12
Package: kernel Severity: normal Hello, when upgrading from linux-image-2.6.12-1-686_2.6.12-10_i386.deb to any of - linux-image-2.6.14-2-686_2.6.14-7_i386.deb - linux-image-2.6.15-1-686_2.6.15-8_i386.deb - linux-image-2.6.16-2-686_2.6.16-14_i386.deb - vanilla 2.6.15 wake on lan (wol) doesn't work any more with my e1000 card (Intel PRO/1000 MT Desktop Adapter with the e1000 driver). After shutting down linux, the link led is off now (nic and switch), and wol is not possible. wol is possible and working fine after starting and shutting down Windows 2000, or Linux kernel 2.6.12, where link led stays on on both nic and switch. I found a similar issue here with the sk98lin driver: http://www.linuxquestions.org/questions/showthread.php?t=444793 but ethtool is working for me with e1000. Martin -- System Information: Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331546: sbuild should run "apt-get update"
Hello Michael, >> But what if I resync my mirror afterwards? I didn't change the chroot >> then, but the stored package lists would become invalid, wouldn't they? > Indeed, but this is the same for ftp.debian.org. It used to be a > fundamental thing of how sbuild works: You give it a package and a > chroot, and it will builds it in it, nothing more, nothing less. > Conceptually, the apt-get update is designed to be done by buildd, but > we do not have this of course. > It might be worthwhile to have an option for this, dunno how the others > feel about it. I think the advantage of sbuild over other build tools is the automatic resolution of source dependencies, at least the man page states that. For doing this correctly, I think it's necessary to run "apt-get update". Especially in combination with schroot, where the complete apt system is in the chroot, and therefore I think only sbuild is responsible for it, not buildd. (I plan to setup a buildd, too, but first I want to get familiar with sbuild.) And if you look at current sbuild 0.36 at line 441, there an apt-get update is issued if some packages cannot be installed, before giving up. Unfortunately, I gave a .dsc file to sbuild, and therefore in line 410 the retry mechanism is skipped, while I think it shouldn't. Another problem can be seen at line 410 as well: $ sbuild -d sid package.dsc works, but $ sbuild -d sid ../another-dir/package.dsc won't work. I think this inconsistency should be removed as well. When using schroot, the ugly symlinks "chroot-" in cwd aren't necessary, so why not start sbuild from every directory? >> Oh, thanks for the hint to /usr/share/sbuild/, but as I can see, >> these tools are not for schroot usage of sbuild, are they? > Maybe not, I have not used schroot so far. I see the advantage of schroot over sudo in the possibility to have different suites with different sources.list files on one machine. (at least Dir::Etc::SourceList seems not to be provided to sudo apt-get, see line 299) The disadvantage is maybe that apt-get is needed within the chroot, however. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331546: sbuild should run "apt-get update"
> Well, I believe it is not sbuild's job to maintain your chroots. In > your case, you created a new chroot and then changed it's behaviour (by > modifying sources.list), at which point you should have run apt-get > update yourself. This is not that easy, because the creation of the chroot is done as root, apt-get update should be run as user sbuild on host, which gets root on chroot with schroot. It works without further modifying schroot config: # su -c "schroot -c etch -u root apt-get update" sbuild But what if I resync my mirror afterwards? I didn't change the chroot then, but the stored package lists would become invalid, wouldn't they? > A case could be made for locally built packages you need as > Build-Depends, but for that as well the commands in /usr/share/sbuild/ > should suffice. Oh, thanks for the hint to /usr/share/sbuild/, but as I can see, these tools are not for schroot usage of sbuild, are they? >> here 2 interactive questions are asked, which should be avoided, too: >> What interface should be used for configuring packages? 6 >> Ignore questions with a priority less than... critical >> but after that, the build succeeds, besides #331506 > Those should not be asked (but this is a different bug report), sbuild > should set the debconf frontend to noninteractive. I thought it did > that already. Ok, I won't file a new bug for it, you might retitle (or clone) this one if you think it's necessary. (If one preinstalls debconf with debootstrap --resolve-deps --variant=buildd --include=fakeroot,debconf this works around those questions for now) Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331550: manpage says sbuild instead of schroot
Package: schroot Version: 0.1.5-1 Severity: minor Both the man pages schroot(1) and schroot.conf(5) begin at DESCRIPTION with the word "sbuild" instead of "schroot". Martin -- System Information: Debian Release: testing Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331546: sbuild should run "apt-get update"
Package: sbuild Version: 0.36 Severity: normal When running sbuild with schroot, and giving a .dsc file to sbuild, it should run "apt-get update" before trying to install the Build-Depends. I did: # debootstrap --resolve-deps --variant=buildd --include=fakeroot etch /chroot/etch http://mirror/debian # cp /etc/apt/sources.list /chroot/etch/etc/apt/sources.list # cp -p -R /var/lib/sbuild /chroot/etch/var/lib/ # mkdir -p /chroot/etch/build/buildd/ # chown sbuild. /chroot/etch/build/buildd # ln -s ../build/buildd /chroot/etch/home/sbuild # su - sbuild $ pwd ; ls /home/sbuild mc_4.6.0-4.6.1-pre4-2.diff.gz mc_4.6.0-4.6.1-pre4-2.dsc mc_4.6.0-4.6.1-pre4.orig.tar.gz $ sbuild -d etch mc_4.6.0-4.6.1-pre4-2.dsc (build fails because apt-get: W: Couldn't stat source package list http://mirror ...) $ schroot -c etch -u root # apt-get update # exit $ sbuild -d etch mc_4.6.0-4.6.1-pre4-2.dsc here 2 interactive questions are asked, which should be avoided, too: What interface should be used for configuring packages? 6 Ignore questions with a priority less than... critical but after that, the build succeeds, besides #331506 Martin -- System Information: Debian Release: testing Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331506: sbuild: needs sudo even with $conf::chroot_mode = "schroot"
Package: sbuild Version: 0.35 Severity: normal Hello, I use sbuild together with schroot, but after a build, for checking the space needed du -s is run, but as sudo instead of within schroot. Martin -- System Information: Debian Release: testing Architecture: i386 (i686) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#331498: cdebootstrap: doesn't create device nodes correctly within the chroot
Package: cdebootstrap Version: 0.3.8 Severity: important When issuing # cdebootstrap -f build etch /chroot/etch http://mirror/debian the chroot is created. However, the device files below /chroot/etch/dev are all missing, only /dev/null is created, but as a regular file with size 0. With # debootstrap --resolve-deps --variant=buildd etch /chroot/etch http://mirror/debian everything works ok. -- System Information: Debian Release: testing Architecture: i386 (i686) Kernel: Linux 2.6.11 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309405: workaround
Hello, in between I managed to work around the problem. With cifs 1.34 compiled into 2.6.11 (and probably 2.6.12, too), a acceptable performance can be achieved with mount option "direct". For further plans and (hopefully) the final fix for the problem see: http://lists.samba.org/archive/linux-cifs-client/2005-September/000989.html http://lists.samba.org/archive/linux-cifs-client/2005-September/000991.html In between this bug should remain open. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330503: aptitude: wrong dependency resolution, cannot update one package
Package: aptitude Version: 0.2.15.9-6 Severity: normal Updating one package with complex dependencies fails: I tried to update from slang1a-utf8 (1.4.9dbs-8) to libslang1-utf8 (1.4.9dbs-10). The following dependencies exist: slang1a-utf8 (1.4.9dbs-8) Conflicts: slang1-utf8 libslang1-utf8 (1.4.9dbs-10) Conflicts: slang1-utf8, slang1a-utf8 Replaces: slang1a-utf8 Provides: slang1a-utf8 util-linux (2.12-7+kbsd.1) PreDepends: slang1a-utf8 (>1.4.4-7.1) Installing libslang1-utf8 is not possible, even though it should be possible to replace slang1a-utf8 with libslang1-utf8 without any problems. I know that kfreebsd-i386 is not an official architecture, but I think the dependency resolution algorithm has not changed there. I also tested with # apt-get -s install libslang1-utf8 but this wanted to remove util-linux as well. I report this issue here nevertheless to make you aware of it, in case aptitude has its own dependency resolution. If that's wrong then please reassign it. Martin -- System Information: Debian Release: unstable Architecture: kfreebsd/i386 (i686) Versions of packages aptitude depends on: apt 0.6.41+kbsd -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309546: libdbd-sybase-perl: missing Depends: libdbi-perl
Package: libdbd-sybase-perl Version: 1.00-1 Severity: normal the subject already says it... Martin -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Versions of packages libdbd-sybase-perl depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libct1 0.61-6.2 libraries for connecting to MS SQL ii perl5.8.4-8 Larry Wall's Practical Extraction ii perl-base [perlapi-5.8.0] 5.8.4-8 The Pathologically Eclectic Rubbis -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309405: mount.cifs: poor performance and high CPU load with large files (500MB+) compared to mount.smbfs
Hello, > Quoting Andrew Bartlett ([EMAIL PROTECTED]): >> None of this is a samba issue. mount.cifs is a simple helper binary >> that starts the in-kernel cifs filesystem, the same results may be >> obtained with a very simple 'mount' command. >> >> The correct package for this bug is the kernel, and the correct >> upstream is Steve French <[EMAIL PROTECTED]> and the disucssion list >> [EMAIL PROTECTED] I redirected my issue to this list, thanks for the hint. See http://lists.samba.org/archive/linux-cifs-client/2005-May/000841.html > Fine, one bug away for the samba package..:-) > > The only concern we now now is to know whether this is a problem that > may be reproduced with the current Debian kernelIt seems from the > bug report that the bug reporter experienced it with this kernel > also...so it may be worth reassigning it to the kernel (in Debian) > while probably reporting it also to Steve (I'm not online ATM but is > there a bugzilla BTS for the development too?). > Steve, Eloy, do we reassign this to one of Debian kernel packages as > well or just close it? I did some further tesing in between. First result: Only writing to the cifs mounted share is slow, reading from it is fast (8 MB/s) and not interrupted. Second result: Writing is slow and interrupted even with the original and current Sarge package kernel-image-2.6.8-2-686 (2.6.8-13). (For my first test I did nothing else than taking .config from the above and compiling my own version of it with kernel-package and kernel-source-2.6.8 (2.6.8-15). I only removed most drivers not relevant in the VM and optimized for P4 rather than 686. So I think this bug should not just be closed as it occurs with only plain Debian sarge packages, too. If you think it should be reassigned to a kernel package, then please do so, as I'm not sure which of these is the right for this bug. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309405: mount.cifs: poor performance and high CPU load with large files (500MB+) compared to mount.smbfs
Package: smbfs Version: 3.0.14a-1 Severity: normal I run a Linux box within a VMware, a Windows Server 2003 and a Windows 2000 Server (both not in VMware). When copying a CD image file from within Linux to a cifs mounted Win2003 share, I see a very poor performance and high CPU load (about 90% system) on the Linux VM. Copying begins with 3 MB/s (measured by mc), after 4% it suddenly stops for say 10-20 seconds, then continues with 1..2 MB/s, but stopping from time to time for several seconds. CPU load is only high while copying, not in the pauses. Copying the whole file (700MB) took about 10 minutes. Copying the same file in the same direction from a samba share at the W2K3 box is very much faster, copying is finished in about a minute, and CPU load on the Linux side is by far less. When copying the same file from Linux to a cifs mounted Windows 2000 share, I get a similar picture: Copying begins with 3 MB/s, but soon slows down to 1 MB/s with high CPU load. But here, it doesn't seem to have these long idle times. Nevertheless copying takes about 10 minutes, too. When mounting the Win2000 share with smbfs, however, I get about 4 MB/s and a system load of approx. 35%. (This may indicate, that bug #203887 is indeed solved.) I don't think it has anything to do with VMware as all other transfers from and to this Linux VM are fast (NFS, HTTP, FTP, and Samba as mentioned). (FTP and NFS copy performs with 10 MB/s) I tried to compile a new kernel with the newest CIFS (1.34), but unfortunately it doesn't compile with the Debian sarge kernel sources for 2.6.8, neither plain 1.34 nor 1.34-RHEL4. CIFS 1.34 does compile with Debian sid kernel 2.6.11, but unfortunately, the VMware net driver doesn't work with this kernel, so I cannot test this. I cannot test smbfs with W2K3 for comparison either, as I don't want to modify the W2K3 settings to allow non-signed SMB. On the Linux side I could test nearly everything, however, if somebody has some more ideas what to test. Martin -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-vmware-1 (from sarge kernel-source-2.6.8-15) Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages smbfs depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcomerr2 1.37-2 common error description library ii libkrb531.3.6-2 MIT Kerberos runtime libraries ii libldap22.1.30-6 OpenLDAP libraries ii netbase 4.21 Basic TCP/IP networking system ii samba-common3.0.14a-1Samba common files used by both th -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#218040: fetchmail: maybe a global option preconnect can help
Package: fetchmail Version: 6.2.5-12 Followup-For: Bug #218040 Just in case something is done to get this bug fixed, I want to describe my configuration, as it seems to be a bit different from the ones mentioned so far: I run fetchmail on a server which is different from the machine doing the ppp connection. Both server and router are always up, but the ppp link isn't and shouldn't in my case. It's not possible to run fetchmail on the dialup router. As I don't want to bring the ppp link up just to look for mails, I wish to notify fetchmail when it doesn't need to try to fetch mails (and avoid generating the error logs of course). The "monitor" or "interface" options are obviously useless for me as the ethernet link between server and router is up all the time. I am able to get the state of the ppp link via a shell script exit status, however. Unfortunately, "preconnect" produces log entries as already discussed when the script returns a non-zero exit status. (BTW: Why it reports "SYNTAX" is still another question: Why should a failing preconnect script be a syntax error??) What would help me (and I think could solve all the problems described here) would be another, global "preconnect" script, which is run just after awakening, but before the first log message. If this script exits non-zero, fetchmail would immediately sleep again, without producing any noise of course. (Maybe one should check for config file changes though, as this global preconnect may have changed in between) Another advantage for this scenario would be that the script need only to be run once, and not for each mailbox entry specified. Martin Koeppe -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295608: CoLo 1.17 [was Re: Bug#295608]
> Martin, can you please download 1.17 from > http://www.colonel-panic.org/cobalt-mips/colo/colo-1.17.tar.gz and see > if that works (there's a binary in binaries/colo-chain.elf). Yes, with this version DHCP from Win2K server is ok. Thank you for your quick response. > I won't upload 1.17 to Debian until 1.16 has entered testing. Maybe 1.17 should be included even in d-i, as this issue has confused me a bit when first installing with d-i. Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#295608: colo's DHCP client is not RFC conform -> fails with Win2000 DHCP server
Package: colo Version: 1.16-1 Severity: normal When typing "net" in the colo shell, it does not receive an IP address when connected to a Win2000 DHCP server. I traced the network traffic during the DHCP phase: frame source IPdestination IP content source MAC destination MAC - 1 0.0.0.0 255.255.255.255DHCP Discover cobalt's MAC ff:ff:ff:ff:ff:ff - 2 server's IP 255.255.255.255DHCP Offer server's MAC ff:ff:ff:ff:ff:ff - 3 0.0.0.0 server's IPDHCP Request cobalt's MAC server's MAC - This sequence is then repeated 10 times, as the Win2000 DHCP server seems to ignore the DHCP Request. No IP address is assigned. Tracing the DHCP packets from dhcp-client_2.0pl5 or from the Windows DHCP client produces: - 1 0.0.0.0 255.255.255.255DHCP Discover cobalt's MAC ff:ff:ff:ff:ff:ff - 2 server's IP 255.255.255.255DHCP Offer server's MAC ff:ff:ff:ff:ff:ff - 3 0.0.0.0 255.255.255.255DHCP Request cobalt's MAC ff:ff:ff:ff:ff:ff - 4 server's IP 255.255.255.255DHCP Ack server's MAC ff:ff:ff:ff:ff:ff - The IP address is successfully assigned. RFC 2131 says in chapter 3.1 client-server interaction - allocating a network address, item 3 that the DHCP Request packet must be broadcasted (and to the same broadcast address as the DHCP Discover packet). With ISC dhcp3 server on Linux it happens to work nevertheless, however, without broadcasting the DHCP Request. Martin Köppe -- System Information: Debian Release: 3.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
