Bug#904034: qcontrol: Please backport 0.5.5-3 or newer to stretch
Package: qcontrol Version: 0.5.5-2 Severity: wishlist Dear Maintainer, I've just upgraded my TS-419 to Stretch, and I'm suffering the issues fixed in #795558 (error opening /sys/class/gpio/export) [1] and #852127 (qcontrold starts too late due to systemd changes) [2]. There was also a report on the debian-arm mailing list from 2016 [3] which appeared to be suffering the same problem from the same upgrade, in the second paragraph. I'm also seeing the same "SysRq" logs from the third when I press LCD-down, and I assume that's only because qcontrold got to the GPIO pin too late to claim it from the watchdog I saw mentioned in the bug reports. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795558 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852127 [3] https://lists.debian.org/debian-arm/2016/08/msg00049.html -- System Information: Debian Release: 9.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 4.9.0-7-marvell Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages qcontrol depends on: ii libc62.24-11+deb9u3 ii liblua5.1-0 5.1.5-8.1+b2 ii udev 232-25+deb9u4 qcontrol recommends no packages. qcontrol suggests no packages. -- no debconf information
Bug#702763: qcontrol: Merged ts41x.lua script is missing lcd_button function
Package: qcontrol
Version: 0.4.2+svn-r40-3
Severity: normal
Bug 689912 consolidated the upstream ts419p and ts41x configuration scripts,
but the resulting script does not contain the lcd_button script from the
ts419p example script.
I copied the lcd_button script over, and it works fine.
(This is a locally built copy of 0.4.2+svn-r40-3 based on the source in
unstable,
using debhelper 9 from backports)
-- System Information:
Debian Release: 6.0.7
APT prefers stable
APT policy: (500, 'stable')
Architecture: armel (armv5tel)
Kernel: Linux 2.6.32-5-kirkwood
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages qcontrol depends on:
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro
ii udev 164-3 /dev/ and hotplug management daemo
qcontrol recommends no packages.
qcontrol suggests no packages.
-- Configuration Files:
/etc/qcontrol/ts41x.lua changed:
--[[
Debian configuration file for qcontrol (LUA syntax)
Supports the QNAP TS-410, TS-410U, TS-419P and TS-419U.
--]]
register(ts41x)
-- Requires CONFIG_KEYBOARD_GPIO enabled in the kernel and
-- the kernel module gpio_keys to be loaded.
register(evdev, /dev/input/by-path/platform-gpio-keys-event,
408, restart_button,
133, media_button)
function power_button( time )
os.execute(poweroff)
end
function restart_button( time )
os.execute(reboot)
end
function media_button( time )
piccmd(usbled, 8hz)
end
function lcd_button( state, down, up )
-- exactly key 1 and 2 pressed switches backlight off
if state == 3 then
piccmd(lcd-backlight, off)
else
-- any key pressed activates the backlight
if down ~= 0 then
piccmd(lcd-backlight, on)
end
-- pressing key 1 switches off the usbled the media-key enables...
if down == 1 then
piccmd(usbled, off)
end
end
end
-- If argument is a function then call it, else return it.
function evalfn(f)
if type(f) == function then
return f( )
else
return f
end
end
-- Select a value based on the state of a GPIO pin.
--
-- results == list of result to return for each state
-- value=0 = results[1]
-- value=1 = results[2]
-- value unknown = results[3]
--
-- If result[N] is a function it will be called,
-- otherwise it is simply returned as is.
function gpio_select(number, results)
local path=string.format(/sys/class/gpio/gpio%d/value, number)
local gpio=io.open(path)
if not gpio then
logprint(ts41x: ..path.. does not exist, trying to enable)
g = io.open(/sys/class/gpio/enable)
if not g then
logprint(ts41x: unable to open gpio control file)
return evalfn(results[3])
end
g:write(number)
gpio=io.open(path)
end
if not gpio then
logprint(ts41x: unable to open gpio file)
return evalfn(results[3])
end
local v=gpio:read(*n)
if v == 0 then return evalfn(results[1])
elseif v == 1 then return evalfn(results[2])
else return evalfn(results[3])
end
end
-- MPP45_GPIO, JP1: 0: LCD, 1: serial console
gpio_select(45, {
function () register(a125, /dev/ttyS0) end,
nil,
nil})
fanfail = 0
function fan_error( )
fanfail = fanfail + 1
if fanfail == 3 then
logprint(ts41x: fan error)
piccmd(statusled, red2hz)
piccmd(buzzer, long)
else
if fanfail == 10 then
fanfail = 0
end
end
end
function fan_normal( )
piccmd(statusled, greenon)
fanfail = 0
end
last_temp_log = nil
last_temp_value = 0
function logtemp( temp )
now = os.time()
-- Log only every 5 minutes or if the temperature has changed by
-- more than 5.
if ( ( not last_temp_log ) or
( os.difftime(now, last_temp_log) = 300 ) or
( math.abs( temp - last_temp_value ) = 5 ) ) then
logprint(string.format(ts41x: temperature %d, temp))
last_temp_log = now
last_temp_value = temp
end
end
last_fan_setting = nil
function setfan( speed )
if ( ( not last_fan_setting ) or
( last_fan_setting ~= speed ) ) then
logprint(string.format(ts41x: setting fan to \%s\, speed))
end
piccmd(fanspeed, speed)
last_fan_setting = speed
end
function temp( temp )
logtemp(temp)
if temp 80 then
setfan(full)
elseif
Bug#417622: NTFS-3g way too old, can cause data corrumption in rare conditions
Steve Langasek wrote: Michael, Please keep the Cc: list intact when replying. On Tue, Apr 03, 2007 at 11:01:00PM +0200, Michael Fritscher wrote: From my POV, the question is not whether ntfs-3g 1.0.0 should be included in etch (it won't be), but whether the risk of this data loss is significant enough that we should consider dropping ntfs-3g from etch altogether for the sake of our users' data. Since ntfs-3g didn't ship with any previous release, and has no reverse-dependencies in etch, it doesn't seem unreasonable to drop it from the release, and that seems to be in keeping with our policy of treating data loss bugs with the highest severity? It killed already files for me and others. It is mentioned in the forum, too: http://forum.ntfs-3g.org/viewtopic.php?t=170highlight= Another problem is that unmounting was asyncron in these early versions, which can cause data loss, too. So I strongly advise to drop this package, if you don't want to update it. That's certainly persuasive to me. Adam, is there any hope of a targetted fix for these issues described, or are users really just safer if we drop the package from etch? Just to add an extra data point, the release notes for NTFS-3G [1] indicate that big-endian wasn't supported until the release after the one currently in Etch (ie. 20061115 release has fix: the code wasn't endian safe and I'm pretty sure the documentation in Etch mentions that it's not working on BE machines) So having a build of this version for PowerPC in Etch seems like it's asking for trouble. Same for the other BE arches. I've not tested this though, not having a scratch NTFS drive handy, which is why I never got around to making a separate bug report out of this. It may be that the warnings are largely paranoia. -- Paul TBBle Hampson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405606: aiccu is now under 3-clause BSD license
Steve Langasek wrote: On Mon, Jan 08, 2007 at 11:01:35AM +1100, Paul TBBle Hampson wrote: OK. As per [1] in the 388759 buglog and the upstream website [2] the 2007.01.07 release of aiccu is now under the 3-clause BSD license. ... CC'd to debian-release to see if the Etch-response is drop, unblock, or wait-and-see. Drop, unless someone has a plan for fixing the protocol incompatibility problems *without* pulling in unrelated changes from a new upstream release. I don't have any such plans, and I doubt the maintainer does either at this late stage. And without pulling in the new upstream release, I don't believe we get the new license, so it stays in non-free and we don't have the packages built on most arches. It's been like this for nine months, so let's just get it off the RC count, and when the maintainer has time, the new version can go into unstable of his own accord. -- Paul TBBle Hampson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#321391: libcurl3-dev doesn't report HTTPS protocol or SSL feature support
Package: libcurl3-dev Version: 7.14.0-3 Severity: normal Just trying to rebuild centericq, and its configure script checks for SSL in `curl-config --features`. However, this is not currently present, nor is HTTPS present in `curl-config --protocols`. I expect this is due to something in the gnuTLS transition not flagging that SSL is supported? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (950, 'unstable'), (900, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages libcurl3-dev depends on: ii libc6-dev [libc-dev]2.3.2.ds1-22 GNU C Library: Development Librari ii libcurl37.14.0-3 Multi-protocol file transfer libra ii libgnutls-dev 1.2.5-3 the GNU TLS library - development files ii libidn11-dev0.5.18-1 Development files GNU libidn, impl ii zlib1g-dev 1:1.2.3-1compression library - development libcurl3-dev recommends no packages. -- no debconf information -- Paul TBBle Hampson, [EMAIL PROTECTED] 8th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Bug#318689: ethereal: libcap patch in 315670 does not check for non-root user before trying to drop caps
Package: ethereal Version: 0.10.11-2 Severity: normal The patch in #315670 doesn't check if it _has_ CAP_NET_RAW before it tries to drop others. When run as non-root, it is actually an attempt to _gain_ the capability, and therefore fails: [EMAIL PROTECTED]:~$ ethereal Could not set capabilities: Operation not permitted [EMAIL PROTECTED]:~$ I can't say off hand how to do this _right_, but I suspect the function dropexcesscapabilities() should checkif CAP_NET_RAW is held before it tries to drop capabilities, and either do nothing or drop _all_ capabilities if CAP_NET_RAW is not already held. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages ethereal depends on: ii ethereal-common 0.10.11-1network traffic analyser (common f ii libadns11.0-8.3 Asynchronous-capable DNS client li ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libcomerr2 1.38-1 common error description library ii libglib2.0-02.6.5-1 The GLib library of C routines ii libgtk2.0-0 2.6.8-1 The GTK+ graphical user interface ii libkrb531.3.6-4 MIT Kerberos runtime libraries ii libpango1.0-0 1.8.1-1 Layout and rendering of internatio ii libpcap0.8 0.8.3-6 System interface for user-level pa ii libpcre35.0-1.1 Perl 5 Compatible Regular Expressi ii zlib1g 1:1.2.2-8compression library - runtime Versions of packages ethereal recommends: ii gksu 1.3.0-1graphical frontend to su -- no debconf information -- Paul TBBle Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Bug#318218: xserver-xorg: libvgahw.a is miscompiled by gcc-4
Package: xserver-xorg Severity: normal Version: 6.8.2.dfsg.1-1 libvgahw.a in X.org's xserver 6.8.2 is miscompiled by gcc-4. This is a known bug to X.org [1][2][3], gcc [4] and even Red Hat [5], who've posted a libvgahw.a [6] that fixed it, at least in my case. I found that the libvgahw.a from xserver-xorg 6.8.2.dfsg.1-0pre1v1 also worked fine. (No longer avaiable on people.debian.org, but I had it installed on another machine.) I understand this is also already known to the Debian X Maintatiner, but I couldn't find a bug against either xorg or gcc-4.0 packgages in the BTS, nor any mention in the debian-x email archives. As such, I guess this is more of a visibility bug, so I (and presumably anyone who subscribes to it) can see when the problem's solved and no longer have to manually intervene in xorg-xserver upgrades. [1] https://bugs.freedesktop.org/show_bug.cgi?id=2976 [2] https://bugs.freedesktop.org/show_bug.cgi?id=2991 [3] https://bugs.freedesktop.org/show_bug.cgi?id=3557 [4] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22278 [5] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=161242 [6] ftp://people.redhat.com/mharris/libvgahw.a -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- Paul TBBle Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Bug#318219: alsa-base: Init.d script patch to autostart timidity as a sequencer client
Package: alsa-base Version: 1.0.9b-2 Severity: wishlist Tags: patch Here's a patch I knocked up to have timidity started by alsa-base's init.d script if autostart_timidity is set to 'true'. It was actually a proof of concept I tried to submit six months ago, but I think the bug was eaten by my local mailer setup. (If not, and this is a duplicate, then feel free to close/merge it.) I recently discovered there's an alternative to timidity for this task, but the name escapes me. If this is felt to be a good thing to add to alsa-base, I'd be happy to expand on the patch as neccessary. -- Package-specific info: --- Begin additional package status --- Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-===-== ii libasound2 1.0.9-3 ALSA library --- End additional package status --- --- Begin /proc/asound/version --- Advanced Linux Sound Architecture Driver Version 1.0.9b. Compiled on Jul 4 2005 for kernel 2.6.11. --- End /proc/asound/version --- --- Begin /proc/asound/cards --- 0 [CMI8738]: CMI8738 - C-Media PCI CMI8738 C-Media PCI CMI8738 (model 37) at 0xd800, irq 9 --- End /proc/asound/cards --- --- Begin /dev/snd/ listing --- total 0 crw-rw 1 root audio 116, 0 2005-07-04 02:26 controlC0 crw-rw 1 root audio 116, 24 2005-07-04 02:26 pcmC0D0c crw-rw 1 root audio 116, 16 2005-07-04 02:26 pcmC0D0p crw-rw 1 root audio 116, 17 2005-07-04 02:26 pcmC0D1p crw-rw 1 root audio 116, 26 2005-07-04 02:26 pcmC0D2c crw-rw 1 root audio 116, 18 2005-07-04 02:26 pcmC0D2p crw-rw 1 root audio 116, 33 2005-07-04 02:26 timer --- End /dev/snd/ listing --- -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages alsa-base depends on: ii alsa-utils 1.0.9a-3 ALSA utilities ii debconf [debconf-2.0] 1.4.52Debian configuration management sy ii debianutils2.14.1Miscellaneous utilities specific t ii linux-sound-base 1.0.9b-2 base package for ALSA and OSS soun ii lsof 4.75.dfsg.1-1 List open files. ii module-init-tools 3.2-pre1-2tools for managing Linux kernel mo ii modutils 2.4.27.0-3Linux module utilities alsa-base recommends no packages. Versions of packages libasound2 depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an -- debconf information excluded -- Paul TBBle Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Bug#314797: xmame-gl: xmame.xgl tries to load libGL.so and libGLU.so, but doesn't depend on them
Package: xmame-gl Severity: grave The xmame-gl package declares dependancies on: xlibmesa-gl | libgl1 and xlibmesa-glu | libglu1 However, the xmame.xgl binary tries do dlopen (I presume) libGL.so and libGLU.so, which are actually symlinks provided in the -dev versions of the above packages. I suspect the fix is so change the dlopen to look for libGL.so.1 and libGLU.so.1, since a dependancy on libgl1-dev and libglu1-dev would be very strange. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (990, 'unstable'), (900, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages xmame-gl is related to: ii reportbug 3.13 reports bugs in the Debian distrib pn totem-gstreamer none (no description available) -- Paul TBBle Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Bug#314253: freeradius: Missed the scripts/ directory in the source tarball
Package: freeradius Version: 1.0.2-4 Severity: normal Dumbass, you forgot the script/ directory in the source tarball. Actually reported by Michael Langer on the FreeRADIUS-users list. This affects stable/ too, but no one noticed this since I packaged the dang thing in 2003. _ Oh well. 1.0.3 upload coming this weekend, should also catch the build error in #313173. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (900, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages freeradius depends on: ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libgdbm31.8.3-2 GNU dbm database routines (runtime ii libltdl31.5.6-6 A system independent dlopen wrappe ii libpam0g0.76-22 Pluggable Authentication Modules l -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312038: apt-cacher-cleanup.pl complains about a valid file
Package: apt-cacher Version: 0.9.4 Severity: normal My cron.daily outputs: /etc/cron.daily/apt-cacher: Someone is cheating, bad filename found: physics.muni.cz_‾yeti_Ftp_enca_all_Packages.gz at /usr/share/apt-cacher/apt-cacher-cleanup.pl line 86. every night, due to the following site in my sources.list: deb http://192.168.0.1/apt-cacher/physics.muni.cz/~yeti/Ftp enca/all/ deb http://192.168.0.1/apt-cacher/physics.muni.cz/~yeti/Ftp enca/$(ARCH)/ This means the rest of apt-cacher-cleanup doesn't run, since the error is a 'die'. I'd suggest adding '~' to the list of allowable filenames, and making this test a 'print and next' rather than a 'die' since at the moment a bad filename means the tests abort completely, not just for that file. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (900, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages apt-cacher depends on: ii apache2-mpm-prefork [httpd-cg 2.0.54-4 traditional model for Apache2 ii curl 7.13.2-2 Get a file from an HTTP, HTTPS, FT ii perl 5.8.4-8Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310387: Client help at http://server/apt-cacher/ builds bad URL example
Package: apt-cacher Version: 0.9.2 Severity: minor The page produced at http://192.168.0.1/apt-cacher/ has two minor issues. It reports itself as 0.8.6, and suggests deb http://yourcache.example.com/apt-cacher0/ftp.au.debian.org/debian unstable main contrib non-free instead of deb http://yourcache.example.com/apt-cacher/ftp.au.debian.org/debian unstable main contrib non-free (Both the extra '0' after apt-cacher, and not using nbsp in the line, although the nbsp is possibly not a good idea.) -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (900, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages apt-cacher depends on: ii apache2-mpm-prefork [httpd-cg 2.0.54-2 traditional model for Apache2 ii curl 7.13.2-2 Get a file from an HTTP, HTTPS, FT ii perl 5.8.4-8Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310393: Checksumming code starts with 'die' on line 69 of /usr/share/apt-cacher/apt-cacher-lib-cs.pl
Package: apt-cacher Version: 0.9.2 Severity: normal Unconditional die on line 69 of apt-cacher-lib-cs.pl seems wrong, somehow. I didn't test any further than disabling checksumming again though, so maybe the code's not ready yet? -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (900, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages apt-cacher depends on: ii apache2-mpm-prefork [httpd-cg 2.0.54-2 traditional model for Apache2 ii curl 7.13.2-2 Get a file from an HTTP, HTTPS, FT ii perl 5.8.4-8Larry Wall's Practical Extraction -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#305771: libtdb1: libtdb is LGPL, rather than GPL as stated in copyright
Package: libtdb1 Version: 1.0.6-11 Severity: normal Basically, the broken-out libtdb at [1] records itself as LGPL, in tdb.c ([2]), and that's been true for every revision of tdb.c in this directory in SVN. (This package predates the SVN repository, so I guess this is a historical oversight.) This is not a higher severity since it's not legally wrong to relicense LGPL programs as GPL (as far as I know) but it does mean the libtdb1 package in Debian is more limited in usability (eg. cannot be linked in in combination with OpenSSL) so I've marked this as normal rather than wishlist. There is however a problem as the tdb tools in the above directory _are_ still marked as GPL, although Tridge just said (at linux.conf.au 2005) that he believes tdb is LGPL, so I suspect this is an upstream oversight, and in fact tdbtorture includes no license text at all. Any chance of a fix before Sarge? I'm happy to take a stab at this upstream if the maintainer does not wish to. (I've just seen tdb and ldb at linux.conf.au 2005 and I've been left well and truly drooling. ^_^) [1] http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_3_0_RELEASE/source/tdb/?rev=6426 [2] http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_3_0_RELEASE/source/tdb/tdb.c?rev=6369view=auto -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (900, 'experimental'), (900, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages libtdb1 depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303320: libyaml-perl: Unneeded dependancy on perl (= 5.8.0-7)
Package: libyaml-perl Severity: wishlist Any chance we could drop the versioning of the perl dependancy/build-dependancy? Apart from this, the package seems to work fine on Woody. Or at least 0.36-1 did, I haven't tried 0.38-1 yet. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (900, 'experimental'), (900, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303148: ifupdown: Logical interface support broken
Package: ifupdown
Version: 0.6.5
Severity: normal
Tags: Patch
The latest version of ifupdown has broken logical interface support as
follows:
ifup -v eth0=work produces:
| Suu:~# ifup -vvv eth0=work
| Configuring interface eth0=work (inet)
| run-parts --verbose /etc/network/if-pre-up.d
| run-parts: executing /etc/network/if-pre-up.d/wireless-tools
|
* ifconfig work 10.254.0.4 netmask 255.255.255.0 broadcast 10.254.0.255
up
| SIOCSIFADDR: No such device
| work: ERROR while getting interface flags: No such device
| SIOCSIFNETMASK: No such device
| SIOCSIFBRDADDR: No such device
| work: ERROR while getting interface flags: No such device
| work: ERROR while getting interface flags: No such device
| Failed to bring up work.
Obviously, the settings are coming from the work stanza OK, but surely
that should be
* ifconfig eth0 10.254.0.4 netmask 255.255.255.0 broadcast 10.254.0.255
up
?
Anyway, assuming I'm right, here's the patch:
--- ifupdown.nw.org 2005-04-05 15:04:39.215576720 +1000
+++ ifupdown.nw 2005-04-05 15:05:06.911366320 +1000
@@ -2801,7 +2801,7 @@
int i;
if (strncmpz(id, iface, idlen) == 0) {
- return ifd-logical_iface;
+ return ifd-real_iface;
} else {
for (i = 0; i ifd-n_options; i++) {
if (strncmpz(id, ifd-option[i].name, idlen) == 0) {
Simply, the various references to %iface% in the .defn files are passed
to the system, so should be the real_iface (ie. what the system sees it
as) not logical_iface (ie. what the stanza's called)
If this is wrong, maybe ifrename should be being applied earlier in the
process? I can see how people might prefer the actual interface to end
up being called 'work' or 'home', but given how people object to
'wlanX', I doubt this would actually ever fly.
I'd love to mark this Important but when I asked on #debian if anyone
else had seen this, no one else seemed to be to using this
functionality.
Also, while I was poking around, checking for a preexisting bug report,
it looks like #244101 has been fixed by providing $LOGICAL to the if-*
scripts. Just thought I'd mention it, I haven't tested it or anything.
I just noticed the variable when I was tracking this problem through the
.nw file.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable'), (900, 'experimental'), (900, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Versions of packages ifupdown depends on:
ii debconf [debconf-2.0] 1.4.47 Debian configuration management sy
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii net-tools 1.60-10 The NET-3 networking toolkit
-- debconf information excluded
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#301081: ITP: mutt-ng -- Mutt next generation (mutt-ng) is a fork of the well-known email client mutt
On Thu, Mar 24, 2005 at 07:39:04AM +0100, Jesus Climent wrote: On Thu, Mar 24, 2005 at 02:33:27PM +1100, Paul Hampson wrote: On the other hand, I'm having a problem with the package, it doesn't include muttng_dotlock, and seems to think my mailspool (mbox in /var/mail) is read-only. (vanilla) Mutt can use it fine. Same problem here. Reported to Norbert but never got deeper into it. Let's try renaming mutt_dotlock to muttng_dotlock ;) I hard-linked muttng_dotlock to mutt_dotlock but it didn't help. I might futz with it later, once I get sick of using vanilla mutt for my Inbox. ^_^ -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- pgpZvCBoqkLdK.pgp Description: PGP signature
Bug#300992: flow-tools: docs/Makefile.am and docs/Makefile.in have paths for docbook stuff in /usr/local/
Package: flow-tools Severity: wishlist Tags: patch Basically, if you modify any of the docbook SGML files in a local dpatch, then building fails because jade is looking for docbook files in /usr/local/sgml/ Here's the dpatch to fix this. (I did the Makefile.in changes by hand, not by rerunning automake) #! /bin/sh -e ## 04_docbook ## build system: Fix paths for jade rebuilding documentation. if [ $# -lt 1 ]; then echo 2 `basename $0`: script expects -patch|-unpatch as argument exit 1 fi case $1 in -patch) patch -f --no-backup-if-mismatch -p1 $0;; -unpatch) patch -f --no-backup-if-mismatch -R -p1 $0;; *) echo 2 \ `basename $0`: script expects -patch|-unpatch as argument exit 1;; esac exit 0 @DPATCH@ --- flow-tools-0.67.orig/docs/Makefile.am +++ flow-tools-0.67/docs/Makefile.am @@ -19,10 +19,10 @@ docbook-to-man $*.sgml $*.1.in .sgml.html: - jade -V nochunks -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html + jade -V nochunks -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -c /usr/share/sgml/jade/catalog -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html .sgml.html.in: - jade -V nochunks -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html.in + jade -V nochunks -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -c /usr/share/sgml/jade/catalog -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html.in all-am: Makefile $(man_MANSIN) $(man_HTMLS) --- flow-tools-0.67.orig/docs/Makefile.in +++ flow-tools-0.67/docs/Makefile.in @@ -374,10 +374,10 @@ docbook-to-man $*.sgml $*.1.in .sgml.html: - jade -V nochunks -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html + jade -V nochunks -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -c /usr/share/sgml/jade/catalog -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html .sgml.html.in: - jade -V nochunks -c /usr/local/share/sgml/docbook/dsssl/modular/catalog -c /usr/local/share/sgml/docbook/catalog -c /usr/local/share/sgml/jade/catalog -d /usr/local/share/sgml/docbook/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html.in + jade -V nochunks -c /usr/share/sgml/docbook/stylesheet/dsssl/modular/catalog -c /usr/share/sgml/jade/catalog -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/html/docbook.dsl -t sgml $*.sgml $*.html.in all-am: Makefile $(man_MANSIN) $(man_HTMLS) # Tell versions [3.59,3.63) of GNU make to not export all variables. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.5 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#300355: php4: Segfault in session support
Package: php4
Version: 4:4.1.2-7
Severity: normal
Tags: patch woody
Basically, there's a repeatable segfault in session.c in php 4.1.2 It's
documented in PHP4 bug 15168 [1], although they claim it only happens
with the mm session handler, and I triggered it with the file session
handler. (Same segfault as in the bug report.)
Anyway, I've fetched the changes that appeared in the relevant branch of
PHP CVS [2], and integrated them with a couple of fixes that appear in
the Debian/stable latest PHP4 package, and included the patch below.
It appears that this package _has_ an attempt to fix this problem
already, but I'm guessing it didn't work, so I've replaced it.
The below patch applies to ext/session/session.c. Hunk 1 is just because
that's the CVS version it's closes too (end of the line for that branch)
and Hunk 3 is whitespace fixes for consistency in the existing Debian
patch. Hunk 2 depends on the existing Debian patch, and it and Hunk 4
are the important ones.
Anyway, I can't really justify this as a security bug, since it just
causes segfaults in Apache, and short output on the screen, but it's
here in case anyone _can_ build such a case, and for documentation
purposes. As such, I don't mind if it goes +wontfix. ^_^
--- session.c.org Fri Mar 18 22:18:05 2005
+++ session.c Sat Mar 19 00:56:19 2005
@@ -17,7 +17,7 @@
+--+
*/
-/* $Id: session.c,v 1.237.2.8 2002/02/26 19:32:52 derick Exp $ */
+/* $Id: session.c,v 1.237.2.11 2002/03/05 22:07:15 zeev Exp $ */
#ifdef HAVE_CONFIG_H
#include config.h
@@ -426,20 +426,20 @@
static void php_session_track_init(TSRMLS_D)
{
zval **old_vars = NULL;
- zval *session_vars = NULL;
if (zend_hash_find(EG(symbol_table), HTTP_SESSION_VARS,
sizeof(HTTP_SESSION_VARS), (void **)old_vars) == SUCCESS
Z_TYPE_PP(old_vars) == IS_ARRAY) {
- PS(http_session_vars) = *old_vars;
- zend_hash_clean(Z_ARRVAL_P(PS(http_session_vars)));
+ PS(http_session_vars) = *old_vars;
+ zend_hash_clean(Z_ARRVAL_P(PS(http_session_vars)));
} else {
- if(old_vars) {
- zend_hash_del(EG(symbol_table), HTTP_SESSION_VARS,
sizeof(HTTP_SESSION_VARS));
- }
- MAKE_STD_ZVAL(session_vars);
- array_init(session_vars);
- PS(http_session_vars) = session_vars;
- ZEND_SET_GLOBAL_VAR_WITH_LENGTH(HTTP_SESSION_VARS,
sizeof(HTTP_SESSION_VARS), PS(http_session_vars), 1, 0);
- ZEND_SET_GLOBAL_VAR_WITH_LENGTH(_SESSION, sizeof(_SESSION),
PS(http_session_vars), 1, 0);
+ if(old_vars) {
+ zend_hash_del(EG(symbol_table), HTTP_SESSION_VARS,
sizeof(HTTP_SESSION_VARS));
+ }
+ MAKE_STD_ZVAL(PS(http_session_vars));
+ array_init(PS(http_session_vars));
+ PS(http_session_vars)-refcount = 2;
+ PS(http_session_vars)-is_ref = 1;
+ zend_hash_update(EG(symbol_table), HTTP_SESSION_VARS,
sizeof(HTTP_SESSION_VARS), PS(http_session_vars), sizeof(zval *), NULL);
+ zend_hash_update(EG(symbol_table), _SESSION,
sizeof(_SESSION), PS(http_session_vars), sizeof(zval *), NULL);
}
}
@@ -1288,17 +1288,17 @@
void session_adapt_uris(const char *src, size_t srclen, char **new, size_t
*newlen TSRMLS_DC)
{
if (PS(define_sid) (PS(session_status) == php_session_active)) {
-char *encoded_id = php_url_encode(PS(id), strlen(PS(id)), NULL);
+ char *encoded_id = php_url_encode(PS(id), strlen(PS(id)), NULL);
*new = url_adapt_ext_ex(src, srclen, PS(session_name),
encoded_id, newlen TSRMLS_CC);
-}
+ }
}
void session_adapt_url(const char *url, size_t urllen, char **new, size_t
*newlen TSRMLS_DC)
{
if (PS(define_sid) (PS(session_status) == php_session_active)) {
-char *encoded_id = php_url_encode(PS(id), strlen(PS(id)), NULL);
+ char *encoded_id = php_url_encode(PS(id), strlen(PS(id)), NULL);
*new = url_adapt_single_url(url, urllen, PS(session_name),
encoded_id, newlen TSRMLS_CC);
-}
+ }
}
void session_adapt_flush(int (*write)(const char *, uint TSRMLS_DC) TSRMLS_DC)
@@ -1343,6 +1343,7 @@
PS(id) = NULL;
PS(session_status) = php_session_none;
PS(mod_data) = NULL;
+ PS(http_session_vars) = NULL;
}
static void php_rshutdown_session_globals(TSRMLS_D)
[1] http://bugs.php.net/bug.php?id=15168 - Ignore the random tag-on bug
on May 14th. _
[2] http://cvs.php.net/php-src/ext/session/session.c?r1=1.237.2.8onb=1.237.2
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux yurika 2.4.26 #1 Mon Aug 9 23:25:59 EST 2004 i686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8
Versions of packages php4 depends on:
ii apache-common 1.3.27-0.1.ipv6.r2 Support files for all Apache webse
ii fileutils 4.1-10
Bug#300219: freeradius: FreeRADIUS crashes with crypt authentication
tags 300219 +pending
Thankyou Mr Bug Control Robot
On Fri, Mar 18, 2005 at 01:27:44PM +0100, Manuel Menal wrote:
Package: freeradius
Severity: important
Tags: patch
When pthreads are enabled (default on Debian) and crypt
encryption is used, FreeRADIUS crashes.
The following patch fixes the bug :
diff -Nurp freeradius-1.0.1/src/lib/crypt.c
freeradius-1.0.1.new/src/lib/crypt.c
--- freeradius-1.0.1/src/lib/crypt.c2004-02-26 20:04:20.0 +0100
+++ freeradius-1.0.1.new/src/lib/crypt.c2005-03-18 13:25:55.187248153
+0100
@@ -49,7 +49,7 @@ int lrad_crypt_check(const char *key, co
/*
* Ensure we're thread-safe, as crypt() isn't.
*/
- if (!lrad_crypt_init == 0) {
+ if (lrad_crypt_init == 0) {
pthread_mutex_init(lrad_crypt_mutex, NULL);
lrad_crypt_init = 1;
}
It's obviously a mistake, which causes pthread_mutex_lock/unlock
to be called on an uninitialized mutex.
Indeed. A very similar mistake was fixed with the random pool in
the 1.0.2 release. I've sent this upstream, and will endevaour to
drop a new package to my sponsor by Monday.
Good catch, and thankyou. ^_^
--
Paul TBBle Hampson, [EMAIL PROTECTED]
7th year CompSci/Asian Studies student, ANU
Shorter .sig for a more eco-friendly paperless office.
signature.asc
Description: Digital signature
Bug#299749: freeradius-dialupadmin: admin.conf paths preceded with %
tags 299749 -experimental
Thankyou Mr Bug Control Robot
On Wed, Mar 16, 2005 at 03:16:47PM +1000, marco wrote:
Package: freeradius-dialupadmin
Version: 1.0.2-1
Severity: normal
Tags: experimental
from the web page after install:
Error: File '%/etc/freeradius-dialupadmin/naslist.conf' does not exist
or is not readable
Error: File '%/etc/freeradius-dialupadmin/captions.conf' does not exist
or is not readable
appears in the menu.
testbuild04:/# grep %\/ /etc/freeradius-dialupadmin/admin.conf
general_sql_attrmap: %/etc/freeradius-dialupadmin/sql.attrmap
general_accounting_attrs_file: %/etc/freeradius-dialupadmin/accounting.attrs
general_extra_ldap_attrmap: %/etc/freeradius-dialupadmin/extra.ldap-attrmap
general_user_edit_attrs_file: %/etc/freeradius-dialupadmin/user_edit.attrs
general_sql_attrs_file: %/etc/freeradius-dialupadmin/sql.attrs
general_default_file: %/etc/freeradius-dialupadmin/default.vals
general_auth_request_file: %/etc/freeradius-dialupadmin/auth.request
INCLUDE: %/etc/freeradius-dialupadmin/naslist.conf
INCLUDE: %/etc/freeradius-dialupadmin/captions.conf
This is inside a 'sarge' vserver built ontop of a homemade vserver
kernel. The host system was a knoppix a to hd install
Ooops, brain fart.
Take out the second % on line 143 of debian/rules, and see if that fixes
it. I expect it will, but I won't have time to rebuild and upload until
after this weekend, I expect.
(It should look like this afterwards:)
-e 's#%{general_base_dir}/conf#/etc/freeradius-dialupadmin#' \
--
Paul TBBle Hampson, [EMAIL PROTECTED]
7th year CompSci/Asian Studies student, ANU
Shorter .sig for a more eco-friendly paperless office.
signature.asc
Description: Digital signature
Bug#276746: A patch for Unix98 pty support in l2tpd
tags 276746 +patch
Thankyou Mr Bug Control Robot.
Package: l2tpd
Version: 0.70-pre20031121-2
Followup-For: Bug #276746
I'm sure this has been done before, but l2tpd.org is absent,
and google didn't actually come up with any patches so I wrote
my own. I'm hoping this will prompt a new upload with this patch,
as I was unable to locate another L2TP LAC in Debian.
diff -u l2tpd-0.70-pre20031121/Makefile l2tpd-0.70-pre20031121/Makefile
--- l2tpd-0.70-pre20031121/Makefile
+++ l2tpd-0.70-pre20031121/Makefile
@@ -33,8 +33,9 @@
#
# Uncomment the next line for Linux
#
-OSFLAGS= -DLINUX
+#OSFLAGS= -DLINUX
#OSFLAGS= -DLINUX -I/usr/include
+OSFLAGS= -DLINUX -DUNIX98PTYS -D_GNU_SOURCE
#
# Uncomment the following to use the kernel interface under Linux
#
diff -u l2tpd-0.70-pre20031121/l2tpd.c l2tpd-0.70-pre20031121/l2tpd.c
--- l2tpd-0.70-pre20031121/l2tpd.c
+++ l2tpd-0.70-pre20031121/l2tpd.c
@@ -274,7 +274,9 @@
int start_pppd (struct call *c, struct ppp_opts *opts)
{
+#ifndef UNIX98PTYS
char a, b;
+#endif
char tty[80];
char *stropt[80];
struct ppp_opts *p;
@@ -324,6 +326,30 @@
else
{
#endif
+#ifdef UNIX98PTYS
+/* if ((c-fd = posix_openpt(O_RDRW|O_NOCTTY)) 0)*/
+ if ((c-fd = getpt()) 0)
+ {
+ logput(LOG_WARN, %s: unable to allocate pty: '%s',
abandoning!\n,
+ __FUNCTION__, strerror(errno));
+ return -EINVAL;
+ }
+ grantpt(c-fd);
+ unlockpt(c-fd);
+tcgetattr (c-fd, ptyconf);
+*(c-oldptyconf) = ptyconf;
+ptyconf.c_cflag = ~(ICANON | ECHO);
+ ptyconf.c_lflag = ~ECHO;
+tcsetattr (c-fd, TCSANOW, ptyconf);
+ snprintf (tty, sizeof (tty), %s, ptsname(c-fd));
+fd2 = open (tty, O_RDWR);
+ if(!fd2)
+ logput(LOG_WARN, unable to open tty %s, tty);
+
+ /* XXX JEF: CHECK ME: This should be safe, we just snprintf'd
it. */
+ stropt[pos++] = strdup(tty);
+ stropt[pos] = NULL;
+#else
if ((c-fd = getPtyMaster (a, b)) 0)
{
log (LOG_WARN, %s: unable to allocate pty, abandoning!\n,
@@ -347,7 +373,7 @@
/* XXX JEF: CHECK ME */
stropt[pos++] = strdup(tty);
stropt[pos] = NULL;
-
+#endif /* UNIX98PTY */
#ifdef USE_KERNEL
}
#endif
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Versions of packages l2tpd depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
--
Paul TBBle Hampson, [EMAIL PROTECTED]
7th year CompSci/Asian Studies student, ANU
Shorter .sig for a more eco-friendly paperless office.
signature.asc
Description: Digital signature
Bug#298716: l2tpd: pppd 2.4.2 replaced -detach with nodetach
Package: l2tpd
Version: 0.70-pre20031121-2.0.0.1
Severity: normal
Tags: patch
The attached patch replaces -detach with nodetach in the three
places in control.c where it occurs in the call to pppd. pppd
2.4.2 is where this change in parameters occurred.
diff -u l2tpd-0.70-pre20031121/control.c l2tpd-0.70-pre20031121/control.c
--- l2tpd-0.70-pre20031121/control.c
+++ l2tpd-0.70-pre20031121/control.c
@@ -808,7 +808,7 @@
control_xmit (buf);
po = NULL;
po = add_opt (po, passive);
-po = add_opt (po, -detach);
+po = add_opt (po, nodetach);
if (c-lac)
{
if (c-lac-defaultroute)
@@ -900,7 +900,7 @@
strncpy (ip2, IPADDY (c-addr), sizeof (ip2));
po = NULL;
po = add_opt (po, passive);
-po = add_opt (po, -detach);
+po = add_opt (po, nodetach);
po = add_opt (po, %s:%s, c-lns-localaddr ? ip1 : , ip2);
if (c-lns-authself)
{
@@ -948,7 +948,7 @@
case OCCN: /* jz: get OCCN, so the only thing we must do
is to start the pppd */
po = NULL;
po = add_opt (po, passive);
-po = add_opt (po, -detach);
+po = add_opt (po, nodetach);
po = add_opt (po, file);
strcat (dummy_buf, c-dial_no); /* jz: use /etc/ppp/dialnumber.options
for pppd - kick it if you dont like */
strcat (dummy_buf, .options);
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Versions of packages l2tpd depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#297100: pbuilder source includes remains of pbuilder-uml build
Package: pbuilder Version: 0.122 Severity: minor In the source for 0.122, debian/pbuilder-uml.files and debian/pbuilder-uml/ exist. The latter contains the binaries of pbuilder-uml, and appears to be left-over from a build of pbuilder-uml that wasn't cleaned. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages pbuilder depends on: ii coreutils 5.2.1-2The GNU core utilities ii debianutils 2.13.0 Miscellaneous utilities specific t ii debootstrap 0.2.45-0.1 Bootstrap a basic Debian system ii gcc 4:3.3.5-1 The GNU C compiler ii wget 1.9.1-10 retrieves files from the web -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295808: [cicq] [Fwd: Bug#295808: centericq failed with CPP error message]
On Tue, Feb 22, 2005 at 08:46:45PM +0100, Julien Lemoine wrote: Here is a bug report from a debian user, is this problem fixed in cvs ? It's been reported several times on the CICQ mailing list, but no cause or fix has yet been suggested. -- Paul TBBle Hampson, [EMAIL PROTECTED] 7th year CompSci/Asian Studies student, ANU Shorter .sig for a more eco-friendly paperless office. signature.asc Description: Digital signature
Bug#291945: eleventh-hour transition for mysql-using packages related to apache
On Sat, Feb 12, 2005 at 08:25:41PM +0100, Francesco Paolo Lovergine wrote: On Sat, Feb 12, 2005 at 09:17:44AM -0800, Steve Langasek wrote: On Sat, Feb 12, 2005 at 09:53:34AM +0100, Francesco Paolo Lovergine wrote: Nice, so we should check that any linked GPL library directly (obviuolsy) or indirectly (with N=1,2,3... levels of indirection) linked against openssl adds the exception. No, we should simply not be linking libmysqlclient against OpenSSL. The exemption was needed because there exists software that uses both libmysqlclient and libssl, but making libmysqlclient itself use libssl just because we now have the exemption will cause licensing problems for applications which currently do *not* depend on libssl. That's clear, I meant simply that if program A links libB which links libC which links libssl, than both A, libB and libC should add the exception, isn't it? That's independently from having A using libssl functions directly or not. That's true; I'm merely pointing out the importance of not turning libmysqlclient into libC here. So what if we had two editions of libmysqlclient, one of them ssl-enabled and the other - as currently - not? That would allow using ssl whenever possible. I think that could be done, without breaking things. That's funny. Didn't we spend all that time since Woody merging lib-*-ssl back into lib-*? -- --- Paul TBBle Hampson, MCSE 8th year CompSci/Asian Studies student, ANU The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361) [EMAIL PROTECTED] No survivors? Then where do the stories come from I wonder? -- Capt. Jack Sparrow, Pirates of the Caribbean This email is licensed to the recipient for non-commercial use, duplication and distribution. --- signature.asc Description: Digital signature
