Bug#413288: FTBFS on mipsel/experimental (Was: Re: Log for failed build of postfix_2.4.0~rc2-1 (dist=experimental))
On Sun, Mar 04, 2007 at 12:15:33AM +0100, Martin Zobel-Helas wrote: ../../lib/libdns.a: undefined reference to `_info' Well, that's a different error than I've seen on the mipsel buildd for unstable... Which I also haven't been able to reproduce Can you capture the failed build tree for me? thanks, lamont -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413303: boot failure
Package: linux-image Version: 2.6.18-4-686 I can not boot system (Debian etch), becouse I receive error: irq 233: nobody cared (try booting with the irqpoll option) [b0138147] _report_bad_irq+0x2b/0x69 [b013832b] note_interrupt+0x1a6/0x1df [b0137a00] _do_IRQ+0xae/0xe8 [b0104eca] do_IRQ+0x3f/0x4d [b010159d] mwait_idle+0x0/0x38 [b010344e] common_interrupt+0x1a/0x20 [b010159d] mwait_idle+0x0/0x38 [b01015c2] mwait_idle+0x25/0x38 [b0101574] cpu_idle+0x6f/0x98 [b0363703] start_kernel+0x369/0x36f handlers: [d08307c0] (usb_hcd_irq+0x0/0x55 [usbcore]) Disabling IRQ #233 . ATA: abnormal status 0xD8 on port 0xF807 ATA: abnormal status 0xD8 on port 0xF807 ATA: abnormal status 0xD8 on port 0xF807 ATA: abnormal status 0xD8 on port 0xF807 ata4.00: qc timeout (cmd 0xec) ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4) My MotherBoard: MSI p965 (intel p965, JMicron) I connect my SATA HDD to ICH8 SATA socked. I connect 2 IDE CD-ROM to JMicron. When I connect my HDD to another SATA socked of ICH8 - system boot normal. When I disconnect one CD-rom, system boot, but with error (see attachment dmesg). With 2.6.16 kernel system boot normal, but without CD-Rom. lspci Description: Binary data dmesg Description: Binary data
Bug#413073: atlantik: Ctrl-R to roll doesn't work in jail.
Hi, On Thu, Mar 01, 2007 at 06:22:11PM -0800, Josh Triplett wrote: Package: atlantik Version: 4:3.5.5-1 Severity: normal Ctrl-R, the shortcut to roll the dice, doesn't work to choose roll while in jail. I have not played atlantik, but it is a Monopoly®-like board game. In Monopoly, when you're un jail, you are stuck there for several turns and therefore you can not roll the dice. So, maybe this is not a bug? Just asking :) Ana -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413305: O: ami
Package: wnpp Severity: normal I orphan ami package, as few people use it now and I don't use it. Most Korean users I know already switched to other (and much better) Korean IMs. It has problems like dependency on GTK+ 1.x. And the most serious problem is that upstream is almost dead. Information about this package: Package: ami Version: 1.2.3-2 Section: x11 Priority: optional Architecture: i386 Depends: libc6 (= 2.3.5-1), libgdk-pixbuf2 (= 0.22.0), libglib1.2 (= 1.2.0), libgtk1.2 (= 1.2.10-4), libx11-6 Installed-Size: 1264 Maintainer: Changwoo Ryu [EMAIL PROTECTED] Description: An X input method server for Korean text input Ami is an X input method server for Korean text input. . Hangul or Hanja Korean text can be input with Ami, which responds the requests from XIM compliant applications. . In this package, Ami has been built as a standalone version and a WindowMaker dock. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18 Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413248: success with 'utf8' vfat mount option
Many thanks for the quick replies (including the info about #409516). I've now tried the following vfat mount options: (0) defaults (as generated by my oldish installer (weekly build 20070115)) (1) defaults,codepage=437 (this should be the default, so should be the same) (2) defaults,codepage=850 (3) defaults,iocharset=UTF-8 (4) defaults,iocharset=UTF8 (just a hunch, but no good) (5) defaults,utf8 (see mount(8) in the section 'Mount options for vfat') Option (5) works for me; the others don't (details below). Frans Pop wrote: Anyway, I doubt this would be an installer issue as there is no real way for the installer to determine the correct settings. Peter Green wrote: if so then imo this option should be set by the installer when generating fstab as afaict newly installed debian systems are completely utf-8 based nowadays. Okay, if vfat option 'utf8' is the solution, perhaps the installer *should* set it when generating fstab? It doesn't seem so variable (and difficult to determine) as different codepage/iocharset things might have been. It would be nice if this stuff worked 'out of the box'. Much better than just a comment in the release notes. (Unless it does work with newer builds? I should repeat that this is with the 20070115 build.) I still don't understand why I don't observe this problem on the box that I upgraded from sarge, as if the upgrade is incomplete somehow. Is the reason that I haven't 'upgraded' the locale settings to utf-8? Or something deeper? Anyway, details on the tests: (0),(1),(2) the same problems as in the original report, for example: debian:~$ mount | grep hda1 /dev/hda1 on /windows type vfat (rw,codepage=850) debian:~$ find /windows/windows/SendTo/ | wc wc: standard input:2: Invalid or incomplete multibyte or wide character 7 17 315 (3),(4) the mount fails, for example: debian:/etc# mount /windows/ mount: wrong fs type, bad option, bad superblock on /dev/hda1, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so debian:/etc# dmesg | tail -2 Unable to load NLS charset UTF-8 FAT: IO charset UTF-8 not found (5) success! so far, anyway... for example: debian:/etc# mount | grep hda1 /dev/hda1 on /windows type vfat (rw,utf8) debian:~$ find /windows/windows/SendTo/ /windows/windows/SendTo/ /windows/windows/SendTo/3½ Floppy (A).lnk [...] debian:~$ find /windows/windows/SendTo/ | wc 7 17 316 debian:~$ find /windows/windows/Favorites/ | grep Hifisound /windows/windows/Favorites/Hifisound der Lautsprecher Selbstbau Spezialist aus Münster.url (final example: mkisofs now works; previously it aborted) debian:~$ mkisofs -r -J -o cdtest.iso /windows/windows/Favorites I: -input-charset not specified, using utf-8 (detected in locale settings) [...] Total rockridge attributes bytes: 20387 Total directory bytes: 14336 Path table size(bytes): 86 Max brk space used 22000 387 extents written (0 MB)
Bug#413304: catalog rewrites 'PUBLIC -//OASIS//DTD DocBook V4//EN' to 4.3/docbook.dtd, instead of 4.4
Package: docbook Version: 4.4-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 /usr/share/sgml/docbook/dtd/catalog states: -- latest DocBook v4-- PUBLIC -//OASIS//DTD DocBook V4//EN 4.3/docbook.dtd -- DTDDECL -//OASIS//DTD DocBook V4//EN 4.3/docbook.dcl -- which should probably be 4.4/docbook.dtd (or 4.5 with the next upload). Regards, Daniel - -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.11 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages docbook depends on: ii sgml-base 1.26 SGML infrastructure and SGML catal ii sgml-data 2.0.3 common SGML and XML data docbook recommends no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF6i81m0bx+wiPa4wRAmH2AKCvH4PzI3SsbHZ7rVMTLv+sMoXIlgCePGSl PaTt4V3XQHDin/GkOizHehM= =IRMy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413245: iceweasel: also getting two tabs in a new window
Package: iceweasel Version: 2.0.0.2+dfsg-2 Followup-For: Bug #413245 I can confirm this bug; I'm getting exactly the same behavior as the submitter. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages iceweasel depends on: ii debianutils 2.17.5 Miscellaneous utilities specific t ii fontconfig2.4.2-1.2 generic font configuration library ii libatk1.0-0 1.12.4-2 The ATK accessibility toolkit ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libcairo2 1.2.4-4The Cairo 2D vector graphics libra ii libfontconfig12.4.2-1.2 generic font configuration library ii libfreetype6 2.2.1-5FreeType 2 font engine, shared lib ii libgcc1 1:4.1.1-21 GCC support library ii libglib2.0-0 2.12.6-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-5 The GTK+ graphical user interface ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libmyspell3c2 1:3.1-18 MySpell spellchecking library ii libpango1.0-0 1.14.8-5 Layout and rendering of internatio ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libstdc++64.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-5 X11 client-side library ii libxft2 2.1.8.2-8 FreeType-based font drawing librar ii libxinerama1 1:1.0.1-4.1X11 Xinerama extension library ii libxp61:1.0.0.xsf1-1 X Printing Extension (Xprint) clie ii libxrender1 1:0.9.1-3 X Rendering Extension client libra ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii psmisc22.3-1 Utilities that use the proc filesy ii zlib1g1:1.2.3-13 compression library - runtime iceweasel recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413307: FTBFS with GCC 4.3: error: 'std::string' has not been
Package: boinc Version: 5.4.11-4 Usertags: ftbfs-gcc-4.3 Tags: patch Your package fails to build with GCC 4.3. Version 4.3 has not been released yet but I'm building with a snapshot in order to find errors and give people an advance warning. A patch for this problem is below. Automatic build of boinc_5.4.11-4 on coconut0 by sbuild/ia64 0.49 ... if g++ -DHAVE_CONFIG_H -I. -I. -I.. -fPIC -DPIC -I../lib -I../api -I../db -I../client -I../tools -I../sched -pthread -fPIC -DPIC -I../lib -I../api -I../db -I../client -I../tools -I../sched -pthread -g -Wall -O3 -I/usr/include -I/usr/include/openssl -pthread -MT boinc_cmd.o -MD -MP -MF .deps/boinc_cmd.Tpo -c -o boinc_cmd.o boinc_cmd.C; \ then mv -f .deps/boinc_cmd.Tpo .deps/boinc_cmd.Po; else rm -f .deps/boinc_cmd.Tpo; exit 1; fi boinc_cmd.C:39: error: 'std::string' has not been declared boinc_cmd.C: In function 'int main(int, char**)': boinc_cmd.C:391: error: 'string' was not declared in this scope make[3]: *** [boinc_cmd.o] Error 1 make[3]: Leaving directory `/build/tbm/boinc-5.4.11/lib' --- boinc-5.4.11/client/client_state.h~ 2007-03-04 02:23:43.858424648 + +++ boinc-5.4.11/client/client_state.h 2007-03-04 02:23:57.352565108 + @@ -25,6 +25,7 @@ #include ctime #endif +#include string using std::string; using std::vector; --- boinc-5.4.11/lib/boinc_cmd.C~ 2007-03-04 02:19:40.080107322 + +++ boinc-5.4.11/lib/boinc_cmd.C2007-03-04 02:22:36.348659850 + @@ -35,6 +35,7 @@ #endif #include vector +#include string using std::vector; using std::string; -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413306: zope2.9: DateTime messed up again
Package: zope2.9 Version: 2.9.6-3 Severity: important Heya, obviously DateTime is messed up again. Doesn't look related to #224256, so I'm submitting a new bug. Please see http://dev.plone.org/plone/ticket/6062 and http://www.zope.org/Collectors/Zope/2191 (check comments = #15) This renders plone's ATEvent useless, for example. Having zope with a broken DateTime module in etch doesn't sound like something you'd want to have in etch - if possible please try to fix it before etch is released. Thanks, Bernd -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.2-grsec Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages zope2.9 depends on: ii debconf [debconf-2.0] 1.5.11 Debian configuration management sy ii libc6 2.3.6.ds1-11 GNU C Library: Shared libraries ii lsb-base3.1-23 Linux Standard Base 3.1 init scrip ii python2.4 2.4.4-2 An interactive high-level object-o ii zope-common 0.5.31 common settings and scripts for zo zope2.9 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412897: [Fontforge-devel] Bug#412897: Typo in man page fontforge(1)
On Thu, 2007-03-01 at 13:59, Kęstutis Biliūnas wrote: tags 412897 pending thanks Tr, 2007 02 28 19:42 +, Reuben Thomas rašė: Package: fontforge Version: 0.0.20061019-1 Severity: minor Near the top there's missing space in: fontforgespline font database (.sfd) Reuben, this bug is fixed on the my local copy and will be closed on the next upload. George, please apply attached patch for fixing this typo. Thank you, applied. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413308: refsection seems to be unsupported
Package: docbook-utils Version: 0.6.14-1 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The refsection element seems to be unsupported. Replacing it with any of the refsectx elements works and gives the expected output. Regards, Daniel - -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (550, 'stable'), (110, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.11 Locale: LANG=de_DE, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages docbook-utils depends on: ii docbook-dsssl 1.79-4 modular DocBook DSSSL stylesheets, ii jadetex 3.13-7.1 generator of printable output from ii links 0.99+1.00pre12-1.1 Character mode WWW browser ii lynx 2.8.5-2sarge2.2Text-mode WWW Browser ii perl 5.8.8-7Larry Wall's Practical Extraction ii sgmlspl 1.03ii-31 SGMLS-based example Perl script fo ii sp1.3.4-1.2.1-47 James Clark's SGML parsing tools ii w3m 0.5.1-5.1 WWW browsable pager with excellent Versions of packages docbook-utils recommends: ii docbook-xml 4.4-5 standard XML documentation system, - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF6jPym0bx+wiPa4wRAgtGAJ0VuZV/cV16ye42BWm7jpmMFRZtTQCfaA3e w7UU+CHKRakeqwVKR2DH8lM= =76X+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403396: enigmail: security issue: attachments may be not encrypted
close 403396 thanks Heya, although I'm still not sure if this was a bug in 2:0.94.1-1 or if it was just my fault - at least the error didn't occur anymore in the last time. I didn't check if it was just fixed by 2:0.94.2-1 or just *someweirdthinggoingaway*, though. enigmail works just fine now. At least another bug closed :) Thanks, Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407461: boinc-client sends bogus platform '' on amd64
On 3/3/07, Thibaut VARENE [EMAIL PROTECTED] wrote: On 3/3/07, Frank S. Thomas [EMAIL PROTECTED] wrote: Hi Steffen, hi Thibaut, On Wednesday 24 January 2007 10:25, Steffen Moeller wrote: For the patch, maybe one should just check if the string to be strdup-ped is not empty? The idea behind the patch from how I understood it is that once can disguise the 64bit machine as a 32bit one and thus also work on the otherwise beloved 32bit-only projects. Yes that is the general idea. It took me some time but I've now posted packages of BOINC 5.8.16 to our repository[1]. This version does exactly what Steffen proposed, it only resets projects if statefile.platform_name is not empty. Thibaut, it would be nice if you could build 5.8.16 on amd64 and check if it really fixes #407461. According to my testing after /upgrading/ from previous fixed 5.4.11, pristine 5.8.16 doesn't seem to break anything. You should not work at 04:26 in the morning. :-) I fully agree. Hehe, I tend to do that more often than not ;) It wasn't intended but it seems I sent my previous email at 4:26 again ;P I should get a life =] Cheers T-Bone -- Thibaut VARENE http://www.parisc-linux.org/~varenet/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413042: zaptel-source:
I was able to reinstall the stock modules this Saturday - it appears to work. Doing more digging in the Make file - the kernel flag is already there. Please close this bug - looks like it is a different problem. Karl Schmidt EMail [EMAIL PROTECTED] Transtronics, Inc. WEB http://xtronics.com 3209 West 9th StreetPh (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Why are so many spending time watching dark movies about hopelessness, the macabre, and perversion; why are they reading books about unfaithfulness and self destruction? Why is nothing uplifting, also considered 'cool' or entertaining? -kps -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406853: updated patch for 5.8.16
On Sun, 4 Mar 2007 01:07:04 +0100 Thibaut VARENE [EMAIL PROTECTED] wrote: [...] OK it seems I was a bit too quick. ia64 /proc/cpuinfo content changed between 2.6.18 and 2.6.19 it seems (see http://www.pateam.org/archive/tmp/boinc/cpuinfo-ia64-recentkernel.txt), so I'll have to work around that... New patch sometime tomorrow, probably. T-Bone -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407361: libtowitoko2: postinst calls wrong paramter for pscd restart install fails
On Fri, Mar 02, 2007 at 12:43:29PM -0300, Gustavo Franco wrote: tags 407361 patch thanks Please consider the following patches to fix this bug that i intent to NMU soon. --- libtowitoko2.postrm2007-03-02 12:30:58.0 -0300 +++ libtowitoko2.postrm 2007-03-02 12:41:02.0 -0300 @@ -23,7 +23,9 @@ # restart pcscd (PCSC daemon) if the package is installed # and if pcscd is running if [ -x /etc/init.d/pcscd ]; then - /etc/init.d/pcscd restart-if-running 3/dev/null || true + if [ `pidof pcscd` ]; then +/etc/init.d/pcscd restart 3/dev/null || true + fi fi Please see policy 9.3.3 for an explanation of why this patch is incorrect (as is the original code). Also, if using invoke-rc.d as described in policy, you can arguably do without the pidof check at all, since it's the admin's responsibility to set a policy for the daemon if they don't want it to be started. (The most straightforward way to do that is by turning it off in the relevant runlevel.) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413309: uswsusp: Adding System76 Darter laptop to the whitelist?
Package: uswsusp
Version: 0.6~cvs20070202-1
Severity: normal
Tags: patch
I have submitted this information upstream, but I'm including it here in case
you're interested
in adding this machine to the s2ram whitelist in the meantime.
{ ASUSTeK Computer Inc., Z35FM ,, ,
S3_BIOS|PCI_SAVE },
It is for the System76 Darter laptop which ship (and work out of the box) with
Ubuntu. This patch
makes it also work with Debian.
Francois
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#410695: zope2.7 causqe upgrade failure
On Fri, Mar 02, 2007 at 07:49:53PM +0100, Josselin Mouette wrote: I have already encountered similar problems in the past, with GConf, and they were triggered by a circular dependency. It seems that APT is unable to deal with such dependencies correctly, as it removes packages depending on each other in random order (which is fair) but can also remove one of them before packages depending on the other are removed. Sorry, can you point to the dependency loop at work here? I didn't notice one in my examination. The solution is, in such cases, to make APT remove all packages depending on either of those in the dependency loop, then remove the loop itself. This is unfortunately far from trivial to implement, and - let's be realistic - impossible to do before the release. Agreed. As the recommended upgrade path from sarge-etch is aptitude rather than apt, the main reason I've left this as 'serious' is concern that the cause is common to both apt-get and aptitude and just triggers sooner with apt-get (which seems to be the case if the problem is the dependency loop bug), and that, in the absence of clear understanding of the origin of the bug, there could be a significant number of other upgrade scenarios where apt would fail. But if this only affects circular dependencies, that seems unlikely. An acceptable workaround would be to upload a dummy zope2.7 package, which doesn't depend on python2.3, and would make the transition to zope2.9. At least, such upgrades wouldn't fail. Based on discussions on the -python list, where users insist that it's unacceptable even for zope2.7's removal to be forced on upgrade to etch, it seems unlikely that this would be accepted either. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412899: CVE-2007-1099: dropbear dbclient insufficient warning on hostkey mismatch
The description of this bug in the upstream changelog is: - Security: dbclient previously would prompt to confirm a mismatching hostkey but wouldn't warn loudly. It will now exit upon a mismatch. Why should it didn't warn loudly be a grave security bug? Isn't any sort of prompt already a pretty loud warning in terms of user experience? Did the prompt fail to mention that there was a key mismatch somehow? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
On Sat, Mar 03, 2007 at 08:57:40PM +0100, Steinar H. Gunderson wrote: I talked to the release team -- they'd approve a freeze exception for fixing the shlibs entry. To the Debian-Release team, Could you please confirm that you'd approve a freeze exception to fix the shlibs entry for libblkid1? It would require respinning the debian-installer images, so I want to make sure it would be acceptable before I upload a new set of e2fsprogs packages. The downside if we don't fix this bug is that someone who has sarge installed and then upgrades to nfs-kernel-server without upgrading libblkid1, will suffer bug#413057. The fix is low risk; a one-line fix in debian/rules. Thanks, regards, - Ted -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413057: Bug#413208: Bug#413057: nfs-kernel-server: Exports dont work any more
On Sat, Mar 03, 2007 at 11:50:54PM -0500, Theodore Tso wrote: On Sat, Mar 03, 2007 at 08:57:40PM +0100, Steinar H. Gunderson wrote: I talked to the release team -- they'd approve a freeze exception for fixing the shlibs entry. To the Debian-Release team, Could you please confirm that you'd approve a freeze exception to fix the shlibs entry for libblkid1? It would require respinning the debian-installer images, so I want to make sure it would be acceptable before I upload a new set of e2fsprogs packages. It's acceptable to me; the final d-i images haven't been spun yet for etch, and anyway a one-line change for a shlibs fix isn't exactly a big delta so I don't see a reason to respin even if we did have version skew. (I.e., the source requirements are still satisfied for d-i as much as they are for any random other package that might happen to be built against a previous version of libblkid1, no?) Anyway, cc:ed to Frans to get input from the d-i side. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413311: linux-image-2.6.18-4-686: Install routine fails due to readlink error
Package: linux-image-2.6.18-4-686 Version: 2.6.18.dfsg.1-11 Severity: grave Justification: renders package unusable Attempting to do an upgrade produces the following error: Setting up linux-image-2.6.18-4-686 (2.6.18.dfsg.1-11) ... Running depmod. Finding valid ramdisk creators. Using mkinitrd.yaird to build the ramdisk. readlink: invalid option -- m Try `readlink --help' for more information. readlink: invalid option -- m Try `readlink --help' for more information. Failed to symbolic-link initrd.img-2.6.18-4-686 to initrd.img. dpkg: error processing linux-image-2.6.18-4-686 (--configure): subprocess post-installation script returned error exit status 17 Errors were encountered while processing: linux-image-2.6.18-4-686 E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: A quick check of the man page for readlink does indeed show that there is no such option. So, the kernel install is left in a partial state, and attempting to remove linux-image-2.6.18-4-686 with aptitude attempts to remove other packages as well, such as linux-image-686. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.18-4-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-4-686 depends on: ii coreutils 5.2.1-2The GNU core utilities ii debconf [debconf-2.0] 1.4.30.13 Debian configuration management sy ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo ii yaird [linux-initramfs-tool] 0.0.12-18 Yet Another mkInitRD -- debconf information: linux-image-2.6.18-4-686/preinst/failed-to-move-modules-2.6.18-4-686: linux-image-2.6.18-4-686/preinst/lilo-initrd-2.6.18-4-686: true linux-image-2.6.18-4-686/preinst/elilo-initrd-2.6.18-4-686: true linux-image-2.6.18-4-686/preinst/overwriting-modules-2.6.18-4-686: true linux-image-2.6.18-4-686/prerm/removing-running-kernel-2.6.18-4-686: true linux-image-2.6.18-4-686/prerm/would-invalidate-boot-loader-2.6.18-4-686: true linux-image-2.6.18-4-686/postinst/bootloader-test-error-2.6.18-4-686: linux-image-2.6.18-4-686/preinst/abort-overwrite-2.6.18-4-686: linux-image-2.6.18-4-686/postinst/old-system-map-link-2.6.18-4-686: true linux-image-2.6.18-4-686/postinst/depmod-error-2.6.18-4-686: false linux-image-2.6.18-4-686/preinst/abort-install-2.6.18-4-686: linux-image-2.6.18-4-686/postinst/depmod-error-initrd-2.6.18-4-686: false linux-image-2.6.18-4-686/postinst/old-initrd-link-2.6.18-4-686: true linux-image-2.6.18-4-686/preinst/bootloader-initrd-2.6.18-4-686: true * linux-image-2.6.18-4-686/preinst/already-running-this-2.6.18-4-686: linux-image-2.6.18-4-686/postinst/old-dir-initrd-link-2.6.18-4-686: true linux-image-2.6.18-4-686/postinst/kimage-is-a-directory: shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-4-686/preinst/lilo-has-ramdisk: linux-image-2.6.18-4-686/postinst/bootloader-error-2.6.18-4-686: linux-image-2.6.18-4-686/preinst/initrd-2.6.18-4-686: linux-image-2.6.18-4-686/postinst/create-kimage-link-2.6.18-4-686: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413310: zzuf: [patch] Allow LD_PRELOADing other libraries
Package: zzuf
Version: 0.8.1-1
Severity: wishlist
Tags: patch
Hi,
I found it useful to allow preloading other libraries when using zzuf.
Here's a patch for that:
diff -ur zzuf-0.8.1/src/zzuf.c zzuf-0.8.1.sli/src/zzuf.c
--- zzuf-0.8.1/src/zzuf.c 2007-03-02 01:51:54.0 +0200
+++ zzuf-0.8.1.sli/src/zzuf.c 2007-03-04 06:23:16.0 +0200
@@ -837,7 +837,7 @@
char buf[64];
#if defined HAVE_FORK
static int const files[] = { DEBUG_FILENO, STDERR_FILENO, STDOUT_FILENO };
-char *libpath, *tmp;
+char *libpath, *tmp, *old_preload, *new_preload;
int pid, j, len = strlen(opts-oldargv[0]);
# if defined __APPLE__
# define FILENAME libzzuf.dylib
@@ -910,10 +910,27 @@
strcpy(tmp ? tmp + 1 : libpath, .libs/ FILENAME EXTRAINFO);
if(ret == 0)
-setenv(PRELOAD, libpath, 1);
+{
+ old_preload = getenv(PRELOAD);
+ new_preload = malloc(strlen(old_preload)+strlen(libpath)+2);
+ strcpy(new_preload, old_preload);
+ strcat(new_preload, :);
+ strcat(new_preload, libpath);
+setenv(PRELOAD, new_preload, 1);
+}
else
-setenv(PRELOAD, LIBDIR / FILENAME EXTRAINFO, 1);
+{
+ old_preload = getenv(PRELOAD);
+ new_preload =
+ malloc(strlen(old_preload)+
+ strlen(LIBDIR / FILENAME EXTRAINFO)+2);
+ strcpy(new_preload, old_preload);
+ strcat(new_preload, :);
+ strcat(new_preload, LIBDIR / FILENAME EXTRAINFO);
+ setenv(PRELOAD, new_preload, 1);
+}
free(libpath);
+free(new_preload);
if(execvp(opts-newargv[0], opts-newargv))
{
Sami
-- System Information:
Debian Release: 4.0
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-amd64
Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15)
Versions of packages zzuf depends on:
ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries
zzuf recommends no packages.
-- no debconf information
signature.asc
Description: Digital signature
Bug#413312: gauche: New upstream release 0.8.9
Package: gauche Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, gauche 0.8.9 was released, it includes a lot of bug fixes. see http://www.shiro.dreamhost.com/scheme/gauche/index.html Please update your package to 0.8.9 based one. Thanks. - -- Regards, Hideki Yamane -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF6lcfIu0hy8THJksRAs6VAJ0ZNEV0PhrNB/H03DwQpQxsx6iu2wCfb7DP qQWVPvnkrYI6pZ1BYIzI76c= =0v9T -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413177: The mouse pointer moves awkwardly on X on Hurd.
Samuel Thibault wrote: Samuel Thibault, le Sat 03 Mar 2007 21:36:28 +0100, a écrit : I had to fix the TODO of my patch, it seems to work fine now: please try to replace debian/patches/20_mmx_support.patch with http://dept-info.labri.fr/~thibault/tmp/patch-gnumach-mmx and rebuild the package, it works for me. (and please try to reproduce 413185's bug, in case that's actually the same). I repackaged the official souce of gnumach (2:1.3.99.dfsg.cvs20070211-1) with replaced debian/patches/20_mmx_support.patch and installed it, I confirmed the problem solved. [EMAIL PROTECTED] wrote: I also get some other X oddities with the new gnumach package: WindowMaker segfaults on startup. And if the session fails to come up (because of an unrelated problem in my strange environment), instead of the X server just restarting once and sitting there as it normally does, it goes into a loop restarting again and again; also, monitor timings are wrong after restart(s). None of this happens with the older package. Although mouse's problem was certainly solved, it was confirmed that X without WM restarted again after the logout. I suggest that it may be another problem perhaps. Hiroyuki -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413311: Acknowledgement (linux-image-2.6.18-4-686: Install routine fails due to readlink error)
The problem appears to be caused by unresolved dependencies when tracking stable, but using kernel packages from testing or unstable. The follwing steps are needed to get this situation straightened out: 1. aptitude remove linux-image-2.6.18-4-686 2. aptitude install coreutils/unstable 3. aptitude install linux-image-686/unstable The key packages which seem to be needed as part of the upgrade are coreutils and libc6-i686, which don't seem to get pulled in properly as dependencies. However, the manual procedure *did* resolve the issue on my system. -- Oh, look: rocks! -- Doctor Who, Destiny of the Daleks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413314: Iptraf doesn't generates log when called from command line
Package: iptraf Version: 3.0.0-3 2 Hi, i'm using Debian Etch and tried to run iptraf as root with the following command: iptraf -s eth0 -L ./fabiano.log -B So it should run in background (-B), runing the TCP and UDP monitor in the eth0 iface (-s eth0) and saving the results in the file ./fabiano.log. The program starts and goes to background, but nothing is writed in the logfile (except by a header like Wed Feb 21 19:09:16 2007; TCP/UDP service monitor started ). I left the process runing for as long as some hours (3 or 4 hours), and nothing. I already tried to enable loging in the options, and setting the log interval to 1 minute, but it fails anyway. I can give more info if you need. Thanks in advance and sorry for my bad english -- Abraços, Fabiano
Bug#410951: r-other-gking-matchit: sarge to etch upgrade fails
reassign 410951 r-other-gking-matchit tags 410951 -pending thanks On Fri, Mar 02, 2007 at 04:19:15PM -0300, Gustavo Franco wrote: reassign 410951 r-cran-matchit tags 410951 pending thanks I've found that r-other-gking-matchit sarge to etch upgrade fails due to the relaxed dependency on r-cran-matchit [ Depends: r-base-core ( 2.2.0) ], if r-cran-matchit works with r-base-core = 2.4, please update the Depends field to = 2.4.0.20061125-1, otherwhise r-other-gking-matchit, r-cran-matchit and maybe others should be removed. The error message is due to the missing ldpaths on r-base-core 2.2 that is running in the sarge system and satisfies the r-cran-matchit dependency. ldpaths exists on r-base-core 2.4 though. I don't see any problems with the dependencies of r-cran-matchit. r-cran-matchit has a correct, *versioned* dependency on r-base-core ( 2.2.0). This isn't satisfied by any r-base-core package in sarge, only by the r-base-core_2.4.0.20061125-1 package in etch. Furthermore, it's not r-cran-matchit that's failing here. This failure is from the postrm of the *old* version of r-other-gking-matchit, which depends on having a fully-configured r-base-core package installed at the point of postrm upgrade -- a condition which is not guaranteed by policy. The new version of r-base-core is /unpacked/ at this stage, but /usr/lib/R/etc/ldpaths is left as a dangling symlink pointing to /etc/R/ldpaths, which is only created in the r-base-core postinst. So the real bug is in the postrm of the old version of r-other-gking-matchit in sarge. Here's the full sequence in more detail, from an aptitude dist-upgrade: [...] Preparing to replace r-base-core 2.1.0-1 (using .../r-base-core_2.4.0.20061125-1_i386.deb) ... Unpacking replacement r-base-core ... [...] Unpacking replacement r-other-gking-matchit ... /usr/bin/R: line 113: /usr/lib/R/etc/ldpaths: No such file or directory dpkg: warning - old post-removal script returned error exit status 1 dpkg - trying script from the new package instead ... dpkg: error processing /mirror/pool/main/m/matchit/r-other-gking-matchit_2.2-11-1_all.deb (--unpack): there is no script in the new version of the package - giving up [...] Selecting previously deselected package r-cran-matchit. dpkg: considering removing r-other-gking-matchit in favour of r-cran-matchit ... dpkg: yes, will remove r-other-gking-matchit in favour of r-cran-matchit. Unpacking r-cran-matchit (from .../r-cran-matchit_2.2-11-1_all.deb) ... /usr/bin/R: line 113: /usr/lib/R/etc/ldpaths: No such file or directory dpkg: error processing /mirror/pool/main/m/matchit/r-cran-matchit_2.2-11-1_all.deb (--unpack): subprocess post-removal script returned error exit status 1 [...] snip bit where dpkg becomes impressively confused about whose postinst is whose, and gives a postrm error from sudo citing the same problem [...] Setting up r-cran-matchit (2.2-11-1) ... Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done $ dpkg -l r-other-gking-matchit 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) ||/ Name VersionDescription +++-==-==- iH r-other-gking- 1.0-1-1GNU R package of nonparametric matching meth $ Note that at this point, it's trivial to get r-other-gking-matchit properly installed -- all it takes is a second aptitude dist-upgrade or a dpkg --configure --pending. But it does add to the complexity of the upgrade path, and each bug like this increases the probability that a user will end up with a wedged system in the middle of an upgrade. So I'm reassigning this bug back to r-other-gking-matchit, which is both the package with the bug and the only package that can fix the bug. In this case, the fix is simple: all we need is a no-op postrm script to be included in the new version of the r-other-gking-matchit package, which will handle the failed-upgrade case gracefully. For reference, the only thing that the old version of r-other-gking-matchit does in its postrm is: R CMD perl /usr/lib/R/share/perl/build-help.pl --htmllists If that's actually an important thing to have done during the upgrade (the new version of r-other-gking-matchit no longer does this), then it can be cleaned up in the postinst instead. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397973: parted: Fix mac partition table corruption
On Sat, Mar 03, 2007 at 03:25:20AM +0100, David Härdeman wrote: So clearing the flag will only clear it in the internal mac_data structure, it won't cause the system name of the partition to be reset? Or is this handled by mac_partition_set_system? Yes, the system name will not be reset. clearing the flag implies nothing else than that it doesn't apply, it doesn't say what type the partition is after the flag is removed. Which means, AIUI, that clearing the flag is not sufficient to clear the flag on disk, so if a user clears the flag, saves changes, closes parted (or similar), and restarts parted, the flag will show up again, correct? That seems suboptimal to me. If we would set a default, then a partition of type foobar (without the lvm flag set) would get its system type changed if you executed set partnr lvm off in parted. Yes, I understand that's a deficiency of how raid flag support is implemented on mac partition tables. Also, I believe this is the same approach that has been taken in the later versions of the upstream package (see the source package in experimental). Ah well, it's a minor point anyway, compared with the bits that are wholly breaking partman, so I won't insist on it (at least, not here and now). Maintainers, please advise whether you're planning a maintainer upload of parted to fix this for etch, otherwise I'll probably NMU this weekend. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Bug#397973: parted: Fix mac partition table corruption
A further concern on this patch:
On Sat, Mar 03, 2007 at 02:47:04AM +0100, David Härdeman wrote:
diff -ur ./parted-1.7.1.orig/libparted/labels/mac.c
./parted-1.7.1/libparted/labels/mac.c
--- ./parted-1.7.1.orig/libparted/labels/mac.c2006-05-25
19:28:55.0 +0200
+++ ./parted-1.7.1/libparted/labels/mac.c 2007-03-03 02:41:42.0
+0100
@@ -1260,19 +1260,23 @@
return 1;
case PED_PARTITION_LVM:
- mac_data-is_lvm = state;
- if (state)
+ if (state) {
strcpy (mac_data-system_name, Linux_LVM);
- else
- mac_partition_set_system (part, part-fs_type);
+ mac_data-is_lvm = state;
+ } else {
+ if (mac_data-is_lvm)
+ mac_partition_set_system (part, part-fs_type);
+ }
return 1;
So in this case, if (!state), mac_data-is_lvm is never un-set. Is that not
an issue?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface
Hi Michael,
On Saturday 03 March 2007 12:22, Michael Biebl wrote:
Hi,
you will also very likely need the attached patch:
Debian does not use pam_console but uses group membership to control
access to D-Bus. Activating both options in the conf file makes it work
on Debian and Ubuntu.
Thanks very much.
About activating the service, you will very likely have to provide a
D-Bus init script (for /etc/dbus-1/event.d/) comparable to the one from
dhcdbd.
Ok. How would the sequnce number of the wpa_supplicant event.d scriplet be
determined?
Attached is the patch I recently commited to SVN, can you please check it?
Also, an experimental package has been prepared at:
http://users.tpg.com.au/sigm/debian/pkg-wpa/wpasupplicant_0.6.0~cvs20070224-1.dsc
I don't think that NetworkManager uses D-Bus's service autostart
activation, but you can install the attached wpa_supplicant.service to
/usr/share/dbus-1/service/ anyway, for applications that use that
mechanism.
Added.
Thanks, Kel.
Index: debian/changelog
===
--- debian/changelog (revision 799)
+++ debian/changelog (working copy)
@@ -29,13 +29,16 @@
* Install a service file to /usr/share/dbus-1/services/ for dbus aware
applications that may take advantage of that in the future (Michael
Biebl).
+ * Add a dbus event hook for starting wpa_supplicant as a system service.
+ * Add prerm and postinst handling for reloading dbus daemon, and restarting
+or stopping the wpa_supplicant dbus daemon on configure/remove.
* Add support to ifupdown.sh for `wpa-mode' and `wpa-frequency' options used
in IBSS mode. Note that ifupdown.sh does not do any sanity checking for
the other many requirements for using wpa_supplicant in IBSS mode.
* Update XS-Vcs-* fields in control file, add Vcs-Browser token.
* Move debian spcific ifupdown sh glue into debian/ifupdown/.
- -- Kel Modderman [EMAIL PROTECTED] Sun, 4 Mar 2007 14:06:46 +1000
+ -- Kel Modderman [EMAIL PROTECTED] Sun, 4 Mar 2007 15:17:27 +1000
wpasupplicant (0.5.5-4) unstable; urgency=low
Index: debian/rules
===
--- debian/rules (revision 799)
+++ debian/rules (working copy)
@@ -25,6 +25,8 @@
debian/wpasupplicant/sbin/wpa_action
install --mode=644 -D dbus-wpa_supplicant.conf \
debian/wpasupplicant/etc/dbus-1/system.d/wpa_supplicant.conf
+ install --mode=755 -D debian/dbus/wpa_supplicant.dbus-event \
+ debian/wpasupplicant/etc/dbus-1/event.d/23wpa_supplicant
install --mode=644 -D debian/dbus/wpa_supplicant.service \
debian/wpasupplicant/usr/share/dbus-1/services/wpa_supplicant.service
dh_installinit --name=wpa-ifupdown --no-start \
Index: debian/dbus/wpa_supplicant.dbus-event
===
--- debian/dbus/wpa_supplicant.dbus-event (revision 0)
+++ debian/dbus/wpa_supplicant.dbus-event (revision 0)
@@ -0,0 +1,56 @@
+#!/bin/sh
+#
+# wpa_supplicant D-Bus daemon
+#
+# Debian/Ubuntu wpasupplicant Maintainers [EMAIL PROTECTED]
+#
+
+set -e
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+DESC=wpa_supplicant D-Bus daemon
+NAME=wpa_supplicant
+PIDFILE=/var/run/$NAME.dbus.pid
+DAEMON=/sbin/$NAME
+DAEMON_OPTS=-u -B -P $PIDFILE
+SCRIPTNAME=/etc/dbus-1/event.d/23$NAME
+
+test -x $DAEMON || exit 0
+
+. /lib/lsb/init-functions
+
+d_start() {
+ start-stop-daemon --start --quiet --pidfile $PIDFILE \
+ --exec $DAEMON -- $DAEMON_OPTS
+}
+
+d_stop() {
+ start-stop-daemon --stop --quiet --pidfile $PIDFILE \
+ --oknodo --exec $DAEMON
+}
+
+case $1 in
+ start)
+ log_daemon_msg Starting $DESC $NAME
+ d_start
+ log_end_msg $?
+ ;;
+ stop)
+ log_daemon_msg Stopping $DESC $NAME
+ d_stop
+ log_end_msg $?
+ ;;
+ restart|force-reload)
+ log_daemon_msg Restarting $DESC $NAME
+ d_stop
+ sleep 5
+ d_start
+ log_end_msg $?
+ ;;
+ *)
+ echo Usage: $SCRIPTNAME {start|stop|restart|force-reload} 2
+ exit 1
+ ;;
+esac
+
+exit 0
Index: debian/wpasupplicant.postinst
===
--- debian/wpasupplicant.postinst (revision 796)
+++ debian/wpasupplicant.postinst (working copy)
@@ -43,6 +43,16 @@
if dpkg --compare-versions $2 lt 0.4.8-1; then
rm_init_script
fi
+
+ # Ask the bus to reload the config file
+ if [ -x /etc/init.d/dbus ]; then
+ invoke-rc.d dbus force-reload || true
+ fi
+
+ # Restart wpa_supplicant D-Bus service
+ if [ -x /etc/dbus-1/event.d/23wpa_supplicant ]; then
+ /etc/dbus-1/event.d/23wpa_supplicant restart
+ fi
;;
abort-upgrade|abort-deconfigure|abort-remove)
Index: debian/wpasupplicant.prerm
===
--- debian/wpasupplicant.prerm (revision 0)
+++ debian/wpasupplicant.prerm (revision 0)
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+# summary of how this script can be called:
+#* postrm `remove'
+#* postrm `purge'
Bug#412975: quilt-el: please include debian/watch
tags 412975 + pending To check a newest upstream version by uscan, could you please include a debian/watch file in the quilt-el source package as follows? Looks good to me. I'm going to include this file at the next release. Thanks, Satoru -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413315: qemu: No longer allocates I/O address space for PCI devices
Package: qemu Version: 0.9.0-1 Tags: experimental Qemu no longer allocates I/O address space for PCI devices: $ qemu -h | head -n1 QEMU PC emulator version 0.9.0, Copyright (c) 2003-2007 Fabrice Bellard $ echo -e info pci\nquit\n | qemu -hda /dev/zero -monitor stdio \ -nographic -serial null -no-kqemu | grep BAR BAR4: I/O at 0x [0x000e]. BAR0: 32 bit memory at 0xe000 [0xe1ff]. BAR1: 32 bit memory at 0xe200 [0xe2000fff]. BAR0: I/O at 0x [0x00fe]. As you can see, it has used 0x instead of proper addresses. The devices still work in e.g. Linux, because Linux apparently allocates the address space itself. Version 0.8.2 did not have this problem: $ qemu -h | head -n1 QEMU PC emulator version 0.8.2, Copyright (c) 2003-2005 Fabrice Bellard $ echo -e info pci\nquit\n | qemu -hda /dev/zero -monitor stdio \ -nographic -serial null -no-kqemu | grep BAR BAR4: I/O at 0xc000 [0xc00f]. BAR0: 32 bit memory at 0xe000 [0xe1ff]. BAR1: 32 bit memory at 0xe200 [0xe2000fff]. BAR0: I/O at 0xc100 [0xc1ff]. Regards, -- Göran Weinholt [EMAIL PROTECTED] 20 JUSTICE KENNEDY: That seems odd. I mean, 21 Microsoft doesn't say please buy our disk because it's 22 the prettiest disk in the business.
Bug#413184: [EMAIL PROTECTED]: Re: Bug#397973: parted: Fix mac partition table corruption]
Right, forwarding to the right bug, since the main bug moved out from under
me.
- Forwarded message from Steve Langasek [EMAIL PROTECTED] -
From: Steve Langasek [EMAIL PROTECTED]
To: David Härdeman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Bug#397973: parted: Fix mac partition table corruption
Date: Sat, 3 Mar 2007 22:00:59 -0800
On Sat, Mar 03, 2007 at 03:25:20AM +0100, David Härdeman wrote:
So clearing the flag will only clear it in the internal mac_data
structure, it won't cause the system name of the partition to be reset? Or
is this handled by mac_partition_set_system?
Yes, the system name will not be reset. clearing the flag implies
nothing else than that it doesn't apply, it doesn't say what type the
partition is after the flag is removed.
Which means, AIUI, that clearing the flag is not sufficient to clear the
flag on disk, so if a user clears the flag, saves changes, closes parted (or
similar), and restarts parted, the flag will show up again, correct?
That seems suboptimal to me.
If we would set a default, then a partition of type foobar (without the
lvm flag set) would get its system type changed if you executed set
partnr lvm off in parted.
Yes, I understand that's a deficiency of how raid flag support is
implemented on mac partition tables.
Also, I believe this is the same approach that has been taken in the
later versions of the upstream package (see the source package in
experimental).
Ah well, it's a minor point anyway, compared with the bits that are wholly
breaking partman, so I won't insist on it (at least, not here and now).
Maintainers, please advise whether you're planning a maintainer upload of
parted to fix this for etch, otherwise I'll probably NMU this weekend.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
- End forwarded message -
- Forwarded message from Steve Langasek [EMAIL PROTECTED] -
From: Steve Langasek [EMAIL PROTECTED]
To: David Härdeman [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: parted: Fix mac partition table corruption
Date: Sat, 3 Mar 2007 22:05:38 -0800
A further concern on this patch:
On Sat, Mar 03, 2007 at 02:47:04AM +0100, David Härdeman wrote:
diff -ur ./parted-1.7.1.orig/libparted/labels/mac.c
./parted-1.7.1/libparted/labels/mac.c
--- ./parted-1.7.1.orig/libparted/labels/mac.c2006-05-25
19:28:55.0 +0200
+++ ./parted-1.7.1/libparted/labels/mac.c 2007-03-03 02:41:42.0
+0100
@@ -1260,19 +1260,23 @@
return 1;
case PED_PARTITION_LVM:
- mac_data-is_lvm = state;
- if (state)
+ if (state) {
strcpy (mac_data-system_name, Linux_LVM);
- else
- mac_partition_set_system (part, part-fs_type);
+ mac_data-is_lvm = state;
+ } else {
+ if (mac_data-is_lvm)
+ mac_partition_set_system (part, part-fs_type);
+ }
return 1;
So in this case, if (!state), mac_data-is_lvm is never un-set. Is that not
an issue?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
- End forwarded message -
Bug#397457: php5-ming: installation not complete
On Fri, Mar 02, 2007 at 09:18:05PM -0500, Stuart Anderson wrote: After further Sarge-Etchupgrade testing, it seems that this problem is not an occasional fluke, but is at best non-deterministic. It needs to be fixed properly as described in #404159. I don't understand what this has to do with sarge-etch upgrade testing given that php5-ming was not in sarge, hopefully the maintainer can explain (and explain why this should be a release blocker). I have a set of sarge backports of the packages that I have been using on some production servers here. Technically, Steve is right in that this doesn't apply to a sarge-etch upgrade, except on my servers (but see below). The remaining problem, is that the php package changed the scheme it uses for identifying what modules to load. This happened around the time -10 was uploaded, and the problem had not been seen (or at least not recognized) then. The problem is that the php.ini file gets replaced by the php package Uh, no, the php.ini file is only supposed to be replaced by the php package if the administrator *approves* of having the new version installed. That's the administrator's choice; if they choose to discard local changes to this config file from the sarge version, then yeah, any changes from php-ming are going to fall out, but that's hardly RC any more than it's RC when the same thing happens to an admin allowing a conffile to be overwritten. and the addition of the phpN-ming module gets lost. Yes, but only as described above. A 'dpkg-reconfigure phpN-ming' fixes the problem. This bug can be seen in a testing-testing upgrade as well as the sarge-etch upgrade that is only my problem. Bug 404159 is for this situation. Sure. It can also happen in an etch-lenny upgrade in the future. And yes, installing a per-extension file to the conf.d directory is absolutely preferable, but not RC in my opinion. After doing a few more upgrades, I have seen this problem most of the time, instead of the once which made me think it was just some kind of a fluke. This is why I raised the severity. I didn't fix this back in Deceember as I thought the old scheme was still adequate, and I didn't want to be changing postinstalls so late in the release. Recent experience has indicated it needs to be done anyway, so I have set aside some time this weekend to prepare -11 packages. Btw, if anyone can put in a good word for me with the DAM (I'm on the last step of the NM process), I could save the time of hunting down my sponsor to get the -11 packages uploaded. 8-) If you can post the URL for these packages to this bug, I'm sure someone will pick them up for you. Not that I'm opposed to putting in a good word with the DAM, but there's some difference of time scale that applies there... :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413185: When the files are downloaded with apt-get install, the system reboots occasionally.
Michael Banck wrote: Can you install the corresponding version of gnumach-dbg, and change your Grub entry to boot that? If you catch the Mach bug the next time, it should drop you to the kernel debugger; please tell us the address of eip for further information. I was not able to reproduce the phenomenon by the gnumach-dbg kernel (Version: 2:1.3.99.dfsg.cvs20070211-1) though I tested 30 times or more. By way of experiment, when it returned to the gnumach kernel (Version: 2:1.3.99.dfsg.cvs20070211-1) and I tested on the same condition, I reproduced it by the first time. I suggest that this phenomenon doesn't occur in the gnumach-dbg kernel in fact. Hiroyuki -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413316: ltsp-server: incompatible with ltsp-utils
Package: ltsp-server Version: 0.99debian11 Severity: important it seems that ltsp-utils and ltsp-server packages are incompatible... ltsp-utils is used for installing and configuring ltsp 4.x environments using ltsp.org binaries, whereas ltsp-server is used to build ltsp 5 environments using debian binaries. using programs from ltsp-utils on machines that have installed ltsp environments with ltsp-server will quite possibly result in a broken ltsp environment, as they populate /opt/ltsp with totally different binaries. i propose adding a Conflicts: ltsp-utils to ltsp-server, at least until the two different sets of tools become aware of one another and play nicely together. live well, vagrant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385366: libgl1-mesa-dri: Sometimes crashes even without EnablePageFlip
Package: libgl1-mesa-dri Version: 6.5.2-3 Followup-For: Bug #385366 I further tried (again experimental packages) with: Option AccelMethod XAA Option EnablePageFlip 0 and the OSD displayed several times correctly and than it locked up anyway. The time it locked up the OSD touched 2 windows using GL -- I had fgfs running at 1280x960 and below it Atlas maximized to 1400x(1050-panel). The OSD touched both windows. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-4-amd64 Locale: LANG=C, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Versions of packages libgl1-mesa-dri depends on: ii libc6 2.3.6.ds1-13 GNU C Library: Shared libraries ii libdrm2 2.3.0-1 Userspace interface to kernel DRM ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii libgl1-mesa-glx 6.5.2-3 A free implementation of the OpenG Versions of related packages: ii xserver-xorg-core 1.1.1-18+b1 X.Org X server -- core server ii xserver-xorg-video-ati 6.6.3-2 X.Org X server -- ATI display driver libgl1-mesa-dri recommends no packages. -- no debconf information -- Jan 'Bulb' Hudec [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#411953: emacs-lisp-intro: The package has an invariant section
tag 411953 + confirmed thanks Hi, I emailed Richard Stallman (FSF) and Robert Chassell (the original author). Robert replied that he considered the Preface to be a secondary section because it described how he thought of his audience; but that he didn't really care; Richard replied that he Robert's reasons seemed sound, and that he didn't see any reason to take any action. So afaics this is a valid bug, and isn't going to be resolved upstream, so a move to non-free is definitely needed. Cheers, aj signature.asc Description: Digital signature
Bug#411953: emacs-lisp-intro: The package has an invariant section
FWIW, I've uploaded an NMU moving this to non-free. It'll need NEW processing (by someone else) before hitting the archive. Cheers, aj signature.asc Description: Digital signature
Bug#413310: zzuf: [patch] Allow LD_PRELOADing other libraries
On Sun, Mar 04, 2007 at 07:08:13AM +0200, Sami Liedes wrote:
I found it useful to allow preloading other libraries when using zzuf.
Here's a patch for that:
Argh, shouldn't do this when tired. Here's a patch that should work.
Sami
diff -ur zzuf-0.8.1/src/zzuf.c zzuf-0.8.1.sli/src/zzuf.c
--- zzuf-0.8.1/src/zzuf.c 2007-03-02 01:51:54.0 +0200
+++ zzuf-0.8.1.sli/src/zzuf.c 2007-03-04 09:50:13.0 +0200
@@ -837,7 +837,7 @@
char buf[64];
#if defined HAVE_FORK
static int const files[] = { DEBUG_FILENO, STDERR_FILENO, STDOUT_FILENO };
-char *libpath, *tmp;
+char *libpath, *tmp, *old_preload, *new_preload;
int pid, j, len = strlen(opts-oldargv[0]);
# if defined __APPLE__
# define FILENAME libzzuf.dylib
@@ -910,10 +910,31 @@
strcpy(tmp ? tmp + 1 : libpath, .libs/ FILENAME EXTRAINFO);
if(ret == 0)
-setenv(PRELOAD, libpath, 1);
+{
+ old_preload = getenv(PRELOAD);
+ if (!old_preload)
+ old_preload = ;
+ new_preload = malloc(strlen(old_preload)+strlen(libpath)+2);
+ strcpy(new_preload, old_preload);
+ strcat(new_preload, :);
+ strcat(new_preload, libpath);
+setenv(PRELOAD, new_preload, 1);
+}
else
-setenv(PRELOAD, LIBDIR / FILENAME EXTRAINFO, 1);
+{
+ old_preload = getenv(PRELOAD);
+ if (!old_preload)
+ old_preload = ;
+ new_preload =
+ malloc(strlen(old_preload)+
+ strlen(LIBDIR / FILENAME EXTRAINFO)+2);
+ strcpy(new_preload, old_preload);
+ strcat(new_preload, :);
+ strcat(new_preload, LIBDIR / FILENAME EXTRAINFO);
+ setenv(PRELOAD, new_preload, 1);
+}
free(libpath);
+free(new_preload);
if(execvp(opts-newargv[0], opts-newargv))
{
signature.asc
Description: Digital signature
