Bug#943582: python-twisted: twist/twistd fails, missing dependency on PyHamcrest
Package: python-twisted Version: 18.9.0-4 Severity: important Howdy.. I recently updated 'python-twisted', and at the next reboot, some servers using 'twistd' failed to start. I reproduced the problem with a simple invocation of the /usr/bin/twist command: $ twist Traceback (most recent call last): File "/usr/bin/twist", line 6, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3250, in @_call_aside File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3234, in _call_aside f(*args, **kwargs) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 3263, in _initialize_master_working_set working_set = WorkingSet._build_master() File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 583, in _build_master ws.require(__requires__) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 900, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 786, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'PyHamcrest>=1.9.0' distribution was not found and is required by Twisted I know the PyHamcrest dependency was adjusted in the recent release, perhaps something got broken as a side-effect? A different sid box with python-twisted-18.9.0-3 (and also no python-hamcrest) still works. thanks, -Brian -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-twisted depends on: ii python-twisted-core 18.9.0-4 ii python2 2.7.17-1 python-twisted recommends no packages. python-twisted suggests no packages. -- no debconf information
Bug#877206: new release is available, should fix this
I just released foolscap-0.13.0, which ought to fix this.. let me know if you see any problems, or if I can help with getting it into debian/ubuntu before the package gets removed. Thanks!
Bug#877206: working on a fix
(upstream author here) Sorry folks, I didn't realize this problem was so bad. I haven't seen a bug filed about this on https://foolscap.lothar.com/trac/ or https://github.com/warner/foolscap/issues , but I just saw email from the Ubuntu bugtracker because I'm subscribed to Tahoe-LAFS changes, and the FTBFS bug is threatening to remove Tahoe too (because of the dependency). When I checked my nightly buildbot job, it looks like the problem has been happening since exactly the Twisted-17.9.0 release, but I hadn't noticed (I don't have any sorts of notifications on that buildbot). It hasn't been affecting our Tahoe unit tests. Let me see if I can find a fix this weekend, and make a new release. It looks like Failures are no longer pickleable, which we do in a logging routine that's exercised by those tests. I've been meaning to replace that logging with a JSON-based serialization scheme.. I guess it's time to accelerate that project. cheers, -Brian
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
On 5/17/17 12:24 AM, Andreas Henriksson wrote: > Thus z_ret = 4294967293 = -1 = Z_ERRNO > > Snippet from zlib.h: > >If an error occurred in the file system and not in the compression >library, errnum is set to Z_ERRNO and the application may consult >errno to get the exact error code. > > This means it's very likely a problem with your (non-Debian) operating > system setup. Please do not report issues to Debian when you're not > using a Debian installation (e.g. non-Debian kernel) without first > making sure it's actually reproducile on a Debian installation (or > atleast certainly not with severity grave!). Wasting our limited time > chasing non-Debian issues isn't very nice. I'm sorry about that.. I did not consider that it could be related to the kernel. I'll investigate further and if I find any issues that are relevant to debian, I'll add more information to this ticket. thanks, -Brian
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
Upstream bug filed in: https://bugzilla.gnome.org/show_bug.cgi?id=782715 cheers, -Brian
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
On 5/15/17 7:33 AM, Andreas Henriksson wrote: > fwiw, I'm not able to reprocude this on amd64 with gnome-terminal. I wonder if it's somehow specific to this chromebook. I'm running a thing called "crouton", which gives you a chroot (of sid, in this case, but you can get various other debian/ubuntu releases too). The X server that the terminal program is using will send all its pixels to a Chrome extension that draws them into a web frame. I don't *think* any of that should be visible to the application, but maybe drawing pixels doesn't happen as fast as it would on a normal computer? > In other words, this assertion fails: > http://sources.debian.net/src/vte2.91/0.46.1-1/src/vtestream-file.h/#L790 > > z_ret = uncompress ((Bytef *) dst, _ulongf, (const Bytef *) > src, srclen); > g_assert_cmpuint (z_ret, ==, Z_OK); > > Would be great if you could confirm by posting the asserting message > that the application outputs when crashing. I ran lilyterm from a non-crashing terminal (xterm) and had it dump a MB of "a"s, and got: Vte:ERROR:/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h:790:unsigned int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int): assertion failed (z_ret == Z_OK): (4294967293 == 0) and a coredump. So yes, I think that matches. (I'm using lilyterm because I wasn't able to get gnome-terminal to run from a regular shell.. I assume that it wants to be launched from some special GNOME mode where it gets a control socket or a D-Bus thing or something). > Seems to me like you need to seek the answer to why uncompress fails > in the zlib library (Possibly vte could handle the error more > gracefully but probably a good idea to find out why zlib uncompress > fails first.) Yup. What is it decompressing anyways? I don't know much about terminal programs, but from the other symbol names in that stack trace (VteTerminalPrivate::insert_rows, _vte_ring_insert), I wonder if this involves the scrollback history. Toggling lilyterm's "Scrollback lines" option didn't seem to help. I'll keep digging, and I'll file a bug on the gnome tracker. cheers, -Brian
Bug#862591: libvte-2.91-0: xfce4-terminal crashes when dumping a lot of text
Package: libvte-2.91-0 Version: 0.46.1-1 Severity: grave There seems to be a bug in sid's libvte, such that dumping a large amount of text to stdout in a short period of time causes the terminal program to crash. "cat" of a file with 1MB of the letter "a" is sufficient to reproduce it. I'm assigning this to libvte because I was able to crash xfce4-terminal, lilyterm, and termit this way, so it's clearly not specific to any one terminal program. I'm marking it "grave" because losing a terminal is pretty harsh.. any programs you've spawned from there (emacs, web browsers) abruptly exit too. I'm running this on an ARM64 chromebook (an Acer R13), which might be an unusual platform, just in case that makes a difference. I was able to get a stack trace by building vte2.91-0.46.1 and xfce4-terminal-0.8.4 locally with debug symbols turned on. It looks like this: Thread 1 "xfce4-terminal" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. #0 0x007cb52229fc in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x007cb5223df4 in __GI_abort () at abort.c:89 #2 0x007cb53dc59c in g_assertion_message (domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250 "/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h", line=line@entry=790, func=func@entry=0x7cb5fac098 <_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)", message=message@entry=0x5ccf97f720 "assertion failed (z_ret == Z_OK): (4294967293 == 0)") at ././glib/gtestutils.c:2432 #3 0x007cb53dc96c in g_assertion_message_cmpnum (domain=domain@entry=0x7cb5fa3bb8 "Vte", file=file@entry=0x7cb5fac250 "/home/warner/stuff/debian/vte2.91-0.46.1/./src/vtestream-file.h", line=line@entry=790, func=func@entry=0x7cb5fac098 <_vte_boa_uncompress::__PRETTY_FUNCTION__> "unsigned int _vte_boa_uncompress(char*, unsigned int, const char*, unsigned int)", expr=expr@entry=0x7cb5fac3f8 "z_ret == Z_OK", arg1=, cmp=cmp@entry=0x7cb5fa7420 "==", arg2=arg2@entry=0, numtype=numtype@entry=105 'i') at ././glib/gtestutils.c:2488 #4 0x007cb5fa0a94 in _vte_boa_uncompress (dstlen=65512, srclen=6140, src=0x7fc82a4618 "", dst=) at ././src/vtestream-file.h:790 #5 0x007cb5fa0a94 in _vte_boa_read_with_overwrite_counter(VteBoa*, gsize, char*, _vte_overwrite_counter_t*) (boa=0x5ccf75e420 [VteBoa], offset=offset@entry=0, data=, overwrite_counter=overwrite_counter@entry=0x7fc82b4714) at ././src/vtestream-file.h:911 #6 0x007cb5fa0e54 in _vte_boa_read (data=, offset=0, boa=) at ././src/vtestream-file.h:922 #7 0x007cb5fa0e54 in _vte_file_stream_read(VteStream*, gsize, char*, gsize) (astream=0x5ccf76dc50 [VteFileStream], offset=42288, data=0x7fc82b4750 "", len=24) at ././src/vtestream-file.h:1137 #8 0x007cb5f79dac in _vte_ring_read_row_record (ring=0x5ccf76e568, position=, record=0x7fc82b4770) at ././src/ring.cc:124 #9 0x007cb5f79dac in _vte_ring_discard_one_row (ring=0x5ccf76e568) at ././src/ring.cc:417 #10 0x007cb5f79dac in _vte_ring_maybe_discard_one_row (ring=0x5ccf76e568) at ././src/ring.cc:439 #11 0x007cb5f79dac in _vte_ring_insert(VteRing*, gulong) (ring=ring@entry=0x5ccf76e568, position=position@entry=2761) at ././src/ring.cc:551 #12 0x007cb5f7c604 in VteTerminalPrivate::ring_insert(long, bool) (this=this@entry=0x5ccf76e490, position=2761, fill=fill@entry=false) at ././src/vte.cc:247 #13 0x007cb5f7e694 in VteTerminalPrivate::ring_append(bool) (fill=false, this=0x5ccf76e490) at ././src/vte.cc:257 #14 0x007cb5f7e694 in VteTerminalPrivate::insert_rows(unsigned int) (cnt=1, this=) at ././src/vte.cc:2188 #15 0x007cb5f7e694 in VteTerminalPrivate::update_insert_delta() (this=0x5ccf76e490) at ././src/vte.cc:2234 #16 0x007cb5f7f9e0 in VteTerminalPrivate::insert_char(unsigned int, bool, bool) (this=this@entry=0x5ccf76e490, c=97, insert=insert@entry=false, invalidate_now=invalidate_now@entry=false) at ././src/vte.cc:2964 #17 0x007cb5f8b248 in VteTerminalPrivate::process_incoming() (this=this@entry=0x5ccf76e490) at ././src/vte.cc:3686 #18 0x007cb5f8bf08 in VteTerminalPrivate::time_process_incoming() (this=this@entry=0x5ccf76e490) at ././src/vte.cc:10428 #19 0x007cb5f8bfe8 in VteTerminalPrivate::process(bool) (this=this@entry=0x5ccf76e490, emit_adj_changed=emit_adj_changed@entry=true) at ././src/vte.cc:10452 #20 0x007cb5f8c244 in update_timeout(gpointer) (data=) at ././src/vte.cc:10679 #21 0x007cb53b5484 in g_timeout_dispatch (source=0x5ccf575f80, callback=, user_data=) at ././glib/gmain.c:4674 #22 0x007cb53b4898 in g_main_dispatch (context=0x5ccf446770) at ././glib/gmain.c:3203 #23 0x007cb53b4898 in g_main_context_dispatch (context=context@entry=0x5ccf446770) at ././glib/gmain.c:3856 #24 0x007cb53b4c40 in g_main_context_iterate (context=0x5ccf446770,
Bug#852380: still broken
FWIW, ekeyd is still giving me errors when I try to launch it on my sid box, updated today: $ dpkg -s lua-socket |grep Version: Version: 3.0~rc1+git+ac3201d-3 $ dpkg -s ekeyd |grep Version: Version: 1.1.5-6.1 $ sudo /usr/sbin/ekeyd Unable to run configuration file: control.lua:755: control.lua:526: attempt to index global 'socket' (a nil value) cheers, -Brian
Bug#835119: similar problem
I'm seeing a similar problem, except that the computer in question has been running continuously the whole time, and it's directly connected to the internet (so no firewalls or NAT-entries that might be timing out). This is with tor-0.2.8.8-1 (in sid). What I'm noticing is that if the Tor daemon has been running for a while, a basic connection via the SOCKS port never connects. If I bounce the daemon, then a connection works. The daemon is not generally doing anything else: it's pretty idle. I haven't yet characterized how long it must be idle before connections cease to work.. I'll try increasingly long intervals over the next week. The current datapoint is that an uptime of 9.5 days lead to a failure, but a connection that happens one minute after startup works. I *did* see that 'arm' reported 0 circuits open when it was not working, although just a few minutes before my (failed) test, /var/log/tor/log said "Tor has successfully opened a circuit. Looks like client functionality is working.", so it's not entirely idle (but also entirely not working). cheers, -Brian
Bug#830555: new Foolscap release available
I've just released foolscap-0.12.0 to PyPI, which should fix this. We've deprecated a function that talks to the root nameservers, and this release removes the test that used to exercise that function. I think that was the only place which should be doing off-box network access (there's plenty of localhost access, of course, this being a networking package). I hope that will resolve the issue. Please let me know if there's anything I can do to help get this packaged and (most importantly) the auto-removal of Foolscap and Tahoe-LAFS resolved. thanks! -Brian
Bug#830555: upstream ticket added
Ouch.. I didn't know it was doing this.. I'm guessing one of the tests is pinging the nameservers to exercise the "figure out my own IP address" function. I've filed a bug upstream to track down the offending test and change it: https://foolscap.lothar.com/trac/ticket/263 I'll try to address that soon. We have a new release in the works, should be done in a few weeks. I know that Tahoe-LAFS is marked for autoremoval from testing on Aug 22nd because of this, and I really don't want that to happen :-). cheers, -Brian
Bug#795848: problem is fixed in the current release
I only recently heard about this.. we fixed that problem in the (current) foolscap-0.9.1 release, made on 21-Sep-2015. Upgrading to 0.9.1 ought to resolve this FTBFS. (there is a new problem that involves a bad interaction between foolscap-0.9.1 and twisted >=15.3.0, but for teh most part it only affects Tahoe-LAFS. I'm working on a new foolscap release that will resolve it, but I don't think that's cause to hold up putting foolscap-0.9.1 into sid). cheers, -Brian
Bug#786440: python-pip: pip is out-of-date, 'pip list' fails sometimes
Package: python-pip Version: 1.5.6-5 Severity: important I noticed that 'pip list' on my sid system failed, with a rather obscure error: Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/pip/basecommand.py, line 122, in main status = self.run(options, args) File /usr/lib/python2.7/dist-packages/pip/commands/list.py, line 80, in run self.run_listing(options) File /usr/lib/python2.7/dist-packages/pip/commands/list.py, line 142, in run_listing self.output_package_listing(installed_packages) File /usr/lib/python2.7/dist-packages/pip/commands/list.py, line 151, in output_package_listing if dist_is_editable(dist): File /usr/lib/python2.7/dist-packages/pip/util.py, line 367, in dist_is_editable req = FrozenRequirement.from_dist(dist, []) File /usr/lib/python2.7/dist-packages/pip/__init__.py, line 299, in from_dist assert len(specs) == 1 and specs[0][0] == '==' AssertionError After some digging, it turned out that the problem was that I have the 'python-pyhsm' package installed, which has a version string of 1.0.4k, and the extra k causes pkg_resources to return a spec that looks like === 1.0.4k (with three equal signs, not two), triggering the assert. Most packages have a normalized version string, for which pkg_resources emits a spec like == 1.0.0, which doesn't cause pip to complain. This was fixed in pip-6.0, which tolerates both == and ===. Sid currently has a pkg_resources that can emit ===, but not a pip that can tolerate it. This only shows up if you happen to have at least one python package installed with a non-normalized version string. For me, I was able to make pip work again by uninstalling python-pyhsm. I'm sure you're aware that sid's pip-1.5.6 is pretty out-of-date, and that 6.1.1 is the current version (https://pip.pypa.io/en/stable/news.html). It's not a trivial upgrade, for sure, but consider this note as supporting evidence in the campaign to get pip updated :). cheers, -Brian Steps To Reproduce: apt-get install python-pip python-pyhsm pip list Expected: a list of packages Got Instead: part of the list, then an exception with an AssertionError cheers, -Brian -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') 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) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages python-pip depends on: ii ca-certificates 20141019 ii python2.7.9-1 ii python-colorama 0.3.3-1 ii python-distlib0.2.0-1 ii python-html5lib 0.999-3 ii python-pkg-resources 16.0-1 ii python-requests 2.4.3-6 ii python-setuptools 16.0-1 ii python-six1.9.0-3 pn python:anynone Versions of packages python-pip recommends: ii build-essential 11.7 pn python-dev-all none ii python-wheel 0.24.0-1 python-pip 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#786446: python-setuptools: syntax error in multiarch patch, causes failure with newer 'pip wheel'
Package: python-setuptools
Version: 16.0-1
Severity: normal
I know setuptools/pip/etc are in flux, so this may be premature.
To work around bugs in the (older) version of Pip that sid currently has
(#786440), I uninstalled python-pip and python-wheel, and installed the
current pip directly from source. Then I attempted to build a wheel
for one package ('pip wheel zope.interface'). I got an error from the
system-installed setuptools:
File /usr/lib/python2.7/dist-packages/setuptools/command/install_lib.py,
line 129, in pf
if new_suffix and self.multiarch and dst.endswith(ext_suffix) and not
dst.endswith(new_suffix):
NameError: free variable 'new_suffix' referenced before assignment in
enclosing scope
It appears that the debian-specific patching of install_lib.py (from
debian/patches/multiarch-extname.diff) has a bug:
@@ -97,12 +112,24 @@ class install_lib(orig.install_lib):
outfiles = []
+if self.multiarch:
+import sysconfig
+ext_suffix = sysconfig.get_config_var ('EXT_SUFFIX')
+if ext_suffix.endswith(_multiarch + ext_suffix[-3:]):
+new_suffix = None
+else:
+new_suffix = %s-%s%s % (ext_suffix[:-3], self.multiarch,
ext_suffix[-3:])
+
def pf(src, dst):
if dst in exclude:
log.warn(Skipping installation of %s (namespace package),
dst)
return False
+if new_suffix and self.multiarch and dst.endswith(ext_suffix) and
not dst.endswith(new_suffix):
+dst = dst.replace(ext_suffix, new_suffix)
+log.info(renaming extension to %s, os.path.basename(dst))
+
If self.multiarch is ever False, then the 'if new_suffix..' line inside
pf() will reference the non-existent 'new_suffix'.
I'd suggest swapping the conditions in that line:
if self.multiarch and new_suffix and ...
so that the test will be short-circuited in the non-multiarch case.
Patching it this way seems to allow me to build wheels again.
Steps To Reproduce:
dpkg --purge python-pip python-wheel
apt-get install python-setuptools
curl https://bootstrap.pypa.io/get-pip.py | sudo python
pip wheel zope.interface
Expected:
a zope.interface .whl file in the current directory
Got Instead:
the exception described above
cheers,
-Brian
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable')
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)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages python-setuptools depends on:
ii python-pkg-resources 16.0-1
pn python:anynone
python-setuptools recommends no packages.
python-setuptools 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#678231: sysv-rc: please log filename of obsolete init.d script
On 6/20/12 12:00 AM, Roger Leigh wrote:
That pinpointed the trouble to three files: bootlogd, stop-bootlogd,
and stop-bootlogd-single. I still don't understand what problem
they're causing, but I've got more information to go on now.
They probably lack an LSB header to specify their dependencies? It
would be good to know if they are truly problematic. If you still have
the files, if you could attach a copy here that would be great.
Sure (found a copy from a backup). They *do* have BEGIN INIT INFO
headers (I grepped for all files in /etc/init.d/ that lacked the
headers, while trying to track down the problem, and they did not appear
on that list). I also remember that the dpkg-query -W
-f='${Conffiles}\n' command (in sysv-rc.postinst) did report obsolete
for those three... I don't know what criteria that uses, though.
Here's the contents of bootlogd:
BEGIN /etc/init.d/bootlogd
#! /bin/sh
### BEGIN INIT INFO
# Provides: bootlogd
# Required-Start:mountdevsubfs
# X-Start-Before:hostname keymap keyboard-setup procps pcmcia
hwclock hwclockfirst hdparm hibernate-cleanup lvm2
# Required-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: Start or stop bootlogd.
# Description: Starts or stops the bootlogd log program
#which logs boot messages.
### END INIT INFO
PATH=/sbin:/bin # No remote fs at start
DAEMON=/sbin/bootlogd
[ -x $DAEMON ] || exit 0
NAME=bootlogd
DESC=boot logger
BOOTLOGD_OPTS=-r -c
[ -r /etc/default/bootlogd ] . /etc/default/bootlogd
. /lib/init/vars.sh
. /lib/lsb/init-functions
# Because bootlogd is broken on some systems, we take the special measure
# of requiring it to be enabled by setting an environment variable.
case $BOOTLOGD_ENABLE in
[Nn]*)
exit 0
;;
esac
# Previously this script was symlinked as stop-bootlogd which, when run
# with the start argument, should stop bootlogd. Now stop-bootlogd is
# a distinct script, but for backward compatibility this script continues
# to implement the old behavior.
SCRIPTNAME=${0##*/}
SCRIPTNAME=${SCRIPTNAME#[SK]??}
ACTION=$1
case $0 in
*stop-bootlog*)
[ $ACTION = start ] ACTION=stop
;;
esac
case $ACTION in
start)
# PATH is set above
[ $VERBOSE != no ] log_daemon_msg Starting $DESC $NAME
if [ -d /proc/1/. ]
then
umask 027
start-stop-daemon --start --quiet --exec $DAEMON -- \
$BOOTLOGD_OPTS
ES=$?
else
$DAEMON $BOOTLOGD_OPTS
ES=$?
fi
[ $VERBOSE != no ] log_end_msg $ES
;;
stop)
PATH=/bin:/sbin:/usr/bin:/usr/sbin
[ $VERBOSE != no ] log_daemon_msg Stopping $DESC $NAME
start-stop-daemon --oknodo --stop --quiet --exec $DAEMON
ES=$?
sleep 1
[ $VERBOSE != no ] log_end_msg $ES
if [ -f /var/log/boot ] [ -f /var/log/boot~ ]
then
[ $VERBOSE = no ] || log_action_begin_msg Moving boot log
file
# bootlogd writes to boot, making backup at boot~
cd /var/log {
chgrp adm boot || :
savelog -q -p -c 5 boot \
mv boot.0 boot \
mv boot~ boot.0
}
ES=$?
[ $VERBOSE = no ] || log_action_end_msg $ES
fi
;;
restart|force-reload)
/etc/init.d/bootlogd stop
/etc/init.d/bootlogd start
;;
status)
status_of_proc $DAEMON $NAME exit 0 || exit $?
;;
*)
echo Usage: $SCRIPTNAME {start|stop|restart|force-reload|status} 2
exit 3
;;
esac
:
END /etc/init.d/bootlogd
The other two files' headers are:
### BEGIN INIT INFO
# Provides: stop-bootlogd
# Required-Start:$local_fs $all
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Stop bootlogd
# Description: See the init.d/bootlogd script
### END INIT INFO
and
### BEGIN INIT INFO
# Provides: stop-bootlogd-single
# Required-Start:$local_fs $all
# Required-Stop:
# Default-Start: S
# Default-Stop:
# Short-Description: Stop bootlogd in single user mode
# Description: See the init.d/bootlogd script
### END INIT INFO
Deleting all three cleared up the problem.. my system is now running
with dependency-based boot.
cheers,
-Brian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510901: python-foolscap: should advertise [secure_connections] feature to setuptools
I have updated the package in Debian-SVN now. Could you please check (and confirm) that this fixes the problem for you. If it does please let me know so I can get the updated package uploaded. I think that looks good.. I built a package from the current SVN debian/* files on a system with setuptools installed, and the Tahoe build process seems to be happy with the resulting .deb package. I don't know if you build the .deb yourself, or if it gets built by some automated process (pbuilder or something), but I assume that the new Build-Depends: item will ensure that setuptools is present during the build, which ought to be enough to fix this problem. I'll double-check once the official package is in sid. thanks! -Brian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499699: update?
What's the status of this one? Stephan showed me some packaging work in the python-modules team's SVN repository[1] that looked great. It sounded like it was in the NEW queue at one point, but I don't see it there any longer. Did it get rejected? cheers, -Brian (upstream author of Foolscap) [1]: http://svn.debian.org/viewsvn/python-modules/packages/foolscap/trunk/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499699: setuptools issue
So, one issue I just noticed about the proposed packaging is that, because it uses python-support instead of pyshared, it tickles some bugs in setuptools that show up in our Tahoe project. It seems that setuptools is not as good at finding metadata in python-support -provided packages as in pyshared -provided ones. http://bugs.python.org/setuptools/issue17 has more information. We have a workaround for this (http://allmydata.org/trac/tahoe/ticket/229 has details), by adding --site-dirs /var/lib/python-support/python2.5 to the setup.py command line. However, trying to build Tahoe against the proposed python-support -based package fails in a new way, with an error like: pkg_resources.UnknownExtra: foolscap 0.3.2 has no such extra feature 'secure_connections' which suggests that our workaround is insufficient to get setuptools to see the extra feature metadata in /usr/share/python-support/python-foolscap/foolscap-0.3.2.egg-info/requires.txt . I believe this is a setuptools bug, and when we get some time we'll add it to setuptools-issue17 (or a new issue), but since our hackish workaround was good enough for a while, I wanted to ask: How hard would it be to use python-support instead of pyshared for the new python-foolscap package? It would make our lives (as Tahoe users/developers) easier, as well as any other folks who are writing programs who all three of (foolscap, setuptools, the setuptools 'extra feature' feature to indicate that their program requires SSL-based foolscap connections). thanks, -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#499699: setuptools issue
On Wed, 10 Dec 2008 00:39:59 +0100 Stephan Peijnik [EMAIL PROTECTED] wrote: As python-central seems to be unaffected by this issue as well (that's at least what some research on the net suggests) I am going to switch to python-central. I just pushed this update to SVN. That seems to fix the issue we have with the Tahoe code.. setuptools finds everything correctly with a package created with the new SVN debian/ directory. thanks! -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475440: behavior is now different in sid
I just re-ran a test, and I'm not seeing the problem in sid any more. Some data points: * sid now contains python-nevow 0.9.31, which is packaged with pycentral instead of pysupport * the .egg-info is ineed in the correct place: /usr/lib/python2.5/site-packages/Nevow-0.9.31.egg-info which is a symlink to /usr/share/pyshared/Nevow-0.9.31.egg-info Our Tahoe 'setup.py develop' step properly refrains from downloading or building Nevow. I don't know if setuptools contains a problem or not. It's possible that this problem was caused by earlier versions of the debian python-nevow package putting the .egg-info file in the wrong place. I imagine that Hardy has an older version which may have problems, in which case this particular bug could be closed (and perhaps reassigned to nevow for historical accuracy) and the Ubuntu bug (https://bugs.launchpad.net/allmydata.org/+bug/254035) could be reassigned to nevow (and remains open in Hardy). cheers, -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#475440: more information
I poked around some more, and found that while Nevow is now ok, the python-simplejson package is not. Our tahoe setup.py --develop process fails to notice that simplejson is already installed, and downloads+builds a new copy. python-simplejson uses python-support instead of pycentral. The .egg-info/ directory is in a directory that is on sys.path: /var/lib/python-support/python2.5/ . While experimenting, I noticed that moving the .egg-info/ directory earlier in sys.path (to /usr/lib/python2.5/site-packages/) was sufficient to make setuptools correctly notice simplejson and refrain from downloading+building it during our tahoe --develop step. So my hypothesis is that setuptools is not correctly handling the later elements of sys.path, perhaps because they are added by a site.py or *.pth file. Switching a package to use pycentral happens to fix the problem, because pycentral puts .egg-info files in the normal /usr/lib directory. python-support packages remain vulnerable to this apparent bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#491799: Slow darcs in sid
Package: darcs Version: 2.0.0-5 Severity: minor This is twb; I'm unilaterally moving this private discussion into the Debian BTS so I can track it more easily. I'll bounce messages to the [EMAIL PROTECTED] mailing list when this message creates it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477384: I'm wrong, the bug *is* fixed
Oops, you're absolutely right, python-twisted has the correct .egg-info file. (for some reason my machine had python-twisted-core installed but not python-twisted). Problem resolved. thanks! -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477384: nope, not actually fixed
reopen 477384 thanks I just installed 8.1.0-1, and unfortunately it looks like the bug is not actually fixed: 2670:[EMAIL PROTECTED] dpkg -L python-twisted-core |grep egg-info /usr/share/pyshared/Twisted_Core-8.1.0.egg-info To fix this bug, that file needs to be named Twisted-8.1.0.egg-info, not Twisted_Core-8.1.0.egg-info . In addition, inside that file, the Name: header must say Name: Twisted rather than Name: Twisted Core. The previous version had this file too.. it's a naming issue, not an existence issue. thanks, -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397781: [PATCH] possible fix
Here's a patch I used to bring the python binding up to date. I'm not exactly
sure what the problem was, but this patch seems to let me build a
correctly-functioning extension module.
cheers,
-Brian
--- rrdtool-1.2.15/bindings/python/rrdtoolmodule.c~ 2006-07-14
05:11:26.0 -0700
+++ rrdtool-1.2.15/bindings/python/rrdtoolmodule.c 2006-11-13
19:44:28.0 -0800
@@ -517,20 +517,19 @@
Py_DECREF(t);
/* Initialization function for the module */
-void
-/*initrrdtool(void)*/
-initrrdtoolmodule(void)
+PyMODINIT_FUNC
+initrrdtool(void)
{
PyObject*m, *d, *t;
/* Create the module and add the functions */
-m = Py_InitModule(rrdtoolmodule, _rrdtool_methods);
+m = Py_InitModule(rrdtool, _rrdtool_methods);
/* Add some symbolic constants to the module */
d = PyModule_GetDict(m);
SET_STRCONSTANT(d, __version__);
-ErrorObject = PyErr_NewException(rrdtoolmodule.error, NULL, NULL);
+ErrorObject = PyErr_NewException(rrdtool.error, NULL, NULL);
PyDict_SetItemString(d, error, ErrorObject);
/* Check for errors */
Bug#389333: [patch] fix for the memory leak
Tags: patch I found the problem.. it looks like the upstream change that started using sysfs in preference to usbfs (gnome-pilot/gpilotd/gpilot.d 1.151) neglected to free the memory it allocated by calling g_file_get_contents(). I've attached a patch below. If you would, please forward this patch along to the right Bugzilla place.. I can't make heads or tails of that thing. thanks, -Brian --- gpilotd/gpilotd.c.orig 2006-09-05 00:16:41.0 -0700 +++ gpilotd/gpilotd.c 2006-09-24 23:28:23.0 -0700 @@ -1313,6 +1313,7 @@ } vend_id = g_strndup (fcontent, 4); g_free (fname); + g_free (fcontent); fname = g_build_filename (sysfs_dir_name, entry, f_prod, NULL); @@ -1327,6 +1328,7 @@ } prod_id = g_strndup (fcontent, 4); g_free (fname); + g_free (fcontent); to_match = g_strconcat (Vendor=, vend_id, ProdID=, prod_id, NULL);
Bug#386480: possible patch
Here's a patch. I'm not sure if it's quite the right way to do it, but it
seems to create a python-metakit package that works for me.
-Brian
diff -ur metakit-2.4.9.3/debian/control libmetakit2.4.9.3-2.4.9.3/debian/control
--- metakit-2.4.9.3/debian/control 2006-09-21 11:23:00.0 -0700
+++ libmetakit2.4.9.3-2.4.9.3/debian/control2006-09-21 11:22:38.0
-0700
@@ -2,7 +2,7 @@
Section: libs
Priority: optional
Maintainer: Gerfried Fuchs [EMAIL PROTECTED]
-Build-Depends: debhelper (= 4.0), tcl8.4-dev, python2.3-dev, python-support
(= 0.4.0)
+Build-Depends: debhelper (= 4.0), tcl8.4-dev, python2.4-dev, python-support
(= 0.4.0)
Standards-Version: 3.7.2
Package: libmetakit2.4.9.3c2
diff -ur metakit-2.4.9.3/debian/pyversions
libmetakit2.4.9.3-2.4.9.3/debian/pyversions
--- metakit-2.4.9.3/debian/pyversions 2006-09-21 11:23:00.0 -0700
+++ libmetakit2.4.9.3-2.4.9.3/debian/pyversions 2006-09-21 11:23:21.0
-0700
@@ -1 +1 @@
-2.3
+2.4
diff -ur metakit-2.4.9.3/debian/rules libmetakit2.4.9.3-2.4.9.3/debian/rules
--- metakit-2.4.9.3/debian/rules2006-09-21 11:23:00.0 -0700
+++ libmetakit2.4.9.3-2.4.9.3/debian/rules 2006-09-21 11:57:43.0
-0700
@@ -35,7 +35,7 @@
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
--with-tcl=/usr/include/tcl8.4,/usr/lib/tcl8.4 \
- --with-python=/usr
+
--with-python=/usr/include/python2.4,/usr/lib/python2.4/site-packages
touch configure-stamp
@@ -52,7 +52,7 @@
dh_clean -k
dh_installdirs
install -d debian/tmp/usr/include debian/tmp/usr/lib
- mkdir -p debian/tmp/usr/lib/python2.3/site-packages
+ mkdir -p debian/tmp/usr/lib/python2.4/site-packages
(cd builds ln -s ../debian debian)
$(MAKE) -C builds install DESTDIR=$(CURDIR)/debian/tmp
builds/libtool --finish $(CURDIR)/debian/tmp/usr/lib
@@ -78,7 +78,7 @@
dh_installmanpages
dh_installinfo
dh_installchangelogs CHANGES
- dh_pysupport -V2.3
+ dh_pysupport -V2.4
dh_link
dh_strip
dh_compress
Bug#333783: me too
I'm seeing the same problem. I've attached a test file (created by the attached script.. the line number and length are prefixed on each line). When I do 'less' on this file, in an 80x30 xterm (details below), then hit 'j' to scroll downwards, things are fine until line 026 (the first long line that didn't fit on the initial screen) is supposed to be exposed, at which point 'j' does not appear to do anything. Hitting it again shows me 'arliecharliecharliecharliecharliecharliecharlie', which appears to be the 47 characters of line 026 (which is 127 characters long) that would have wrapped around from that line. Hitting 'j' again scrolls everything up and displays line 027 normally. Hitting C-l to refresh the screen scrolls everything up a line, providing the space to show both lines of 027 plus line 027 properly. Other long lines in the file experience the same problem. less: 391-1 xterm: 6.8.2.dfsg.1-8 libncurses5: 5.4-9 relevant output from `printenv`: SHELL=/bin/bash TERM=xterm HOSTDISPLAY=monolith:0.0 XTERM_SHELL=/bin/bash PAGER=less PATH=/home/warner/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/local/sbin:/sbin XTERM_VERSION=XTerm(202) LANGUAGE=en_US:en_GB:en DISPLAY=:0.0 output from `locale`: 21:[EMAIL PROTECTED] locale LANG= LC_CTYPE=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_COLLATE=POSIX LC_MONETARY=POSIX LC_MESSAGES=POSIX LC_PAPER=POSIX LC_NAME=POSIX LC_ADDRESS=POSIX LC_TELEPHONE=POSIX LC_MEASUREMENT=POSIX LC_IDENTIFICATION=POSIX LC_ALL= I don't have 'localepurge' installed on this machine, although I do on others. thanks, -Brian #! /usr/bin/python import random words = [alpha, bravo, charlie, delta, echo, flux] for i in range(100): word = words.pop(0) words.append(word) line = word * random.randint(4, 20) length = 3+1+3+1+len(line) print %03d:%03d:%s % (i, length, line) 000:078:alphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalpha 001:058:bravobravobravobravobravobravobravobravobravobravo 002:120:charliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharlie 003:108:deltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadelta 004:052:echoechoechoechoechoechoechoechoechoechoecho 005:048:fluxfluxfluxfluxfluxfluxfluxfluxfluxflux 006:053:alphaalphaalphaalphaalphaalphaalphaalphaalpha 007:093:bravobravobravobravobravobravobravobravobravobravobravobravobravobravobravobravobravo 008:113:charliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharlie 009:058:deltadeltadeltadeltadeltadeltadeltadeltadeltadelta 010:036:echoechoechoechoechoechoecho 011:076:fluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxflux 012:073:alphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalpha 013:043:bravobravobravobravobravobravobravo 014:092:charliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharlie 015:028:deltadeltadeltadelta 016:084:echoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoecho 017:040:fluxfluxfluxfluxfluxfluxfluxflux 018:088:alphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalpha 019:073:bravobravobravobravobravobravobravobravobravobravobravobravobravo 020:043:charliecharliecharliecharliecharlie 021:038:deltadeltadeltadeltadeltadelta 022:040:echoechoechoechoechoechoechoecho 023:024:fluxfluxfluxflux 024:068:alphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalpha 025:068:bravobravobravobravobravobravobravobravobravobravobravobravo 026:127:charliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharlie 027:078:deltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadelta 028:048:echoechoechoechoechoechoechoechoechoecho 029:032:fluxfluxfluxfluxfluxflux 030:043:alphaalphaalphaalphaalphaalphaalpha 031:098:bravobravobravobravobravobravobravobravobravobravobravobravobravobravobravobravobravobravo 032:148:charliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharlie 033:103:deltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadelta 034:088:echoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoechoecho 035:088:fluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxflux 036:078:alphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalpha 037:068:bravobravobravobravobravobravobravobravobravobravobravobravo 038:085:charliecharliecharliecharliecharliecharliecharliecharliecharliecharliecharlie 039:078:deltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadeltadelta 040:032:echoechoechoechoechoecho 041:056:fluxfluxfluxfluxfluxfluxfluxfluxfluxfluxfluxflux 042:108:alphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalphaalpha
Bug#293421: dh_strip?
I'm guessing that -g was not switched on in the previous version. Perhaps now that the -dbg packages are available, the -dev packages should be stripped? cheers, -Brian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
