Bug#839156: "/usr/bin/passenger-config: No such file or directory"
Seems to me that the problem is that ruby-passenger.install only installs /usr/sbin, and /usr/bin is ignored. I think /usr/bin should be added to ruby-passenger.install & then all would be well. I don't know much about how rack stuff is supposed to work, but puppet- master-passenger is completely unusable with this bug in place, and I suspect other packages that try to use passenger would be as well. Not sure offhand what severity this merits, but rather think this ought to qualify for a stable update. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#398789: Debian bug #398789
On Tue, 2016-10-11 at 09:29 +, Holger Levsen wrote: > Hi, > > On Tue, Oct 11, 2016 at 02:13:15AM +0000, Nick Phillips wrote: > > > > As I see you were the submitter of https://bugs.debian.org/cgi-bin/ > > bugr > > eport.cgi?bug=398789 and I'm now stuck with the same problem, I'm > > wondering if you ever came up with a good workaround? > > it would have been nicer, if you had given any indication what 398789 > is > about… > > it also would have been better, if you had cc:ed the bug, to maybe > get > attention from the maintainer. > > > > > I'm in exactly the situation you describe in your last mail to the > > bug > > - trying to use live-build to create a livecd but openssh is > > causing > > the whole thing to fail due to "PRNG not seeded". > no idea, sorry. please mail the bug. > > what surprises this me, is that the bug doesnt seem to happen on > https://piuparts.debian.org/sid/source/o/openssh.html > > feel free to reply to 398...@bugs.debian.org > It seems that using cdebootstrap rather than debootstrap makes it work. *shrug*... Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#810141: [Fwd: Re: [Pkg-libvirt-maintainers] Bug#810141: libvirt-daemon-system postinst tries to touch files in nonexistent dirs]
Sorry, accidentally sent this only to Guido and not to the bug... Forwarded Message From: Nick Phillips <nick.phill...@otago.ac.nz> To: Guido Günther <a...@sigxcpu.org> Subject: Re: [Pkg-libvirt-maintainers] Bug#810141: libvirt-daemon -system postinst tries to touch files in nonexistent dirs Date: Fri, 8 Jan 2016 09:15:19 +1300 On Thu, 2016-01-07 at 18:15 +0100, Guido Günther wrote: > Hi, > On Thu, Jan 07, 2016 at 09:42:08AM +1300, Nick Phillips wrote: > > Package: libvirt-daemon-system > > Version: 1.2.9-9+deb8u1 > > Severity: normal > > > > On upgrade from wheezy to jessie, libvirt-daemon-system failed to > > complete > > installation - postinst was trying to touch > > /var/log/libvirt/uml/.placeholder > > and /var/log/libvirt/lxc/.placeholder - when neither of those > > directories > > exist. > > > > Had to manually create dirs in order for postinst to complete. > > The dirs are created by the package itself, e.g. > > dpkg -S /var/log/libvirt/uml > > So if that failed, dpkg did not create the dirs (e.g. due to some > --path-exclude pattern). > > We'd need more logs to tell. We had lots of successful upgrades from > wheezy to jessie already, can you think of s.th. that could be > different > on your system? > Cheers, > -- Guido No, I can't. It was odd though, that I also had messages complaining about failing to register a libvirt service as one was already being provided by a different package (I think removing libvirt-bin manually fixed that). Is it possible that removing that package removed them for some reason? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz Faculty of Medicine, University of Otago
Bug#810140: binwalk: unnecessary(?) deps make binwalk useless on minimal systems
Control: reassign -1 binwalk
On Wed, 2016-01-06 at 22:47 +, Gianfranco Costamagna wrote:
> Control: reassign -1 apt
>
> Hi Nick and apt people,
>
> I see in binwalk control file:
>
> Depends: libmagic1, python-lzma, python-lzo, python-matplotlib,
> python-numpy, python-opengl, python-pyqtgraph, python-qt4, python-qt4
> -gl, python-scipy, ${misc:Depends}, ${python:Depends}
> Recommends: arj, bzip2, cramfsprogs, cramfsswap, gzip, mtd-utils,
> ncompress, p7zip, p7zip-full, sleuthkit, squashfs-tools, tar
>
>
> So I think we already have something minimal as depends.
>
What I am reporting is not a bug in apt at all. If you've seen one,
it's a separate issue.
Why depend on python-matplotlib, python-numpy, python-opengl, python
-pyqtgraph, python-qt4, python-qt4-gl, python-scipy?
One issue is python-pyqtgraph depending on python-pyside | python-qt4
Since binwalk already depends on python-qt4, we get both.
python-pyside brings in python-pyside.phonon, which brings in phonon,
which by default brings in phonon-backend-vlc, which brings in vlc etc.
etc.
Getting rid of python-pyside manually gets rid of a heap of the
unnecessary stuff. But given that the graphical stuff is not apparently
required by binwalk for its core functionality, and does cause massive
dep bloat, why depend on any of it?
Cheers,
Nick
--
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago
Bug#810140: binwalk: unnecessary(?) deps make binwalk useless on minimal systems
On Wed, 2016-01-06 at 23:29 +, Gianfranco Costamagna wrote: > sure, I removed it, and changed the order for pyqtgraph, since > binwalk seems to actually need > just qt4 and it is a lot less heavy than pyside. > > With the two uploads this bug should be fixed. Is it not possible to turn the deps on python-matplotlib, python -opengl, python-pyqtgraph, python-qt4, python-qt4-gl, and perhaps python-numpy and python-scipy all into recommends as well? (given that that's what binwalk upstream appears to suggest) To me, it seems that the likes of arj, bzip2, cramfsprogs, cramfsswap, gzip, mtd-utils, ncompress, p7zip, p7zip-full, sleuthkit, squashfs -tools, tar have a far better claim to be "depends" than any of those (supposedly optional) libs that are currently "depends", as they are needed for binwalk's core functionality, while the qt stuff is only needed if you want to do graphing. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#810141: libvirt-daemon-system postinst tries to touch files in nonexistent dirs
Package: libvirt-daemon-system Version: 1.2.9-9+deb8u1 Severity: normal On upgrade from wheezy to jessie, libvirt-daemon-system failed to complete installation - postinst was trying to touch /var/log/libvirt/uml/.placeholder and /var/log/libvirt/lxc/.placeholder - when neither of those directories exist. Had to manually create dirs in order for postinst to complete. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/24 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libvirt-daemon-system depends on: ii adduser 3.113+nmu3 ii gettext-base 0.19.3-2 ii init-system-helpers 1.22 ii libapparmor1 2.9.0-3 ii libaudit11:2.4-1+b1 ii libavahi-client3 0.6.31-5 ii libavahi-common3 0.6.31-5 ii libblkid12.25.2-6 ii libc62.19-18+deb8u1 ii libcap-ng0 0.7.4-2 ii libdbus-1-3 1.8.20-0+deb8u1 ii libdevmapper1.02.1 2:1.02.90-2.2 ii libgnutls-deb0-283.3.8-6+deb8u3 ii libnl-3-200 3.2.24-2 ii libnl-route-3-2003.2.24-2 ii libnuma1 2.0.10-1 ii librados20.80.7-2 ii librbd1 0.80.7-2 ii libsasl2-2 2.1.26.dfsg1-13+deb8u1 ii libselinux1 2.3-2 ii libssh2-11.4.3-4.1 ii libsystemd0 215-17+deb8u2 ii libvirt-clients 1.2.9-9+deb8u1 ii libvirt-daemon 1.2.9-9+deb8u1 ii libvirt0 1.2.9-9+deb8u1 ii libxml2 2.9.1+dfsg1-5+deb8u1 ii libyajl2 2.1.0-2 ii logrotate3.8.7-1+b1 ii policykit-1 0.105-8 Versions of packages libvirt-daemon-system recommends: ii bridge-utils 1.5-9 ii dmidecode 2.12-3 ii dnsmasq-base 2.72-3+deb8u1 ii ebtables 2.0.10.4-3 ii iproute2 3.16.0-2 ii iptables 1.4.21-2+b1 ii parted3.2-7 ii pm-utils 1.4.1-15 Versions of packages libvirt-daemon-system suggests: pn apparmor pn auditd pn radvd ii systemd215-17+deb8u2 pn systemtap -- Configuration Files: /etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf' -- no debconf information
Bug#810140: binwalk: unnecessary(?) deps make binwalk useless on minimal systems
Package: binwalk Version: 2.0.1+dfsg-1 Severity: normal Hi... Just tried to install binwalk on a bunch of headless systems. The quantity of deps pulled in made it impossible on at least one system, and undesirable on others. Given that the binwalk install.md states that besides a Python interpreter, all deps are optional, would it be possible to make the qt & graphical libs into recommends? Most use of binwalk is likely just "binwalk fwimage", and does not need pyqtgraph etc., and pulling it all - qt libs, extraneous python libs, vlc, gstreamer plugins... - in makes the package unusable in at least some cases. Cheers, Nick -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (990, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/24 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages binwalk depends on: ii libc6 2.19-18+deb8u1 ii libmagic1 1:5.22+15-2 ii python 2.7.9-1 ii python-matplotlib 1.4.2-3.1 ii python-opengl 3.0.2-1 ii python-pyqtgraph 0.9.8-3 ii python-qt4 4.11.2+dfsg-1 ii python-qt4-gl 4.11.2+dfsg-1 Versions of packages binwalk recommends: ii arj3.10.22-13 ii bzip2 1.0.6-7+b3 ii mtd-utils 1:1.5.1-1 ii ncompress 4.2.4.4-9 pn openjdk-7-jdk | openjdk-8-jdk ii p7zip 9.20.1~dfsg.1-4.1+deb8u1 ii p7zip-full 9.20.1~dfsg.1-4.1+deb8u1 binwalk suggests no packages. -- no debconf information
Bug#799037: read-edid: get-edid hangs on Mac Mini 4,1
Package: read-edid
Version: 3.0.1-2
Severity: normal
get-edid hangs (using 100% CPU) on this Mac Mini 4,1. Philips 170B LCD monitor
is connected via
Apple HDMI->DVI adapter. X is not running. This is a particular PITA as
ocsinventory-agent
tries to use get-edid, and gradually gets the fans going faster and faster...
More info follows.
Cheers,
Nick
Last part of strace output is:
write(2, "Looks like no busses have an EDI"..., 42Looks like no busses have an
EDID. Sorry!
) = 42
write(2, "Attempting to use the classical "..., 46Attempting to use the
classical VBE interface
) = 46
open("/dev/zero", O_RDWR) = 3
mmap(0x1000, 655360, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0) = 0x1000
close(3)= 0
open("/dev/mem", O_RDWR)= 3
mmap(NULL, 1282, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3, 0) = 0
mmap(0xa, 393216, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED|MAP_FIXED, 3,
0xa) = 0xa
close(3)= 0
ioperm(0, 0x400, 0x1) = 0
iopl(0x3) = 0
write(2, "\n\tPerforming real mode VBE call\n", 32
Performing real mode VBE call
) = 32
write(2, "\tInterrupt 0x10 ax=0x4f00 bx=0x0"..., 40Interrupt 0x10
ax=0x4f00 bx=0x0 cx=0x0
) = 40
lspci gives:
00:00.0 Host bridge: NVIDIA Corporation MCP89 HOST Bridge (rev a1)
Flags: bus master, 66MHz, fast devsel, latency 0
00:00.1 RAM memory: NVIDIA Corporation MCP89 Memory Controller (rev a1)
Flags: bus master, 66MHz, fast devsel, latency 0
00:01.0 RAM memory: NVIDIA Corporation Device 0d6d (rev a1)
Flags: 66MHz, fast devsel
00:01.1 RAM memory: NVIDIA Corporation Device 0d6e (rev a1)
Flags: 66MHz, fast devsel
00:01.2 RAM memory: NVIDIA Corporation Device 0d6f (rev a1)
Flags: 66MHz, fast devsel
00:01.3 RAM memory: NVIDIA Corporation Device 0d70 (rev a1)
Flags: 66MHz, fast devsel
00:02.0 RAM memory: NVIDIA Corporation Device 0d71 (rev a1)
Flags: 66MHz, fast devsel
00:02.1 RAM memory: NVIDIA Corporation Device 0d72 (rev a1)
Flags: 66MHz, fast devsel
00:03.0 ISA bridge: NVIDIA Corporation MCP89 LPC Bridge (rev a2)
Subsystem: Apple Inc. Device cb89
Flags: bus master, 66MHz, fast devsel, latency 0
I/O ports at 2100 [size=256]
00:03.1 RAM memory: NVIDIA Corporation MCP89 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:03.2 SMBus: NVIDIA Corporation MCP89 SMBus (rev a1)
Subsystem: NVIDIA Corporation Device cb89
Flags: 66MHz, fast devsel
I/O ports at 2000 [disabled] [size=256]
Memory at d3586000 (32-bit, non-prefetchable) [disabled] [size=8K]
I/O ports at 2240 [disabled] [size=64]
I/O ports at 2200 [disabled] [size=64]
Capabilities: [44] Power Management version 2
00:03.3 RAM memory: NVIDIA Corporation MCP89 Memory Controller (rev a1)
Flags: 66MHz, fast devsel
00:03.4 Co-processor: NVIDIA Corporation MCP89 Co-Processor (rev a1)
Subsystem: NVIDIA Corporation Device cb89
Flags: bus master, 66MHz, fast devsel, latency 0
Memory at d350 (32-bit, non-prefetchable) [size=512K]
00:04.0 USB controller: NVIDIA Corporation MCP89 OHCI USB 1.1 Controller (rev
a1) (prog-if 10 [OHCI])
Subsystem: NVIDIA Corporation Device cb89
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17
Memory at d358a000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Kernel driver in use: ohci-pci
00:04.1 USB controller: NVIDIA Corporation MCP89 EHCI USB 2.0 Controller (rev
a2) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation Device cb89
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
Memory at d358b100 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=00a0
Capabilities: [80] Power Management version 2
Kernel driver in use: ehci-pci
00:06.0 USB controller: NVIDIA Corporation MCP89 OHCI USB 1.1 Controller (rev
a1) (prog-if 10 [OHCI])
Subsystem: NVIDIA Corporation Device cb89
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 18
Memory at d3589000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Kernel driver in use: ohci-pci
00:06.1 USB controller: NVIDIA Corporation MCP89 EHCI USB 2.0 Controller (rev
a2) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation Device cb89
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at d358b000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=00a0
Capabilities: [80] Power Management version 2
Kernel driver in use: ehci-pci
00:08.0 Audio device: NVIDIA Corporation MCP89 High Definition Audio (rev a2)
Subsystem: NVIDIA
Bug#780998: Info received (Problem only applies to Emacs)
Amusingly, as I settled in this morning to work out what was actually causing this problem, everything now works. Between the failing and succeeding, there have been: ubuntu updates reboot logging in and out with Gnome Classic Unity before back to Gnome Fingers crossed it stays working. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#780998: Problem only applies to Emacs
Investigating a little further, it seems that Emacs is not the only X client affected. So far though, meld is the only other app I've found that is affected in a similar (although more severe) manner. Haven't yet had a chance to try other combinations of OS on each end with meld (affected = Ubuntu X server, meld on Debian over ssh). Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#780998: Emacs fails to resize with remote X session
Additional info here - this only seems to be a problem (for me) when the remote machine is running Jessie's Emacs24 and the client is running Ubuntu. My desktop is running Ubuntu 15.04. When the remote machine is running Emacs24 on wheezy (emacs-snapshot package from BPO version 2:20140701-1~bpo70+1) the window resizes fine. When the remote host is running Emacs24 on Jessie (emacs24 package version 24.4+1-5), problem is present. When the client is a Raspberry Pi running their version of wheezy, there is no problem resizing emacs24 running remotely on either Ubuntu 15.04 or Jessie. I'm sorry, I don't have a vanilla Wheezy or Jessie desktop to test as client. Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#734530: Still not fixed I see...
Does this help clarify?
Cheers,
Nick
--
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago
Index: ocsinventory-agent-2.0.5/lib/Ocsinventory/Agent/Backend/OS/Generic/Screen.pm
===
--- ocsinventory-agent-2.0.5.orig/lib/Ocsinventory/Agent/Backend/OS/Generic/Screen.pm 2012-04-02 02:12:25.0 +1200
+++ ocsinventory-agent-2.0.5/lib/Ocsinventory/Agent/Backend/OS/Generic/Screen.pm 2015-03-24 12:23:21.475677751 +1300
@@ -607,12 +607,35 @@
eval use MIME::Base64;;
$base64 = encode_base64($raw_edid) if !$@;
- if (can_run(uuencode)) {
-chomp($uuencode = `echo $raw_edid|uuencode -`);
-if (!$base64) {
- chomp($base64 = `echo $raw_edid|uuencode -m -`);
-}
+
+ $uuencode = begin 644 -\n;
+ while ($raw_edid =~ m/\G(.{1,45})/sgc) {
+ $uuencode .= pack(u, $1);
}
+ $uuencode .= `\nend;
+
+ if (!$base64) {
+ $base64 = ;
+ my ($string, $mod3, $enc);
+ $raw_edid = $raw_edid . ;
+ while ($raw_edid =~ m/\G(.{1,45})/sgc) {
+ $string = $1;
+ $mod3 - length($string) % 3;
+ $string .= \0, $mod3 -= 3 if $mod3;
+ $enc = pack(u, $string);
+ $enc =~ s/.//;
+ $enc =~ tr#`!-_#A-Za-z0-9+/#;
+ substr($enc, $mod3) =~ tr/A/=/;
+ $base64 .= $enc;
+ }
+ }
+
+# if (can_run(uuencode)) {
+#chomp($uuencode = `echo $raw_edid|uuencode -`);
+#if (!$base64) {
+# chomp($base64 = `echo $raw_edid|uuencode -m -`);
+#}
+# }
$common-addMonitors ({
BASE64 = $base64,
Bug#775307: grml-debootstrap error exit with status 0
Package: grml-debootstrap Version: 0.68 Severity: normal After being incorrectly invoked, grml-debootstrap gives usage information then exits with exit 0. Exit status should not be 0 after an error. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-0.bpo.4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages grml-debootstrap depends on: ii debian-archive-keyring 2014.3~deb7u1 ii debootstrap 1.0.48+deb7u2 ii gawk1:4.0.1+dfsg-2.1 Versions of packages grml-debootstrap recommends: ii dialog 1.1-20120215-2 ii kpartx 0.4.9+git0.4dfdaf2b-7~deb7u2 ii mksh40.9.20120630-7 ii parted 2.3-12 ii qemu-utils 1.1.2+dfsg-6a+deb7u6 grml-debootstrap 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#770425: Possibility of update to 4.x
On Sat, 2014-11-29 at 14:53 +1100, Craig Small wrote: Hi Nick, The security update will only be 3.6.1 with the 4.7.4-4.7.5 patches. It's difficult balancing act really but the whole purpose of the security updates is just to update for security. It's not ideal for certain situations. The proposed update went to the security team a few minutes ago and should mean an update for wordpress in wheezy will be out today. Thanks for that. Doesn't actually concern me which solution was picked, as long as one was chosen and implemented reasonably quickly (I'll stick with the 4.x packages I now have anyway). Cheers, Nick -- Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#770425: Dependencies
Seems that the only new dep in 4.0.1 (besides the themes, which should probably be re-merged if taking this route) is on ca-certificates. In a pbuilder vanilla wheezy chroot, just installed current stable wordpress, then replaced with the built version and 3 themes using dpkg. Only extra package needed was ca-certificates. Which, obviously, is in stable. Craig - if you're going to do the work on backporting the fixes, you might also consider the likelihood of there being further such fixes required during the stable security support window. In this case already, the delay in getting a fixed version into the archive is probably long enough for these issues to be being exploited. Is there any reason to think we'd be able to be quicker next time? Cheers, Nick -- Nick Phillips / n...@debian.org / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#770425: Possibility of update to 4.x
FYI... * 4.0.1+dfsg-1 appears to build fine with a wheezy-only pbuilder. * Review at http://premium.wpmudev.org/blog/wordpress-4-0-hugely-underwhelming/ claims that The fact is, users who upgrade to 4.0 when it’s released on August 27 won’t even realize there are any changes. It's worked smoothly on 2 out of 3 of my machines. The other relied on customisations in /etc/wordpress/wp-config.php (which warns you not to make changes, despite being a config file). Issues: * New package splits out the themes into separate packages. * New package no longer links /usr/share/wordpress/wp-config.php to /etc/wordpress/wp-config.php - customisations there will be ignored until admin intervenes. Both of these issues could fairly easily be reverted to old behaviour, I think. Cheers, Nick -- Nick Phillips / n...@debian.org / 03 479 4195 # These statements are mine, not those of the University of Otago
Bug#765035: python-urllib3: Incorrect version for build-dep on python-nose
Package: python-urllib3 Version: 1.9.1-1 Severity: normal In trying to build urllib3 on wheezy, I've found that it appears to require a version of nose with nose.__main__ - from github, this appears to mean 1.3.3 and up; 1.1.2 is no good. Cheers, Nick -- System Information: Debian Release: 7.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) 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#734530: ocsinventory-agent: Quote in EDID causes failure
Package: ocsinventory-agent Version: 2:2.0.5-1 Severity: normal It seems that if raw EDID info from whatever monitor is connected to the system on which the OCSI Agent is running contains a double-quote character, the agent is unable to successfully communicate with the server. The cause is the inadequate escaping of the raw EDID when trying to pipe it to uuencode in /usr/share/perl5/Ocsinventory/Agent/Backend/OS/Generic/Screen.pm This results in incorrect output from the uuencode command, hence invalid XML being submitted to the server, and failure of the agent submission. -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ocsinventory-agent depends on: ii debconf [debconf-2.0] 1.5.49 ii libnet-ip-perl1.25-3 ii libnet-ssleay-perl1.48-1+b1 ii libproc-daemon-perl 0.14-1 ii libwww-perl 6.04-1 ii libxml-simple-perl2.20-1 ii perl [libcompress-zlib-perl] 5.14.2-21+deb7u1 ii po-debconf1.0.16+nmu2 ii ucf 3.0025+nmu3 Versions of packages ocsinventory-agent recommends: ii dmidecode 2.11-9 ii hdparm 9.39-1+b1 ii pciutils 1:3.1.9-6 Versions of packages ocsinventory-agent suggests: ii nmap 6.00-0.3+deb7u1 ii read-edid 2.0.0-3.1 pn smartmontools none -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734530: Acknowledgement (ocsinventory-agent: Quote in EDID causes failure)
I'd suggest something like:
$uuencode = begin 644 -\n;
while ($raw_edid =~ m/\G(.{1,45})/sgc) {
$uuencode .= pack(u, $1);
}
$uuencode .= `\nend;
to generate the UUencoded string (adapted from Convert::UU)
and:
if (!$base64) {
$base64 = ;
my ($string, $mod3, $enc);
$raw_edid = $raw_edid . ;
while ($raw_edid =~ m/\G(.{1,45})/sgc) {
$string = $1;
$mod3 - length($string) % 3;
$string .= \0, $mod3 -= 3 if $mod3;
$enc = pack(u, $string);
$enc =~ s/.//;
$enc =~ tr#`!-_#A-Za-z0-9+/#;
substr($enc, $mod3) =~ tr/A/=/;
$base64 .= $enc;
}
}
to replace the use of uuencode to generate the Base64-encoded string -
if anyone cares about the possible absence of MIME::Base64 these days.
That (Screen.pm) isn't the only use of uuencode; I think I saw one
other. Will be worth replacing that too just for efficiency, even if
there's no chance of problems passing input to it.
Cheers,
Nick
--
Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz
Faculty of Medicine, University of Otago
Bug#718460: libpq5 not thread-safe
Package: libpq5
Version: 9.1.9-1
Severity: normal
Tags: patch upstream
I've had crashes with glibc detecting double free/memory corruption through
mod_wsgi, Django, psycopg2, libpq, libssl.
Turns out that libpq is not thread-safe; it uses a global SSL_context and
does not protect its use of it appropriately, resulting in crashes in
libssl.
The point at which it had been affecting me was during the call to
SSL_CTX_use_certificate_chain_file in initialize_SSL in fe-secure.c
There are several further vulnerable uses of SSL_context later within that
function; the patch I'm attaching protects all of them using a single
call to pthread_mutex_lock -- I've not bothered to investigate whether
the subsequent uses of SSL_context are such that they require the context
not be modified by other threads in the interim, or whether it would be
safe to protect each use separately. I don't think the gain from doing
so would be significant anyway, as this section of code is only used once
during each connection setup.
While I am using postgres 9.1 from wheezy, I note that this issue is not
fixed in current postgres 9.3 beta2 upstream.
Cheers,
Nick
-- System Information:
Debian Release: 7.1
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libpq5 depends on:
ii libc6 2.13-38
ii libcomerr21.42.5-1.1
ii libgssapi-krb5-2 1.10.1+dfsg-5+deb7u1
ii libkrb5-3 1.10.1+dfsg-5+deb7u1
ii libldap-2.4-2 2.4.31-1+nmu2
ii libssl1.0.0 1.0.1e-2
libpq5 recommends no packages.
libpq5 suggests no packages.
-- no debconf information
=== patch follows
Description: libpq thread safety fix
Protect libpq use of global SSL_context with mutex.
Author: Nick Phillips n...@debian.org
Forwarded: no
Last-Update: 2013-08-01
--- postgresql-9.1-9.1.9.orig/src/interfaces/libpq/fe-secure.c
+++ postgresql-9.1-9.1.9/src/interfaces/libpq/fe-secure.c
@@ -1089,6 +1089,10 @@ initialize_SSL(PGconn *conn)
* sslcert settings are used for different connections in the
same
* process.
*/
+#ifdef ENABLE_THREAD_SAFETY
+ if (pthread_mutex_lock(ssl_config_mutex))
+ return -1;
+#endif
if (SSL_CTX_use_certificate_chain_file(SSL_context, fnbuf) != 1)
{
char *err = SSLerrmessage();
@@ -1097,6 +1101,9 @@ initialize_SSL(PGconn *conn)
libpq_gettext(could not read certificate file
\%s\: %s\n),
fnbuf, err);
SSLerrfree(err);
+#ifdef ENABLE_THREAD_SAFETY
+ pthread_mutex_unlock(ssl_config_mutex);
+#endif
return -1;
}
if (SSL_use_certificate_file(conn-ssl, fnbuf,
SSL_FILETYPE_PEM) != 1)
@@ -1107,6 +1114,9 @@ initialize_SSL(PGconn *conn)
libpq_gettext(could not read certificate file
\%s\: %s\n),
fnbuf, err);
SSLerrfree(err);
+#ifdef ENABLE_THREAD_SAFETY
+ pthread_mutex_unlock(ssl_config_mutex);
+#endif
return -1;
}
/* need to load the associated private key, too */
@@ -1145,6 +1155,9 @@ initialize_SSL(PGconn *conn)
engine_str,
err);
SSLerrfree(err);
free(engine_str);
+#ifdef ENABLE_THREAD_SAFETY
+ pthread_mutex_unlock(ssl_config_mutex);
+#endif
return -1;
}
@@ -1159,6 +1172,9 @@ initialize_SSL(PGconn *conn)
ENGINE_free(conn-engine);
conn-engine = NULL;
free(engine_str);
+#ifdef ENABLE_THREAD_SAFETY
+ pthread_mutex_unlock(ssl_config_mutex);
+#endif
return -1;
}
@@ -1176,6 +1192,9 @@ initialize_SSL(PGconn *conn)
ENGINE_free(conn-engine);
conn-engine = NULL;
free(engine_str);
+#ifdef ENABLE_THREAD_SAFETY
+ pthread_mutex_unlock(ssl_config_mutex);
+#endif
return -1;
}
if (SSL_use_PrivateKey(conn-ssl, pkey) != 1)
@@ -1190,6 +1209,9 @@ initialize_SSL(PGconn *conn)
ENGINE_free(conn-engine);
conn-engine = NULL
Bug#701933: smbclient: smbget uses incorrect auth info on recursive get
Package: smbclient Version: 2:3.5.6~dfsg-3squeeze9 Severity: normal Client machine is in a workgroup. Server is in a domain. When attempting to recursively download from a share on the server, the client uses correct auth information to get the directory listing, then attempts to reauthenticate to actually get the files - using incorrect auth info. Specifically, it tries to authenticate using the client machine's workgroup instead of the domain specified with -w on the command line. Reading through libsmb, it appears that it shouldn't even be trying to reconnect in the first place, but should be using a cached connection (which it looks like it fails to identify as being appropriate because it thinks the auth info doesn't match). -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages smbclient depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcap2 1:2.19-3 support for getting/setting POSIX. ii libcomerr21.41.12-4stable1 common error description library ii libgssapi-krb5-2 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries - k ii libk5crypto3 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries - C ii libkrb5-3 1.8.3+dfsg-4squeeze6 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.23-7.3 OpenLDAP libraries ii libpopt0 1.16-1 lib for parsing cmdline parameters ii libreadline6 6.1-3 GNU readline and history libraries ii libtalloc22.0.1-1hierarchical pool based memory all ii libwbclient0 2:3.5.6~dfsg-3squeeze9 Samba winbind client library ii samba-common 2:3.5.6~dfsg-3squeeze9 common files used by both the Samb ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime smbclient recommends no packages. Versions of packages smbclient suggests: pn cifs-utilsnone (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#690190: virt-what fails to detect running on xen domU
Package: virt-what Version: 1.2-1 Severity: normal Running on a domU under a Xen 4.0.1 hypervisor, virt-what gives no output, indicating that it believes it is running on bare metal. -- System Information: Debian Release: 6.0.5 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/1 CPU core) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virt-what depends on: ii dmidecode 2.9-1.2Dump Desktop Management Interface ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib virt-what recommends no packages. virt-what 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#629590: Oops...
Sorry, didn't see this until just now - think I need to update my mail forwarding! Which version of apt-get is that? No longer sure, but it seems that I noticed it change between June and July last year (2011) - may have been lenny version that worked and squeeze that doesn't? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago
Bug#629590: oops...
Initial command line described as failing should have started with aptitude, not apt-get! I note that it seems apt-get may now also be exhibiting this behaviour; perhaps it has now been compiled against the same library version that aptitude already had? Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629590: aptitude: Fails to obey '-o #clear DPkg::Pre-Install-Pkgs;'
Package: aptitude
Version: 0.6.3-3.2
Severity: normal
The command line:
apt-get -q -y -o #clear DPkg::Pre-Install-Pkgs; install somepkg
still causes dpkg-preconfigure to be used to preconfigure packages, when the
line:
DPkg::Pre-Install-Pkgs {/usr/sbin/dpkg-preconfigure --apt || true;};
is present in /etc/apt/apt.conf.d/70debconf
The equivalent invocation of apt-get successfully inhibits the preconfiguration.
I note that:
apt-config -o #clear DPkg::Pre-Install-Pkgs; dump
fails to parse the option and barfs, insisting that the option must contain an
=.
Perhaps this is related?
Cheers,
Nick
-- Package-specific info:
aptitude 0.6.3 compiled at Oct 16 2010 18:18:04
Compiler: g++ 4.4.5
Compiled against:
apt version 4.10.1
NCurses version 5.7
libsigc++ version: 2.2.4.2
Ept support enabled.
Gtk+ support disabled.
Current library versions:
NCurses version: ncurses 5.7.20100313
cwidget version: 0.5.16
Apt version: 4.10.1
linux-vdso.so.1 = (0x7fff09fff000)
libapt-pkg.so.4.10 = /usr/lib/libapt-pkg.so.4.10 (0x7f1c28d92000)
libncursesw.so.5 = /lib/libncursesw.so.5 (0x7f1c28b3f000)
libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f1c28939000)
libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f1c2866d000)
libept.so.1 = /usr/lib/libept.so.1 (0x7f1c28419000)
libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f1c28038000)
libz.so.1 = /usr/lib/libz.so.1 (0x7f1c27e21000)
libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0x7f1c27b8a000)
libboost_iostreams.so.1.42.0 = /usr/lib/libboost_iostreams.so.1.42.0
(0x7f1c2796e000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f1c27752000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f1c2743e000)
libm.so.6 = /lib/libm.so.6 (0x7f1c271bb000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f1c26fa5000)
libc.so.6 = /lib/libc.so.6 (0x7f1c26c44000)
libutil.so.1 = /lib/libutil.so.1 (0x7f1c26a4)
libdl.so.2 = /lib/libdl.so.2 (0x7f1c2683c000)
libuuid.so.1 = /lib/libuuid.so.1 (0x7f1c26637000)
libbz2.so.1.0 = /lib/libbz2.so.1.0 (0x7f1c26427000)
librt.so.1 = /lib/librt.so.1 (0x7f1c2621f000)
/lib64/ld-linux-x86-64.so.2 (0x7f1c290ae000)
Terminal: xterm
$DISPLAY is set.
`which aptitude`: /usr/bin/aptitude
aptitude version information:
aptitude linkage:
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages aptitude depends on:
ii apt [libapt-pkg4.10]0.8.10.3 Advanced front-end for dpkg
ii libboost-iostreams1.42. 1.42.0-4 Boost.Iostreams Library
ii libc6 2.11.2-10Embedded GNU C Library: Shared lib
ii libcwidget3 0.5.16-3 high-level terminal interface libr
ii libept1 1.0.4High-level library for managing De
ii libgcc1 1:4.4.5-8GCC support library
ii libncursesw55.7+20100313-5 shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.2.4.2-1type-safe Signal Framework for C++
ii libsqlite3-03.7.3-1 SQLite 3 shared library
ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3
ii libxapian22 1.2.3-2 Search engine library
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages aptitude recommends:
ii apt-xapian-index 0.41 maintenance and search tools for a
ii aptitude-doc-en [aptitude-doc 0.6.3-3.2 English manual for aptitude, a ter
ii libparse-debianchangelog-perl 1.1.1-2.1 parse Debian changelogs and output
ii sensible-utils0.0.4 Utilities for sensible alternative
Versions of packages aptitude suggests:
pn debtags none (no description available)
ii tasksel 2.88 Tool for selecting tasks for insta
-- 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#626998: xen-tools: Over-zealous response to --admins option
Package: xen-tools Version: 4.2-1 Severity: normal xt-create-xen-config (called from xen-create-image) either creates a user or changes an existing user's shell, and modifies /etc/sudoers, when the --admins option is given. It appears that there is no longer any way to merely add the required information (the admins config line) into the xen config, which is I would expect to be what most users would want. While the ability to create users/change shells/add to sudoers may be nice to have, doing it by default when admins are specified certainly violates the principle of least surprise. At the very least, there should be an option to create the xen image and config file without damag^Wmodifying the rest of the system. Cheers, Nick -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages xen-tools depends on: ii debootstrap 1.0.26+squeeze1 Bootstrap a basic Debian system ii libconfig-inifiles-perl 2.52-1 Read .ini-style configuration file ii libfile-slurp-perl .13-1 single call read write file rout ii libtext-template-perl1.45-1 Text::Template perl module ii perl-modules 5.10.1-17 Core Perl modules Versions of packages xen-tools recommends: ii libexpect-perl1.20-2 Expect.pm - Perl Expect interface ii rinse 1.7-1 RPM installation environment ii xen-hypervisor-3.2-1-amd64 [x 3.2.1-2The Xen Hypervisor on AMD64 ii xen-hypervisor-4.0-amd64 [xen 4.0.1-2The Xen Hypervisor on AMD64 ii xen-shell 1.8-3 Console based Xen administration u Versions of packages xen-tools suggests: pn btrfs-tools none (no description available) pn cfengine2 none (no description available) pn evms-cli none (no description available) pn reiserfsprogs none (no description available) ii xen-utils-4.0 [xen-utils] 4.0.1-2XEN administrative tools ii xfsprogs 3.1.4 Utilities for managing the XFS fil -- Configuration Files: /etc/xen-tools/xen-tools.conf changed [not included] -- 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#584076: wbritish-huge: irregardless is not a word
Package: wbritish-huge Version: 6-2.3 Severity: normal irregardless is not a word and should not be included in word lists which might be used to verify whether or not any given word is valid. -- System Information: Debian Release: 5.0.4 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages wbritish-huge depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii dictionaries-common 0.98.12Common utilities for spelling dict wbritish-huge recommends no packages. wbritish-huge suggests no packages. -- debconf information: wbritish-huge/languages: british-huge (British English -- huge) shared/packages-wordlist: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516223: Bother.
I think I had been looking at the PCI ID list at http://cateee.net/lkddb/web-lkddb/HW_RANDOM_INTEL.html or somewhere similar, and thinking that therefore the 244e device listed by lspci would have the hwrng. However, 244e appears to actually be commented out in the source of intel_rng, so perhaps there is some issue with this particular hardware. I can't (yet) find anything definitive though. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516223: more...
Looking at another system and again at the intel_rng source, I see that the first device listed in each section in the source is commented, and that the other system we have has both the 244e and ISA bridge [0601]: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller [8086:2670] (rev 09) which is on the list. The equivalent device on the system in question would be the ISA bridge [0601]: Intel Corporation 82801IR (ICH9R) LPC Interface Controller [8086:2916] (rev 02). No idea whether that would actually provide the RNG functionality, although the manual for the Intel S3200SH board (Intel Order Number: E14960-004, sorry didn't note URL, but search for that should find it) suggests that it should. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518264: dpkg-dev: dpkg-genchanges fails to process packages with differing versions
Package: dpkg-dev Version: 1.14.25 Severity: normal Regression from 1.13.26 (etch) - dpkg-genchanges can no longer process packages such as apache that produce binary packages with differing versions. It seems to think it can use the same binary package version for all packages despite different versions being specified in the control file (that is, the control file inside the DEBIAN directory in the built package subdirectory). -- System Information: Debian Release: 5.0 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages dpkg-dev depends on: ii binutils2.18.1~cvs20080103-7 The GNU assembler, linker and bina ii bzip2 1.0.5-1 high-quality block-sorting file co ii cpio2.9-13 GNU cpio -- a program to manage ar ii dpkg1.14.25 Debian package management system ii libtimedate-perl1.1600-9 Time and date functions for Perl ii lzma4.43-14 Compression method of 7z format in ii make3.81-5 The GNU version of the make util ii patch 2.5.9-5 Apply a diff file to an original ii perl [perl5]5.10.0-19Larry Wall's Practical Extraction ii perl-modules5.10.0-19Core Perl modules Versions of packages dpkg-dev recommends: ii build-essential 11.4 Informational list of build-essent ii gcc [c-compiler] 4:4.3.2-2 The GNU C compiler ii gcc-4.1 [c-compiler] 4.1.2-25 The GNU C compiler ii gcc-4.3 [c-compiler] 4.3.2-1.1 The GNU C compiler Versions of packages dpkg-dev suggests: ii debian-keyring2009.01.18 GnuPG (and obsolete PGP) keys of D ii gnupg 1.4.9-3GNU privacy guard - a free PGP rep -- 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#516223: linux-image-2.6.26-1-xen-amd64, linux-image-2.6.26-1-amd64: intel-rng module fails to load
Package: linux-2.6 Version: 2.6.26-13 Severity: normal Using either of the kernel images listed in the subject on an Intel 1CPU 4Core Xeon 1U server, the intel-rng module fails to load: n...@mrslim:/stor/home/nwp$ sudo modprobe intel-rng FATAL: Error inserting intel_rng (/lib/modules/2.6.26-1-xen-amd64/kernel/drivers/char/hw_random/intel-rng.ko): No such device The hardware is there: n...@mrslim:/stor/home/nwp$ lspci -nn 00:00.0 Host bridge [0600]: Intel Corporation 3200/3210 Chipset DRAM Controller [8086:29f0] 00:19.0 Ethernet controller [0200]: Intel Corporation 82566DM-2 Gigabit Network Connection [8086:10bd] (rev 02) 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 02) 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 [8086:2938] (rev 02) 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 [8086:2939] (rev 02) 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 [8086:293c] (rev 02) 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 [8086:2940] (rev 02) 00:1c.4 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 [8086:2948] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 [8086:2934] (rev 02) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 [8086:2935] (rev 02) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 [8086:2936] (rev 02) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 [8086:293a] (rev 02) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 92) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IR (ICH9R) LPC Interface Controller [8086:2916] (rev 02) 00:1f.2 IDE interface [0101]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA IDE Controller [8086:2920] (rev 02) 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus Controller [8086:2930] (rev 02) 00:1f.5 IDE interface [0101]: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller [8086:2926] (rev 02) 02:00.0 VGA compatible controller [0300]: Matrox Graphics, Inc. MGA G200e [Pilot] ServerEngines (SEP1) [102b:0522] (rev 02) 03:02.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet Controller [8086:1076] (rev 05) There appears to be some reference to this problem at: https://bugzilla.redhat.com/show_bug.cgi?id=215144 ...although it's talking about an older kernel. I haven't (yet?) tried the patch listed there. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages linux-image-2.6.26-1-xen-amd64 depends on: ii initramfs-tools 0.92o tools for generating an initramfs ii linux-modules-2.6.26-1-xen-am 2.6.26-13 Linux 2.6.26 modules on AMD64 linux-image-2.6.26-1-xen-amd64 recommends no packages. Versions of packages linux-image-2.6.26-1-xen-amd64 suggests: ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy v pn linux-doc-2.6.26 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#507512: Fix/workaround in upstream repository
It seems this problem is fixed/worked-around by a couple of patches in the upstream git repository. If anyone is interested, the tickets/0.24.x/961 branch (2 commits) causes the connections to be closed before the exec happens. I think the problem will return if keep_alive is ever re-enabled, but it fixes it for now. I can make unofficial packages available to anyone needing them. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507512: Yay, I ran out of FDs.
Now as if to prove my point, I find that I have machines failing in the middle of puppet runs due to lack of FDs. This unfortunately proves the fix in 0.24.6 to be inadequate, as I am running 0.24.7 on the machine in question. Grrr... Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514197: Fwd: Mail delivery failed: returning message to sender
Package: ifmetric Version: 0.3-2 Severity: normal n...@mrslim:/stor/home/nwp$ sudo ifmetric eth1 3 NETLINK: Packet too small or truncated! 92!=16!=244 -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-xen-amd64 (SMP w/4 CPU cores) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ifmetric depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ifmetric recommends no packages. ifmetric suggests no packages. -- no debconf information -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513987: unbound trusts glue that contradicts local data for transparent zone
On 3/02/2009, at 12:10 PM, Nick Phillips wrote: Package: unbound Version: 1.0.2-1 Severity: normal Unbound seems to trust (and pass on to clients) extra/glue data in responses from authoritative servers, even when this extra data contradicts that held locally for a transparent zone. Example: Authoritative server has records: foo.example.com A 192.168.1.1 bar.example.com CNAME a.example.com. Unbound has the following in a transparent zone: foo.example.com A 10.1.1.1 A query to unbound, `dig -t a bar.example.com @unbound ip` receives the answer given by the authoritative server: bar.example.com CNAME a.example.com. foo.example.com A 192.168.1.1 This is at the very least counter-intuitive, at worst - who knows? Looking at it more closely, it appears the extra record is not being helpfully added by the authoritative server and then being passed on by unbound; unbound is explicitly making an extra query for that information (when it already has the correct information in the transparent zone!). Cheers, Nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513987: unbound trusts glue that contradicts local data for transparent zone
Package: unbound Version: 1.0.2-1 Severity: normal Unbound seems to trust (and pass on to clients) extra/glue data in responses from authoritative servers, even when this extra data contradicts that held locally for a transparent zone. Example: Authoritative server has records: foo.example.com A 192.168.1.1 bar.example.com CNAME a.example.com. Unbound has the following in a transparent zone: foo.example.com A 10.1.1.1 A query to unbound, `dig -t a bar.example.com @unbound ip` receives the answer given by the authoritative server: bar.example.com CNAME a.example.com. foo.example.com A 192.168.1.1 This is at the very least counter-intuitive, at worst - who knows? -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-etchnhalf.1-powerpc64 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507512: Leaking FDs
The output I sent is there while waiting for next run; any daemon that has been started by puppet will, unless it explicitly closes extraneous FDs itself when it forks, keep all those FDs open forever. This is bad because it wastes system resources, clutters up the output of lsof, makes it hard to tell what is actually going on on your system etc. It's bad essentially for the same reasons a memory leak is bad, but also gets in the way of seeing what connections your system is actually using. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / nick.phill...@otago.ac.nz # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#502798: xen-tools console annoyance
Surely the real problem here is that /usr/lib/xen-tools/lenny.d/30- disable-gettys does not correctly set the console to be on hvc0 by default. The xen-tools.conf supplied states that hvc0 *is* the default for serial_console, but for the current lenny setup, that turns out not to be the case and therefore it doesn't work. Cheers, Nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508403: pbuilder-satisfydepends-experimental doesn't always try higher versions
On 12/12/2008, at 2:40 AM, Junichi Uekawa wrote: That's a very old and initial version of pbuilder-satisfydepends-experimental. I'm not sure what changed since then, and I'm not sure how it's supposed to work. Can you try the newer version? There should be a pbuilder from bpo, and if you are a DD, you should probably have a sid box to develop on anyway... OK, I've moved all the necessary stuff over to a lenny box, and confirm that it works with lenny pbuilder with standard pbuilder-satisfydepends and with pbuilder-satisfydepends-experimental. Amusingly enough the build a dummy package and let aptitude sort it out approach is exactly what I was thinking of as a solution to a similar problem the day before. Now I get to point at pbuilder-satisfydepends as an example solution for the other problem - thanks! :-) Cheers, Nick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508403: pbuilder-satisfydepends-experimental doesn't always try higher versions
Package: pbuilder Version: 0.161 Severity: normal Hi... It seems that this (etch) version of pbuilder-satisfydepends-experimental doesn't actually really work, in that in some situations it will not try using a version of a package from experimental/backports (I've added some extra echoes to help see what's going on): - copying local configuration - mounting /proc filesystem - mounting /dev/pts filesystem - policy-rc.d already exists Obtaining the cached apt archive contents Installing the build-deps - Attempting to parse the build-deps : pbuilder-satisfydepends-experimental,v 1.1 2006/11/06 20:55:12 lool Exp $ - Considering build-dep devscripts (= 2.10.7) - Trying to add devscripts=2.10.35~bpo40+1 Already adding - Considering build-dep quilt - Trying to add quilt Already adding devscripts=2.10.35~bpo40+1 - Considering build-dep patchutils (= 0.2.25) - Trying to add patchutils Already adding devscripts=2.10.35~bpo40+1 quilt - Considering build-dep debhelper (= 5.0.44) - Trying to add debhelper=7.0.15~bpo40+2 Already adding devscripts=2.10.35~bpo40+1 quilt patchutils APT_ADD_COMMAND is 'man-db=2.5.2-2~bpo40+1' - Trying to add debhelper=7.0.15~bpo40+2 man-db=2.5.2-2~bpo40+1 Already adding devscripts=2.10.35~bpo40+1 quilt patchutils APT_ADD_COMMAND is '' - Loop detected, last APT error was: == Reading package lists... Building dependency tree... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: debhelper: Conflicts: quilt ( 0.46-5) but 0.45-6 is to be installed E: Broken packages - = - (not adding to debhelper=7.0.15~bpo40+2 man-db=2.5.2-2~bpo40+1) - Cannot install debhelper=7.0.15~bpo40+2 man-db=2.5.2-2~bpo40+1; apt errors follow: Reading package lists... Done Building dependency tree... Done E: Version '7.0.15~bpo40+2 man-db=2.5.2-2~bpo40+1' for 'debhelper' was not found E: Could not satisfy build-dependency. E: pbuilder-satisfydepends failed. Since at the time it found the quilt dependency it was unaware that it needed the bpo version, it chucked vanilla quilt in the install list. When it subsequently found that the old version was unsatisfactory, it didn't try the newer version. I don't know whether the newer versions of pbuilder deal with this better (I suspect the aptitude-style satisfydepends might handle it?), but it looks like it would be fairly awkward to fix in the version that I have here. I've also not looked into alternative workarounds yet; maybe I'll just move the build environment over onto a lenny machine :-) In any case, I thought it was something you should be aware of, if you're not already. Cheers, Nick -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-etchnhalf.1-powerpc64 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages pbuilder depends on: ii cdebootstrap0.3.15 Bootstrap a Debian system ii coreutils 5.97-5.3 The GNU core utilities ii debianutils 2.17 Miscellaneous utilities specific t ii debootstrap 0.3.3.2etch1 Bootstrap a basic Debian system ii gcc 4:4.1.1-15 The GNU C compiler ii wget1.10.2-2 retrieves files from the web Versions of packages pbuilder recommends: ii cowdancer0.25Copy-on-write directory tree utili ii devscripts 2.10.35~bpo40+1 scripts to make the life of a Debi ii fakeroot 1.5.10 Gives a fake root environment ii sudo 1.6.8p12-4 Provide limited super user privile -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507512: puppet: Puppet 0.24.5 leaks FDs into managed daemons
Package: puppet Version: 0.24.5-2.0nwp-etch0 Severity: normal Puppet 0.24.5 leaks FDs (e.g. sockets used for communication with the puppetmaster!) when starting/restarting services. Try running `lsof -i | grep 8140` on a machine managing services with puppet. This is apparently fixed upstream in 0.24.6 (commit 923fd89). IMHO this would be worth shoehorning into lenny. Cheers, Nick -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.24-etchnhalf.1-powerpc64 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages puppet depends on: ii adduser3.102 Add and remove users and groups ii facter 1.3.5-1 a library for retrieving facts fro ii libopenssl-ruby1.0.0+ruby1.8.2-1 OpenSSL interface for Ruby ii libshadow-ruby1.8 1.4.1-7 Interface of shadow password for R ii libxmlrpc-ruby 1.8.2-1 XML-RPC support for Ruby ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii ruby 1.8.2-1 An interpreter of object-oriented Versions of packages puppet recommends: ii rdoc 1.8.2-1Generate documentation from ruby s -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486590: FTBFS: versioned build-dep on cdbs required
Package: libwibble Version: 0.1.17 Severity: normal It appears that libwibble actually requires cdbs = 0.4.50, or possibly 0.4.51 to build. Those of us who are having nightmare toolchain issues trying to do backports would appreciate it if you would add versions to build-depends at times like this ;-/ Cheers, Nick -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-powerpc64 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486439: debhelper appears to need build-dep on file
Package: debhelper Version: 7.0.10 Severity: normal When building debhelper 7.0.10 in a pbuilder chroot with minimal debootstrap + build-essential, debhelper build produces lots of error messages relating to the lack of the file command. It seems that dh_strip and dh_shlibdeps are trying to use it. I'm not sure that this matters (is there anything to strip in there anyway? are there any shlibdeps?) - but if not it would be nice to avoid generating all the error messages, or at least to indicate that they are harmless. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484724: Well...
...it seems that the fix for this bug in 0.24.4-8 (not sure which version it was introduced in; somewhere between -4 and -8) breaks allowdupe for groups; I think the chunk: if @resource[:allowdupe] == :true param == :uid cmd -o end in lib/provider/nameservice/objectadd.rb needs to do the same or similar when gid is being set. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484724: Info received (Well...)
Gah. It's more complicated than that. Puppet must specify -o when you're specifying a UID and modifying a user, or when you're specifying a GID and modifying a group, and not e.g. when you specify a GID but are modifying a user. I think this means that the useradd and groupadd providers should override the nameservice/objectadd modifycmd appropriately. A lot of hassle because usermod/groupmod insist on sucking... ;-) Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484724: Info received (Bug#484724: Info received (Well...))
Filed as ticket #1360 upstream. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484596: closed by Nicolas François [EMAIL PROTECTED] (Re: Bug#484596: passwd: usermod fussy about options in an undocumented manner)
Debian Bug Tracking System wrote: I did not change the documentation. I find the description of -o quite clear. -o, --non-unique When used with the -u option, this option allows to change the user ID to a non-unique value. In 1:4.1.0-1, usermod does not depend on the order of options anymore. That's clear about what happens when you use it along with the -u option, not what happens if you provide it when -u is not present. I'd suggest it should be ignored, as the logic of the -o is maintained that way, and it's not as annoying - I would argue that it is perfectly valid to want to allow duplicate UIDs even when you are not adjusting a UID. This makes me wonder - what does usermod do when the UID is duplicated and it is being asked to e.g. change the GECOS field? Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484724: puppet: User type fails to update GECOS when not also updating UID
Package: puppet Version: 0.24.4-5 Severity: normal Hi... It seems puppet passes incorrect options to usermod when attempting to update GECOS but not make any other changes. The -o option to usermod (to allow duplicate user ids) causes usermod to fail if the -u option is not present (which, when not modifying UID, it is not). It would be fairly simple to either always pass UID to usermod, or to make the use of -o conditional on use of -u, but ruby isn't my strong point so I'll leave it to someone who will make a neater job of it. I think the usermod provider code also fails to quote the contents to be placed in the GECOS field, despite a comment indicating that it is necessary (it is), and similar code elsewhere in puppet doing so. But it could be that it's been sneakily quoted elsewhere and I didn't spot it; as I said, ruby is not my first language ;-) -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-powerpc64 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages puppet depends on: ii adduser3.102 Add and remove users and groups ii facter 1.3.5-1 a library for retrieving facts fro ii libopenssl-ruby1.0.0+ruby1.8.2-1 OpenSSL interface for Ruby ii libshadow-ruby1.8 1.4.1-7 Interface of shadow password for R ii libxmlrpc-ruby 1.8.2-1 XML-RPC support for Ruby ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii ruby 1.8.2-1 An interpreter of object-oriented Versions of packages puppet recommends: ii rdoc 1.8.2-1Generate documentation from ruby s -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484724: Acknowledgement (puppet: User type fails to update GECOS when not also updating UID)
My ruby-reading skills are coming on in leaps and bounds. It appears that this is fixed in the latest version, although I couldn't see anything that looked like it in the changelog. Not sure about the quoting. I guess I'll soon find out. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484596: passwd: usermod fussy about options in an undocumented manner
Package: passwd Version: 1:4.0.18.1-7 Severity: normal It appears that usermod requires certain options to be present in order for certain other options not to cause errors, and that they be present in a certain order. I've noticed that -o causes errors if it appears either without or before -u, for example. a) this is crazy (and breaks other apps which assume that it will behave sensibly) b) this is undocumented Puppet, for example, assumes sensible behaviour and breaks as a result. This is obviously a bug in puppet as well, but does not excuse usermod. Quirks such as this should at least be documented, if not removed. Cheers, Nick -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-5-powerpc64 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages passwd depends on: ii debianutils2.17 Miscellaneous utilities specific t ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libpam-modules 0.79-5Pluggable Authentication Modules f ii libpam0g 0.79-5Pluggable Authentication Modules l ii libselinux11.32-3SELinux shared libraries ii login 1:4.0.18.1-7 system login tools passwd recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464962: kernels for VIA Nehemiah SMP
I'd certainly very much appreciate the 686 kernels being suitable for Nehemiah, as there is no stock 486-SMP kernel, so I'll be rolling my own if not. Which would suck... Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476091: teapop: QA+l10n patch in case someone takes this package over again
On 14/04/2008, at 8:20 PM, Christian Perrier wrote: Package: teapop Severity: normal Tags: patch Please find attached the patch I was preparing before the package was removed from unstable. It enhances a few thigns wrt QA so it might be useful in case someone takes the package over. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash teapop.patch Thanks. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474099: Debian bug #474099 requests removal of teapop
On 4/04/2008, at 11:50 AM, Thomas Viehmann wrote: Hi, for your information: a removal request for the package teapop has been filed as bug #474099[1]. Unless you follow up soon, the ftp master will remove the package from the Debian archive. Kind regards T. 1. http://bugs.debian.org/474099 I'll endorse this request; I was contemplating either an RFA/ITO or removal request myself. I don't believe teapop is likely to be particularly useful to many people any more, it seems that it may no longer be actively developed, and I don't like the idea of Debian harbouring large quantities of obsolete cruft. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415250: ETA for including the German debconf translation?
On 9/09/2007, at 7:49 AM, Helge Kreutzmann wrote: Hello, several month ago you received the German translation of your debconf template. Do you have any ETA for uploading a new version including this (and possibly other) translation, to get a good testing coverage during the Lenny development cycle? If you have any questions or need help adding the the Debconf template, do not hesitate to ask on debian-i18n. No ETA at present; it is on my list of things to catch up on, but if anyone else wants to do it either in the meantime or permanently, I'd appreciate it. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409864: Unspeakable evil is possible even in python
On 9/02/2007, at 10:51 PM, Christian Perrier wrote: Please don't misinterpret my previous comments as criticism of you as maintainer -- whoever wrote the code evidently just completely failed to consider setups different to their own. That is interesting because, being currently subscribed to the package's PTS even though I'm not the maintainer, I actually didn't went through your entire bug report mostly because of the way it was explained at the beginning. I mostly read something like this package is providing brain-dead codewhich then prevented me to hear the very valid arguments you developed further...which I actually read when I read your *second* mail. Something interesting to consider, maybe, when interacting with package maintainers and developers..:-) Yep. I do try to at least remain civilised when ranting. I think the problem may be that I tend to end up missing out writing steps of explanation which I have drafted and redrafted in my head, and jump straight to the conclusion. It *is* brain-dead code, though ;-) Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409864: Unspeakable evil is possible even in python
OK, well take a look at line 761 in viewvc.py and it being called from line 827, and laugh. Consider for a moment the explicitly-set relative template paths in the viewvc.conf that has been generated for you. Consider further the absolute futility of setting the template_dir option. Then switch to cvsweb or something. A fine example of shit code in any language. For a workaround, either set the template_dir option in the [options] section of your viewvc.conf and comment out all of the explicit templates specified in the [templates] section, or just make sure that every template in the [templates] section is specified with an absolute path. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409864: _install_path
I've had a look in viewcvs.py and I don't see a valid use of _install_path anywhere. In fact it's not even really a valid concept, so that's not surprising. Probably the best bet would be to come up with something that used the CONF_PATHNAME to work something out. I think from my admittedly brief look that that would be usable in each case where _install_path is currently used. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409864: Unspeakable evil is possible even in python
On 9/02/2007, at 3:04 PM, David Martínez Moreno wrote: El viernes, 9 de febrero de 2007 00:40, Nick Phillips escribió: OK, well take a look at line 761 in viewvc.py and it being called from line 827, and laugh. Consider for a moment the explicitly-set relative template paths in the viewvc.conf that has been generated for you. Consider further the absolute futility of setting the template_dir option. Only if it is relative, not absolute. There is a: if os.path.isabs(path): that should take care of giving back the path unaltered if it is absolute, which is our case. Not if the individual template settings are relative, which in my migrated config (from a standard viewcvs config), they are. i.e. template_dir is set and absolute, individual template names are set and relative, and the result is breakage. Maybe I am completely slept or something, but the viewvc.conf from Rodrigo only has the default configuration, that is, an absolute template_dir parameter and no explicit template. I do not see your point, sorry. I'm guessing I'm not the only one who is using this as a migration from viewcvs. In any case, irrespective of the config file that we may or may not ship/create, the behaviour that viewvc exhibits when a relative template name is set is nuts. I would suggest that: * If absolute template paths are explicitly set per-template, they are used * If relative templates (which include the defaults) are to be used, then they should be relative to the specified template_dir * If relative templates are to be used, and template_dir is not set, then they should be relative to /etc/viewvc -- not the result of some half-baked attempt to find some kind of installation dir. Note that _install_path appears also to be used e.g. to determine where to tell cvsgraph to look for config files. Which is also crazy and broken. Please don't misinterpret my previous comments as criticism of you as maintainer -- whoever wrote the code evidently just completely failed to consider setups different to their own. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago
Bug#409864: Unspeakable evil is possible even in python
On 9/02/2007, at 3:04 PM, David Martínez Moreno wrote: Maybe I am completely slept or something, but the viewvc.conf from Rodrigo only has the default configuration, that is, an absolute template_dir parameter and no explicit template. I do not see your point, sorry. Sorry, hadn't looked at his conf file -- I'd just found this bug when about to report one myself, and thought it looked like the same one. Since the behaviour I thought I was describing (relative names in templates section, absolute template_dir set, result broken because for some reason it is using /usr/lib as a prefix) is clearly a problem, I suggest that fixing it to use template_dir as a prefix whenever the per-template name is relative (i.e. is using the default or is specified as a relative name in the config) would be a good idea, and might well fix his problem as well as mine. Oh, and the default for template_dir obviously needs to be sensible too, rather than calculated from __file__! Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago
Bug#400679: roundup: Bug in example apache2 config
Package: roundup Version: 1.2.1-4 Severity: normal The example configuration file for use with apache2/mod_python breaks the use of http://localhost/doc/roundup;. The AliasMatch and RedirectMatch directives in there (all of them) should be anchored to the start of the location with a ^ character. e.g. RedirectMatch permanent ^/roundup/([^/]+)$ /roundup/$1/ rather than the current RedirectMatch permanent /roundup/([^/]+)$ /roundup/$1/ Cheers, Nick -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-powerpc Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages roundup depends on: ii python2.4.3-11 An interactive high-level object-o ii python-central0.5.10 register and build utility for Pyt roundup recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388609: teapop-mysql: purging the package fails (update-inetd unavailable)
On 28/09/2006, at 2:15 PM, Mohammed Adnène Trojette wrote: On Fri, Sep 22, 2006, Nick Phillips wrote: Ah. Bother. Thanks, I'll have a look. Hi Nick! May I suggest a fix similar to the one in the netkit-tftp package? purge) # If netbase is not installed, then we don't need to do the remove. if command -v update-inetd /dev/null 21; then update-inetd --remove tftp .* /usr/sbin/ in.tftpd fi ;; Thanks for that... Cheers, Nick
Bug#389502: moodle: wwwconfig-common/restart.sh can fail
Package: moodle Version: etch version Severity: important wwwconfig-common/restart.sh can fail (not sure why at the moment), which causes maintainer scripts to fail when run with -e, which makes package uninstallable and unremovable (stuck in limbo). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-powerpc Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388609: teapop-mysql: purging the package fails (update-inetd unavailable)
Bill Allombert wrote: Package: teapop-mysql Version: 0.3.7-4.1+b1 Severity: serious Hello Nick, There is an error when attempting to purge teapop-mysql: Removing teapop-mysql ... Purging configuration files for teapop-mysql ... /var/lib/dpkg/info/teapop-mysql.postrm: line 28: update-inetd: command not found dpkg: error processing teapop-mysql (--purge): subprocess post-removal script returned error exit status 127 update-inetd is not provided by an essential package. See Policy 7.2: Note, however, that the `postrm' cannot rely on any non-essential packages to be present during the `purge' phase. Cheers, Ah. Bother. Thanks, I'll have a look. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#202018: hfsplus: Failure to mount hfsplus volume
Aurélien GÉRÔME wrote: retitle 202018 hfsplus: Failure to mount hfsplus volume tags 202018 + moreinfo unreproducible thanks Hi, I am the new Debian maintainer of hfsplus. I write to you both in an attempt to fix http://bugs.debian.org/202018, because I am missing critical information to do so. Could you provide me a HFS+ image which fails like it is mentioned in the bug-report? If it is too big to fit in a mail sent to the Debian BTS, could you put it online somewhere? Cheers, I'm afraid the drive in question is no more, so I can't help. Sorry. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375968: etch beta2 netboot fails on VIA VT310DP
Frans Pop wrote: On Monday 10 July 2006 03:56, Nick Phillips wrote: I did; the daily booted and installed (don't have the date of the daily to hand at the moment) but the kernel installed during the installation did not boot. That can be explained because the installed kernel is currently not the same as that used by the installer when installing testing. You should be able to solve that by using the rescue mode of the installer (boot using 'rescue'). You will be asked to select the partition that has the root filesystem of the installed system. After that, the best thing to do is switch to VT2, 'chroot /target', mount other filesystems you need (you need at least 'mount none /sys -t sysfs', and of course /boot, /usr, etc. if these are separate). Then, download (wget) the 2.6.16 kernel image package from unstable and install it using 'dpkg -i package name'. Yep, that's basically what I did, except for the moment I've used a custom kernel copied over on a USB key, but I'll try the standard one when I get a chance. BTW it seems you actually have to mount the filesystems on /target before you chroot, otherwise /dev in the chroot doesn't have the right devices, which means you can't mount them. I can't remember whether I actually did that or used dpkg with --root in the end. I'll file another report when I get the install finished. Not really needed, unless you have other issues you'd like to report. If not, just follow up to this one. OK, will let you know - will probably try a reinstall fairly soon. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375968: etch beta2 netboot fails on VIA VT310DP
On 10/07/2006, at 1:23 PM, Frans Pop wrote: On Thursday 29 June 2006 11:37, Nick Phillips wrote: Comments/Problems: default install image (2.6) hangs during boot. last line of output is io scheduler cfq registered. install24 boots but USB keyboard is unusable to proceed further. Please retry using a daily built image. That has a more recent kernel which may fix your issues. If that does not work, try booting the installer with: install nolapic or install noapic nolapic I did; the daily booted and installed (don't have the date of the daily to hand at the moment) but the kernel installed during the installation did not boot. I'll file another report when I get the install finished. nolapic and noapic didn't help. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375968: etch beta2 netboot fails on VIA VT310DP
Package: installation-reports Boot method: netboot Image version: etch beta 2 netboot, from http://ftp.nl.debian.org/debian/dists/testing/main/installer-i386/beta2/images/ Date: 20060629 Machine: VIA VT-310DP-based system Processor: VIA Nehemiah Memory: 1GB Partitions: I wish I could get that far Output of lspci and lspci -n: [EMAIL PROTECTED]:1389$ lspci :00:00.0 Host bridge: VIA Technologies, Inc.: Unknown device 0259 :00:00.1 Host bridge: VIA Technologies, Inc.: Unknown device 1259 :00:00.2 Host bridge: VIA Technologies, Inc.: Unknown device 2259 :00:00.3 Host bridge: VIA Technologies, Inc.: Unknown device 3259 :00:00.4 Host bridge: VIA Technologies, Inc.: Unknown device 4259 :00:00.7 Host bridge: VIA Technologies, Inc.: Unknown device 7259 :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge :00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 10) :00:0a.0 Ethernet controller: VIA Technologies, Inc.: Unknown device 3119 (rev 11) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [K8T800 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) :00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 78) :01:00.0 VGA compatible controller: VIA Technologies, Inc.: Unknown device 3118 (rev 02) [EMAIL PROTECTED]:1389$ lspci -n :00:00.0 0600: 1106:0259 :00:00.1 0600: 1106:1259 :00:00.2 0600: 1106:2259 :00:00.3 0600: 1106:3259 :00:00.4 0600: 1106:4259 :00:00.7 0600: 1106:7259 :00:01.0 0604: 1106:b198 :00:09.0 0200: 8086:1229 (rev 10) :00:0a.0 0200: 1106:3119 (rev 11) :00:0f.0 0104: 1106:3149 (rev 80) :00:0f.1 0101: 1106:0571 (rev 06) :00:10.0 0c03: 1106:3038 (rev 81) :00:10.1 0c03: 1106:3038 (rev 81) :00:10.2 0c03: 1106:3038 (rev 81) :00:10.3 0c03: 1106:3038 (rev 81) :00:10.4 0c03: 1106:3104 (rev 86) :00:11.0 0601: 1106:3227 :00:11.5 0401: 1106:3059 (rev 60) :00:12.0 0200: 1106:3065 (rev 78) :01:00.0 0300: 1106:3118 (rev 02) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[E] Configure network HW: [ ] Config network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: default install image (2.6) hangs during boot. last line of output is io scheduler cfq registered. install24 boots but USB keyboard is unusable to proceed further. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363471: Etch B2 installation report
Package: installation-reports Boot method: CD-initiated netinst Image version: Etch Beta 2, http://debian.ihug.co.nz/debian/dists/etch/main/installer-i386/beta2/images/netboot/mini.iso Date: 20060419 Machine: VIA VT310-DP Processor: 2x VIA Eden Memory: 1GB Partitions: n/a Output of lspci and lspci -n: n/a Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[E] Configure network HW: [ ] Config network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: Hang after 4 io schedulers registered. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363473: Etch B1 installation report
Package: installation-reports Boot method: CD-initiated netinst Image version: Etch Beta 1, http://debian.ihug.co.nz/debian/dists/etch/main/installer-i386/beta1/images/netboot/mini.iso Date: 20060419 Machine: VIA VT310-DP Processor: 2x VIA Eden Memory: 1GB Partitions: n/a Output of lspci and lspci -n: n/a Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [E] Config network: [O] Detect CD: [O] Load installer modules: [E] Detect hard drives: [ ] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: Boots, which B2 doesn't. Fails to detect onboard GigE (detects both onboard 100Mbit interfaces). Eventual error - No kernel modules found. -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#298689: What do you gain?
Using a passphrase on your ssl keys should mean that someone is unable to take them and use them elsewhere without your knowledge. Chances are you'd notice (eventually) if someone with root on your server was doing bad things, but there's no way you'd notice if they set up a server using your keys certs, and redirected clients to it. Of course, you still have to make sure that you notice that something's wrong before providing the key passphrase to the keylogger that someone just installed ;-), but it is an extra layer of protection, and a deterrent to opportunistic theft of the keys + certs. It may not be likely, but it is perfectly valid. Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311264: libkwiki-perl is in the archive
Luk Claes wrote: Hi Shouldn't this bug be closed now that libkwiki-perl is available in the archive? Cheers Luk Probably; I need to go over a bunch of bugs and check the current status. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351030: libmail-spf-query-perl: FTBFS: Missing Build-Depends
Julian Mehnle wrote: Daniel Schepler wrote: If I add netbase to the Build-Depends, the package builds fine [in my pbuilder chroot]. Is it really necessary to list netbase in a package's Build-Depends (-Indep) control field? Or could there be something wrong with your pbuilder? (Sorry, I have little experience with Debian packages that require a net connection during building.) That'll be because they shouldn't exist. I'm not sure offhand whether it's ever made it as far as policy, but it's been discussed several times (sometimes in the context of trying to update sources from upstream revision control systems, sometimes for tests), and the general consensus, AFAIR, has always been don't -- if it's only a test, you should probably skip it. I'm not sure what the feeling would be about trying to detect whether or not the requisite infrastructure is present and running the tests in question if so would be; probably still don't (as it will enable 'someone' to detect where builds are happening). Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328431: libspiffy-perl: Please upgrade to 0.29
Florian Ragwitz wrote: Package: libspiffy-perl Version: 0.21-1 Followup-For: Bug #328431 Hello, please upgrade the Debian package of Spiffy.pm to version version 0.29. This version is needed to package Test::Base which is a new dependency Feel free to have a look at pkg-kwiki in svn on alioth -- the currently packaged version should be in there, along with a bunch of other stuff I really should tidy up and upload. If you're at all interested in any of it, feel free to consider adopting it. It's a little more complicated than usual with the kwiki stuff because although I agreed to adopt it from the previous maintainer, I haven't yet made a successful upload. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#328431: libspiffy-perl: New upstream version
On Sun, Jan 15, 2006 at 12:07:44AM +0100, Jonas Genannt wrote: Hello, please see http://search.cpan.org/~ingy/Spiffy-0.26/ Version 0.26 is out, it is needed for the new libyaml-perl package. Please update your package soon! I'm not going to be able to for a couple of weeks. To be honest, I'm going to be looking to escape all the kwiki-related stuff anyway. So if you want to adopt/NMU/whatever, let me know :-) Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345915: Fix for bug #324010 breaks connectivity to AOL
Package: reaim Version: 0.8-4 Severity: important As mentioned in the logs for #324010, the fix for that bug appears to have broken connectivity to AOL in at least some cases. Personally, using gaim from etch no longer works through reaim 0.8-4. Reverting to reaim 0.8-2 fixes the problem. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#324010: Confirmation of regression
I can confirm that 0.8-4 is unable to connect to AOL (login.oscar.aol.com, port 5190) when proxying for gaim. Reverting to 0.8-2 fixes it. I'll file a separate bug. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288507: acknowledged by developer ()
On Fri, Dec 30, 2005 at 09:18:24AM -0800, Debian Bug Tracking System wrote: Hi, you can easily dismiss the Keyboard Shortcuts dialog using your window manager, for example I use Alt+F4 combo (metacity here). Thanks for your report. Actually I couldn't, that's why I filed the bug. Was using sawfish then, but have since switched to metacity. It seems that there is a close button on the window using metacity, but I have no idea if there will be with sawfish now. No idea what was causing the close button not to display, but whatever it was, it was a bug in *something*. Having to use keyboard shortcuts (can't even remember now whether I tried it let alone whether it worked) to access standard functionality is not acceptable behaviour from a GUI... But since I'm no longer in a position to reproduce it, I guess we just have to wait until it bites someone else :-/ Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339330: Extra information
I'm also seeing this problem. It's not just amarok; several other KDE apps also do this since the recent big KDE upgrade in etch. It seems that window placement gets totally screwed, with different effects on different apps -- a couple of examples: * firefox -- is placed at top left as if not being managed, but does have a border, titlebar etc. Grabbing it with middle-click in border and dragging makes it OK * xterm -- totally screwy. All window border is drawn as if for a zero-sized window, but window is still drawn 80x25 as usual. Various other apps follow each of these patterns. It seems that we suddenly gain a speaker beep on window close too (all windows). Seriously ugly. I'm going to try metacity now to see if it is affected. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339330: metacity unaffected
OK, if I log in as a different user and use metacity, these effects do not seem to occur. So it does look like a problem between sawfish and etch's new KDE libs. FWIW, it's not *all* KDE apps. noatun for example causes no problems. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339330: more playing
Problem seems to be related to the notification area panel applet. If I remove and re-add the notification area applet before causing a juk/amarok/whatever window to be displayed, there is no problem. However, if I have the notification area there when I log in, the GNOME splash screen stays for a suspiciously long time with juk as the last item being started, and the problems start when I cause a juk window to be displayed. Hope that helps! Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339543: moin: Moin with mod_python fails to handle Location correctly
Package: moin
Severity: normal
Tags: patch
Moin 1.3.5 and 1.5.0beta3 fail to correctly handle the use of
PythonOption to overcome problems with being run as a handler (incorrect
script_name and path_info).
RequestModPy uses a get method that's not always available with a
mod_python table object (worked around elsewhere in request.py, but not
here), and ignores the fact that script_name is not set correctly (or
usefully, at least) by Apache.
The script_name bug bites when the wiki is not at the top level
(e.g. www.foo.com/wikis/moinwiki instead of www.foo.com/moinwiki,
which would work).
Patch provided *shouldn't* break anything on any other OS/webserver/config.
Patch follows:
--- MoinMoin/request.py 2005-10-30 11:55:39.0 +1300
+++ MoinMoin/request.py-new 2005-11-17 14:10:45.0 +1300
@@ -1786,8 +1786,9 @@
except Exception, err:
self.fail(err)
-def rewriteURI(self, env):
- Use PythonOption directive to rewrite URI
+def fixURI(self, env):
+ Fix problems with script_name and path_info using
+PythonOption directive to rewrite URI.
This is needed when using Apache 1 or other server which does
not support adding custom headers per request. With mod python we
@@ -1795,16 +1796,31 @@
Location /url/to/mywiki/
PythonOption X-Moin-Location /url/to/mywiki/
-/location
+/location
+
+Note that *neither* script_name *nor* path_info can be trusted
+when Moin is invoked as a mod_python handler with apache1, so we
+must build both using request_uri and the provided PythonOption.
# Be compatible with release 1.3.5 Location option
# TODO: Remove in later release, we should have one option only.
old_location = 'Location'
-options = self.mpyreq.get_options()
+options_table = self.mpyreq.get_options()
+if not hasattr(options_table,'get'):
+options=dict(options_table)
+else:
+options=options_table
location = options.get(self.moin_location) or options.get(old_location)
if location:
env[self.moin_location] = location
-RequestBase.rewriteURI(self, env)
+# Try to recreate script_name and path_info from request_uri.
+import urlparse
+scriptAndPath = urlparse.urlparse(self.request_uri)[2]
+self.script_name = location.rstrip('/')
+path = scriptAndPath.replace(self.script_name, '', 1)
+self.path_info = wikiutil.url_unquote(path, want_unicode=False)
+
+RequestBase.fixURI(self, env)
def _setup_args_from_cgi_form(self, form=None):
Override to use mod_python.util.FieldStorage
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.11nwp1
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339363: moin: MoinMoin 1.5?
Package: moin Severity: wishlist Any chance of any packages of a version of MoinMoin 1.5 anytime soon? Experimental, p.d.o., anything would be good. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339363: moin: MoinMoin 1.5?
On Tue, Nov 15, 2005 at 10:16:33PM +0100, Jonas Smedegaard wrote: Until showing up in the experimental archive, you can grab it here as well: http://debian.jones.dk/auryn/pool/official/yaird/ I guess you mean http://debian.jones.dk/auryn/pool-all/official/moin/ ?? Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334286: mozilla-thunderbird: Hangs on trying to send mail with attachments
Alexander Sack wrote: On Mon, Oct 17, 2005 at 04:41:56PM +1300, Nick Phillips wrote: On Sun, Oct 16, 2005 at 09:47:50PM +0200, Alexander Sack - Debian Bugmail wrote: I do not see such a problem here. I have an up to date etch system. Maybe you have some wierd extensions installed? No extensions that I'm aware of for thunderbird -- certainly nothing from outside Debian. I may have some installed for firefox, if that makes any difference. No ... should make no difference. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') You still have packages from sarge? Yep. There usually seems to be too much stuff missing from etch otherwise. Hmmm ... maybe give it a try? Just use dist-upgrade to get all changes? Maybe this is the reason. Otherwise, please do remove thunderbird one more time and then install it again. OK, it seems that the default 2.6.12 kernel in debian doesn't do a sensible /dev/random, and thunderbird was blocking waiting for a read from /dev/random. Goodness knows why it would need that (I have use TLS set to no, for example), but there it is. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334286: mozilla-thunderbird: Hangs on trying to send mail with attachments
Package: mozilla-thunderbird Version: 1.0.2-3 Severity: normal After upgrade from sarge to etch, I'm no longer able to send mail with attachments using thunderbird. When I press send, if the mail has attachments, thunderbird hangs. If the mail has no attachments, it is sent with no problems. If I create a new profile, the problem is still present. -- 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.6.12-1-k7 Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8) Versions of packages mozilla-thunderbird depends on: ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libc6 2.3.5-6GNU C Library: Shared libraries an ii libfontconfig12.3.2-1generic font configuration library ii libfreetype6 2.1.7-2.4 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-2 GCC support library ii libglib2.0-0 2.8.3-1The GLib library of C routines ii libgtk2.0-0 2.6.10-1 The GTK+ graphical user interface ii libpango1.0-0 1.8.2-2Layout and rendering of internatio ii libstdc++51:3.3.6-7 The GNU Standard C++ Library v3 ii libx11-6 6.8.2.dfsg.1-7 X Window System protocol client li ii libxext6 6.8.2.dfsg.1-7 X Window System miscellaneous exte ii libxft2 2.1.7-1FreeType-based font drawing librar ii libxp66.8.2.dfsg.1-7 X Window System printing extension ii libxrender1 1:0.9.0-2 X Rendering Extension client libra ii libxt66.8.2.dfsg.1-7 X Toolkit Intrinsics ii xlibs 6.8.2.dfsg.1-7 X Window System client libraries m ii zlib1g1:1.2.3-4 compression library - runtime Versions of packages mozilla-thunderbird recommends: ii myspell-eo [myspell-di 2.1.2000.02.25-20 The Esperanto dictionary for myspe ii xprint 1:0.1.0.alpha1-12 Xprint - the X11 print system (bin -- debconf information: * mozilla-thunderbird/browser: GNOME -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#334286: mozilla-thunderbird: Hangs on trying to send mail with attachments
On Sun, Oct 16, 2005 at 09:47:50PM +0200, Alexander Sack - Debian Bugmail wrote: I do not see such a problem here. I have an up to date etch system. Maybe you have some wierd extensions installed? No extensions that I'm aware of for thunderbird -- certainly nothing from outside Debian. I may have some installed for firefox, if that makes any difference. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') You still have packages from sarge? Yep. There usually seems to be too much stuff missing from etch otherwise. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311264: Status of libkwiki-perl
Florian Ragwitz wrote: Package: kwiki Followup-For: Bug #311264 So what's the current state of this bug? Are you still working on it? If not I'd like to adopt that package. Current state is as it said; being worked on. I will upload my svn repository to svn.d.o as soon as I can now; I just have to get the structure at least vaguely right for creation of .orig.tar.gz files (these need to include *all* the different CPAN packages which will be in the main Kwiki package). Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302797: libspoon-perl: libio-all-perl package
Florian Ragwitz wrote: Package: libspoon-perl Version: 0.20-1 Followup-For: Bug #302797 Hello, I prepared a package for libio-all-perl. It's available here: http://www-user.tu-chemnitz.de/~rafl/Code/Debian/ I'd be glade if someone would sponsor it because I'm not a DD yet. Please don't; it needs to be co-ordinated with all the Kwiki stuff. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311264: kwiki 0.36-1 uninstallable due to missing libkwiki-perl
Mohammed Adnène Trojette wrote:
On Mon, May 30, 2005, Jan Niehusmann wrote:
# apt-get install kwiki
[...]
The following packages have unmet dependencies:
kwiki: Depends: libkwiki-perl (= 0.36-2) but it is not installable
E: Broken packages
I have just tried to have a look at this one.
Unfortunately, I did not understand well the packaging:
1/ there seems to be a typo in debian/control:
Depends: ${perl:Depends}, ${shlibs:Depends}, liblocale-maketext-perl,
libkwiki-perl (= 0.36-2)
Provides: libcgi-kwiki-perl
The new package is first called libkwiki-perl and then
libcgi-kwiki-perl. Moreover, it is not defined in debian/control :(
2/ kwiki seems to be a transition package as said in debian/changelog:
* Compatibility package to enable gentler transition between
old-style kwiki and new-style kwiki, also ensuring that new
users don't accidentally get into old-style kwiki.
and in the description:
This package is here to make sure people don't accidentally
start new Kwikis using the old-style CGI::Kwiki system.
.
If you are starting a new Kwiki, you DO NOT NEED this
package. Install the libkwiki-perl package instead.
3/ however, it doesn't use the classical way to make a smooth
transition, that is to say defining a dummy package kwiki depending on
the new libkwiki-perl package that replaces kwiki and conflicts kwiki.
4/ I have tried to make a submittable patch, but I noticed that 0.36-1
was using upstream's 0.18 release (I may have been mistaken).
As far as I am concerned, I thus think that this package is an
incomplete transition package. Did I misunderstood something?
The fact that the new replacement package was rejected by ftpmaster, and
I haven't completed repackaging yet. I'm working on it.
Cheers,
Nick
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#199800: New upstream version available
Florian Ernst wrote: Hello Nick, I noticed you apparently didn't touch the tnef package for almost two years now, so I'm wondering if there is anything that prevents any of the recent upstream releases from being packaged. Did you just wait for the Sarge release to happen before updating? Or are there any issues with newer versions of tnef? Cheers, Flo Initially there wasn't any reason to update it; the version we had worked fine, and the new version was just a rewrite, pretty much. Then someone else offered an updated package just as I was about to build one, so... And recently (since about September) yes, I've been waiting for sarge. It seems that there is actually new functionality in the latest version, so it will be worth updating; I haven't heard of any issues with it... ...but I use tnef less and less these days anyway, so if you have an interest in it, I'd encourage you to take it over (if not, I may RFA after sarge anyway). Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308419: ITP: libytnef ytnef
On Mon, May 09, 2005 at 09:38:03PM -0700, Joshua Kwan wrote: This kind of supersedes the tnef package in quality, IMO, so I'll be talking to the maintainer Nick Phillips about collaborating on this, though I already have packages ready. Debs are ready, and I'll be contacting Nick Phillips, maintainer of a similar (but IME inferior) package, about possible collaboration. Missed you on IRC, it seems, but I'd say go for it. I took over tnef to make sure that it would be available and working properly for use with mailscanner -- that basically involved adding a patch to make sure that it would not expand arbitrarily large files if you didn't want it to. At the moment, I'm pretty much completely uninvolved with mailscanner, but will be talking to its author about the state of its TNEF support. He's been recommending configuring mailscanner to use a perl tnef decoder for a while I believe, but users might still want to use an external TNEF decoder. Making it slightly more complicated, mailscanner needs to work with a tnef decoder that is available on all sorts of platforms that Debian really doesn't give a damn about. My attitude to this has always been that tnef is an unfortunate but currently necessary evil, and the sooner it goes away the better -- hence most of the recent uploads of tnef being NMUs -- unless there is a compelling reason to upgrade the Debian version, I certainly won't be rushing to it. I would also be inclined to value stability over features. So I guess you could say I'm here to ensure that tnef gets the kind of neglect it deserves (but no more) ;-) Now, if ytnef were to be usable as a drop-in replacement for tnef, I could certainly consider jumping ship (or just turning up the volume on the neglect bit). Alternatively, I may persuade the mailscanner author to support ytnef directly. So, we'll see, I guess. But in the meantime, go for it :-) Cheers, Nick -- Whoops, no .sig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#302797: libspoon-perl depends on libio-all-perl, which is not in the archive
On Sat, Apr 02, 2005 at 04:20:23PM -0800, Steve Langasek wrote: Package: libspoon-perl Severity: grave I can't even find any mention of libio-all-perl in the NEW queue. Was rejected due to silly mistake with description; now that I have ADSL back I will reupload ASAP. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#257062: xserver-xfree86: please backport new Intel i910 driver
On 26/03/2005, at 8:30 AM, Branden Robinson wrote: On Fri, Mar 18, 2005 at 04:45:57PM +1300, Nick Phillips wrote: On 18/03/2005, at 8:04 AM, Branden Robinson wrote: If an i915 patch is prepared, works, and has been signed off on by i810/i830/i845/i855/i865 as well as i915 users, then the patch submitter and these testers can join me in making a case to the Release Managers for pushing this into testing-proposed-updates (if xfree86 is frozen by then). OK, I'm working on it. If Jason Lunz gets there first, fine. If not, I'll probably get there in a few days, depending on the quantity (and quality) of distractions that come up in the meantime... How's this coming along? Just trying a build at the moment. I don't expect it to work... -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#257062: Please include the new intel driver
On 09/03/2005, at 6:02 AM, Branden Robinson wrote: Well, essentially, a patch would need to be prepped that resembled debian/patches/000_stolen_from_xorg_nv_driver.diff (in the Debian xfree86 source package), but updated the i810 driver directory instead. The bad news is that no more updates to xfree86 for sarge are planned. A case can of course be made for this hardware support, but at this point I'd need to involve the release management team. On balance (and not just because I have a lab full of machines with i915 chipsets to look after), I think that we really ought to try to get this into sarge. It won't be long before there are a hell of a lot of those chips out there. Even if we release Etch a year after Sarge, that's still a significant lag for a significant number of (potential) users -- and hands up who thinks we actually *will* release then... So, count me in favour, and let me know if you want any testing done (on i810 or i915). Cheers, Nick -- Nick Phillips / +64 3 479 4195 / [EMAIL PROTECTED] # these statements are my own, not those of the University of Otago -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#290266: please publish libkwiki-perl 0.36-2 on people.debian.org
On Thu, Jan 13, 2005 at 11:24:42PM +1300, Nick Phillips wrote: Since libkwiki-perl is inaccessible to the public in NEW, people surely would appreciate being able to download at least the source package inofficially from somewhere, for example from people.debian.org OK, will upload to people.debian.org/~nwp shortly. Done. Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
