Bug#867588: buildbot: application fails at runtime requiring sqlalchemy-migrate==0.7.2
So far, I have not observed any failures after removing the offending
lines ("sqlalchemy >= 0.6, <= 0.7.10" and "sqlalchemy-migrate==0.7.2")
from
/usr/lib/python2.7/dist-packages/buildbot-0.8.12.egg-info/requires.txt
Tested with buildbot 0.8.12-3.2 on stretch, with python-sqlalchemy
1.0.15+ds1-1 and python-migrate 0.10.0-7. Also installed "python-mock" and
ran the Buildbot tests with trial, though I am not sure how much of the
migration code gets exercised in the tests.
This commit to upstream seems to indicate that the newer versions of
sqlalchemy and sqlalchemy-migrate included in Debian should be compatible
with each other:
https://github.com/buildbot/buildbot/commit/222361a0e061291c9ba7fd7e6a660c7356ecd218
"Accept sqlalchemy-migrate versions 0.8 and up as compatible with
sqlalchemy version 0.8 and up."
Bug#589565: fixed upstream since v2.4.2
fixed nut/2.4.3-1 thanks You can use -p pidbase to monitor multiple UPSes. Reference: https://github.com/networkupstools/nut/commit/d1c5f0cc448b23933d6a8a00d3da2642eed4c847 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783021: nut-server: usbhid-ups keeps losing contact with apc ups
tags 783021 + moreinfo thanks Could you please check /var/log for information from usbhid-ups around the time that you get the UPS is unavailable notification? If there are no log messages, you might need to run usbhid-ups in gdb to determine why it is disconnecting. Email if you need additional details. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738122: nut: riello_usb fills up /var/log filesystem
Forwarded from Elio Parisi at Riello UPS: Charles Lepple wrote: I'm afraid I am just the messenger - @bigon (Laurent Bigonville, on GitHub) is a Debian maintainer of NUT, and he was pointing out the bug report filed with Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=738122 With other drivers, we sometimes see the did not claim interface 0 before use error if a driver gets out of sync with its PID file, and two copies of the driver are running. So maybe remove the PID file and start the driver again? It should be possible to detect this condition. Hi, attached there are a patch for the problem above. I think that this patch resolve the problem, however I don't be able to reproduce the problem on Debian Sid. I'm looking forward for the result of your test... Regards, Elio Parisi. riello.diff.gz Description: GNU Zip compressed data
Bug#671444: [Nut-upsuser] LiebertPSP
On May 10, 2012, at 4:38 AM, Arnaud Quette wrote: 2012/5/10 Charles Lepple clep...@gmail.com: On May 9, 2012, at 11:27 AM, Arnaud Quette wrote: this thread has just popped again, but on the Debian side this time: http://bugs.debian.org/671444 what's exactly the situation of fixes WRT issues? the last mail I have on this thread is attached below... Attached is a patch corresponding to the following branch: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor At this point, it is probably safe to merge. it applies fine on the trunk. should I go ahead and merge it? Sure, but is it possible to build a .deb for Alastair to test, just to make sure we're fixing the same problem? (I'm not sure if Debian has something like Ubuntu's PPA system.) Aside: it is annoying that with a 16-bit field for the USB PID, companies insist on reusing the VID:PID combinations for drastically different firmware. also, does it fix all the known issues related to this scaling factor? The two potential remaining problems are with ups.load and the RB flag, but they are not as critical as the OB/LB flags. It does not, however, change the subdriver to liebert-hid. I'm not sure to get all the whizzbang that may hide behind this comment ;-) AFAIK, liebert-hid seems to be for Liebert OEM manufactured by Phoenixtec with a limited set of data. while belkin-hid has a more advanced approach. so it's fine as you did. the problem of subdriver naming is something else, that will never be able to completely address due to mergers, OEM, ... In this message, Alastair cited Pier's patch which changes the subdriver for 10af:0001 from belkin-hid to liebert-hid. Due to the way that we match the HID usages, we probably could have put the scale fixes in the liebert-hid subdriver instead, but I agree that belkin-hid is probably the right mapping under the hood. -- Charles Lepple clepple@gmail -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#671444: [Nut-upsuser] LiebertPSP
On May 9, 2012, at 11:27 AM, Arnaud Quette wrote: this thread has just popped again, but on the Debian side this time: http://bugs.debian.org/671444 what's exactly the situation of fixes WRT issues? the last mail I have on this thread is attached below... Attached is a patch corresponding to the following branch: https://github.com/clepple/nut/tree/git-LiebertPSP-scalefactor At this point, it is probably safe to merge. It does not, however, change the subdriver to liebert-hid. -- Charles Lepple clepple@gmail LiebertPSP-2012-05-09.diff Description: Binary data
Bug#539747:
This should be fixed in the next 2.4.x release of NUT. From Arjen de Korte: There are two solutions in the driver: 1) Use the automatically detected 'phoenix' subdriver that flushes the input before sending a command (similar to the patch submitted and also similar to the megatec_usb driver). Bad side effect is the mandatory wait for the input to timeout, so I'm not to thrilled about that. 2) Use the 'ippon' subdriver (configured in 'ups.conf') that reads in one big 64-byte chunk, which seems to be a better match for this specific USB to serial controller (see recent activity on the upsdev mailinglist). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501087: [Nut-upsdev] Bug#501087: nut: support for a tripplite avr750u
On Sat, Oct 4, 2008 at 8:44 AM, Arnaud Quette [EMAIL PROTECTED] wrote: 2008/10/4 Raphael Geissert [EMAIL PROTECTED]: Package: nut Version: 2.2.2-8 Severity: wishlist Tags: patch [...] * the battery charge information, at least as displayed by knutclient 0.9.4, is either 0% or 100%, the latter only being displayed when the UPS is fully charged. * the runtime info is only updated after a test.battery.start.quick/deep, there's no calibrate.start/stop for it. I don't know much about TL devices, and I've not dug the ml, but Charles might have an answer to that. I don't know much about the Tripp Lite devices covered by the usbhid-ups driver, but the usual debug suggestions apply. You can run the driver with -DDD on the command line, and look for messages related to battery charge. Going out on a limb here, maybe it's something that we have to explicitly poll (versus waiting for it to be reported on the interrupt pipe), for the times when it is below 100%. In any case, it's probably a good idea to first verify that knutclient agrees with upsc. -- - Charles Lepple -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439055: [Nut-upsuser] Bug#439055: hid driver tries to mmap huge area, fails
On 9/8/07, Justin Piszcz [EMAIL PROTECTED] wrote: $ ./configure --with-user=nut --with-group=nut --prefix=/app/nut-trunk-1091 checking sys/time.h presence... yes checking for sys/time.h... yes ./configure: line 5460: NUT_TYPE_SOCKLEN_T: command not found ./configure: line 5461: NUT_TYPE_UINT16_T: command not found ./configure: line 5462: NUT_TYPE_UINT8_T: command not found checking for --with-all... not given ./configure: line 5492: syntax error near unexpected token `serial,' ./configure: line 5492: `NUT_ARG_WITH(serial, build and install serial drivers, yes)' autoconf/automake do not produce a working configure and no configure in trunk? This looks like you need to run autoreconf. It will re-run autoconf and automake, but will also include all of the NUT-specific macros in the m4/ directory. Also, be sure that you do not have automake-1.4 installed at all, and you have a later version of automake, such as 1.8 or 1.9. -- - Charles Lepple -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439055: [Nut-upsuser] Bug#439055: hid driver tries to mmap huge area, fails
On 9/7/07, Joey Hess [EMAIL PROTECTED] wrote: Arnaud Quette wrote: I've sadly not much time to investigate, but have you tested the latest trunk? No. Is it packaged? I haven't tried this very recently, but you should be able to use debuild if you create a symlink from the top-level directory: ln -s Packaging/debian . -- - Charles Lepple -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#424625: libhid0: libhid-detach-device needs option to select a specific interface
Package: libhid0 Version: 0.2.15+20060325-2.1 Severity: normal libhid-detach-device is a misnomer; it only detaches the kernel driver from interface #0 of the specified device. There should be an option to specify the interface. (This is an upstream bug, but we don't have a decent BTS for libhid other than this one.) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (400, 'stable') Architecture: powerpc (ppc) Kernel: Linux 2.6.18-4-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages libhid0 depends on: ii libc6 2.5-7 GNU C Library: Shared libraries ii libusb-0.1-4 2:0.1.12-7 userspace USB programming library libhid0 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408440: libnss-ldap: problem still exists in 251-7.5
I just ran into this problem after an upgrade to 251-7.5, and Rene's problem assessment still holds true with this package version. The debconf prompt indicates it is requesting a URI, but even when just pressing Enter to confirm the previous ldapi:// URI, the libnss-ldap.conf file gets rewritten with a host ldapi:// URI. This is a very sneaky bug - there is nothing in the logs indicating that there is a problem with libnss-ldap (other than the fact that all the LDAP users cannot be looked up anymore). If this can't be patched in time for etch, could a note about this be added to NEWS.Debian for this package?
Bug#394935: also having trouble backing up LDAP
Micah Anderson wrote: Charles Lepple wrote: In my case, the dump files are not quite empty - they only list the DNs, and have this prefix: # LDAPv3 # base dc=ghz,dc=cc with scope subtree # filter: (objectclass=*) # requesting: | /bin/gzip Also, for anyone else trying to snag the development version of the ldap handler without a browser handy: wget --no-check-certificate 'https://code.autistici.org/trac/backupninja/browser/trunk/handlers/ldap?format=raw' Does this happen with the development version? No, but one thing I had to do after downloading the handler was replace @AWK@ and @SED@ with /usr/bin/awk and /bin/sed, respectively. Oddly enough, the ldap handler did not return an error before I edited it-- the log said Info: finished action /etc/backup.d/30ghz.ldap: SUCCESS. -- Charles Lepple
Bug#394935: also having trouble backing up LDAP
In my case, the dump files are not quite empty - they only list the DNs, and have this prefix: # LDAPv3 # base dc=ghz,dc=cc with scope subtree # filter: (objectclass=*) # requesting: | /bin/gzip Also, for anyone else trying to snag the development version of the ldap handler without a browser handy: wget --no-check-certificate 'https://code.autistici.org/trac/backupninja/browser/trunk/handlers/ldap?format=raw'
Bug#394935: also having trouble backing up LDAP
Micah Anderson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Charles Lepple wrote: In my case, the dump files are not quite empty - they only list the DNs, and have this prefix: # LDAPv3 # base dc=ghz,dc=cc with scope subtree # filter: (objectclass=*) # requesting: | /bin/gzip Also, for anyone else trying to snag the development version of the ldap handler without a browser handy: wget --no-check-certificate 'https://code.autistici.org/trac/backupninja/browser/trunk/handlers/ldap?format=raw' Does this happen with the development version? I was in a hurry to get to work this morning, so I just downloaded and installed it, and figured I'd wait until the next backup cycle (I backed LDAP up by hand, too). -- Charles Lepple
Bug#408313: iproute: please add *.dist files generated from netem directory
Package: iproute Version: 20061002-3 Severity: normal In order to simulate packet delays with the netem module, tc needs the *.dist files from iproute2-2.6.18-061002/netem/ to be generated and installed in /usr/lib/tc. I was able to copy these from a Fedora box, since they are simply text files. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages iproute depends on: ii libatm1 2.4.1-17shared library for ATM (Asynchrono ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libdb4.3 4.3.29-6Berkeley v4.3 Database Libraries [ Versions of packages iproute recommends: pn iproute-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407882: nut-usb from 2.0.4 doesn't work with nut 2.0.5, and vice versa
Package: nut-usb Version: 2.0.4-3 Severity: normal The base nut package should probably conflict with nut-usb_2.0.4, and nut-usb should depend on nut = 2.0.5 (due to the change in socket names). Otherwise, users could easily upgrade the core package but miss the other driver packages. The same might be true for nut-snmp, but I don't have a SNMP-enabled UPS to test that theory. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (700, 'testing'), (600, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages nut-usb depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libusb-0.1-4 2:0.1.12-2 userspace USB programming library ii nut 2.0.5-1 The core system of the nut - Netwo ii udev 0.103-2 /dev/ and hotplug management daemo nut-usb recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#380304: nut-usb: bcmxcp_usb does not find ups at bootup
After the system starts up, and before you unplug/replug the UPS, can you see the UPS with lsusb? What are the permissions on the corresponding /proc/bus/usb/*/* and/or /dev/bus/usb/*/* nodes for the UPS?
Bug#385669: mysql-server: daily binary log rotation script fails due to unexpected format of log list
Christian Hammers wrote: Hello Charles On 2006-09-01 Charles Lepple wrote: Here is a trace of /etc/cron.daily/mysql-server: It seems to me that you have an old script from MySQL 4.x laying around, the current 5.x packages do not have an /etc/cron.daily/ file as they use expire_days in /etc/mysql/my.cnf. Can you verify with dpkg -S etc/cron.daily/mysql-server if this skript still belongs to any package? If not, just delete it. $ dpkg -S /etc/cron.daily/mysql-server mysql-server: /etc/cron.daily/mysql-server $ aptitude show mysql-server Unable to find an archive sarge for the package mysql-server Package: mysql-server State: installed Automatically installed: no Version: 5.0.24-3 Priority: optional Section: misc Maintainer: Christian Hammers [EMAIL PROTECTED] Uncompressed Size: 69.6k Depends: mysql-server-5.0 Provided by: mysql-server-5.0, mysql-server-4.1 [...] It looks like the non-virtual mysql-server is in testing, but so is the mysql-server-5.0 which provides the virtual package. Apparently, my pin file and sources.list are not in sync, because the system is a stable/testing hybrid (instead of testing/unstable, as the pin information may have indicated). Would you suggest enabling unstable as well, then upgrading mysql-server-5.0, and removing the dummy package if it doesn't get removed automatically? thanks, -- Charles Lepple
Bug#385669: mysql-server: daily binary log rotation script fails due to unexpected format of log list
Christian Hammers wrote: On 2006-09-03 Charles Lepple wrote: Would you suggest enabling unstable as well, then upgrading mysql-server-5.0, and removing the dummy package if it doesn't get removed automatically? Oh, hm, I have no experience with mixing stable/testing, I would rather recommend using only stable and get mysql-server-5.0 from www.backports.org. Using testing/unstable might also work but stable+testing.. hmm.. On further inspection, it seems that there is a mysql-server non-virtual package in unstable (in addition to the virtual one provided by mysql-server-5.0): from http://packages.qa.debian.org/m/mysql-dfsg-5.0/news/20060903T223230Z.html Description: libmysqlclient15-dev - mysql database development files libmysqlclient15off - mysql database client library mysql-client - mysql database client (current version) mysql-client-5.0 - mysql database client binaries mysql-common - mysql database common files (e.g. /etc/mysql/my.cnf) mysql-server - mysql database server (current version) mysql-server-5.0 - mysql database server binaries So that may be confusing dpkg/apt as well. I can try going to testing-only if that will rule out any weirdness, but it looks like the problem is independent of that. Removing the non-virtual mysql-server did get rid of the cron job as expected, but that package probably needs to be removed from the archive if the mysql-server-version packages are providing it as well. It also seems like mysql-client is also both real and virtual in testing/unstable, although I have not run across any similar problems there. -- Charles Lepple
Bug#385669: mysql-server: daily binary log rotation script fails due to unexpected format of log list
Package: mysql-server Version: 5.0.24-3 Severity: normal Here is a trace of /etc/cron.daily/mysql-server: --- $ sudo sh -x mysql-server + set -e + set -u + M='/usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf' + MA='/usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf' ++ tempfile + tmp=/tmp/file9Mkdf8 + test -x /usr/bin/mysqladmin + . /etc/mysql/debian-log-rotate.conf ++ KEEP_BINARY_LOGS=7 + '[' 7 -eq 0 ']' + /usr/bin/mysqladmin --defaults-file=/etc/mysql/debian.cnf --silent ping + echo 'SHOW MASTER LOGS;' + /usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf --skip-column-names ++ wc -l + '[' 33 -gt 7 ']' ++ tail -n 7 /tmp/file9Mkdf8 ++ head -n 1 + filename='mysql-bin.000585470052' + echo 'PURGE MASTER LOGS TO '\''mysql-bin.000585 470052'\'';' + /usr/bin/mysql --defaults-file=/etc/mysql/debian.cnf ERROR 1373 (HY000) at line 1: Target log not found in binlog index --- Note that 'SHOW MASTER LOGS;' is returning an extra column (file size). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.20-021stab028.5.777-enterprise Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages mysql-server depends on: ii mysql-server-5.0 5.0.24-3 mysql database server binaries mysql-server recommends no packages. -- debconf information: mysql-server/skip_networking: false mysql-server/really_downgrade_from_41: false mysql-server/want_chroot: false mysql-server/start_on_boot: true mysql-server/postrm_remove_databases: false * mysql-server/mysql_install_db_notes: mysql-server/nis_warning: mysql-server/mysql_update_hints1: * mysql-server/postrm_remove_database: false mysql-server/fix_privileges_warning: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345190: Patch applied to libhid SVN repository
This patch has been applied to the libhid SVN repository. Thanks, - Charles Lepple
Bug#350493: Subject: python-hid: Python bindings are virtually unusable
Package: python-hid Version: 0.2.12-1 Severity: grave Justification: renders package unusable The SWIG interface file in libhid 0.2.12-1 does not properly handle conversion of Python string and list objects into buffer/length pairs. This means that nearly all of the functions which pass HID path arrays or binary buffers will not work (resulting in TypeErrors, or crashing the interpreter). Upstream SVN (post 0.2.15) has fixes for all of the functions currently known to be broken. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.12-11-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages python-hid depends on: ii libc62.3.2.ds1-22GNU C Library: Shared libraries an ii libhid0 0.2.12-1userspace USB HID access library ii libusb-0.1-4 2:0.1.10a-9.sarge.1 userspace USB programming library ii python 2.3.5-2 An interactive high-level object-o -- no debconf information
Bug#338738: is this a duplicate of #332939?
This bug looks like it might be a duplicate of #332939. I would flag it as such, but I am no expert on hotplug/udev interaction. - C
Bug#310603: sqlite3-doc: lang_{vacuum,keywords}.html missing
Package: sqlite3-doc Version: 3.2.1-1 Severity: minor lang_keywords.html and lang_vacuum.html are both linked from lang.html, but do not exist in the sqlite3-doc package. Severity is 'minor' since the pages are available at http://sqlite.org/ A quick look at the tarball suggests that this may be an upstream problem, since there is only one lang.tcl in the www directory. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310603: more missing files
Here is a longer list of lang_* files referenced in sqlite3-doc, but not packaged: lang_altertable.html lang_conflict.html lang_createtable.html lang_createtrigger.html lang_createview.html lang_droptrigger.html lang_dropview.html lang_keywords.html lang_reindex.html lang_select.html lang_vacuum.html A more thorough test might be to run a HTML link checker starting at index.html, but I don't have much experience with that.
Bug#310437: backupninja: backup handler for trac environments
Package: backupninja Version: 0.5-3 Severity: wishlist Tags: patch Attached is a backup handler for trac environments. It is a modified version of the Subversion handler, so configuration is similar. Versions of packages backupninja depends on: ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii mawk 1.3.3-11 a pattern scanning and text proces -- no debconf information # # this handler will backup trac environments (based on the svn handler) # # http://trac.edgewall.com/ # getconf src /var/lib/trac getconf dest /var/backups/trac getconf tmp /var/backups/trac.tmp error=0 cd $src for repo in `find . -name VERSION` do repo=`dirname $repo` # Just make the $tmp dir, not $tmp/$repo ret=`mkdir -p $tmp 21` code=$? if [ $ret ]; then debug $ret fi if [ $code != 0 ]; then error command failed mkdir -p $tmp fi ret=`trac-admin $src/$repo hotcopy $tmp/$repo 21` code=$? if [ $ret ]; then debug $ret fi if [ $code != 0 ]; then error command failed -- trac-admin $src/$repo hotcopy $tmp/$repo error=1 fi done if [ $error -eq 1 ]; then echo Error: because of earlier errors, we are leaving trac backups in $tmp instead of $dest else if [ -d $dest -a -d $tmp ]; then rm -rf $dest fi if [ -d $tmp ]; then mv $tmp $dest fi fi exit 0 # vim: filetype=sh
Bug#305453: approx: would like to see outbound HTTP proxy support
Eric Cooper said: Can you try setting the http_proxy environment variable before starting approx and seeing if that works? I'll try to add more explicit support via approx.conf as well. That worked-- I set it in /etc/init.d/approx. (I'm not sure why I was thinking that the daemon wouldn't get a full copy of the environment.) Rather than reinventing the wheel, maybe it would be a better idea to source an /etc/defaults/approx file to get environment variables? That way, if libcurl adds other options, approx users could just change their defaults file. You could just point users to the libcurl documentation for proxy setup. -- Charles Lepple
Bug#305451: approx: runs as root
Eric Cooper said: It would be nice if approx ran as an unprivileged user. From what I can tell, it doesn't need root privileges (even to bind the listening socket). You're right, and another user also made the same suggestion, so I plan to do that. Do you have any advice on which user/group to use? Heh. Maybe you could borrow the aptproxy userid. Actually, along these lines, I wonder if there's a precedent for conflicting with another package with a server that binds to the same port. After all, the default for both apt-proxy and approx is to listen on port . (Of course, you can always reconfigure one or the other to listen on a different port, whereas most other conflicts arise from two packages that have staked out the same portion of the filesystem namespace.) Even if you had both listening to the same port, they keep databases in different subdirectories of /var. Sharing the same userid wouldn't be so much of a technical challenge as a political question. But IANADD :-) I couldn't find a place in the Policy docs that spelled this out. Should I try to create a new approx user/group, which would require the base-passwd maintainer's agreement, or to reuse something else like daemon or www-data? that's probably a question for the debian-devel list (if it hasn't been covered before). -- Charles Lepple
Bug#305451: approx: runs as root
Package: approx Version: 1.09 Severity: wishlist It would be nice if approx ran as an unprivileged user. From what I can tell, it doesn't need root privileges (even to bind the listening socket). Otherwise, this program is a welcome change from apt-proxy. Performance seems *way* better, even after I imported my entire apt-proxy cache into /var/cache/approx. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.10-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages approx depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcurl37.13.2-2 Multi-protocol file transfer libra ii libidn110.5.13-1.0 GNU libidn library, implementation ii libpcre35.0-1Perl 5 Compatible Regular Expressi ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305453: approx: would like to see outbound HTTP proxy support
Package: approx Version: 1.09 Severity: wishlist One feature that apt-proxy has that is useful in corporate networks is the ability to connect to a HTTP proxy server to retrieve files (when a direct HTTP connection is prohibited by a firewall). Granted, approx is a proxy itself, and this might seem redundant in the presence of a regular HTTP proxy, but not all HTTP proxy setups are smart enough to cache .deb files, and in those cases, having apt-proxy connect to a HTTP proxy is very handy. Since approx uses libcurl as the backend, would it be possible to expose some of libcurl's proxy settings in approx.conf? I'll volunteer to test this functionality if needed. I can test packages from experimental, or even try to build from source (but I currently know next to nothing about ocaml). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: powerpc (ppc) Kernel: Linux 2.6.10-powerpc Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages approx depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an ii libcurl37.13.2-2 Multi-protocol file transfer libra ii libidn110.5.13-1.0 GNU libidn library, implementation ii libpcre35.0-1Perl 5 Compatible Regular Expressi ii libssl0.9.7 0.9.7e-3 SSL shared libraries ii zlib1g 1:1.2.2-4compression library - runtime -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302902: nut-cgi: upsstats.cgi crashes if hosts.conf has no valid MONITOR lines
Package: nut-cgi
Version: 2.0.1-2
Severity: normal
Tags: patch
I forgot to copy in a good version of hosts.conf when setting up a new
nut-cgi installation, and when I invoked upsstats.cgi, I got an
Internal Server Error from apache.
It turns out that upsstats.cgi was dereferencing a NULL pointer and
crashing if no valid MONITOR lines were encountered.
The attached patch prints an error message telling the user that the
problem lies in hosts.conf.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.10-powerpc
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)
Versions of packages nut-cgi depends on:
ii libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii libfontconfig1 2.3.1-2 generic font configuration library
ii libfreetype6 2.1.7-2.3 FreeType 2 font engine, shared lib
ii libgd2-xpm 2.0.33-1.1 GD Graphics Library version 2
ii libjpeg626b-10 The Independent JPEG Group's JPEG
ii libpng12-0 1.2.8rel-1 PNG library - runtime
ii libx11-6 4.3.0.dfsg.1-12 X Window System protocol client li
ii libxpm4 4.3.0.dfsg.1-12 X pixmap library
ii xlibs4.3.0.dfsg.1-12 X Keyboard Extension (XKB) configu
ii zlib1g 1:1.2.2-4 compression library - runtime
-- no debconf information
--- nut-2.0.1/clients/upsstats.c.orig 2003-09-30 00:50:10.0 -0400
+++ nut-2.0.1/clients/upsstats.c 2005-04-03 12:49:39.583284972 -0400
@@ -752,6 +752,20 @@ static void load_hosts_conf(void)
}
pconf_finish(ctx);
+
+ if (!ulhead) {
+ printf(!DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.0 Transitional//EN\\n);
+ printf( \http://www.w3.org/TR/REC-html40/loose.dtd\;\n);
+ printf(HTMLHEAD\n);
+ printf(TITLEError: no hosts to monitor/TITLE\n);
+ printf(/HEADBODY\n);
+ printf(Error: no hosts to monitor (check CODEhosts.conf/CODE)\n);
+ printf(/BODY/HTML\n);
+
+ /* leave something for the admin */
+ fprintf(stderr, upsstats: no hosts to monitor\n);
+ exit(EXIT_FAILURE);
+ }
}
static void display_single(void)
Bug#301456: bittornado: man page is out of date w.r.t. --minport/--maxport
Package: bittornado Version: 0.3.10-3 Severity: minor This version of bittornado apparently uses random incoming ports in the range 1-6, not 6881-6889 as mentioned in the man page (defaults for --minport and --maxport). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-p3-1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages bittornado depends on: ii python2.3.5-1An interactive high-level object-o -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301456: clarification to man page problem
Sorry-- somehow I missed the individual client man pages, such as btdownloadcurses and btdownloadheadless. They appear to be up-to-date. The overall man page (bittorrent-downloader) still refers to the old port allocation method, though, as does /usr/share/doc/bittornado/README.txt.gz (step 6). -- Charles Lepple
Bug#301151: trac: AssertionError raised when visiting WikiRestructuredTextLinks after clean install
Package: trac
Version: 0.8.1-1
Severity: normal
When you create a new environment with trac-admin, the
WikiRestructuredTextLinks node is not viewable or editable. (The rest of
the Wiki nodes seem to work fine, including editing.)
Approximate steps to reproduce:
$ svnadmin create /tmp/example/repo
$ trac-admin /tmp/example/trac-env
Trac [/tmp/example/trac-env] initenv
...
$ chmod -R a+w /tmp/example/trac-env
* configure apache
* go to http://servername/cgi-bin/trac.cgi/wiki/WikiRestructuredTextLinks
The Traceback output is attached. This occurred when running Trac as a
CGI script, but I have seen the same problem when it is called from
mod_python.
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-p3-1
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages trac depends on:
ii python2.3.5-1An interactive high-level object-o
ii python-clearsilver0.9.13-3 python bindings for clearsilver
ii python-sqlite 1.0.1-2python interface to SQLite
ii python2.3-subversion 1.1.3-2python modules for interfacing wit
ii subversion1.1.3-2advanced version control system (a
-- no debconf information
Title: Oops - My Project - Trac
Navigation
Login
Settings
Help/Guide
FAQ
Accessibility
About Trac
Oops...
Trac detected an internal error:
If you think this really should work and you can reproduce it. Then you
should consider to report this problem to the Trac team.
Go to http://trac.edgewall.com/ and create a new ticket where you describe
the problem, how to reproduce it. Don't forget to include the python
traceback found below.
TracGuide
The Trac User and Administration Guide
Python traceback
Traceback (most recent call last):
File /usr/lib/python2.3/site-packages/trac/core.py, line 531, in cgi_start
real_cgi_start()
File /usr/lib/python2.3/site-packages/trac/core.py, line 526, in real_cgi_start
dispatch_request(path_info, args, req, env)
File /usr/lib/python2.3/site-packages/trac/core.py, line 441, in dispatch_request
module.run()
File /usr/lib/python2.3/site-packages/trac/Module.py, line 44, in run
self.render()
File /usr/lib/python2.3/site-packages/trac/Wiki.py, line 341, in render
Formatter(self.req.hdf, self.env,self.db).format(self.page.text, out)
File /usr/lib/python2.3/site-packages/trac/WikiFormatter.py, line 561, in format
self.handle_code_block(line)
File /usr/lib/python2.3/site-packages/trac/WikiFormatter.py, line 517, in handle_code_block
self.out.write(self.code_processor(self.hdf, self.code_text, self.env))
File /usr/lib/python2.3/site-packages/trac/wikimacros/rst.py, line 210, in execute
settings_overrides = {'halt_level':6})
File /usr/lib/site-python/docutils/core.py, line 371, in publish_string
enable_exit_status=enable_exit_status)
File /usr/lib/site-python/docutils/core.py, line 513, in publish_programmatically
output = pub.publish(enable_exit_status=enable_exit_status)
File /usr/lib/site-python/docutils/core.py, line 196, in publish
output = self.writer.write(document, self.destination)
File /usr/lib/site-python/docutils/writers/__init__.py, line 72, in write
self.translate()
File /usr/lib/site-python/docutils/writers/html4css1.py, line 103, in translate
self.document.walkabout(visitor)
File /usr/lib/site-python/docutils/nodes.py, line 153, in walkabout
child.walkabout(visitor)
File /usr/lib/site-python/docutils/nodes.py, line 153, in walkabout
child.walkabout(visitor)
File /usr/lib/site-python/docutils/nodes.py, line 153, in walkabout
child.walkabout(visitor)
File /usr/lib/site-python/docutils/nodes.py, line 153, in walkabout
child.walkabout(visitor)
File /usr/lib/site-python/docutils/nodes.py, line 153, in walkabout
child.walkabout(visitor)
File /usr/lib/site-python/docutils/nodes.py, line 145, in walkabout
visitor.dispatch_visit(self)
File /usr/lib/site-python/docutils/nodes.py, line 1323, in dispatch_visit
return method(node)
File /usr/lib/site-python/docutils/writers/html4css1.py, line 1050, in visit_reference
assert len(node) == 1 and isinstance(node[0], nodes.image)
AssertionError
Powered by Trac 0.8.1
By Edgewall Software.
Visit the Trac open source project athttp://trac.edgewall.com/
Bug#300288: dstat: terminal color detection broken
Package: dstat
Version: 0.5.7-2
Severity: normal
on line 1254 of dstat (0.5.7-2):
### Check terminal capabilities
#if not sys.stdout.isatty() or not curses.wrapper(lambda \
# s:curses.has_colors()):
if not sys.stdout.isatty() or os.environ.get('TERM',None) not in \
('ansi', 'linux', 'rxvt', 'screen', 'screen-w', 'xterm'):
op.color = False
op.nolimit = True
op.update = False
When using xterm-color, dstat reverts back to uncolored, continuous (no
headers) format.
Also, I'm not exactly sure about the op.nolimit and op.update options,
but it seems like those should be conditional on the not
sys.stdout.isatty() test, and if stdout is a terminal, then op.color
should be set. That way, even if I am on a non-color-capable terminal,
the headers will get redisplayed once per screenful of stats.
I realize that adding all color-capable terminals to the list would be a
big maintenance headache, but it would be nice if any terminal ending in
-color turned on op.color. Or, there could be a --color option to
complement --nocolor.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.9.skas-2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968)
Versions of packages dstat depends on:
ii python2.3.5-1An interactive high-level object-o
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300288: dstat: terminal color detection broken
Dag Wieers said: On Fri, 18 Mar 2005, Charles Lepple wrote: Also, I'm not exactly sure about the op.nolimit and op.update options, but it seems like those should be conditional on the not sys.stdout.isatty() test, and if stdout is a terminal, then op.color should be set. That way, even if I am on a non-color-capable terminal, the headers will get redisplayed once per screenful of stats. This was actually for people who were piping the output to a file. In that case you don't want colors or any of the ansi/vt100 crap :) But there's a lot of potential improvements in this area. Understood. I think it's a neat idea, it just looks like it got broken when the ncurses stuff was removed. How's the attached patch for starters? I realize that adding all color-capable terminals to the list would be a big maintenance headache, but it would be nice if any terminal ending in -color turned on op.color. Or, there could be a --color option to complement --nocolor. I'd love to use ncurses for what it was designed, sadly if I try to use ncurses it clears the complete screen or does something ugly inside a screen. I tend to avoid ncurses whenever possible, sorry :-) I'm feeling lazy, so I didn't even attempt to do matching for terminal names ending in '-color', but 'xterm-color' is common enough. -- Charles Lepple dstat-color.patch Description: Binary data
Bug#286136: also seeing restart failures with apt-proxy
On at least two separate occasions, apt-proxy has failed to start back up after logrotate signals it to restart. The machine is a 533 MHz P3, so I'm not terribly surprised that apt-proxy takes longer than a second to shut down. Would the --retry option to start-stop-daemon help matters? It seems as though it should ensure that apt-proxy has totally shut down before restarting, but I could be misreading the man page. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10-p3-1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages apt-proxy depends on: ii bzip2 1.0.2-1A high-quality block-sorting file ii debconf 1.4.30.11 Debian configuration management sy ii logrotate 3.7-2 Log rotation utility ii python 2.3.4-5An interactive high-level object-o ii python-apt 0.5.10 Python interface to libapt-pkg ii python-bsddb3 3.3.0-6Python interface to libdb3 ii python-twisted 1.3.0-6Event-based framework for internet -- debconf information: apt-proxy/upgrading-v2: apt-proxy/upgrading-v2-result: -- Charles Lepple
Bug#264429: patch no longer applies to zaptel-source 1:1.0.2-2
patching file rules Hunk #1 FAILED at 127. Hunk #2 FAILED at 205. 2 out of 2 hunks FAILED -- saving rejects to file rules.rej On closer inspection, the new debian/rules file already has $(ROOT_CMD) in the kdist_image target. I'm not sure whether the dh_testroot is needed during the 'make clean' stage (Hunk #2), but the current version (1:1.0.2-2) did not have any problems at this stage when built using fakeroot. -- Charles Lepple
Bug#274081: zaptel-source dependencies
I would tend to agree that zaptel-source should Recommend: zaptel, since zaptel-source and zaptel show up in different parts of the package list. -- Charles Lepple
Bug#292592: 'make-kpkg modules_image' fails with zaptel-source and fakeroot
Package: zaptel-source Version: 1:1.0.2-2 Severity: normal Tags: patch I get the following error messages from make-kpkg: mkdir -p \ /usr/src/modules/zaptel/debian/zaptel-modules-2.6.9.skas-2/usr/include/linux install -m 644 zaptel.h \ /usr/src/modules/zaptel/debian/zaptel-modules-2.6.9.skas-2/usr/include/linux install -m 644 torisa.h \ /usr/src/modules/zaptel/debian/zaptel-modules-2.6.9.skas-2/usr/include/linux ( cd /usr/src/modules/zaptel/debian/zaptel-modules-2.6.9.skas-2/usr/lib ; rm -f libtonezone.so ; ln -sf libtonezone.so.1.0 libtonezone.so ) /bin/sh: line 0: cd: /usr/src/modules/zaptel/debian/zaptel-modules-2.6.9.skas-2/usr/lib: No such file or directory /sbin/ldconfig /sbin/ldconfig: Can't create temporary cache file /etc/ld.so.cache~: Permission denied make[3]: *** [install-modules] Error 1 make[3]: Leaving directory `/usr/src/modules/zaptel' make[2]: *** [binary-modules] Error 2 make[2]: Leaving directory `/usr/src/modules/zaptel' make[1]: *** [kdist_image] Error 2 make[1]: Leaving directory `/usr/src/modules/zaptel' Module /usr/src/modules/zaptel failed. Perhaps /usr/src/modules/zaptel does not understand --rootcmd? If you see messages that indicate that it is not in fact being built as root, please file a bug against /usr/src/modules/zaptel. Since libtonezone is split off into its own package, I think the 'rm -f'/'ln -sf' commands and ldconfig can be removed from the Makefile. (I included the tail end of the message in case others are searching for it, but further investigation seems to indicate that this has nothing to do with --rootcmd (fakeroot, in this case)). -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9.skas-2 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) -- no debconf information --- zaptel/Makefile.dist2005-01-17 18:19:08.0 -0500 +++ zaptel/Makefile 2005-01-27 21:01:03.0 -0500 @@ -304,8 +304,8 @@ install -m 644 zaptel.h $(DESTDIR)$(INSTALL_PREFIX)/usr/include/linux install -m 644 torisa.h $(DESTDIR)$(INSTALL_PREFIX)/usr/include/linux # install -m 644 tonezone.h $(DESTDIR)$(INSTALL_PREFIX)/usr/include - ( cd $(DESTDIR)$(INSTALL_PREFIX)/usr/lib ; rm -f libtonezone.so ; ln -sf $(LIBTONEZONE) libtonezone.so ) - /sbin/ldconfig +# ( cd $(DESTDIR)$(INSTALL_PREFIX)/usr/lib ; rm -f libtonezone.so ; ln -sf $(LIBTONEZONE) libtonezone.so ) +# /sbin/ldconfig install-modconf: if [ -f $(MODCONF) ]; then mv -f $(MODCONF) $(MODCONF).bak ; fi
Bug#290994: Acknowledgement ([powerpc] [20050114] installation of d-i snapshot on Mac G4 Cube)
Update on the fb/X situation: If I boot with video=aty128fb:1024x768, I get no output on the ADC connector (the screen goes blank sometime after the yaboot prompt). However, if I hook up a VGA monitor to the other video connector, things seem to work, and I can use the FBDev X server. (For some reason, it went into 1152x864 mode, but I can deal with that.) Maybe the VGA-vs-ADC info should go in the documentation? (The ADC-connected displays were a common option on G4 Cubes.) -- Charles Lepple -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290514: python-gtkmvc: 404 error on link in description (and new upstream)
Package: python-gtkmvc Severity: wishlist Project development seems to have moved to SourceForge: http://sourceforge.net/projects/pygtkmvc (The URL listed in the description does not work, and http://sra.itc.it/people/cavada/ points to the above page) -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.4.20 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
