Bug#1051743: debhelper: dh_installsystemd --name documentation doesn't match actual behavior
Subject: debhelper: dh_installsystemd --name documentation doesn't match actual
behavior
Package: debhelper
Version: 13.11.6
Severity: normal
Dear Debhelper Maintainers,
The dh_installsystemd documentation says that
As an example, B will look for
F<<< IB<< I >>I<.service> >>> instead of
F<< I >>).
after building a handful of packages and having this silently not work
(the silence isn't a problem per-se, it's just supposed to look for a
correctly named file and use it if present) I eventually figured out
that it would instead install the file F<< I >>,
ie. it would drop I entirely and just use the --name
argument.
There is also a lengthy comment in the source where the work happens
that matches the POD documentation, but the code itself at that point
simply does
my $name = $dh{NAME} // $package;
which doesn't concatenate anything, it just uses --name if defined, and
package if not.
A quick glance through git history shows that it's behaved this way
since at least 2018 and it looks like that was just an accurate
refactoring of the previous code - I haven't dug further, but perhaps
that is enough to suggest that 5 years is long enough that the
documentation should change to match the behaviour rather than changing
the code (possibly across debhelper's famously well-managed
compatibility levels.)
(If you agree with my assessment, I would be happy to contribute a
documentation patch, though it would be US/English only, I haven't
worked with translations before.)
Bug#910394: sqlcipher: Crashes on running any SQL Statement (with a key)
Oh, this is already known upstream: https://github.com/sqlcipher/sqlcipher/issues/196 so it should be "merely" a matter of getting the sid version into stretch-backports.
Bug#910394: sqlcipher: Crashes on running any SQL Statement (with a key)
Freshly installed to test this: i-meant-that$ dpkg --status sqlcipher|grep Version Version: 3.2.0-2 i-meant-that$ sqlcipher mydata.db SQLCipher version 3.8.6 2014-08-15 11:46:33 Enter ".help" for instructions Enter SQL statements terminated with a ";" sqlite> pragma key = 'passphrase'; sqlite> create table memos(text, priority INTEGER); Segmentation fault ie. one line from https://www.zetetic.net/sqlcipher/sqlcipher-api/ about actually setting a key, plus the first line of the man page example. (Bonus points for maybe adding any mention at all of "pragma key" to the man page :-) i-meant-that$ gdb --quiet -ex run --args sqlcipher mydata.db SQLCipher version 3.8.6 2014-08-15 11:46:33 sqlite> pragma key = 'passphrase'; sqlite> create table memos(text, priority INTEGER); Program received signal SIGSEGV, Segmentation fault. 0x76fc195f in EVP_EncryptUpdate () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 (gdb) where #0 0x76fc195f in EVP_EncryptUpdate () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1 #1 0x77b22e3b in sqlcipher_openssl_cipher (ctx=0x5579c238, mode=, key=0x5579c258 "\352U\243\236\375\266\026\037\242\247\370\232\215\323\063O\362-w\367\223c\242ɑ^W_]\254#)", key_sz=, iv=0x55797f98 "+\372\032\331\003O\271\246\201>\210\210\360\375W\034\253p\227\303\315\331Y\210@\252\233\\\212<\032y\177\334\330\030\231\213F\177.\365\032\222\360\063\361\067q", in=0x5579d1b8 "\004", in_sz=960, out=0x55797bd8 "") at sqlite3.c:16517 #2 0x77b3347e in sqlcipher_page_cipher (ctx=ctx@entry=0x55797b38, for_ctx=, pgno=1, mode=1, page_sz=, in=0x5579d1b8 "\004", out=0x55797bd8 "") at sqlite3.c:15696 #3 0x77b45104 in sqlite3Codec (iCtx=0x55797b38, data=0x5579d1a8, pgno=1, mode=6) at sqlite3.c:14389 #4 0x77b53799 in pager_write_pagelist (pPager=pPager@entry=0x55785a78, pList=0x5579d5e0) at sqlite3.c:48086 #5 0x77b5b5fa in sqlite3PagerCommitPhaseOne (pPager=0x55785a78, zMaster=zMaster@entry=0x0, noSync=noSync@entry=0) at sqlite3.c:50033 #6 0x77b5b7cf in sqlite3PagerCommitPhaseOne (noSync=0, zMaster=0x0, pPager=) at sqlite3.c:49932 #7 sqlite3BtreeCommitPhaseOne (p=0x55785558, zMaster=zMaster@entry=0x0) at sqlite3.c:57764 #8 0x77b5f421 in sqlite3BtreeCommitPhaseOne (zMaster=0x0, p=) at sqlite3.c:89551 #9 vdbeCommit (p=0x5579cb48, db=0x5576ec58) at sqlite3.c:1586 #10 sqlite3VdbeHalt (p=p@entry=0x5579cb48) at sqlite3.c:1993 #11 0x77b8e926 in sqlite3VdbeExec (p=p@entry=0x5579cb48) at sqlite3.c:71867 #12 0x77b8f8cf in sqlite3Step (p=0x5579cb48) at sqlite3.c:69631 #13 sqlite3_step (pStmt=) at sqlite3.c:4161 #14 0xa9d3 in shell_exec (db=0x5576ec58, zSql=0x5576ebc0 "create table memos(text, priority INTEGER);", pArg=0x7fffd2d0, pzErrMsg=0x7fffd138, xCallback=0x9a90 ) at ./src/shell.c:1360 #15 0xbbdf in process_input (p=0x7fffd2d0, in=0x0) at ./src/shell.c:3613 #16 0x7406 in main (argc=, argv=) at ./src/shell.c:4129
Bug#886871: postgresql-common: perl error in pg_createcluster
Package: postgresql-common
Version: 189
While diagnosing an unrelated problem with pg_upgradecluster, got the
"Configuring already existing cluster" message and chased down the code
to this, starting at line 351:
if ($existingver = $version) {
print "Configuring already existing cluster (configuration: $confdir,
data: $datadir, owner: $owneruid:$ownergid)\n";
} else {
Perl, like C, allows assignments in expressions; also like C, this is
often incorrect/unintended code, as it is in this case. (The preceding
lines set $existingver and it is obviously intended that they be
compared, not overwritten without ever examining the value; this isn't
subtle, it's just that you probably don't see this message unless
something *else* has already gone wrong, which is why it appears to have
been present since 2008.)
(Version 189 in sid is the newest version I could easily find to report
against.)
Bug#881693: ftp.debian.org: RM: owl -- ROM; abandoned upstream
Package: ftp.debian.org Severity: normal barnowl is a fork that people actually use, and there was some plan to do something clever about this that didn't go anywhere - it's time to just make it go away. Thanks!
Bug#830750: photofloat: traceback on run
Package: photofloat Version: 0~20120917+dfsg-3 Severity: normal Tried a run based on the instructions in /usr/share/doc/photofloat/README.Debian $ mkdir photo $ cd photo $ mkdir albums cache $ ln -s /usr/share/photofloat/web/* . $ mkdir albums/flickr $ ln $(kpa-grep --tag flickr) albums/flickr/ $ photofloat albums cache 2016-07-10T20:36:15.950083 | |--[thumbing] img_418-0601.jpg -> 1024px 2016-07-10T20:36:16.907571 |--[caching] flickr Traceback (most recent call last): File "/usr/bin/photofloat", line 21, in main() File "/usr/bin/photofloat", line 15, in main TreeWalker(sys.argv[1], sys.argv[2]) File "/usr/share/photofloat/scanner/TreeWalker.py", line 16, in __init__ self.walk(self.album_path) File "/usr/share/photofloat/scanner/TreeWalker.py", line 55, in walk album.add_album(self.walk(entry)) File "/usr/share/photofloat/scanner/TreeWalker.py", line 76, in walk album.cache(self.cache_path) File "/usr/share/photofloat/scanner/PhotoAlbum.py", line 68, in cache self._sort() File "/usr/share/photofloat/scanner/PhotoAlbum.py", line 51, in _sort self._photos.sort() File "/usr/share/photofloat/scanner/PhotoAlbum.py", line 318, in __cmp__ date_compare = cmp(self.date, other.date) TypeError: can't compare datetime.datetime to unicode Running it again is faster (presumably it's not regenerating the cached thumbnails, though it still prints all of the names) and ends with the same traceback. This appears to have been mentioned, but not responded to, elsewhere: https://lists.zx2c4.com/pipermail/photofloat/2013-November/28.html https://lists.zx2c4.com/pipermail/photofloat/2014-January/29.html with a possible patch: https://lists.zx2c4.com/pipermail/photofloat/2014-February/42.html http://lists.zx2c4.com/pipermail/photofloat/attachments/20140207/f14817be/attachment.patch (It looks like that's followed by release discussion, but just thought I'd still add the "doesn't work out of the box" data point.) -- System Information: Debian Release: 8.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages photofloat depends on: ii lmodern 2.004.4-5 ii python-imaging 2.6.1-2+deb8u2 ii python 2.7.9-1 Versions of packages photofloat recommends: ii libjs-jquery 1.7.2+dfsg-3.2 ii libjs-jquery-mousewheel 10-1 Versions of packages photofloat suggests: pn libapache2-mod-php5 | php5-fpm | php5-cgi ii nginx-light [nginx]1.6.2-5+deb8u2+b1 -- no debconf information
Bug#795205: python-serial: new version available (since 2013)
Package: python-serial Version: 2.6-1.1 Severity: normal pyserial 2.7 has been up on pypi and sf.net since late 2013, but the debian package is only 2.6 and is older than that... is there some reason I'm missing that it was held back at the time? I don't see anything in the changelog.Debian suggesting one (or was it just the NMU'er not wanting to go to far?) I'm particularly interested in this fix that's already in 2.7: http://sourceforge.net/p/pyserial/patches/29/ - without this fix, if you're using setitimer at all, pyserial basically doesn't work. (I'll try to follow up with packaging updates in the next week or two.) _Mark_ eic...@thok.org Debian Package Maintainer -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python-serial depends on: ii python 2.7.9-1 python-serial recommends no packages. Versions of packages python-serial suggests: ii python-wxgtk3.0 3.0.1.1+dfsg-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781009: xul-ext-zotero: fails to find installed pdfinfo and pdftotext
Package: xul-ext-zotero Version: 4.0.22-1 Severity: normal right-click on a just-downloaded pdf, select retrieve metadata (last item), and it gives a popup about installing pdf tools, which then opens the zotero preferences window in the search tab, which says PDF Indexing pdftotext-Linux-x86_64 is NOT installed pdfinfo-Linux-x86_64 is NOT installed When in fact, ii poppler-utils 0.26.5-2 amd64PDF utilities (based on Poppler) provides pdfinfo and pdftotext... (It's presumably also a bug that xul-ext-zotero doesn't just depend on poppler-utils, but I'd be happy with it actually using them, since automatically finding title and author info is a big part of the point of using zotero in the first place.) Looks like zotero-standalone exhibits the same bug. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages xul-ext-zotero depends on: ii iceweasel 31.3.0esr-1 xul-ext-zotero recommends no packages. xul-ext-zotero suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769875: docker.io: docker-run manpage misformatted, loses curly braces, breaks examples
Package: docker.io
Version: 1.2.0~dfsg1-1
Severity: normal
man docker-inspect includes:
Getting the IP address of a container instance
To get the IP address of a container use:
# docker inspect --format='.NetworkSettings.IPAddress'
1eb5fabf5a03
172.17.0.2
Looking at /usr/share/man/man1/docker-inspect.1.gz I see
.nf
# docker inspect \-\-format='\{\{.NetworkSettings.IPAddress\}\}' 1eb5fabf5a03
172.17.0.2
Which looks like it might be *intended* to cause the curly braces to
render literally, but it isn't working. (Without the braces, the
example gives back the literal string .NetworkSettings.IPAddress instead
of the actual address.)
At a quick glance, the Listing all port bindings right after that has
the same class of problem, as does the entire quoted json example.
I haven't done real nroff in decades, but if I feed the expected output
to ronn, it gives
# docker inspect \-\-format=\'{{\.NetworkSettings\.IPAddress}}\' 1eb5fabf5a03
which renders as-desired, when fed to nroff -man.
-- System Information:
Debian Release: jessie/sid
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages docker.io depends on:
ii adduser 3.113+nmu3
ii iptables1.4.21-2
ii libapparmor12.8.0-8
ii libc6 2.19-11
ii libdevmapper1.02.1 2:1.02.90-1
ii libsqlite3-03.8.6-1
ii perl5.20.1-1
Versions of packages docker.io recommends:
ii aufs-tools 1:3.2+20130722-1.1
ii ca-certificates 20140325
ii cgroupfs-mount 1.0
ii git 1:2.1.0-1
ii xz-utils 5.1.1alpha+20120614-2
Versions of packages docker.io suggests:
pn btrfs-tools none
ii debootstrap 1.0.63
pn lxc none
pn rinsenone
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763423: there *is* a way to turn it off
Got email from the upstream author who pointed out (and I just confirmed) that once you've started, hit *Settings, *Configure KPhotoAlbum, under the General Tab, Miscellaneous section, you can uncheck *Listen for Android devices on startup. I believe that for Debian this should certainly default to unchecked. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763423: there *is* a way to turn it off
Since this gets written out to ~/.kde/share/config/kphotoalbumrc under [General] as listenForAndroidDevicesOnStartup=false, it might be possible for the Debian-specific patch to install something in the existing global config in /usr/share/kde4/config/kphotoalbumrc though that uses different stanzas and I don't know what the exact change there should be (if I did, I'd have supplied a diff :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763423: kphotoalbum: Android support is great - but it has *no security*
Package: kphotoalbum Version: 4.5-1 Severity: normal Just got the popup about trying the Android app, which acts as a remote for the client, and I tried it and it worked... with *no access control* or even a popup... lsof confirms that kphotoalbum is just listening on a port: kphotoalb 29586 eichin 25u IPv41687321 0t0 UDP *:23455 https://www.youtube.com/watch?v=TxtD7BG61Ro at +9m10s describes how to turn it off, and there's a tiny button on the bottom of the screen to turn it off. I couldn't find a specific reference in the policy guide asserting that things like this should be closed-by-default, but it just seems obvious... main.cpp has options.add(nolisten-network, ki18n( Don't start listening for android devices on startup. )); which is backwards - and looking a little bit more (and experimenting) confirms that it doesn't *stay* off, it doesn't save the user's choice to the config file. Probably should be a higher severity than normal but I haven't explored quite far enough to confirm that there really is no way to cleanly leave it off. It's a very nice feature, it's just not in any way safe to have turned on by default... -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kphotoalbum depends on: ii kde-runtime4:4.14.1-1 ii libc6 2.19-11 ii libexiv2-130.24-4 ii libgcc11:4.9.1-15 ii libjpeg8 8d1-1 ii libkdcraw234:4.14.0-1 ii libkdecore54:4.14.1-1 ii libkdeui5 4:4.14.1-1 ii libkio54:4.14.1-1 ii libkipi11 4:4.13.3-1 ii libphonon4 4:4.8.0-1 ii libqt4-dbus4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libqt4-network 4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libqt4-sql 4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libqt4-sql-sqlite 4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libqt4-xml 4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libqtcore4 4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libqtgui4 4:4.8.6+git64-g5dc8b2b+dfsg-2 ii libstdc++6 4.9.1-15 ii mplayer2 2.0-728-g2c378c7-2+b2 ii perl 5.20.1-1 ii phonon 4:4.8.0-1 Versions of packages kphotoalbum recommends: pn khelpcenter4 none ii kipi-plugins 4:4.1.0-1+b2 ii libav-tools 6:11-1 kphotoalbum suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755376: python-pbs: pbs replaced by sh
Package: python-pbs Version: 0.95-1 Severity: normal per the top of https://pypi.python.org/pypi/pbs, as of pbs 0.110, pbs is now sh, see http://pypi.python.org/pypi/sh which is at 1.09 (see also http://amoffat.github.io/sh/) -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-pbs depends on: ii python 2.7.6-2 ii python2.7 2.7.7-2 python-pbs recommends no packages. python-pbs suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753458: googlecl: new plausible fork/upstream with a 0.9.15 version
Package: googlecl Version: 0.9.13-2 Severity: wishlist A possible new upstream for googlecl appeared on the forum, I just noticed it: https://groups.google.com/forum/#!topic/googlecl-discuss/WqlM3fpBOVE https://github.com/vinitkumar/googlecl I have no particular opinion on the validity of this fork, but it does seem to be getting a lot of recent activity, from a glance at the closed-issues list... https://github.com/vinitkumar/googlecl/issues?page=1state=closed -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages googlecl depends on: ii python2.7.6-2 ii python-gdata 2.0.18+dfsg1-2 pn python:anynone googlecl recommends no packages. googlecl suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753256: dgit: syntax error in at line 1: PGP signature not allowed here
Package: dgit Version: 0.21 Severity: minor Used dgit to pull ratmenu 2.3.20 down, work on it, pushed 2.3.21 which made it to unstable, dgit fetch again for consistency, made more changes for 2.3.22, tried to push ... but *forgot* to dgit build first (I'd been testing with dpkg-buildpackage directly.) $ dgit push canonical suite name for unstable is sid downloading http://ftp.debian.org/debian//pool/main/r/ratmenu/ratmenu_2.3.21.dsc... last upload to archive specified git hash Use of uninitialized value $_[0] in sprintf at /usr/share/perl5/Dpkg/ErrorHandling.pm line 48, GEN5 line 1. dgit: error: syntax error in at line 1: PGP signature not allowed here As errors go, that one is hideous (and I'm someone that *likes* python tracebacks for error reporting :-) It wasn't until I went back in my history to confirm the steps-to-reproduce that I noticed the lack of dgit build - if I'd tried to actually dig into the error message it would probably have led me even further astray... -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dgit depends on: ii curl 7.37.0-1+b1 ii devscripts 2.14.5 ii dpkg-dev 1.17.10 ii dput 0.9.6.4 ii git [git-core] 1:2.0.0-2 ii libdpkg-perl 1.17.10 ii libwww-perl6.06-1 ii perl [libdigest-sha-perl] 5.18.2-4 ii realpath 1.19 ii wget 1.15-1+b1 Versions of packages dgit recommends: ii openssh-client [ssh-client] 1:6.6p1-5 Versions of packages dgit suggests: pn sbuild none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696866: git current (post 0.7) builds almost trivially
I needed post-0.5 to play with the spark.io spark core, which needed :leave support at least; dropping the debian dir into a git clone of upstream, running ./autogen.sh (and doing a dpkg --commit of that, which was probably wrong but I got about 15 seconds into untangling the cdbs autotools support and moved on :-) and it worked fine. So, consider this another ping towards doing a low-effort version bump... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722177: 6.x dependencies
While you're updating things for nikola 6 - Debian only has python-doit 0.22.1, and nikola (6.2 at least, but probably went in earlier) needs at least doit 0.23 (and the failure mode is an obscure error, under earlier versions.) -- _Mark_ eic...@thok.org eic...@gmail.com
Bug#531036: 2nd re: Bug#531036: Working patch for #531036 (ratmenu: doesn't support multibyte/UTF-8 characters)
Explicitly setting LANG=en_US.UTF-8 helped, and installing more fonts (xfonts-terminus in particular) improved things further (didn't work by itself, $LANG really is critical to Xmb* working, it appears.) Now that I can actually demonstrate it, I'm happy to push the change out, should show up soon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531036: Working patch for #531036 (ratmenu: doesn't support multibyte/UTF-8 characters)
Appreciate the effort... except the resulting ratmenu doesn't actually display those characters, against a Karmic X server (where the uxterm example works fine.) XmbTextEscapement returns zero for the non-ASCII string, even though def_string is empty and missing_charset_count is zero... I haven't dug into the relevant X sources yet, but offhand, is there any locale, environment, or xrdb settings needed to demonstrate this? (uxterm does display the characters for me in the example...) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561039: updated patch
found a second reset_heartbeat instance that did the same thing;
switched to checking against not HB_DISABLED for consistency.
--- tzc-2.6.15.orig/tzc.c
+++ tzc-2.6.15/tzc.c
@@ -1369,7 +1377,9 @@
globals-ebuf = (char *) malloc(globals-ebufsiz);
globals-ebufptr = globals-ebuf;
- reset_heartbeat();
+ if (globals-heartbeat.status != HB_DISABLED) {
+ reset_heartbeat();
+ }
globals-pending_replies = NULL;
@@ -1605,7 +1616,9 @@
}
/* zephyr server is still talking to us, so reset the heartbeat
*/
- reset_heartbeat();
+ if (globals-heartbeat.status != HB_DISABLED) {
+ reset_heartbeat();
+ }
/* if this is a heartbeat zgram, don't report it */
if (!strcasecmp(notice-z_class, TZC_HEARTBEAT_CLASS)
@@ -2003,6 +2016,7 @@
globals-heartbeat.period = atoi(optarg);
if (globals-heartbeat.period == 0)
globals-heartbeat.status = HB_DISABLED;
+ break;
case 'd':
globals-debug = 1;
break;
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546245: sysvinit: /etc/nologin symlink deleted by /sbin/shutdown
Package: sysvinit Version: 2.86.ds1-61 Severity: normal When looking at some etch-lenny upgrade diffs, noticed that while the sysvinit postinst creates a symlink from /etc/nologin to /var/run/initscripts/nologin, the first shutdown after the upgrade (or install) simply deletes the symlink. sysvinit-2.86.ds1/src/paths.h: #define NOLOGIN /etc/nologin /* Stop user logging in. */ sysvinit-2.86.ds1/src/shutdown.c, shutdown(): unlink(NOLOGIN); (Maybe this should reopen Bug#191041 which introduced the use of /var/run, but that's from 2003 and archived... also, pam also looks at /etc/nologin directly, perhaps the symlink change should just be reverted?) -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages sysvinit depends on: ii initscripts 2.86.ds1-61 Scripts for initializing and shutt ii libc62.7-18 GNU C Library: Shared libraries ii libselinux1 2.0.65-5SELinux shared libraries ii libsepol12.0.30-2Security Enhanced Linux policy lib ii sysv-rc 2.86.ds1-61 System-V-like runlevel change mech ii sysvinit-utils 2.86.ds1-61 System-V-like utilities sysvinit recommends no packages. sysvinit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#525563: please package new upstream release (2.0)
Looks like it's enough to
$ git clone git://gitorious.org/python-markdown/mainline.git
$ cd mainline
$ svn co
svn://svn.debian.org/python-modules/packages/python-markdown/trunk/debian
Bump the version (debian/changelog diff) and tweak the rules file:
Index: debian/changelog
===
--- debian/changelog(revision 9376)
+++ debian/changelog(working copy)
@@ -1,3 +1,9 @@
+python-markdown (2.0-0) unstable; urgency=low
+
+ * local quick-port to upstream 2.0
+
+ -- Mark W. Eichin eic...@thok.org Wed, 19 Aug 2009 21:58:02 -0400
+
python-markdown (1.7-3) UNRELEASED; urgency=low
* Remove myself from Uploaders.
Index: debian/rules
===
--- debian/rules(revision 9376)
+++ debian/rules(working copy)
@@ -6,11 +6,8 @@
include /usr/share/cdbs/1/class/python-distutils.mk
DEB_AUTO_CLEANUP_RCS:= yes
-DEB_INSTALL_CHANGELOGS_ALL := CHANGE_LOG.txt
+DEB_INSTALL_CHANGELOGS_ALL := docs/CHANGE_LOG
-install/python-markdown::
- chmod 0755 debian/python-markdown/usr/lib/`pyversions
-d`/site-packages/markdown.py
-
clean::
find -name '*.pyo' -exec rm -f {} \;
and the resulting package builds and is useful. This isn't enough, of
course:
* debian/watch is wrong, they're not using sourceforge anymore
* pyversions: missing XS-Python-Version in control file, fall back
to debian/pyversions
* I don't know if the changelog choice above is *right*
* dh_python: Doing nothing since dh_pycompat exists; dh_pysupport
or dh_pycentral should do the work. You can remove dh_python from
your rules file. (except that with cdbs, it's not *in* the
rules file...)
* warning, `debian/python-markdown/DEBIAN/control' contains
user-defined field `Python-Version'
(Not volunteering to co-maintain, I'm not responsive enough on my
*own* packages, but I'm now using it enough to chip in from time to
time :-)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541247: ntp: missing lockfile-progs dependency
Package: ntp Version: 1:4.2.4p4+dfsg-8lenny2 Severity: normal ntp (1:4.2.4p4+dfsg-4) unstable; urgency=low * Also use lockfile-progs to ensure that ntpd does not start while ntpdate.ifup is running (closes: #436029) -- Peter Eisentraut pet...@debian.org Tue, 29 Apr 2008 11:19:54 +0200 Now, I do see that ntpdate Recommends: lockfile-progs - I just don't think that's strong enough, it's too easy to install both ntp and ntpdate without them. Alternatively, any documentation at all that you *must* grab lockfile-progs would help (there's nothing in the docstring, README.Debian, or NEWS.Debian...) (If you're wondering why we install both: standard appliance install with varying end-user choices, where they might enable ntp or not, but if they don't they might still run ntpdate once to set the the clock... obviously we've also worked around it by installing lockfile-progs, now, but only because we ran into a system where ntpd was not running at all, because ntpdate collided since lockfile-progs wasn't present.) -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ntp depends on: ii adduser 3.110add and remove users and groups ii libc6 2.7-18 GNU C Library: Shared libraries ii libcap1 1:1.10-14support for getting/setting POSIX. ii libedit22.11~20080614-1 BSD editline and history libraries ii libncurses5 5.7+20081213-1 shared libraries for terminal hand ii libssl0.9.8 0.9.8g-15+lenny1 SSL shared libraries ii lsb-base3.2-20 Linux Standard Base 3.2 init scrip ii netbase 4.34 Basic TCP/IP networking system Versions of packages ntp recommends: ii perl 5.10.0-19 Larry Wall's Practical Extraction Versions of packages ntp suggests: pn ntp-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540955: libpam-runtime: clever upgrade-logic seems to not work
Package: libpam-runtime Version: 1.0.1-5+lenny1 Severity: normal libpam-runtime.postinst does a clever update if the md5sums match our records bit, but only if [ -z $2 ] || dpkg --compare-versions $2 lt 0.76-17 which appears to mean it only triggers on upgrades from sarge to etch (since lenny is 1.0.1-5+lenny1 and etch is 0.79-5+etch1) but /usr/share/pam/common-passwords.md5sum in partiular *did* get updated between etch and lenny, so it looks like this is intended to be applied currently... (not 100% sure on my reading of the script, but I'm only looking at this because I have an etch to lenny upgrade where it didn't happen...) -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#540982: postgresql-common: dependencies insufficient for ssl-cert group
Package: postgresql-common Version: 94lenny1 Severity: normal The ssl-cert package creates the ssl-cert group in its postinst. postgresql-common does: if getent group ssl-cert /dev/null; then adduser --quiet postgres ssl-cert fi to add the postgres user to this group, but only if it exists. I believe this was introduced with postgresql-common (92) unstable; urgency=low * Demote ssl-cert Depends: to Recommends:. (Closes: #498406) -- Martin Pitt mp...@debian.org Sun, 16 Nov 2008 13:42:31 +0100 since policy says A package will not be configured unless all of the packages listed in its `Depends' field have been correctly configured. but it says no such thing about Recommends... There's an attempt to fix this in: postgresql-8.3 (8.3.4-2) unstable; urgency=medium * Add dependency to ssl-cert. This has always been implicitly there through postgresql-common, but when upgrading -8.3 and ssl-cert at the same time, apt does not ensure to configure ssl-cert before postgresql-8.3 if there is no direct dependency. (Closes: #501690) -- Martin Pitt mp...@debian.org Sat, 11 Oct 2008 14:28:34 +0200 but I don't see any reason that would actually help, since the postgresql-8.3 ordering is irrelevant, at least on fresh installs. I've actually observed this in a lenny-based install: Setting up postgresql-client-common (94lenny1) ... Setting up postgresql-client-8.3 (8.3.7-0lenny1) ... Setting up postgresql-common (94lenny1) ... Setting up openssl-blacklist (0.4.2) ... Setting up ssl-cert (1.0.23) ... Setting up postgresql-8.3 (8.3.7-0lenny1) ... that is, the inconsistency is real (I found this by looking at why an upgraded system and a newly installed system differed.) If postgresql-8.3 is going to include the dependency *anyway*, perhaps debbugs#498406 should just be reverted? -- System Information: Debian Release: 5.0.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515118: CVE-2009-0363: multiple buffer overflows that can be remotely triggered
FYI I've just heard back from kretch and he's testing a new release, so we should be able to kick out a new package within the week. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515118: CVE-2009-0363: multiple buffer overflows that can be remotely triggered
I'll take a look at those patches and also see if upstream is at all interested. (Last resort would be a self-immolating use-barnowl-instead package.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514310: vncsnapshot: argument parsing (-tunnel) broken
Package: vncsnapshot
Version: 1.2a-1+b1
Severity: normal
Took some playing around with ltrace to catch this, but
vncsnapshot -tunnel ${host}:3 /tmp/${host}.03.jpg
gives a Usage message which includes
Usage: vncsnapshot [OPTIONS] [HOST]:DISPLAY# filename
vncsnapshot [OPTIONS] -listen [DISPLAY#] filename
vncsnapshot [OPTIONS] -tunnel HOST:DISPLAY# filename
vncsnapshot [OPTIONS] -via GATEWAY [HOST]:DISPLAY# filename
Turns out -tunnel (tunnel.c, processTunnelArgs) looks at the *last*
argument for host:port:
pdisplay = strchr(argv[*pargc - 1], ':');
rather than tunnelArgIndex. This would suggest
vncsnapshot -tunnel /tmp/${host}.03.jpg ${host}:3
which in fact gets around the argument parsing, and prompts for a
password, and then fails with:
Couldn't convert '/tmp/${host}.03.jpg' to host address
Unable to connect to VNC server
Anyway, here's a patch (with debugging noise left in) that makes
vncsnapshot -tunnel work. -via is probably broken too, I haven't
tried it yet. The key bits are
* actually *use* tunnelArgIndex
* use localhost::port so it doesn't add 5900 to it again
(It looks like upstream hasn't been touched since 2004, so getting
this fixed in debian directly would probably be worthwhile.)
--- vncsnapshot-1.2a.orig/tunnel.c
+++ vncsnapshot-1.2a/tunnel.c
@@ -106,6 +106,8 @@
if (!runCommand(cmd))
return False;
+ fprintf(stderr, Successfully runCommand(%s)\n, cmd);
+
return True;
}
@@ -115,11 +117,16 @@
{
char *pdisplay;
+ fprintf(stderr, processTunnelArgs:);
+ showArgs(*pargc, argv);
+
if (tunnelArgIndex = *pargc - 1)
usage();
- pdisplay = strchr(argv[*pargc - 1], ':');
- if (pdisplay == NULL || pdisplay == argv[*pargc - 1])
+ fprintf(stderr, tAI=%d: %s\n, tunnelArgIndex, argv[tunnelArgIndex]);
+ fprintf(stderr, tAI+1: %s\n, argv[tunnelArgIndex+1]);
+ pdisplay = strchr(argv[tunnelArgIndex + 1], ':');
+ if (pdisplay == NULL || pdisplay == argv[tunnelArgIndex + 1])
usage();
*pdisplay++ = '\0';
@@ -130,12 +137,15 @@
if (*remotePort 100)
*remotePort += SERVER_PORT_OFFSET;
- sprintf(lastArgv, localhost:%d, localPort);
+ sprintf(lastArgv, localhost::%d, localPort); /* see argsresources.c,
GetArgsAndResources, Two colons comment */
- *remoteHost = argv[*pargc - 1];
- argv[*pargc - 1] = lastArgv;
+ *remoteHost = argv[tunnelArgIndex + 1];
+
+ argv[tunnelArgIndex + 1] = lastArgv;
removeArgs(pargc, argv, tunnelArgIndex, 1);
+ showArgs(*pargc, argv);
+
}
static void
--- vncsnapshot-1.2a.orig/argsresources.c
+++ vncsnapshot-1.2a/argsresources.c
@@ -337,3 +337,10 @@
*((Bool *)arg) = value;
return 1;
}
+
+void showArgs(int argc, char** argv) {
+ int i;
+ for (i=0; iargc; i++) {
+fprintf(stderr, \tARGV[%d]=%s\n, i, argv[i]);
+ }
+}
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.24.2-mc0
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages vncsnapshot depends on:
ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries
ii libgcc11:4.1.1-21GCC support library
ii libjpeg62 6b-13 The Independent JPEG Group's JPEG
ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3
ii vnc-common 3.3.7-14 Virtual network computing server s
ii zlib1g 1:1.2.3-13compression library - runtime
vncsnapshot recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511553: python-werkzeug: unicode.html missing from package
Package: python-werkzeug Version: 0.3.1-1 Severity: normal /usr/share/doc/python-werkzeug/html/index.html points to a missing unicode.html. The source package contains python-werkzeug-0.3.1/docs/src/unicode.txt but python-werkzeug-0.3.1/build doesn't have a corresponding unicode.html... -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages python-werkzeug depends on: ii python [python-wsgiref] 2.5.2-3An interactive high-level object-o ii python-support0.8.4 automated rebuilding support for P Versions of packages python-werkzeug recommends: ii python-simplejson 1.9.2-1Simple, fast, extensible JSON enco Versions of packages python-werkzeug suggests: pn ipython none (no description available) ii python-genshi 0.5.1-1Python XML-based template engine ii python-lxml 2.1.1-2.1 pythonic binding for the libxml2 a ii python-pkg-resources 0.6c8-4Package Discovery and Resource Acc -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#120160: WINDOWID equivalent for m-x shell?
Sven Joachim svenj...@gmx.de writes: tags 120160 + moreinfo thanks Hello Mark, I'm going through the list of old Emacs bugs in Debian. This one is a bit mysterious to me. On 2001-11-19 04:50 +0100, Mark W. Eichin wrote: Package: emacs21 Version: 21.1-5 Priority: wishlist Could FRAME_X_WINDOW (f) get leaked (through some (x-* FRAME) function), or even better, passed into the environment that a M-x shell gets? (maybe use $WINDOWID like xterm does - would be convenient for calling out to things like xwit; or maybe not.) Passing into the environment of a shell running under Emacs seems to be wrong, since the frame where the shell buffer is displayed (if any) is subject to change, and you cannot change the environment of subprocesses after they are started. It's also not clear to me which problem you want to solve. Could you elaborate? Hmm, that's a good point. And poking at frames in emacs22, it looks like I can get the window id with (frame-parameter nil 'outer-window-id) which is probably sufficient for whatever I was trying to do at the time, so you can go ahead and close this (since I have no interest in backporting the feature, just having it in emacs.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501629: python-sphinx: ansi color not always appropriate
Package: python-sphinx Version: 0.4.2-1 Severity: wishlist Both sphinx-build and sphinx-quicksetup attempt (and fail) to use ansi color sequences, even when TERM=dumb (for example, when run from an emacs shell buffer, or m-x compile. This produces garbage, like this: ^[[01mSphinx v0.4.2, building linkcheck^[[39;49;00m While it does look like I can add -N in the generated Makefile, and thus this is only a wishlist item since I have a workaround - it really shouldn't generate color unless it has *some* indication that it might work - even mooching off of $LSCOLORS would be better than doing it blindly, though it should be enough to look at a TERM or TERMCAP property - or perhaps indirectly via curses.has_colors() which does appear to be able to tell xterm from dumb successfully. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages python-sphinx depends on: ii libjs-jquery 1.2.6-1JavaScript library for dynamic web ii python2.5.2-2An interactive high-level object-o ii python-central0.6.8 register and build utility for Pyt ii python-docutils 0.5-2 Utilities for the documentation of ii python-jinja 1.2-2 small but fast and easy to use sta ii python-pygments 0.10-1 syntax highlighting package writte python-sphinx recommends no packages. python-sphinx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499909: xscreensaver: new login button exists
Package: xscreensaver Version: 5.05-3 Severity: wishlist I couldn't find anything in the man page (and haven't dug in to the code yet) but I use xscreensaver to lock my laptop screen, and a new login button is something I don't want to have. (This is distinct from debbugs#304406 which suggests that it won't work anyway - I'm looking for a configuration option, though I'd be happy to lose it altogether too.) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages xscreensaver depends on: ii libatk1.0-01.22.0-1 The ATK accessibility toolkit ii libc6 2.7-13GNU C Library: Shared libraries ii libcairo2 1.6.4-6 The Cairo 2D vector graphics libra ii libglade2-01:2.6.2-1 library to load .glade files at ru ii libglib2.0-0 2.16.5-1 The GLib library of C routines ii libgtk2.0-02.12.11-3 The GTK+ graphical user interface ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libpam0g 1.0.1-4 Pluggable Authentication Modules l ii libpango1.0-0 1.20.5-2 Layout and rendering of internatio ii libsm6 2:1.0.3-2 X11 Session Management library ii libx11-6 2:1.1.4-2 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxml22.6.32.dfsg-3 GNOME XML library ii libxmu62:1.0.4-1 X11 miscellaneous utility library ii libxpm41:3.5.7-1 X11 pixmap library ii libxrandr2 2:1.2.3-1 X11 RandR extension library ii libxrender11:0.9.4-2 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio ii libxxf86vm11:1.0.2-1 X11 XFree86 video mode extension l ii xscreensaver-data 5.05-3data files to be shared among scre Versions of packages xscreensaver recommends: ii libjpeg-progs 6b-14 Programs for manipulating JPEG fil ii perl [perl5] 5.10.0-13 Larry Wall's Practical Extraction ii wamerican [wordlist] 6-2.3 American English dictionary words ii xli1.17.0+20061110-2 command line tool for viewing imag Versions of packages xscreensaver suggests: ii conkeror [www-browser] 0.9~git080629-1 keyboard focused web browser with pn fortune none (no description available) ii iceweasel [www-browser] 3.0.1-1 lightweight web browser based on M ii lynx-cur [www-browser] 2.8.7dev9-2 Text-mode WWW Browser with NLS sup pn qcam | streamer none (no description available) ii w3m [www-browser]0.5.2-2+b1 WWW browsable pager with excellent pn xdaliclock none (no description available) pn xfishtanknone (no description available) pn xscreensaver-gl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304406: xscreensaver: New Login button without gdmflexiserver
This is checked in compilation-time. I could build a `xscreensaver-nonewlogin' package but I think could be annoying... And if you're using no [x|g|k]dm I guess you should know that there's no option to new login :). There are two issues here: (1) according to apt-file search, gdmflexiserver is *only* provided by gdm, not xdm (which I do happen to be running) nor kdm. (kdm might provide something *like* it, but xscreensaver is hard coded to have *newLoginCommand: gdmflexiserver -l -a -c FLEXI_XSERVER in the binary, so it wouldn't help if it did...) (2) per debian policy, 7.2 binary dependencies, xscreensaver needs at *least* a Suggests: gdm to describe the above dependency... While it would be *better* to see the button go away if it can't possibly work, I think you at least need to correct the packaging to reflect the above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495308: bfr: man page contains POD errors
Package: bfr Version: 1.6-2 Severity: normal bfr(1) ends with POD ERRORS. POD ERRORS Hey! The above document had some coding errors, which are explained below: Around line 179: You forgot a '=back' before '=head2' Around line 181: '=item' outside of any '=over' Around line 229: You forgot a '=back' before '=head2' Around line 231: '=item' outside of any '=over' bfr documentation2004-03-03 BFR(1) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages bfr depends on: ii libc6 2.7-13 GNU C Library: Shared libraries bfr recommends no packages. bfr suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486304: dfo: tracebacks while syncing
http://groups.google.com/group/dfo-users/browse_thread/thread/50e04abad374aca5 suggests that it's a similar sql-injection-ish quoting error; the fix given in that thread is mostly a demonstration, it's not anywhere near complete, but at least it's another instance of the same thing... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486304: dfo: tracebacks while syncing
Package: dfo Version: 0.7+svn45-4 Severity: normal dfo mostly works, but I get these mono tracebacks intermittently while or perhaps after syncing (photos, tags, and sets seem ok, pools aren't up to date though...) near t: syntax error at Mono.Data.SqliteClient.SqliteCommand.GetNextStatement (IntPtr pzStart, System.IntPtr pzTail, System.IntPtr pStmt) [0x0] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32 rows_affected) [0x0] at Mono.Data.SqliteClient.SqliteCommand.ExecuteNonQuery () [0x0] at PersistentInformation.RunNonQuery (System.String query) [0x0] at PersistentInformation.InsertPool (System.String groupid, System.String title) [0x0] at FlickrCommunicator.UpdatePools () [0x0] at FlickrCommunicator.RoutineCheck () [0x0] near t: syntax error at Mono.Data.SqliteClient.SqliteCommand.GetNextStatement (IntPtr pzStart, System.IntPtr pzTail, System.IntPtr pStmt) [0x0] at Mono.Data.SqliteClient.SqliteCommand.ExecuteReader (CommandBehavior behavior, Boolean want_results, System.Int32 rows_affected) [0x0] at Mono.Data.SqliteClient.SqliteCommand.ExecuteNonQuery () [0x0] at PersistentInformation.RunNonQuery (System.String query) [0x0] at PersistentInformation.InsertPool (System.String groupid, System.String title) [0x0] at FlickrCommunicator.UpdatePools () [0x0] at FlickrCommunicator.RoutineCheck () [0x0] -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages dfo depends on: ii libflickrnet2.1.5-cil 25277-6 Flickr.Net API Library ii libgconf2.0-cil 2.20.1-1 CLI binding for GConf 2.20 ii libglade2.0-cil 2.12.1-1 CLI binding for the Glade librarie ii libglib2.0-cil 2.12.1-1 CLI binding for the GLib utility l ii libgtk2.0-cil 2.12.1-1 CLI binding for the GTK+ toolkit 2 ii libmono-corlib2.0-cil 1.9.1+dfsg-1 Mono core library (2.0) ii libmono-sqlite2.0-cil 1.9.1+dfsg-1 Mono Sqlite library ii libmono-system-data2.0-cil 1.9.1+dfsg-1 Mono System.Data Library ii libmono-system2.0-cil 1.9.1+dfsg-1 Mono System libraries (2.0) ii mono-runtime1.9.1+dfsg-1 Mono runtime dfo recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484231: erc: erc discards errors on join
Package: erc Version: 5.3-1 Severity: normal (C-c C-j runs the command erc-join-channel) connected to freenode, joined #python.web. c-c c-j #python did nothing, no errors, but no new buffer and no change either. c-c c-j #pylons however did create a new buffer with the #pylons channel in it. Some googling pointed out: http://www.nabble.com/Official-IRC-channel-for-Python--td15660847.html that one needs a registered nick to join #python; the python-list thread suggests that other clients actually tell you that on failure, so erc probably should too. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages erc depends on: ii emacs [emacsen] 22.2+2-2 The GNU Emacs editor (metapackage) ii emacs22 [emacsen] 22.2+2-2 The GNU Emacs editor ii emacsen-common1.4.17 Common facilities for all emacsen ii make 3.81-4 The GNU version of the make util erc recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477626: owl: should this package be orphaned or removed?
Barry deFreese [EMAIL PROTECTED] writes: Package: owl Version: 2.1.8-2.1 Severity: normal User: [EMAIL PROTECTED] Usertags: proposed-orphan Dear Maintainer, While reviewing some packages, your package came up as a package that should maybe be orphaned by its maintainer, because: * Out of date * Buggy (1 RC bug) Which is gcc4.3-autobuilder specific, apparently, and only showed up in the last week. * Last maintainer upload 2004 (NMU in 2005). * Low popcon. (~16 installed). I know of more users than that personally :-) but they're downstream (ubuntu, debathena, etc.) If you think that it should be removed from Debian instead of being orphaned, please reply to this bug and tell so. If you disagree and want to continue to maintain this package, please close this bug and do an upload also fixing the other issues. Also, you can study the possibility of taking co-maintainers. I'll just close this as part of the next upload (that closes the gcc4.3 problem.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476013: owl: FTBFS: configure: error: installation or configuration problem: C compiler cannot create executables.
Do you keep config.log from these? (Although in this case it's libfaim/config.log I guess.) The report doesn't actually give enough information to figure out what the bug is... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440349: need help reproducing
dann frazier [EMAIL PROTECTED] writes: I've tried to reproduce this issue in various scenarios, but haven't been able to yet. Can you provide me the command you used? -- dann frazier I just tried the svn_path_exists I mentioned in the original bug report under Ubuntu Hardy pre-alpha (svn-load 0.7-1, python-svn 1.5.2-1, libsvn1 1.4.6dfsg1-2ubuntu1) and it works; I've also used svn-load successfully here. My guess is that it's some fix to either the python bindings or subversion itself between when I reported it and now so feel free to close it, thanks for checking up. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470519: libneon27-dev: missing libneon.la
Package: libneon27-dev Severity: normal Attempting to build debs of the 1.5.x branch of subversion fails when libneon27-dev is installed: libtool: link: cannot find the library `/usr/lib/libneon.la' or unhandled argument `/usr/lib/libneon.la' make[1]: *** [subversion/libsvn_ra_neon/libsvn_ra_neon-1.la] Error 1 It's absent in libneon26-dev as well, but present in libneon25-dev, and rolling back to libneon25-dev works. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#470526: python-svn: inconsistent %-encoding
Package: python-svn
Version: 1.5.1-2
Severity: normal
The script below sets up a test repository, and then generates this output:
file:///tmp/pysvn-bug/test_repos/trunk/testing/file with spaces
[('file with spaces', PysvnInfo '')]
file:///tmp/pysvn-bug/test_repos/trunk/testing/file%20with%20twenties
Traceback (most recent call last):
File string, line 1, in ?
pysvn._pysvn_2_4.ClientError: URL
'file:///tmp/pysvn-bug/test_repos/trunk/testing/file%20with%20twenties'
non-existent in revision '4'
I don't know what layer contains the bug, but I would suggest that
it's a reasonable invariant to be able to say that pysvn.Client.info2
can be called on any .path returned by pysvn.Client.list, especially
if the repository hasn't changed in the meantime.
I'll note that if I manually feed that url to the svn commandline, it
fails, but in an entirely different way:
$ svn info
file:///tmp/pysvn-bug/test_repos/trunk/testing/file%20with%20twenties
file:///tmp/pysvn-bug/test_repos/trunk/testing/file%20with%20twenties: (Not
a valid URL)
if I manually quote those, I get:
$ svn info
file:///tmp/pysvn-bug/test_repos/trunk/testing/file%2520with%2520twenties
Path: file%20with%20twenties
Name: file%20with%20twenties
URL: file:///tmp/pysvn-bug/test_repos/trunk/testing/file%2520with%2520twenties
and likewise, that works in info2 as well:
pysvn.Client().info2(file:///tmp/pysvn-bug/test_repos/trunk/testing/file%2520with%2520twenties)
[('file%20with%20twenties', PysvnInfo '')]
but if my code is supposed to know about and perform that quoting, it
really needs to be documented as part of pysvn (obviously I'd prefer
it to be fixed, instead, at whatever level is suitable.)
Also, that %20 case isn't hypothetical - it involves checking in web
content which actually has quoting like that - I've just cooked the
example down a bit.
#!/bin/sh -ex
rm -rf test_repos
rm -rf test_svn_checkout
case $1 in
clean) exit 0;
;;
esac
SVN=file://$(pwd)/test_repos
# create the repository
svnadmin create test_repos
svn mkdir -m $LINENO $SVN/trunk
svn mkdir -m $LINENO $SVN/trunk/testing
# create a file with a space
svn co $SVN/trunk/testing test_svn_checkout
touch test_svn_checkout/file with spaces
svn add test_svn_checkout/file with spaces
svn commit -m $LINENO test_svn_checkout/file with spaces
touch test_svn_checkout/file%20with%20twenties
svn add test_svn_checkout/file%20with%20twenties
svn commit -m $LINENO test_svn_checkout/file%20with%20twenties
python -c 'import pysvn; pc=pysvn.Client();
pl=pc.list('$SVN'/trunk/testing,recurse=True); print pl[1][0].path; print
pc.info2(pl[1][0].path); print pl[2][0].path; print pc.info2(pl[2][0].path)'
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 2.6.22-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages python-svn depends on:
ii libapr1 1.2.11-1 The Apache Portable Runtime Librar
ii libc6 2.7-5GNU C Library: Shared libraries
ii libgcc1 1:4.2.2-4GCC support library
ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3
ii libsvn1 1.4.4dfsg1-1 Shared libraries used by Subversio
ii libuuid11.40.3-1 universally unique id library
ii python 2.4.4-6 An interactive high-level object-o
ii python-central 0.5.15-0.1 register and build utility for Pyt
python-svn recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306459: pymacs: examples from the documentation don't work
To create the re identifier on the Python side, you need to write M-x pymacs-exec RET import re RET It's nice that there's another workaround, but the real problem is that the example as-written in the documentation didn't work :-) Additionally the documentation will be clarified in the upcoming 0.23 release of pymacs. Yay! (both that the docs will be fix *and* that there's new life in pymacs :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454632: owl: new upstream release (2.1.11)
Package: owl Version: 2.1.8-2.1 Severity: wishlist not actually known to fix anything, but should be upgraded for completeness, I hadn't heard about it. -- System Information: Debian Release: lenny/sid APT prefers gutsy-updates APT policy: (500, 'gutsy-updates'), (500, 'gutsy-security'), (500, 'gutsy') Architecture: i386 (i686) Kernel: Linux 2.6.22-14-generic (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages owl depends on: ii libc62.6.1-1ubuntu10 GNU C Library: Shared libraries ii libcomerr2 1.40.2-1ubuntu1 common error description library ii libkrb53 1.6.dfsg.1-7build1 MIT Kerberos runtime libraries ii libncurses5 5.6+20070716-1ubuntu3 Shared libraries for terminal hand ii libperl5.8 5.8.8-7ubuntu3 Shared Perl library ii libzephyr3-krb [ 2.1.20070719.SNAPSHOT-1 The original Instant Message sys ii zephyr-clients 2.1.20070719.SNAPSHOT-1 The original Instant Message sys owl recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451311: aptitude: Aptitude::ProblemResolver::StepLimit=0 spins forever
Package: aptitude Version: 0.4.4-4 Severity: normal Specifying -o Aptitude::ProblemResolver::StepLimit=0 (I'm looking for a way to turn off the resolver entirely, in a controlled-upgrade scenario where it shouldn't require resolution to complete the upgrade and I want it to fail instead, without having to actually parse the output and detect the prompts :-) causes an infinite loop of Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Resolving dependencies... Since StepLimit is documented, it's probably worth at least a sanity check on its value, there. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6. 0.6.46.4-0.1 Advanced front-end for dpkg ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libncursesw5 5.5-5 Shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.0.17-2 type-safe Signal Framework for C++ ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) pn libparse-debianchangelog-perl none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440349: svn-load: repository probe doesn't work
Package: svn-load
Version: 0.6-1
Severity: normal
(Note that this is the unstable version, built on and running on etch...)
svn-load does a
if not svn_path_exists(url, ''):
sys.stderr.write(Error connecting or no such repository: %s\n % url)
sys.exit(1)
svn_path_exists supposedly returns an entry object. However for my
svn+ssh repository, client.info2 returns [] for the top level. It
does however return content for trunk and other components...
I'd suggest replacing the '' with dirs[0] or maybe tagdir (or even
tagdir.split(os.path.sep)[0] ?) to actually probe *some* directory... or
stick with convention and use 'trunk' (which in my case returns:
[('trunk', PysvnInfo )]
which should be acceptable...) Changing it to use trunk causes the
tool to work for me, in any case.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages svn-load depends on:
ii python 2.4.4-2 An interactive high-level object-o
ii python-svn 1.5.0dfsg-1 A(nother) Python interface to Subv
svn-load recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419387: suggest not...
perhaps svn-load should be merged with vcs-load-dirs which has the same functionality, only targeted at different VCSes. The common infrastructure could probably be reused for subversion, too. I'd prefer (as a user) to have svn-load, because it supports a specific usage that none of the vcs-load-dirs programs seem to attempt to (namely, CVS-style vendor-branch-and-tag imports.) At least from a look at svk-load-dirs in particular, it doesn't really seem to be trying to do the same thing, though it's possible that documentation explaining how to do the same task would change my mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440357: jam: jam loses dependencies that are more than 2G
Package: jam Version: 2.5rel-1 Severity: normal Because jam is not compiled with -D_FILE_OFFSET_BITS=64 it treats any file over 2G as missing; this is particularly inconvenient when using jam to build iso images of large software releases. Since jam doesn't deliver any libraries, this seems like a reasonable change to make unilaterally, as nothing else cares what ABI it's using. (Be sure to build the final jam, not just jam0, with that option, I made that mistake the first time through :-) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages jam depends on: ii libc6 2.3.6.ds1-13etch2 GNU C Library: Shared libraries jam recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440357: jam: jam loses dependencies that are more than 2G (patch)
Note that this also points out a failure to meet policy manual 10.1,
Binaries:
By default, when a package is being built, any binaries created
should include debugging information, as well as being compiled with
optimization.
What's going wrong is that the build rule only passes CFLAGS in to the
jam0 bootstrap build; the Makefile then runs jam0 ($EXEFILE) with no
arguments to build the real jam. The use of -sCCFLAGS=-g in the
install rule is entirely pointless, jam has already been built at that
point (I suggest actually deleting that from the install rule instead
of leaving my comment :-)
The relatively clean way seemed to be to add a JAMFLAGS option to let
us pass in the -sCCFLAGS. You should probably add a -sDEBUG=1
-sOPTIM=-O2 as well, but since this bug isn't about that I didn't want
to add the clutter.
Index: debian/rules
===
--- debian/rules(revision 63959)
+++ debian/rules(working copy)
@@ -23,10 +23,10 @@
dh_testdir
# bootstrap
- ${MAKE}
+ ${MAKE} CFLAGS='-g -D_FILE_OFFSET_BITS=64'
JAMFLAGS='-sCCFLAGS=-D_FILE_OFFSET_BITS=64'
# update generated files
rm jamgram.c jamgram.h
- ${MAKE}
+ ${MAKE} CFLAGS='-g -D_FILE_OFFSET_BITS=64'
JAMFLAGS='-sCCFLAGS=-D_FILE_OFFSET_BITS=64'
touch build-stamp
@@ -47,6 +47,7 @@
dh_clean -k
dh_installdirs
+# note that CCFLAGS and OPTIM are pointless here, the build already happened
above
./jam0 -sBINDIR=${topdir}/debian/${jam}/usr/bin \
-sCCFLAGS=-g -sOPTIM=-O2 \
install
Index: Makefile
===
--- Makefile(revision 63959)
+++ Makefile(working copy)
@@ -2,6 +2,7 @@
CC = cc
CFLAGS =
+JAMFLAGS =
EXENAME = ./jam0
TARGET = -o $(EXENAME)
@@ -59,7 +60,7 @@
rules.c scan.c search.c timestamp.c variable.c
all: $(EXENAME)
- $(EXENAME)
+ $(EXENAME) $(JAMFLAGS)
$(EXENAME):
$(CC) $(TARGET) $(CFLAGS) $(SOURCES) $(LINKLIBS)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436983: python-django: pydoc django.db blows up
On closer inspection - django.db only *has* two functions and they don't have any docstrings :-) though presumably the __import__ changes that by pulling them in from django.db.backends.*.base. It could be argued, then, that a sufficient fix to the original problem would be to include a pointer to real documentation... *preferably* another pydoc option, but really it's enough to have something that lets me say ok, I've gotten far enough in the tutorial that I have a models.py that says from django.db import models What does that actually mean? What methods do I have? ie. something specific, not just go to django.org. Patching pydoc for a specific library isn't really a choice. Very messy and would end up with pydoc having far too many overrides. Oh, certainly - I meant having pydoc supply some hint (a global? a special entry in sys.modules?) that could be tested by special packages like this, assuming it doesn't already. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436983: python-django: pydoc django.db blows up
by django-admin. I'm sorry that this behaviour is unfriendly towards pydoc but I doubt there's any way to avoid this (without defining the variable DJANGO_SETTINGS_MODULE to point to a valid Django settings module). As long as it stays open as a bug, that's fine; I suspect there *is* a way to work around it on the django side (for example, can it tell that pydoc is importing it?) or else there needs to be a way to fix it from the pydoc side... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436983: python-django: pydoc django.db blows up
Package: python-django Version: 0.96-1 Severity: normal $ pydoc django.db problem in django.db - EnvironmentError: Environment variable DJANGO_SETTINGS_MODULE is undefined. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages python-django depends on: ii python2.4.4-6An interactive high-level object-o ii python-support0.6.4 automated rebuilding support for p Versions of packages python-django recommends: ii python-pysqlite2 2.3.5-1python interface to SQLite 3 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436790: dnsdoctor: -o text doesn't work
Package: dnsdoctor Version: 1.0.0-2 Severity: normal File: /usr/bin/dnsdoctor dnsdoctor --help says: -o, --outputOutput (see output) output: [byseverity|byhost] [text|html] byseverity*[bs] Output is sorted/merged by severity byhost [bh] Output is sorted/merged by host text *[t] Output plain text html [h] Output HTML dnsdoctor -o text $domain still produces TAG NAME=NS_NSNS/TAG and the like. (It also seems to emit ^[[K^[[?25h regardless of $TERM... but I can't tell if that's just part of still emitting text, or is a separate bug...) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.22-1-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages dnsdoctor depends on: ii iputils-ping 3:20070202-2Tools to test the reachability of ii libiconv-ruby1.8.2-1 A Wrapper class of iconv for the R ii librexml-ruby3.1.2.1+ruby1.8.2-1 pure Ruby non-validating XML parse ii libyaml-ruby 1.8.2-1 YAML for Ruby ii ruby 1.8.2-1 An interpreter of object-oriented Versions of packages dnsdoctor recommends: ii libxml-ruby1.80.3.8.4-3 Ruby interface to libxml -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426483: krb5-clients: krb5-send-pr missing
Package: krb5-clients Version: 1.4.4-7etch1 Severity: normal According to http://web.mit.edu/kerberos/mail-lists.html krb5 bugs should be submitted with krb5-send-pr. I suggest either actually including it in some package, *or* if you prefer for these bugs to go through debian, to have a krb5-send-pr installed that says that (or runs reportbug appropriately, or something.) (I'd kind of prefer the former, but that may not actually be right for the package...) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages krb5-clients depends on: ii krb5-con 1.16Configuration files for Kerberos V ii libc62.3.6.ds1-13GNU C Library: Shared libraries ii libcomer 1.39+1.40-WIP-2006.11.14+dfsg-2 common error description library ii libkrb53 1.4.4-7etch1MIT Kerberos runtime libraries ii libncurs 5.5-5 Shared libraries for terminal hand krb5-clients recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418602: Acknowledgement (alsa-source: alsa-source doesn't build (with module-assistant) on freshly-upgraded etch)
The proximate cause of that obscure error message appears to be that
/usr/src/modules/alsa-driver/usb/usx2y/usbusx2y.h
says
typedef struct {
snd_usb_audio_tchip;
...
but snd_usb_audio_t isn't defined anywhere.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418602: Acknowledgement (alsa-source: alsa-source doesn't build (with module-assistant) on freshly-upgraded etch)
and the proximate cause of *that* was that there was an older alsa-source unpacked previously in /usr/src/modules/alsa-driver; apparently modass silently failed to erase the previous version before unpacking the new one. So I'd suggest transferring this bug to module-assistant, or just closing it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#417870: fakechroot: libtool's use of rpath fails under fakechroot
Package: fakechroot Version: 2.5-1 Severity: normal A package using libtool to build shared libraries, and then run them in-tree, ends up having two executables and a helper script... one of the executables is .libs/lt-foo and it has a run-time-link-path encoded into it (objdump -p, look for RPATH under Dynamic Section:) that gives an absolute path to the the build tree, so it can find the just-built libraries (instead of looking for not-yet-installed ones.) That works fine normally... but under fakechroot * the path is an internal path, ie. relative to $FAKECHROOT_BASE * /lib/ld-linux.so is not fakeroot-aware * /lib/ld-linux.so is loaded first (it *is* the dynamic linker, after all), so inherently can't have symbols overridden via LD_PRELOAD. The *big* problem here is that if you have an older version of the package installed on the outside system, * the libraries aren't found in the RPATH location, because it doesn't exist * the libraries are then found in the *outside* /usr/lib (In my case, I found it because on one system (with a mostly current outside version of the package), everything worked fine, and on another system (with a stale outside version) shared lib incompatiblities led to segfaults... which was actually *better* because it exposed the problem :-) A full solution could involve having the execve() wrapper notice that an object is ELF, then that its interpreter is /lib/ld-linux.so, and run an alternate fakechroot-aware version (giving a slightly different path for the invocation of some executables, I'm not sure of the subtleties here, but manual tests seem to work.) A decent shortcut (which I'm using myself) is to have the execve() wrapper check as above, but then also check for RPATH, and if one is found, unfake it and stuff it into the start of LD_LIBRARY_PATH. This has a bug -- if the raw RPATH value actually corresponds to an existing outside directory, the libs will be taken from that outside directory. In practice, using this under pbuilder gets somewhat unique directories, which is sufficient for some uses. (Note that this exposes a secondary bug - all dynamic executables [which in practice is everything] inside the fake chroot end up running the *outside* /lib/ld-linux.so... which could matter if you had a significantly different inside vs. outside linux.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc6 2.3.2.ds1-22sarge5 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413918: fakechroot: fakechroot doesn't fake unix domain sockets
Package: fakechroot Version: 2.5-1.1 Severity: wishlist I particularly care because I am using pbuilder with fakechroot on a machine that uses nscd; pbuilder stuffs an entry into the chroot'ed /etc/passwd, /etc/shadow, and /etc/group, but then can't reference it. (There's no exposed mechanism to actually tell a process to not use nscd even if present, which could have been a workaround.) Thus it seems that fakechroot should also fake connect bind getpeername getsockname so that unix domain sockets can be properly mapped to fakespace; in this particular case, it would mean conveniently not seeing the system's nscd, but would also mean that one could run an nscd (or other service like Xnest) inside fakechroot. (I don't have patches for this yet.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc6 2.3.2.ds1-22sarge5 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412918: fakechroot: mktemp misimplemented (leaks unfake paths)
Package: fakechroot Version: 2.5-1.1.20070227-1 Severity: normal mktemp() just expands the template and passes it on to the real mktemp. If the template is an absolute path, that causes us to return an unfake path. Instead, it needs to * narrow the result * copy (memmove) it back into the original template (Oddly, mkstemp64 is already implemented correctly. In a Debian package build context, this particular matters because patch 2.5.9 uses mktemp() and not mkstemp; looks like ranlib [binutils 2.15-6] does too.) -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412774: fakechroot: execve handles #! incorrectly
Package: fakechroot Version: 2.5-1.1.20070227-1 Severity: normal (again, that's a local build version, but it is based on 2.5-1.1 with patches from other current bugs.) The execve wrapper, correctly, expands the actual-filename argument because the kernel needs an unfake name. It then looks for a #! line, and if it finds one, expands the interpreter name. However, it then re-expands actual-filename when it adds it to the constructed command line... which is wrong on two counts: 1. It's already been expanded once already by that point 2. It shouldn't *get* expanded, since the interpreter will be calling wrapped-open on it anyway... Test case: $ fakeroot fakechroot debootstrap --variant=fakechroot sarge /tmp/testroot $ fakeroot fakechroot chroot /tmp/testroot # cat /tmp/foo.sh #!/bin/sh echo $0 dirname $0 dir=`dirname $0` echo `cd $dir; pwd` # chmod +x /tmp/foo.sh # /tmp/foo.sh /tmp/testroot/tmp/foo.sh /tmp/testroot/tmp /tmp/testroot/tmp # exit (It's only the echo $0 that matters, the test is just cooked down from what tomcat's jasper.sh actually does.) The fixed version, which is basically +const char *fake_filename = filename; -expand_chroot_path(filename, fakechroot_path, fakechroot_ptr, fakechroot_buf); -newargv[n++] = filename; +newargv[n++] = fake_filename; Causes the output to be /tmp/foo.sh /tmp /tmp which is (by inspection) correct. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412603: fakechroot: fakechroot doesn't allow nested chroots... but it should
Package: fakechroot
Version: 2.5-1.1.20070223-2
Severity: normal
(again, ignore the version as it's a local build with a bunch of
previously submitted changes applied)
I don't see a reason not to let subsequent chroot() calls within an
already running fakechroot succeed - it's not like the fakeroot case
where there's a process to communicate, the entirety of the state is
in $FAKECHROOT_BASE, and that *already* has the right nesting
semantics.
This patch works for my own case (an obscure use of pbuilder inside of
pbuilder); basically, it drops the EFAULT test, adds comments as to
why other parts work, and uses next_getcwd (since $FAKECHROOT_BASE
is strictly unfake, so it shouldn't have narrow_chroot_path applied to
it.
Index: libfakechroot.c
===
--- libfakechroot.c (revision 55507)
+++ libfakechroot.c (working copy)
@@ -870,16 +875,15 @@
char *envbuf;
#endif
+/* no reason to prevent further fakechroots... we just have to concatenate
bases */
fakechroot_path = getenv(FAKECHROOT_BASE);
-if (fakechroot_path != NULL) {
-return EFAULT;
-}
+/* this does the expanded chdir */
if ((status = chdir(path)) != 0) {
return status;
}
-if (getcwd(dir, FAKECHROOT_MAXPATH) == NULL) {
+if (next_getcwd(dir, FAKECHROOT_MAXPATH) == NULL) {
return EFAULT;
}
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.15-mc2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages fakechroot depends on:
ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an
-- debconf-show failed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412141: fakechroot: readlink misimplemented
Package: fakechroot Version: 2.5-1.1.20070212-6 Severity: important (Ignore the version, it's my local build with other fixes, the bug is clear from reading the source...) libfakechroot.c, readlink() implementation, in particular the end-of-buffer handling, can truncate links; coreutils readlink exposes this because it starts out passing in a bufsiz of 128, and it's easy to have a FAKECHROOT_BASE nearly that deep... The fix I propose is to 1. call next_readlink with FAKECHROOT_MAXPATH-1, not bufsiz 2. check strlen(tmpptr) against bufsiz and return -1 if it won't fit 3. use strncpy so as not to overrun the input buffer 3a. return the length of the input, since the output copy might not have a null at the end. Following is a rough trace of demonstrating the truncation, using readlink from coreutils 5.2.1-2, and note that readlink x130 gives only 27 characters of the link, instead of 30. wildcat$ fakeroot fakechroot wildcat# env | grep FAKE FAKECHROOT=true FAKEROOTKEY=1024906132 FAKECHROOT_VERSION=2.5 FAKED_MODE=unknown-is-root wildcat# mkdir /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 wildcat# echo -n /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 | wc -c 100 wildcat# export FAKECHROOT_BASE=/tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 wildcat# cd /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 wildcat# unset FAKECHROOT_BASE wildcat# pwd / wildcat# cd / wildcat# ls afs/ boot/ dev/ home/lib/ media/ opt/ root/ srv/ tmp/ var/ bin/ cdrom/ etc/ initrd/ lost+found/ mnt/proc/ sbin/ sys/ usr/ vmlinuz@ wildcat# pwd / wildcat# ln -s /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/123456789 /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/x110 wildcat# ln -s /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/1234567890123456789 /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/x120 wildcat# ln -s /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/12345678901234567890123456789 /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/x130 wildcat# readlink /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/x130 /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/12345678901234567890123456789 wildcat# readlink /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789/x130 | wc -c 131 wildcat# cd /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 wildcat# export FAKECHROOT_BASE=/tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 wildcat# pwd /tmp/56789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 wildcat# echo * bin x110 x120 x130 wildcat# readlink x130 /123456789012345678901234567 wildcat# readlink x120 /1234567890123456789 wildcat# readlink x110 /123456789 -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410739: fakechroot: canonicalize_file_name doesn't work either
Package: fakechroot Version: 2.5-1.1.20070207-1 Severity: normal readlink -f . inside fakechroot displays the external path, instead of the local one. Looking at coreutils, readlink -f calls canonicalize_file_name, which is supported, but it only calls it on the input side... it looks like it also needs to call narrow_chroot_path on the return value... Experimentally, calling narrow_chroot_path on the return from next_canonicalize_file_name(name) does work. (You probably want the modified narrow_chroot_path from debian bug #410145, though...) Test case should be simple enough: * build a chroot (debootstrap or whatever) * fakeroot fakechroot chroot $(CHROOT_DIR) realpath -f . if it prints $(CHROOT_DIR), you're seeing the bug; if it prints / you're seeing the fix... -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#187513: mailsync not working from cron - workaround and suggested fix
I saw that mailsync doesn't work from cron problem under Ubuntu
6.06, using mailsync 5.2.1-2build1; given that unstable has 5.2.2 and
it (and libc-client) has the exact same lines of code, the analysis
below applies there too...
Given a .mailsyncrc including
channel slurp imapmail localfile {
msinfo mailsync-mail.msinfo
}
(imapmail and localfile left out as irrelevant)
I put strace mailsync -n slurp in cron, and saw this:
21438 open(/var/mail/anonymous/mailsync-mail/,
O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = -1 ENOENT (No such file or
directory)
21438 open(/var/mail/anonymous, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY)
= -1 ENOENT (No such file or directory)
That's not right :-) Turns out that the execve line shows that cron
has a very limited environment - the only settings are
SHELL, PATH, PWD, LANG, SHLVL, HOME, LANGUAGE, LOGNAME, and _
Note that this *doesn't* include USER; I can trigger the problem
directly by doing
(unset USER; mailsync -n slurp)
Synchronizing stores imapmail - localfile...
Authorizing against {/imap}
Error: Can't open mailbox mailsync-mail.msinfo: no such mailbox
Error: Couldn't open msinfo box mailsync-mail.msinfo.
Aborting!
Adding an explicit USER=eichin to the crontab *worked*, so is a
plausible workaround.
Looking at the code...
mailsync-5.2.1/src/mailsync_main.cc line 93 (in main):
// initialize c-client environment (~/.imparc etc.)
env_init( getenv(USER), getenv(HOME));
uw-imap-2002edebian1/src/osdep/unix/env_unix.c line 656 (in env_init):
/* myUserName must be set before dorc() call */
myUserName = cpystr (user ? user : ANONYMOUSUSER);
Also, the comment describing env_init says:
* Accepts: user name (NIL for anonymous)
I'd suggest that perhaps instead of getenv(USER) perhaps
getpwuid(geteuid()) is appropriate... or even something like
getenv(USER) || getpwuid(geteuid())-pw_name
to allow the user to set $USER and fall back to getpwuid, rather than
doing the unintentional anonymous path. The UW docs do talk about
customizing env_init, as an alternative:
http://www.washington.edu/imap/documentation/CONFIG.html
but it looks like that should be site-specific, not application
specific, and just passing something different to env_init is a better
fix.
_Mark_ [EMAIL PROTECTED]
The Herd Of Kittens
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410145: fakechroot: narrow_chroot_path misimplements getcwd, and breaks make
(I went digging for this in search of an explanation for a /bin/sh: line 1: cd: .: No such file or directory message from deep in a fakeroot/fakechroot/pdebuild/pbuilder/dpkg-buildpackage stack, and will see if this helps shortly... but since it's clearly wrong even if it doesn't, I figured I'd get the bug report out the door promptly.) FTR the obvious fix *does* fix the cd problem, not just the entering directory problem, and my somewhat-hacked pbuilder has successfully built samba and apache (among other things) using this fakechroot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410145: fakechroot: narrow_chroot_path misimplements getcwd, and breaks make
Package: fakechroot Version: 2.5-1.1 Severity: important Inside fakechroot, make displays make[1]: Entering directory `/home/eichin/' ie. it display the *outside* path. Yet a Makefile target running pwd gives the correct value. (I was hunting this down in search of another problem...) Turns out that this is a fakeroot bug. getcwd is documented in getcwd(3) as: The getcwd() function copies an absolute pathname of the current work- ing directory to the array pointed to by buf, which is of length size. Note that further on, the man page only suggests the return value as having meaning in two cases: it's NULL if the call can't fit the path in the buffer, and a linux-specific hack of having getcwd malloc() the value if buf is NULL. gnu make, being quite portable code, simply calls: if (getcwd (current_directory, GET_PATH_MAX) == 0) and expects current_directory to have the desired value. fakechroot-2.5/src/libfakechroot.c #define narrow_chroot_path, in the typical (not in /) case, does this: (path) = ((path) + strlen(fakechroot_path)); \ ie. returns a pointer that skips over the prefix. That's Not Right :-) The obvious fix is to do something like memmove(path, path+strlen(fakechroot_path), 1+strlen(path)-strlen(fakechroot_path)) instead, though I have not tested this. I've also noted that bash uses the return value ignored form in the only two places it actually calls the function, so builtins probably have buggy behaviour here too: ./parse.y:4146: if (getcwd (t_string, sizeof(t_string)) == 0) ./jobs.c:355: dir = getcwd (d, sizeof(d)); if (dir) dir = d; (I went digging for this in search of an explanation for a /bin/sh: line 1: cd: .: No such file or directory message from deep in a fakeroot/fakechroot/pdebuild/pbuilder/dpkg-buildpackage stack, and will see if this helps shortly... but since it's clearly wrong even if it doesn't, I figured I'd get the bug report out the door promptly.) -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.1manekineko Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakechroot depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries fakechroot recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409856: fakeroot: nested fakeroot calls don't re-raise
Package: fakeroot Version: 1.2.10 Severity: normal I'm not sure that subject is clear, but the demonstration that follows should be: wildcat$ fakeroot wildcat# id -u 0 wildcat# id -g 0 wildcat# python Python 2.4.1 (#2, Oct 18 2006, 20:58:01) [GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2 Type help, copyright, credits or license for more information. import os os.setuid(900) os.system(sh) sh-2.05b$ id -u 900 sh-2.05b$ id -g 0 sh-2.05b$ fakeroot wildcat$ id -u 900 wildcat$ id -g 0 pbuilder (in particular, /usr/lib/pbuilder/pbuilder-buildpackage) uses BUILDUSERID, and if you're using pbuilder with an external ccache this is kind of useful... but it means that you can be in a fakeroot, fake-change to uid $BUILDUSERID (900 as above), then when dpkg-buildpackage -rfakeroot does a fakeroot debian/rules clean, the ensuing dh_testroot fails: dh_testroot dh_testroot: You must run this as root (or use fakeroot). make: *** [clean] Error 1 pbuilder: Failed autobuilding of package because just calling fakeroot doesn't fake-change back up to 0. fakeroot-tcp behaves no differently than the default fakeroot-sysv (not that I expected it to.) It looks like 1.5.10 (from roughly current debian/testing) behaves exactly the same way. A quick look at fakeroot-1.2.10/scripts/fakeroot.in doesn't show an obvious way to fix this, without shipping a (obviously not-setuid) helper that does the above setuid call and exec; bash doesn't appear to have a syscall builtin :-) (Another possibility is rewriting fakeroot.in in just about any other language; python or perl would do fine.) Another, somewhat twisted, possibility is for libfakeroot to check an environment variable, that fakeroot.in could set, to execute that setuid, but there may be reasons that doesn't work out. Just another path if delivering a helper doesn't work out for some reason... -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.15-mc2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages fakeroot depends on: ii libc6 2.3.2.ds1-22sarge4 GNU C Library: Shared libraries an -- debconf-show failed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409856: fakeroot: nested fakeroot calls don't re-raise
Clint Adams [EMAIL PROTECTED] writes:
I'm not sure that subject is clear, but the demonstration that follows
should be:
Currently fakeroot doesn't support nested operation. There is this
little block in faked.c:
if(getenv(FAKEROOTKEY_ENV)) {
/* I'm not sure -- maybe this can work?) */
fprintf(stderr,Please, don't run fakeroot from within fakeroot!\n);
exit(1);
}
Obviously this isn't working. I can have the fakeroot script choke
if the environment variable is set as a short-term fix.
I'd noticed that code, and that it wasn't having any impact, but I
assumed it was just old and that the fakeroot wrapper was already
taking care of it.
In the long term, some kind of mechanism for the additional faked
processes to talk to the parent might be possible. A single faked
process for all children might be possible as well, if it can track
multiple threads.
I'll certainly recommend it as a useful feature - we're working
towards running pbuilder itself without privileges, and it uses
fakeroot and fakechroot deeper inside. In that sense, we're filling
in fakeroot where other users would fill in sudo, so the desired
behavior really is run this command as [apparent] root.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385263: kpilot: kpilot doesn't handle [ in pdb-doc names
Package: kpilot Version: 4:3.5.2-0ubuntu6 Severity: normal (apologies if this should go somewhere ubuntu-specific, but m-x debian-bug sends it here... the version in unstable is only a little bit ahead of this one, though, but I haven't tested for the bug there.) Invalid entry (missing ']') at /home/eichin/.kde/share/config/kpilot_docconduitrc:14 Invalid entry (missing ']') at /home/eichin/.kde/share/config/kpilot_docconduitrc:15 those lines are: /home/eichin/Edge/docs/Swords Against Death [Book 2 of.txt=25fa6427e2feac62956ae9c0c3eeb80c /home/eichin/Edge/docs/Swords and Deviltry [Book 1 of .txt=4f872c06a3ab766656b04586c105c96c The bug seems to be that kpilot_docconduitrc is a .ini-style file, with everything in a [General] stanza -- and a parser that doesn't use enough context to tell the difference; a workaround would be to somehow quote (maybe urlencode?) the pathnames to the left of the = above. (The docfiles are conventional downloads from fictionwise.com, from at least 5 years back - and raw pilot-xfer doesn't have any trouble with them, of course.) (Aside from the warning, I think this is interfering with syncing, I always get the dialog about duplicate files now...) -- System Information: Debian Release: testing/unstable APT prefers dapper-updates APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500, 'dapper') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-26-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kpilot depends on: ii debconf [debconf-2.0 1.4.72ubuntu9 Debian configuration management sy ii kdelibs4c2a 4:3.5.2-0ubuntu18.1 core libraries for all KDE applica ii libc62.3.6-0ubuntu20 GNU C Library: Shared libraries an ii libgcc1 1:4.0.3-1ubuntu5GCC support library ii libkcal2b4:3.5.2-0ubuntu6KDE calendaring library ii libmal1 0.40-3 A library of the functions in mals ii libpisock8 0.11.8-17 Library for communicating with a P ii libqt3-mt3:3.3.6-1ubuntu6Qt GUI Library (Threaded runtime v ii libstdc++6 4.0.3-1ubuntu5 The GNU Standard C++ Library v3 kpilot recommends no packages. -- debconf information: shared/pilot/port: None -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#181037: Can you confirm that this bug is fixed?
If the lyx in stable actually works with examples/docbook_article.lyx now (the original bug report was pre-sarge), go ahead and close it - I don't have any other examples (we switched from lyx back to straight latex back in 2004 or so.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#159497: #159497 mondo: should use modprobe, not insmod
Was this in mondo-archive.log? Yes -- surprisingly, I even still have that /var/log/mondo-archive.log around :-) When you run the latest version of mondo, do you still get this? For unrelated reasons, I haven't run it since then, and so I don't really have any idea where to start... however, given what the problem was, if you've ... just done a test run with a vfat filesystem and couldn't find anything like the message you were seeing in neither mindi.log nor ... then I'm happy if you close the bug, all it took to duplicate it at the time was to have a vfat filesystem mounted, run ... whatever it is you run that writes to mondo-archive.log, and look for the quoted error output. If that's gone, great, the bug is gone. _Mark_ [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367436: nbd-client: needs better input handling in config script
Package: nbd-client Version: 1:2.8.4-1 Severity: normal Fetched 64.1kB in 0s (79.2kB/s) Preconfiguring packages ... Configuring nbd-client -- nbd-client can handle multiple concurrent connections. Please state the number of connections you'd like this configuration script to set up. Note that if something has already been specified in /etc/nbd-client, the current configuration will be used as defaults in these dialogs. How many nbd-client connections do you want to use? /tmp/nbd-client.config.199501: line 32: [: -gt: unary operator expected I should have gotten a retry, a default, a complaint - not a raw shell error :-) -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages nbd-client depends on: ii debconf [debconf-2.0] 1.5.0 Debian configuration management sy ii libc6 2.3.6-7GNU C Library: Shared libraries nbd-client recommends no packages. -- debconf information: nbd-client/device: nbd-client/host: nbd-client/no-auto-config: nbd-client/port: nbd-client/type: raw * nbd-client/number: 0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357682: bzip2: bunzip2 --force fails on pipes, *unlike* gunzip
Package: bzip2 Version: 1.0.2-8 Severity: normal File: /usr/bin/bunzip2 $ tail -2 /etc/motd | zcat --force Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. $ tail -2 /etc/motd | bunzip2 --force $ There are two reasons this bothers me: 1. --force is documented in reference to gzip, so it should act like it 2. This makes it impossible to implement a generic decompress pipeline, namely, | zcat --force | bunzip2 --force (etc.) ltrace confirms that it's doing a naive rewind; a third point would be that it's a bug that it doesn't give an error in this case, but silently outputs nothing, potentially very bad in a pipeline. But I don't care about that, I want the zcat-style behaviour :-) BZ2_bzReadOpen(0xbab8, 0xb7fbe820, 0, 0, 0xbfffd33c) = 0x8050048 BZ2_bzRead(0xbab8, 0x8050048, 0xbfffe6c4, 5000, 0xbfffd33c) = 0 rewind(0xb7fbe820, 0x8050048, 0xbfffe6c4, 5000, 0xbfffd33c) = -1 fgetc(0xb7fbe820) = 'EOF' ferror(0xb7fbe820) = 0 fclose(0xb7fbe820) = 0 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14.1manekineko Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bzip2 depends on: ii libbz2-1.01.0.2-8high-quality block-sorting file co ii libc6 2.3.5-3GNU C Library: Shared libraries an bzip2 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306459: pymacs: examples from the documentation don't work
Package: pymacs
Version: 0.22-3
Severity: normal
Under @subsection Python handles:
(setq matcher (pymacs-eval re.compile('pattern').match))
Debugger entered--Lisp error: (error Python: Traceback (most recent call last):
File \/usr/lib/python2.3/site-packages/Pymacs/pymacs.py\, line 95, in loop
argument = eval(text)
File \string\, line 0, in ?
File \string\, line 0, in ?
NameError: name 're' is not defined
)
signal(error (Python: Traceback (most recent call last):\n File
\/usr/lib/python2.3/site-packages/Pymacs/pymacs.py\, line 95, in loop\n
argument = eval(text)\n File \string\, line 0, in ?\n File \string\,
line 0, in ?\nNameError: name 're' is not defined\n))
error(Python: %s Traceback (most recent call last):\n File
\/usr/lib/python2.3/site-packages/Pymacs/pymacs.py\, line 95, in loop\n
argument = eval(text)\n File \string\, line 0, in ?\n File \string\,
line 0, in ?\nNameError: name 're' is not defined\n)
pymacs-serve-until-reply((pymacs-print-for-apply (quote eval) (quote
(re.compile('pattern').match
pymacs-call(eval re.compile('pattern').match)
pymacs-eval(re.compile('pattern').match)
(setq matcher (pymacs-eval re.compile('pattern').match))
eval((setq matcher (pymacs-eval re.compile('pattern').match)))
eval-last-sexp-1(nil)
eval-last-sexp(nil)
call-interactively(eval-last-sexp)
Performing a m-x pymacs-load RET re RET RET first doesn't help.
Oddly, having done the pymacs-load, m-x pymacs-eval RET
sys.modules.keys() RET *does* include re (or if you want a more
obvious example, try it with urllib.)
Suggestions? I'm at least partly curious if this works for anyone else :-)
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages pymacs depends on:
ii python2.3.5-1An interactive high-level object-o
ii python2.3-pymacs 0.22-3 interface between Emacs Lisp and P
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#304526: subversion: FTBFS: cdbs has no patchsys-quilt.mk
Package: subversion Version: 1.1.3-1 Severity: serious subversion's debian/rules line 13: include /usr/share/cdbs/1/rules/patchsys-quilt.mk subversion's debian/control build-depends: cdbs (=0.4.26) cdbs 0.4.27-3 changelog.Debian, ChangeLog, and changelog make no mention of quilt. There is a /usr/share/cdbs/1/rules/simple-patchsys.mk but I have no idea if that's a valid substitute... -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages subversion depends on: ii db4.2-util 4.2.52-18 Berkeley v4.2 Database Utilities ii libapr0 2.0.53-4the Apache Portable Runtime ii libc62.3.2.ds1-20GNU C Library: Shared libraries an ii libdb4.2 4.2.52-18 Berkeley v4.2 Database Libraries [ ii libexpat11.95.8-1XML parsing C library - runtime li ii libldap2 2.1.30-3OpenLDAP libraries ii libneon240.24.7.dfsg-0.2 An HTTP and WebDAV client library ii libssl0.9.7 0.9.7e-3SSL shared libraries ii libsvn0 1.1.3-1 shared libraries used by Subversio ii libxml2 2.6.16-2GNOME XML library ii patch2.5.9-2 Apply a diff file to an original ii zlib1g 1:1.2.2-4 compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
