Bug#298552: Please test unstable version
Sven Arvidsson wrote: Does this bug still happen with the version of gnome-applets from unstable, currently 2.14.3-2? I'm sorry to report that I moved to ubuntu, but the problem wasn't fixed upstream and it is present in the package version 2.16.1-0ubuntu1, present in Edgy Etch. -- Michal begin:vcard fn;quoted-printable:Micha=C5=82 J. Gajda n;quoted-printable:Gajda;Micha=C5=82 J. org:International Institute for Molecular and Cell Biology;Laboratory of Bioinformatics and Protein Engineering email;internet:[EMAIL PROTECTED] title:Senior Research Assistant x-mozilla-html:TRUE version:2.1 end:vcard signature.asc Description: OpenPGP digital signature
Bug#402996: frozen-bubble: lan game impossible
Le jeudi 14 décembre 2006 à 02:47 +0100, Christoph Thielecke a écrit : Package: frozen-bubble Version: 2.1.0-1 Severity: normal *** Please type your report below this line *** if I start a LAN game and a remote server in local lan host a game I cant find the game. The remote server is reachable and if I telnet to the ip address on port 1511 I got a connect. I'm afraid I don't understand what you are trying to do. Is there a public server running in your local LAN? If this is the case, you should run it with the -l option so that it is usable for LAN games as well. -- Josselin Mouette/\./\ Do you have any more insane proposals for me?
Bug#278824: acknowledged by developer ((re-)closing with existing version)
Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #278824: mozilla-thunderbird: Search unusable on 15000+ message folders - sluggish or hangs , which was filed against the mozilla-thunderbird package. It has been marked as closed by one of the developers, namely Alexander Sack [EMAIL PROTECTED]. You should be hearing from them with a substantive response shortly, in case you haven't already. If not, please contact them directly. I'm sorry, I can't reproduce the problem any more. The problem forced me to abandon my delete my old mail archive. However, as of Thunderbird 1.5 it wasn't fixed upstream. -- Michal begin:vcard fn;quoted-printable:Micha=C5=82 J. Gajda n;quoted-printable:Gajda;Micha=C5=82 J. org:International Institute for Molecular and Cell Biology;Laboratory of Bioinformatics and Protein Engineering email;internet:[EMAIL PROTECTED] title:Senior Research Assistant x-mozilla-html:TRUE version:2.1 end:vcard signature.asc Description: OpenPGP digital signature
Bug#403027: Installation report for Netinst CD on Asus U5F laptop
Package: installation-report Severity: normal Boot method: Netinst CD Image version: http://cdimage.debian.org/cdimage/etch_di_rc1/amd64/iso-cd/debian-testing-amd64-netinst.iso downloaded on 2006-12-14 Date: 2006-12-14 15:00:00 GMT+8 Machine: Laptop Asus U5F Processor: Centrino Core2 Duo T5500 Memory: 1Gb Partitions: All 80Gb SATA disk used, d-i did the partitioning mostly automatically: 256Mb of /boot and the rest as an unencrypted LVM volume group. Output of lspci -nn and lspci -vnn: Non available at the moment. Will come on a later installation report, when successful. Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[E] Configure network: [ ] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[O] Clock/timezone setup: [ ] User/password setup:[O] Install tasks: [ ] Install boot loader:[O] Overall install:[E] Comments/Problems: * Network cards I could not access the network using the ipw3945 wireless card. That was expected, since the driver packages are in non-free. I noticed that a package firmware-ipw3945-di_0.3_all.udeb exists, but I could not find any info on how to use it The Ethernet network card did not seem to be detected: with ifconfig I could bring up only a device with a very long MAC. I don't have the model available, but I'll provide it in the next install report. Had I managed to detect the ethernet card I could have tried to use pppoe: I've noticed that there is a udeb for it in the netinst CD, but I haven't seen anything about udeb in the installer. * Partitioning Initially I chose to use LVM plus encryption. After getting the warning about cyphering being untested I selected the option in the warning dialog to not use encryption, but the partitioner would still have all the encription parts turned on. I redid the install and chose plain LVM, then I told it to use the entire disk. At that point creating the volume group failed: in the log, there was the help message of vccreate and at the top it said Please enter physical volume name(s). Later on in the installer I chose to create the volume group, gave it a name and it worked. When I chose to use the whole disk, I got a dialog asking for confirmation because the installer found an existing partition (the MS Windows junk that came with the laptop). The Italian message was: Le seguenti partizioni saranno formattate (part n.1 con fat32) The message probably wanted to say that the existing fat32 partition will be deleted (cancellate), not formatted (formattate). 'volume group' is translated as 'gruppo di volumi'. Personally it would be clearer to me if it were left as 'volume group', but meh. * Other bits Since I could not get any usable network device to work, I tried the netinst installation without network configuration, to at least get a base system. This exposed a couple of quirks: - In the Italian translation, the phrase Se si sta installando dal CD netinst e si sceglie di non usare in mirror ci si troverà solo con un sistema base veramente minimale is repeated twice, the second time with slight variations but same meaning. - I told not to use a mirror, and I got a big red warning saying that the installer could not access the security updates websites and commented them out, and later on I should find out what happened. That message felt very weird, since I just told it not to use a mirror nor to configure the network. - When choosing the system I selected laptop and it asks me to install the binary 1 CD. I don't have the CD, and the menu doesn't have a cancel option, so it looped forever. I'm now downloading http://cdimage.debian.org/cdimage/etch_di_rc1/amd64/iso-cd/debian-testing-amd64-binary-1.iso and trying again. Ciao, Enrico -- 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.18-3-686 Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Bug#402994: use new libpaper hook to track system paper size
Frank Küster [EMAIL PROTECTED] wrote: Second, the files that are affected are currently not configuration files, which is a bug. I should point one thing out for Stephen or anyone else reading this bug report who's not familiar with texconfig: texconfig is already clever enough to notice that it's bound to change a file in /usr/share/texmf, and instead creates a copy of the file in /etc/texmf. So there's no bad bad bad RC bug that a script changes files in dpkg's realm, or similar. It's just a question about what should be a configuration file. Finally, I guess each file that texconfig is able to change should be treated as a configuration file. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#381431: Announce of the upcoming NMU for the phppgadmin package (last one...)
On Thursday 14 December 2006 07:09, Christian Perrier wrote: OK, let's go this way. I proceed as usual, then instead of NMU'ing, I'll send you the NMU patch. Would that be right ? Sure, that would be perfect :) -- Warp Networks | [EMAIL PROTECTED]| http://warp.es Debian| [EMAIL PROTECTED] | http://www.debian.org
Bug#403028: mrt: FTBFS on GNU/kFreeBSD (due to missing build-dep on libkvm-dev)
Package: mrt Severity: important Version: 2.2.2a-6 Tags: patch Hi, the current version fails to build on GNU/kFreeBSD. It needs to build-dep on libkvm-dev. It would be nice if it could be included in the next upload. Thanks in advance Petr --- debian/control~ 2006-12-14 10:12:29.0 +0100 +++ debian/control 2006-12-14 10:12:29.0 +0100 @@ -2,7 +2,7 @@ Section: net Priority: optional Maintainer: Ernesto Nadir Crespo Avila [EMAIL PROTECTED] -Build-Depends: debhelper (= 5) +Build-Depends: debhelper (= 5), libkvm-dev [kfreebsd-i386 kfreebsd-amd64] Standards-Version: 3.7.2 Package: mrt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403026: TeX Policy, TEXMFSYSCONFIG and TeXlive (was: lenny release goals and the tetex-texlive transition)
Package: tex-common Version: 0.42 Severity: normal Norbert Preining [EMAIL PROTECTED] wrote: On Die, 12 Dez 2006, Frank Küster wrote: * Decide whether TeXlive continues to work with conffile links and a separate /etc/texmf/texlive, or switch to the teTeX scheme, and implement I don't understand? TEXMFSYSCONFIG=/etc/texmf Consequently, the files that are now below /etc/texmf/texlive could be at their ordinary places instead, /etc/texmf/texlive/dvips/config.ps - /etc/texmf/dvips/config and the symlinks removed. The current setup is a bit against the written TeX policy, but it's necessary for cooperation with tetex. Now, if we drop tetex, we can reconsider this: Either move them into their ordinary texconfig locations, or keep it and change policy. The drawback of the first (and of the way policy is written in general) is that we get the same problem again if someone packages miktex in 10 years (or so), or that we need to deal with shared configuration files. On the other hand, if we keep them in the texlive subdirectory, the whole purpose of TEXMFSYSCONFIG is defeated. I think the long discussion about tetex's adoption of this hierarchy has shown that the issue is complex, but that all in all having and using TEXMFSYSCONFIG is better. Maybe shared configuration files are not a bad idea, I should look up the Debian Policy about that. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#402946: linux-image-2.6.18-3-686: wrong harddisk size detected
The kernel 2.6.18-3-686 detects a wrong harddisk size, which leads to access beyond end of device errors and thereby makes the system unusable. The corresponding partition cannot be mounted. Even cfdisk does not run, because it detects a corrupted partition table. It also reports that the partition exceeds the disk, why? The error message just reports that it tries to access sectors beyond the reported size. Dec 13 13:35:04 werckmeister kernel: sda: p7 exceeds device capacity The drive has 80MB, as stated by the manufacturer and correctly reported by the 2.6.17 and previous kernels: SCSI device sda: 156368016 512-byte hdwr sectors (80060 MB). The disc was partitioned when the kernel saw the whole disk, i.e. 156368016 blocks. 2.6.18 sees only 139968963 blocks (16399053 blocks are missing), but the last partition ends after block 139968963. Partition table: First Last # Type Sector Sector OffsetLength Filesystem Type (ID) Flag -- --- --- --- -- --- 1 Primary 0 146834099 63 146834100 W95 Ext'd (LBA) (0F) Boot 5 Logical 63*1108484 63 1108422*Linux swap / So (82) None 6 Logical 110848532579819 6331471335 Linux (83) None 7 Logical32579820 146834099 63 114254280 Linux (83) None Pri/Log 146834100 156360644 0 9526545 Free Space None Klaus pgpYdeQYPuROA.pgp Description: PGP signature
Bug#403031: finish-install: serial console detection is not matching what is done in rootskel/console-detect
Package: finish-install Version: 2.6 Severity: normal Well, while working on the efika support, i found out that more problematic serial console setups break finish-install. The efika has ttyPSC0 as console. This is in part due to the fact that rootskel/console-detect uses : /dev/console|/dev/tts/*|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*) TERM_TYPE=serial Which is a lot more complete than the : case $console in ttyS*|hvc*|hvsi*) used in finish-install/S90console. Furthermore, this forces us to modify the code in two places for each new kind of serial console, and with the crazy scheme of the linux upstream folk to call each different serial console with its own name, this may happen a lot in the future. I thus suggest that the finish-install/S90console be changed to : case $TERM_TYPE in serial ) Which, unless i miss something, would catch all those consoles detected by the rootskel/console-detect code, and thanks to the remaniement of my preceding suggestion by frans/colin, will allow to do the right thing. I think that it would be useful to have some override of the TERM_TYPE detection, in case of some new future serial console kind not catched by the above rootskel/console-detect code, i don't know if this is already possible, but this would be a separate bug report maybe. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402844: libsasl2-modules-gssapi-mit: sasl-sample-client/sasl-sample-server authentication fails with GSSAPI mechanism
Michael, Thanks for your report! On Tue, 2006-12-12 at 18:58 -0500, Michael Richters wrote: GSSAPI authentication does not appear to work for the SASL sample client and server. Of course, it is possible that I'm not doing something wrong, given the lack of examples in the documentation. The documentation is really lacking. That's one of the items on our todo list, which won't be in shape for etch, unfortunately. But we try to collect as much information as possible and hope to put together better documentation later. Could you please try the following: On the client: $ kinit $ sasl-sample-client -m gssapi -n geomancer.nutwerk.org On the server: $ sasl-sample-server Then manually copy and paste the server output (the whole line, starting with and including S: or C:) to stdin on the client and vice versa, until you either get success or failure. Thanks, -- Fabian Fagerholm [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#402702: renrot: Extra apostrophe in man page
Chung-chieh Shan wrote: In the renrot man page, in the description section, it's thumbnail should be its thumbnail. Thank you. I've fixed this and similar issues in the upstream. It would be absent in the next release. -- With best regards, Andy Shevchenko. mailto: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367363: bug #367363
On Mon, Dec 11, 2006 at 12:17:56PM +0100, rossi.tek wrote: Is there any news on bug #367363? It seems that bug has slipped through the cracks; I forgot about it. Could you please try sending a fax in verbose mode (-v) and send the log to the bug? Thanks, -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402649: udev detects harddisk in USB case as non removable and thus sets wrong permissions for device nodes
Hi, 2006 m. gruodis 14 d., ketvirtadienis 09:34, Martin Steigerwald rašė: yes, I forgot those. I sent them with my last mail [EMAIL PROTECTED]:~ dcop kded mediamanager properties /dev/sda1 [ .. snip .. ] [EMAIL PROTECTED]:~ dcop kded mediamanager properties /dev/sda2 [ .. snip .. ] Thanks. And here it is my another request: 1. $ wget http://alioth.debian.org/~modax-guest/kdebase-kio-plugins_3.5.5a.dfsg.1-4~mdx1_i386.deb 2. # dpkg -i --force-all kdebase-kio-plugins_3.5.5a.dfsg.1-4~mdx1_i386.deb (I think, force will be needed due to dependences). 3. $ killall kded; kdeinit kded; dcop kicker kicker restart -- OR -- log off log on to KDE 4. Now try to mount your hard drive. It will fail, however, you should see a more verbose error message. Please post it here. 5. Finally, when done, revert back to previous kdebase-kio-plugins either by downloading and # dpkg -i it or # apt-get -f install (if it does the correct thing). Then repeat step 3. pgp8ifBCB0CUc.pgp Description: PGP signature
Bug#403033: net-tools: Strange %s in error message
Package: net-tools Version: 1.60-17 Severity: minor I don't know if it's right, I just thought it is strange: [EMAIL PROTECTED]:~$ /sbin/ifconfig asdf asdf: erro obtendo informações da interface: %s: dispositivo não encontrado Is this %s right? -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8) Versions of packages net-tools depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries net-tools recommends no packages. -- no debconf information
Bug#402922: segfault in mplayer own mpeg2 library
On Wed, Dec 13, 2006 at 04:00:02PM +0100, Pierre Habouzit wrote: Package: mplayer Version: 1.0~rc1-2 Severity: grave Tags: security Justification: user security hole While playing http://madism.org/~madcoder/pub/foobar.mpeg mplayer segfaults, somewhere in mpeg2_idct_copy_mmx. xine and vlc that use debian libpmeg2 instead do not segfault. I'm not 100% sure it's a security problem, but it's very likely. my opinion so far is that this is not a security problem this is my feeling: it may be that the mpeg stream does not contain proper motion-compensate data, or an I frame; libmpcodecs/vd_libmpeg2.c does not detect this, and tries to motion-compensate, and fails. This then would not be a possible path for attack: there is no memory or stack that may be overflown here (but rather there is allocated memory that is then not initialized) a. -- Andrea Mennucc The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do. Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403034: Deep MIME Nesting Content Filter Bypass
Package: clamav Version: 0.88.7-1 Severity: grave Tags: security While the new 0.88.7 version fixes CVE-2006-6406 and CVE-2006-6481 the update introduces another flaw that lets viruses pass undetected. If a virus is nested deeper than the --max-mail-recursion limit, the file will pass and ClamAV's exit code indicates that the file was scanned properly. Again, details, PoC, and discussion can be found at http://www.quantenblog.net/security/virus-scanner-bypass. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403030: wordnet is not included in dictd's dictionary database
Package: wordnet Version: 1:2.1-4 Severity: important X-Debbugs-Cc: [EMAIL PROTECTED] Wordnet is one of the most comprehensive lexical database. I noticed that now dict-wn is not available anymore and wordnet package doesn't register itself under dictd's list of available dictionary databases. I checked the changelog but couldn't find anything relevant. Hence, filing under severity important. Wordnet should be part of dictd's dictionary database. Please. Thanks, Ritesh -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing'), (550, 'unstable'), (500, 'stable'), (350, 'experimental'), (50, 'feisty') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19-xps Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages wordnet depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-4 X11 client-side library ii tcl8.4 8.4.12-1.1 Tcl (the Tool Command Language) v8 ii tk8.48.4.12-1Tk toolkit for Tcl and X11, v8.4 - ii wordnet-base 1:2.1-4 electronic lexical database of Eng wordnet recommends no packages. -- no debconf information -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. Stealing logic from one person is plagiarism, stealing from many is research. The great are those who achieve the impossible, the petty are those who cannot - rrs pgp0o6LNkIfdA.pgp Description: PGP signature
Bug#403032: kchmviewer: Menu entry should go under Apps/Viewers
Package: kchmviewer Version: 2.7-1 Severity: minor This is a viewing program (as the name shows) so seeing it under Apps/Editors has always bothered me. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#337317: seeing this problem (or something very similar) with 0.6.11-1
Daniel Kahn Gillmor wrote: hrm. /dev/bus/usb appears to be created/managed by udev entirely, but /proc/bus/usb is exported (as an empty directory) by the kernel, and then usbfs is mounted on top of that. mounting usbfs should no longer be necessary. since debian added udev with /dev/bus/usb they should have checked and modified all usb applications to use that instead of /proc/bus/usb. [0 [EMAIL PROTECTED] ~]# rmdir /proc/bus/usb rmdir: /proc/bus/usb: Operation not permitted thats ok, you can't remove it. udev will start two processes, one tries the /dev/bus/usb device, one tries the /proc/bus/usb device, and the one who can claim the interface wins. i can see why that would be a problem. i'm just not sure what to do about it. Maybe this bug should be reassigned to udev or initscripts? check if the policy has something about usb devices. if not it could be best to start discussing that - like agreeing on a migration path away from /proc/bus/usb (which is called obsolete by greg kh IIRC), and maybe also touching the topic of the duplicate events and how to suppress them - that can be done either central in udev or individually in each package. with /proc/bus/usb unmounted, i'm still getting two ifdhandlers, but with slightly different messages than before: Dec 13 16:37:56 squeak ifdhandler[14736]: Unable to open USB device /proc/bus/usb/002/032: No such file or directory Dec 13 16:37:56 squeak ifdhandler[14736]: usb:/proc/bus/usb/002/032: initialization failed (driver egate) Dec 13 16:37:56 squeak ifdhandler[14736]: unable to open reader egate usb /proc/bus/usb/002/032 this is ok. since /proc/bus/usb does not exist, the kernel or udev shouldn't throw an event for it. whether this is a bug or not should be discussed with kernel and udev teams. was there still a reader running after this? I'm asking because I'm quite confused. if there was one running then this: Dec 13 16:37:56 squeak ifdhandler[14728]: Unable to open USB device /dev/usbdev2.32_ep00: No such device or address Dec 13 16:37:56 squeak ifdhandler[14728]: usb:/dev/usbdev2.32_ep00: initialization failed (driver egate) Dec 13 16:37:56 squeak ifdhandler[14728]: unable to open reader egate usb /dev/usbdev2.32_ep00 indicates a third event and a third ifdhandler was launched. end point devices? when did they get added? are we breaking compatibility once more? I was nice all year, why is santa claus bringing compatibility issues / api change / new problems for xmas? I haven't fiddled with /lib/udev/openct_usb yet. might be necessary. if you want to hack it, that would be the fastest way to get towards a solution. but the clean way is to get some statement from udev and kernel folks and agree on a policy, and get everyone agree on a best practice. udev adding changes without telling everyone involved is not really a nice way. (and it would have be easy for anyone to have a look which packages contain udev rules files and let those maintainers know.) hrm. i still don't know why udev should be spawning two ifdhandler processes if /proc/bus/usb is unmounted. in my opinion a udev or kernel bug. but the openct_usb script could do a test -e $DEVICE before running openct-control. still I think that is a work around and it is better to fix udev or kernel, but others might disagree. If that's not OK, maybe this should be reassigned to udev. But if that is deemed acceptable, maybe the bug should be with the initscripts package, for including an /etc/init.d/mountkernfs.sh which mounts /proc/bus/usb even on systems which have /dev/bus/usb already? udev added /dev/bus/usb at least half a year ago. I wonder why noone triggered a policy process and came up with a migration plan. IMO /proc/bus/usb is obsolete, and distributions should simply drop it (and fix all packages to use /dev/bus/usb instead). but I guess noone stepped forward to coordinate the process, and thus nothing happened? no idea, after all I don't know what the udev and kernel folks are up to. best is to have a chat with them about what their plans are and how they see it. would be sad if they put the burdon of handling everything on the applications. you could add checks to openct_usb to ignore events if the file does not exist, and to filter out those end point events. but still if the default etch installation has both /dev/bus/usb and /proc/bus/usb you will get two events and two ifdhandler and which one succeeds will be random. except if you filter one out hard again (e.g. ignore all /proc events). but that is somehow a hack I think, not a clean solution. if test -n $DEVICE then if ! test -e $DEVICE then exit 0 fi if echo $DEVICE |grep -q _ep then exit 0 fi if echo $DEVICE |grep -q /proc then exit 0 fi fi if test -n $DEVNAME then if ! test -e $DEVNAME then exit 0 fi if
Bug#402829: mantis: not supportable by the security team
Hi Thijs, thanks for you to participate in the discussion. I have seen that you and Moritz has been the persons who had been active in mantis bug fixing. Thijs Kinkhorst wrote: It makes me somehow angry that i invested so much work in bringing mantis back in a good shape, when people can block its release by just saying 'hey it had a bad history'. You did not add here that the first result of this work only entered Debian a couple of weeks ago. While I do value the fact that you've been fixing up the package, the few weeks do not give much time to get a reliable indication of whether the package has made a radical change. Hmm.. yeah. I accept this argument. Unfortunately i will have to accept it. Lets say: I just missed the right point in time to adopt mantis. Given the information by Moritz that it had 21 vulnerabilities it should be worth to mention that almost 50% of the bugs I've seen affected almost dusty versions of mantis that are *far* away from the current release. I'm sorry, but I do not buy this. I've fixed a large number of bugs in the sarge version of Mantis. The sarge version is 1.5 years old. That can hardly be called far away or dusty, can it? The reason why i call the sarge release dusty is not because of its age in years. Its because of the fact that the sarge release shouldn't have been released as it is. It would have been a release were i would have totally agreed to block it for release. But that did not happen. Instead Sarge was shipped with a full-of-bugs (not only security related, but related to packaging) mantis package. Now we try to fix mistakes of the past, if we block the current mantis package from etch. But that will not help much, for the trust the Debian users who wanted to use a mantis Debian package lost. Please provide it then. I do not think it's convincing to use arguments like it was just dusty to support your point. Debian had the most recent version of mantis when sarge released. This didn't seem to be quite immune from vulnerabilities. Well actually you are right. Just saying its dusty isn't right. My fault. But see my above comments about the sarge release. It wasn't suitable for the company i work in, and if you have a close look at the bug reports, other people stuck on the same problems. Thats a good indication that it wasn't in release quality. Even that it wasn't in any half-good quality at all. It was dangerous to ship such a broken package in a stable distribution and *that* is IMHO the main reason, why it has a low user base according to popcon. But this goes for any other package aswell - the point is that these numbers can be seen in a relative way: there's a lot of packages that have way higher numbers. The security team only has a fixed amount of time available to support them. If a package has an exceptionally high amount of work compared to a relatively low usage number, this can be a valid argument. I will stop here on without arguing about popcon, that its a comparisons between apples and bananas, that someone should note that mantis 0.19 were not installable for a lot of people, etc. But just one thing: Have a look at the upstreams bugtracker and the sponsors list. I don't think that this says: Mantis has a poor userbase, but: Debian is not able to provide us with a proper package of mantis, so we don't use there mantis packages. But that *does* require concrete evidence that something has indeed changed. Especially if you're requesting something like this *very* shortly before the release, with little time to revert any mistakes. Yes, you are right. Currently is not the right time to make mistakes, cause we can't revert them in time. But what if blocking mantis from stable would be a mistake? I'm sure it is, even though i understand your arguments and will finally accept them. Off course this removal from etch will be a loose of trust at the remaining 40 people using Debian's mantis packages. But at least they will have the choice to use mantis/unstable or mantis from the backports. It's up to you now: show why mantis deserves the second chance, and why it's essential that it deserves it, at this point, instead of e.g. for Lenny. Personally I've thought this point over. But i will not be able to change your minds until a release of etch. So i will resign and accept your arguments and your doubts and will not discuss further. Until the next release of Debian I will try to keep mantis packages as up-to-date as possible and then we will hopefully re-integrate it. Greets Patrick signature.asc Description: OpenPGP digital signature
Bug#402938: Properties difference causes unison to crash
For some reason, I have got following email with subject Properties difference causes unison to crash. I suspect broken forwarding somewhere. - Arieh HOLA: NO RECIBI TU MAIL YA QUE ESTA CASILLA ESTA DESACTIVADA (ESTO ES UNA RESPUESTA AUTOMATICA) POR FAVOR REENVIARLO A [EMAIL PROTECTED] con copia a [EMAIL PROTECTED] Y AGENDAR ESTAS DOS DIRECCIONES COMO MI NUEVA DIRECCION DE CORREO MUCHAS GRACIAS Luciano Mari Brusco Ejecutivo de Cuenta Centro Comercial Buenos Aires. Departamento PYMES ( 011) 15 5883-2464 -- Arieh
Bug#403029: visualboyadvance: FTBFS on kfreebsd-i386 (due to missing build-dep on nasm)
Package: visualboyadvance Severity: important Version: 1.7.2-6 Tags: patch Hi, the current version fails to build on kfreebsd-i386. It needs to build-dep on nasm on all architectures with i386 CPU, currently by nasm [i386 kfreebsd-i386 hurd-i386]. It would be nice if it could be included in the next upload. Thanks in advance Petr --- debian/control~ 2006-12-14 10:21:32.0 +0100 +++ debian/control 2006-12-14 10:21:32.0 +0100 @@ -3,7 +3,7 @@ Priority: extra Maintainer: Jose Carlos Medeiros [EMAIL PROTECTED] Uploaders: Ola Lundqvist [EMAIL PROTECTED] -Build-Depends: debhelper (= 5), autotools-dev, libsdl1.2-dev, zlib1g-dev, nasm [i386], libtool, libpng12-dev | libpng-dev, libx11-dev, libxt-dev, x-dev, dpatch, docbook-to-man, libgtkmm-2.4-dev, libglademm-2.4-dev +Build-Depends: debhelper (= 5), autotools-dev, libsdl1.2-dev, zlib1g-dev, nasm [i386 kfreebsd-i386 hurd-i386], libtool, libpng12-dev | libpng-dev, libx11-dev, libxt-dev, x-dev, dpatch, docbook-to-man, libgtkmm-2.4-dev, libglademm-2.4-dev Standards-Version: 3.6.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397852: please package bzr 0.13 / new upstream version available
Hi, As an add on: On the 5th December 2006, version 0.13 was released. It may close #396227 as the network part is being reworked. Cheers, ChriS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398302: klibc-utils: uswsusp image not recognized
Vagrant Cascadian wrote: i'm not sure this bug is really fixed, or fixed completely... ... APT policy: (500, 'testing') The fixed version is not in testing yet. -- David Härdeman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402886: icedove has become highly unstable - 2 to 3 hangs per day
Hi, thanks for the quick answer. First, I'd like to apologize but after 2 or 3 hangs, I got mad and already saw icedove going in this state into stable, and I possibly overreacted a bit (I'd like to stay at etch once stabilized). Anyway, because I can't reproduce the problem on demand, I've done the following: - compress the folders of high throughput (inbox, sent, etc...). I have 350 folders (and 5GB) of emails, so doing all those by hand would be a nightmare. - remove all msf files - remove panacea.dat - do a search in order to rebuild all summaries If I still get the problem, I'll let you know before end of the week. If I don't come back to you till Monday, you can assume that I'm fine. I hope it's a fair proposal. One more thing I remembered having forgotten to tell while doing all this :-[ : my Mail folder is on a separate FAT32 partition, in order to be able to share my folders with Windows (dual-boot). I know, it's not really supported, but till now it worked good (and it's not yet proven that it's the reason for the issue :-) ). So or so, you'll get more from me before end of the week. Thanks, Eric Alexander Sack - Debian Bugmail said: On Wed, Dec 13, 2006 at 12:52:55PM +0100, Eric Lavarde wrote: Package: icedove Version: 1.5.0.8.dfsg1-1 Severity: grave Hi, since upgrade to the dfsg version, I already had to kill and restart icedove already ~5 times since yesterday. Phenomens are very different but it always ends with a hang :-/ I already had a few times icedove stopping to show the content of the emails: I was switching from one folder to the next, and from one message to the next, but icedove showed always the same email content. Today, I had icedove hanging while trying to send an email, and I could capture part of the strace story; I noticed that icedove complained about files already existing though it created them itself. I then tried to remove the temporary files while icedove was running. It went a bit further but continued to hang, at which point I killed it. I set the severity to grave because it's currently not feasible to work properly with icedove, and I don't think it should go to stable like it is. Please backup your .mozilla-thunderbird directory. If you have done this, please compact your folders (right button on folder - Compact ...) and see if it fixes your problem. If that does not help, remove the .msf files of the folders that cause the troubles and see if that helps. Please be responsive ... otherwise, I will have to downgrade severity and see if others report the same problem (which I might do anyway). - Alexander p.s. please take care that the bug is listed as To: or CC: when replying to this mail (e.g. /reply-all/). -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack| : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.asoftsite.org | `-http://www.debian.org/ --
Bug#403004: kmail: Kmail does not start after sarge-etch upgrade
Hi, please post outpot of $ grep ImapPath ~/.kde/share/config/kmailrc pgpO0M9xH5vGo.pgp Description: PGP signature
Bug#403025: [intl:fr] debsecan debconf template translation
* Steve: Please find attached the french debconf templates translation, proofread by the debian-l10n-french mailing list contributors. This file should be put as debian/po/fr.po in your package build tree. Thanks. There are strange characters in that file: En indiquant «U+E000GENERICU+E000» (valeur par défaut), seules des fonction Is this deliberate?
Bug#401712: Enable AUTH PLAIN mechanism inunderlaying libc-client
Hi, I reported this to upstream, see http://bugs.php.net/39779 No response yet. Thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403036: uswsusp: Bogus warnings about CONFIG_SOFTWARE_SUSPEND during package upgrade
Package: uswsusp Version: 0.3~cvs20060928-6 Severity: normal When I upgrade the uswsusp package, I get a debconf warning that I don't have CONFIG_SOFTWARE_SUSPEND enabled in my kernel TWICE. First of all, if my kernel is configured incorrectly, and if you want to warn about it, please only do so during the first time you install the package, not during every upgrade. Second, looking at the uswsusp.config script, I see it doesn't really test for CONFIG_SOFTWARE_SUSPEND, it tests whether there is snapshot support or not, and then shows the debconf template uswsusp/no_snapshot. Maybe the template is wrong? It confuses me. And why is this debconf message critical? Third, whether or not I have snapshot support or not, this package may be perfectly useful to me. The s2ram utility for example does not require any special kernel support. I'd rather not see any warning at all. -- 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.5 Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8) Versions of packages uswsusp depends on: ii debconf [debconf-2.0]1.5.10 Debian configuration management sy ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libgcrypt11 1.2.3-2 LGPL Crypto library - runtime libr ii libgpg-error01.4-2 library for common error values an ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages uswsusp recommends: ii initramfs-tools 0.85c tools for generating an initramfs -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403035: installation-guide: Links to outdated document for advice on AMD64 memory
Package: installation-guide Severity: normal In section '2.4.3. Fake or $(B!H(BVirtual$(B!I(B Parity RAM', the installation guide states: If you want complete information on AMD64 RAM issues, and what is the best RAM to buy, see the PC Hardware FAQ, with a link to http://www.faqs.org/faqs/pc-hardware-faq/part1/. That document has however not been updated since 1997 and is thus not relevant for the AMD64 platform. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (700, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390862: -bigmem version of xen kernels is really needed
So.. is there anything to do about this? -- Pasi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402958: .gnupg/options not created from skeleton file
On Wed, 13 Dec 2006 20:32, [EMAIL PROTECTED] said: bajor:~# gpg --recv-keys 7EF7FFF4276981F4 gpg: directory `/root/.gnupg' created gpg: can't open `/gnupg/options.skel': No such file or directory That is known. I thought Debian had a workaround ;-). The way I solved it is by a larger change to the configuration system which is unlikely what you want to use that after the freeze. I guess locale won't work either. I have not investigated it but I guess it is a regression due to the use of autoconf 2.60 instead of 2.59. The culprit is the way the g10defs.h file is and has always been created. I would call a non-working locale RC. However I have not tested the Debian version (I use Sid but obviously use vanilla builds of gpg). BTW, there is also another bug related to keyservers and proxies. I have attached a fix for that problem against 1.4.6 Shalom-Salam, Werner 2006-12-14 Werner Koch [EMAIL PROTECTED] * http.c (http_wait_response): No more shutdown. Fixes bug#739. --- util/http.c (revision 4377) +++ util/http.c (working copy) @@ -212,8 +212,12 @@ iobuf_ioctl (hd-fp_write, 1, 1, NULL); /* keep the socket open */ iobuf_close (hd-fp_write); hd-fp_write = NULL; -if ( !(hd-flags HTTP_FLAG_NO_SHUTDOWN) ) -shutdown( hd-sock, 1 ); +/* We do not want the shutdown code anymore. It used to be there + to support old versions of pksd. These versions are anyway + unusable and the latest releases haven been fixed to properly + handle HTTP 1.0. */ +/* if ( !(hd-flags HTTP_FLAG_NO_SHUTDOWN) ) */ +/* shutdown( hd-sock, 1 ); */ hd-in_data = 0; hd-fp_read = iobuf_sockopen( hd-sock , r );
Bug#403037: sisu: output, landscape pdf object/paragraph numbers missing in left column
Package: sisu Version: 0.48.8-1 Severity: normal *** Please type your report below this line *** Generated output, landscape pdf object/paragraph numbers missing in left column. Bug appears to have been introduced somewhere between versions 0.47 and 0.48 -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages sisu depends on: ii libwebrick-ruby1.3.1+ruby1.8.2-1 Simple HTTP Server Toolkit for Rubii ruby 1.8.2-1 An interpreter of object-oriented ii unzip 5.52-9De-archiver for .zip files ii zip2.32-1Archiver for .zip files Versions of packages sisu recommends: ii hyperestraier1.4.4-1 a full-text search system for commii kdissert 1.0.6.c-1 mindmapping tool ii keychain 2.6.6-1 key manager for OpenSSH ii librexml-ruby3.1.2.1+ruby1.8.2-1 pure Ruby non-validating XML parseii librmagick-ruby 1.13.0-1ImageMagick API for Ruby ii openssh-client 1:4.3p2-7 Secure shell client, an rlogin/rshii openssl 0.9.8c-2Secure Socket Layer (SSL) binary aii rsync2.6.9-3 fast remote file copy program (likii sisu-pdf 0.48.8-1dependencies to convert SiSU LaTeXii sisu-postgresql 0.48.8-1SiSU dependencies for use with posii sisu-sqlite 0.48.8-1SiSU dependencies for use with sqlii tidy 20051018-1 HTML syntax checker and reformatteii trang20030619-5.1+b1 Multi-format XML schema converter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393266: Bug is NOT is savage dri driver but in savage drm
Hello, I found the source of the problem: savage drm in the kernel. A fast update to the current git HEAD solved the problem. Attention: Kernel headers must be installed. git clone git://anongit.freedesktop.org/git/mesa/drm cd drm/linux-core/ make DRM_MODULES=savage mv /lib/modules/2.6.18-3-686/kernel/drivers/char/drm/savage.ko /lib/modules/2.6.18-3-686/kernel/drivers/char/drm/savage.ko.old mv /lib/modules/2.6.18-3-686/kernel/drivers/char/drm/drm.ko /lib/modules/2.6.18-3-686/kernel/drivers/char/drm/drm.ko.old cp savage.ko /lib/modules/2.6.18-3-686/kernel/drivers/char/drm/savage.ko cp drm.ko /lib/modules/2.6.18-3-686/kernel/drivers/char/drm/drm.ko sudo depmod -a and reboot After I have dri, AIGLX and drm working (no error message any more). So please reassign to bug to the kernel team. regards P.S. I can provide the kernel modules if somebody wants them. pgpKG0WmFUyVK.pgp Description: PGP signature
Bug#403016: Please add pata_artop module for Iomega NAS100d
* Rod Whitby [EMAIL PROTECTED] [2006-12-14 15:33]: I'm going to continue testing by simply adding it to sata-modules, but will be happy to migrate to comply with whatever you decide. This is not etch-critical :-) Note that this is only relevant for 2.6.19 and higher anyway. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403040: please prompt for crypto passphrase
package: usplash severity: wishlist version: 0.3e Hi, I recently installed usplash on powerpc, together with a crypted partition using dm-crypt. Usplash doesn't give me a prompt to enter the passphrase, please provide one :) regards, Holger P.S.: I'm sorry to be so unspecific, I've done this install more than two weeks ago and forgot to file the bugreport. pgpOxmic6WUEd.pgp Description: PGP signature
Bug#400040: [Pkg-bluetooth-maintainers] Bug#400040: bluez-firmware: non functional with udev firmware loading / path mismatch
On Thu, Nov 23, 2006 at 05:26:02PM +0100, Florian Lohoff wrote: Package: bluez-firmware Version: 1.2-1 Severity: important Hi, it seems bluez-firmware installes its drivers into /usr/lib/firmware whereas udev only searches in: FIRMWARE_DIRS='/lib/firmware /usr/local/lib/firmware /usr/lib/hotplug/firmware' as mentioned in /lib/udev/hotplug.functions. It is not clear to me whose fault this is. you are correct, I'm going to move /usr/lib/firmware files into /lib/firmware as it seems this is the standard location, I'm CC'ing the udev mantainer just to be sure. filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: To be learned in an artC, the Theory is sufficient; to be a master of it, both the Theory and practice are requisite. -- Charles Hutton signature.asc Description: Digital signature
Bug#402832: firefox-greasemonkey: update depends and links for iceweasel transition
The upload with updates for the transition is already in NEW. Michael Spang -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403039: libjaxen-java: could you provide -beta12 it fixes a bug
Package: libjaxen-java Version: 1.1~beta11-1 Severity: normal using beta12 the problem I reported in http://jira.codehaus.org/browse/JAXEN-175 is fixed . Please provides the new one. Greetings Alban -- 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.19-rc6-prahal Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Versions of packages libjaxen-java depends on: ii gij-4.0 [java1-runtime] 4.0.3-2 The GNU Java bytecode interpreter ii gij-4.1 [java1-runtime] 4.1.1-20 The GNU Java bytecode interpreter ii kaffe 2:1.1.7-4A JVM to run Java bytecode ii kaffe-pthreads [kaffe] 2:1.1.7-4A POSIX threads enabled version of ii libjdom1-java 1.0-4lightweight and fast library using ii libxerces2-java 2.8.1-1 Validating XML parser for Java wit ii sun-java5-jre [java2-runtim 1.5.0-08-1.1 Sun Java(TM) Runtime Environment ( libjaxen-java recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403038: pmount-hal failing to mount without restarting hald
Package: pmount Version: 0.9.13-1+b1 Severity: normal % pmount-hal /dev/sdd1 Error: given UDI is not a mountable volume Then I pkill hald and restart it. % pmount-hal /dev/sdd1 bhal-storage.c 1401 : INFO: called LIBHAL_FREE_DBUS_ERROR but dbusError was not set. process 12124: Applications must not close shared connections - see dbus_connection_close() docs. This is a bug in the application. Enter LUKS passphrase: -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages pmount depends on: ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libdbus-1-3 1.0.1-2 simple interprocess messaging syst ii libhal-storage1 0.5.8.1-4 Hardware Abstraction Layer - share ii libhal1 0.5.8.1-4 Hardware Abstraction Layer - share ii libsysfs22.1.0-1 interface library to sysfs pmount recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
Matt's asked me to jump in here to explain the Ubuntu changes, and our long-term plan for such thing; as there seems to be a little confusion and/or argument on this topic. On Fri, 5 May 2006 15:17:53 +0200, Ingo Oeser wrote: The proposed solution of using /etc/networking/if-up.d/ works without any problem for most of your users. Actually unbuntu Dapper Drake is just doing it this way and I never had any problems. We fixed it for our customers the same way. Our reason for moving this to an if-up.d script is because we're increasingly relying on udev to drive the hardware parts of our boot sequence; this meant that there was no point in the SysV boot sequence where networking was up, so no point to run the ntpdate script. Moving to an if-up.d script meant that the clock would be adjusted during boot when the each ethernet card came up; the first not being sufficient as that one might not actually get an IP. This isn't ideal either, as now ntpdate gets run every time you fiddle with an interface. Our preferred solution is to use upstart to manage the ntpdate task, and don't run it once it has succeeded at least once. On Tue, 12 Dec 2006 08:41:12 +0100, Tore Anderson wrote: I know. Maybe I should have been clearer though, what I'm objecting to is primarily the suggestion to mimic the way Ubuntu does it, as they invoke ntpdate with the -b parameter in the if-up.d script, ensuring that the clock will _always_ leap. We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. That's what we're trying to do with the ntpdate script. On Wed, 13 Dec 2006 12:01:36 +0100, Tore Anderson wrote: Ranked in order of preference (as defaults, at least): 1) No gratuitous clock adjustments whatsoever (no if-up.d script) 2) No gratuitous clock stepping whatsoever (use of -B) 3) No gratituous clock stepping unless large offset (default ntpdate) 4) Gratituous clock stepping (use of -b) Ubuntu went with #4 for their Dapper release. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Or are you referring specifically to additional clock adjustments after the first one has been made? Scott -- Scott James Remnant [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Bug#403043: unixcw: FTBFS on GNU/kFreeBSD
Package: unixcw
Severity: important
Version: 2.3-3
Tags: patch
Hi,
the current version fails to build on GNU/kFreeBSD.
It incorrectly assumes that number of signals
is given by macro SIGRTMAX.
Moreover there is off by one bug even on Linux,
as signal numbers starts with 1,
see also /usr/include/bits/signum.h.
Current code reject perfectly valid signal 64 in
cw_register_signal_handler() and cw_unregister_signal_handler()
with EINVAL.
Please find attached patch to fix all of that.
There may be still problem with cw_register_signal_handler()
and cw_unregister_signal_handler() for signal number 0.
IMHO, it should be rejected directly with EINVAL.
It would also be nice if you can inform upstream
about this issues.
Thanks in advance
Petr--- unixcw-2.3.orig/src/cwlib/cwlib.c
+++ unixcw-2.3/src/cwlib/cwlib.c
@@ -3008,7 +3008,18 @@
* initialized dynamically to SIG_DFL (if SIG_DFL is not NULL, which it
* seems that it is in most cases).
*/
-static void (*cw_signal_callbacks[RTSIG_MAX]) (int);
+
+#if defined(NSIG)
+#define SIG_MAX (NSIG)
+#elif defined(_NSIG)
+#define SIG_MAX (_NSIG)
+#elif defined(RTSIG_MAX)
+#define SIG_MAX ((RTSIG_MAX)+1)
+#else
+#error unknown number of signals
+#endif
+
+static void (*cw_signal_callbacks[SIG_MAX]) (int);
/**
@@ -3194,14 +3205,14 @@
{
int index;
- for (index = 0; index RTSIG_MAX; index++)
+ for (index = 0; index SIG_MAX; index++)
cw_signal_callbacks[index] = SIG_DFL;
is_initialized = TRUE;
}
/* Reject invalid signal numbers, and SIGALRM, which we use internally. */
- if (signal_number 0 || signal_number = RTSIG_MAX
+ if (signal_number 0 || signal_number = SIG_MAX
|| signal_number == SIGALRM)
{
errno = EINVAL;
@@ -3256,7 +3267,7 @@
int status;
/* As above, reject unacceptable signal numbers. */
- if (signal_number 0 || signal_number = RTSIG_MAX
+ if (signal_number 0 || signal_number = SIG_MAX
|| signal_number == SIGALRM)
{
errno = EINVAL;
Bug#402886: icedove has become highly unstable - 2 to 3 hangs per day
On Thu, Dec 14, 2006 at 09:45:13AM +0100, Eric Lavarde - Debian Bugs wrote: Hi, thanks for the quick answer. First, I'd like to apologize but after 2 or 3 hangs, I got mad and already saw icedove going in this state into stable, and I possibly overreacted a bit (I'd like to stay at etch once stabilized). Anyway, because I can't reproduce the problem on demand, I've done the following: - compress the folders of high throughput (inbox, sent, etc...). I have 350 folders (and 5GB) of emails, so doing all those by hand would be a nightmare. - remove all msf files - remove panacea.dat - do a search in order to rebuild all summaries If I still get the problem, I'll let you know before end of the week. If I don't come back to you till Monday, you can assume that I'm fine. I hope it's a fair proposal. Yes. Thx. One more thing I remembered having forgotten to tell while doing all this :-[ : my Mail folder is on a separate FAT32 partition, in order to be able to share my folders with Windows (dual-boot). I know, it's not really supported, but till now it worked good (and it's not yet proven that it's the reason for the issue :-) ). Sounds ... hmmm ... unsupported :). BTW, just out of curiousity ... why do you still use windows? - Alexander p.s. please take care that the bug is listed as To: or CC: when replying to this mail (e.g. /reply-all/). -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack| : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.asoftsite.org | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403042: sisu: generated cgi sample search forms (postgresql and sqlite), no limit provided for number of matches returned
Package: sisu Version: 0.48.8-1 Severity: normal *** Please type your report below this line *** The generated cgi sample search forms (for postgresql and sqlite), have no limit provided for number of matches returned, which can lead to problems with large match sets in large databases. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages sisu depends on: ii libwebrick-ruby1.3.1+ruby1.8.2-1 Simple HTTP Server Toolkit for Rubii ruby 1.8.2-1 An interpreter of object-oriented ii unzip 5.52-9De-archiver for .zip files ii zip2.32-1Archiver for .zip files Versions of packages sisu recommends: ii hyperestraier1.4.4-1 a full-text search system for commii kdissert 1.0.6.c-1 mindmapping tool ii keychain 2.6.6-1 key manager for OpenSSH ii librexml-ruby3.1.2.1+ruby1.8.2-1 pure Ruby non-validating XML parseii librmagick-ruby 1.13.0-1ImageMagick API for Ruby ii openssh-client 1:4.3p2-7 Secure shell client, an rlogin/rshii openssl 0.9.8c-2Secure Socket Layer (SSL) binary aii rsync2.6.9-3 fast remote file copy program (likii sisu-pdf 0.48.8-1dependencies to convert SiSU LaTeXii sisu-postgresql 0.48.8-1SiSU dependencies for use with posii sisu-sqlite 0.48.8-1SiSU dependencies for use with sqlii tidy 20051018-1 HTML syntax checker and reformatteii trang20030619-5.1+b1 Multi-format XML schema converter -- no debconf information ~ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385735: beidgui: Still receiving Wrong root certificate with 2.5.9-5
On Wed, Dec 13, 2006 at 08:50:16PM +0100, Cyrille Bollu wrote: Sorry. I know you need accurate information to help me. But in order to reproduce the error, I would have to uninstall openct. So, I was trying to give you information from memory. Before uninstalling openct, I have found another test which give me the same message. Maybe it might help? Here it is: If I run beidgui as a regular user (not root), I experiment the same behaviour. Here's the output from the terminal: [EMAIL PROTECTED]:~$ beidgui winscard_clnt.c:3232:SCardCheckDaemonAvailability() PCSC Not Running You need to have both the PC/SC daemon (in the pcscd package) and the beidpcscd daemon (in the beid-tools) running... Error: can't open /var/run/openct/status: Permission non accordée Error: can't open /var/run/openct/status: Permission non accordée Error: can't open /var/run/openct/status: Permission non accordée Error: can't open /var/run/openct/status: Permission non accordée [...] You may want to fix the permissions on that file, then :) However, since you have a smartcard reader with the ACR38 chipset, you only need PC/SC; openct is not required for you (no, really! I mean it!). [EMAIL PROTECTED]:~$ Then, within the GUI, I first receive a message cannot set locale to 'fr_BE'. Do you have an fr_BE locale listed in /etc/locale.gen? If not, this is not a big deal -- simply means that your interface may not be translated as it should be. Then when I click on the chip icon to read my eID, I receive Erreur système: No smartcard inserted Right, that's because it tries to read a smartcard through OpenCT while your hardware uses PC/SC rather than OpenCT. Additional information (1): === If I run beidgui as root: debian-testing:/home/cyb# beidgui winscard_clnt.c:3232:SCardCheckDaemonAvailability() PCSC Not Running The beidpcscd daemon and/or the pcsc daemon isn't running... Then, cannot set local to en_GB. same as above... Then, when I click on the chip icon, I receive Error Wrong Root Certificate and the following messages are printed on my terminal: winscard_clnt.c:3232:SCardCheckDaemonAvailability() PCSC Not Running Session management error: Authentication Rejected, reason : None of the authentication protocols specified are supported and host-based authentication failed Additional information (2): === Ah! Also, the following lines are printed in /var/log/syslog: Dec 13 13:06:03 localhost ifdhandler[3842]: usb_bulk failed: Connection timed out Dec 13 13:06:03 localhost ifdhandler[3842]: ps_receive_from_ifd: failed: -1 Dec 13 13:06:03 localhost ifdhandler[3842]: ps_apdu_recv: failed Not exactly sure what that is; if the above doesn't fix it, we may want to investigate this a bit further (not just yet). Not 100% sure whether it's related. Additional information (3): === Ah! Yet another information: The winscard_clnt.c:3232:SCardCheckDaemonAvailability() PCSC Not Running message appears because I forgot to restart beid once logged in. Indeed, if I type ps -eaf | grep pcsc once logged in, there are no such processes. Once beid is restarted, ps -eaf | grep pcsc shows me belpcscd running and the winscard_clnt.c... message disappears. See? :) And, I have to restart beidpcscd (/etc/init.d/beid start) once logged in. It seems that it doesn't start correctly during the boot process. Strange, I haven't seen /that/ before. When booting, do you see any message related to belpic and/or beid, or just when the beid init script is running? I cannot see anything special. Could you enable the bootlogd (change No to Yes in /etc/default/bootlogd), reboot, and put /var/log/boot.log online somewhere? debian:/# cd etc/rc2.d/ debian:/etc/rc2.d# ls K01fetchmail S18portmap S20makedevS25mdadm K09apache S19hplip S20nethack-common S50pcscd K09samba S19lirc S20nvidia-glx-legacy S89atd K20exim4 S20beid S20openbsd-inetd S89cron K20lpd S20belpcscd S20openct S99rc.local Hmm, belpcscd is outdated and should not be there anymore. Thanks, I just discovered the --purge option of apt-get remove :-) (I already knew update-rc.d) Wonderful. If you reboot now, does it work? Could you please run this command, and send me the output: dpkg -l libbeidlibopensc2 libbeid2 beidgui libbeidlibopensc2-dev beid-tools libbeid2-dev belpic eidviewer libbelpic0-dev libbelpic0 libeid0-dev libeid0 debian-testing:/home/cyb# dpkg -l libbeidlibopensc2 libbeid2 beidgui libbeidlibopensc2-dev beid-tools libbeid2-dev belpic eidviewer libbelpic0-dev libbelpic0 libeid0-dev libeid0 Aucun paquet ne correspond à libbeidlibopensc2-dev. Aucun paquet ne correspond à libbeid2-dev. Could you try installing those and see if that fixes it? Aucun paquet ne correspond à libeid0-dev.
Bug#278824: acknowledged by developer ((re-)closing with existing version)
On Thu, Dec 14, 2006 at 08:47:45AM +0100, Michal J. Gajda wrote: Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report #278824: mozilla-thunderbird: Search unusable on 15000+ message folders - sluggish or hangs , which was filed against the mozilla-thunderbird package. It has been marked as closed by one of the developers, namely Alexander Sack [EMAIL PROTECTED]. You should be hearing from them with a substantive response shortly, in case you haven't already. If not, please contact them directly. I'm sorry, I can't reproduce the problem any more. The problem forced me to abandon my delete my old mail archive. However, as of Thunderbird 1.5 it wasn't fixed upstream. If fact this all was a mess: Your bug has not been closed. It has been cloned once ... the original one was now closed. You can track your bug (which is still open) at: 363728. Sorry for the confusion ;). - Alexander p.s. please take care that the bug is listed as To: or CC: when replying to this mail (e.g. /reply-all/). -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack| : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.asoftsite.org | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402886: icedove has become highly unstable - 2 to 3 hangs per day
On Thu, Dec 14, 2006 at 09:45:13AM +0100, Eric Lavarde - Debian Bugs wrote: One more thing I remembered having forgotten to tell while doing all this :-[ : my Mail folder is on a separate FAT32 partition, in order to be able to share my folders with Windows (dual-boot). I know, it's not really supported, but till now it worked good (and it's not yet proven that it's the reason for the issue :-) ). Oh ... I forgot something really important ... please don't use the windowstbird until 1.5.0.9 is out. tbird 1.5.0.8 has a severe bug that might lead to loss some mails [1] [2]. I pulled in the official patch to fix this in the latest debian package ... So maybe there is indeed some kind of incompatibility at the moment. ... so remember ... DON'T run windows tbird until 1.5.0.9 is available :). [1] - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=400383, https://bugzilla.mozilla.org/show_bug.cgi?id=360409 [2] - afaik they are not really lost, but just not displayed anymore, until the introduced patch fixes this ... so better don't call for troubles here. - Alexander p.s. please take care that the bug is listed as To: or CC: when replying to this mail (e.g. /reply-all/). -- GPG messages preferred. | .''`. ** Debian GNU/Linux ** Alexander Sack| : :' : The universal [EMAIL PROTECTED] | `. `' Operating System http://www.asoftsite.org | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403041: breaks crypto setup
package: usplash severity: important version: 0.3e tags: security Hi, I recently installed usplash on powerpc, together with a crypted partition using dm-crypt. Usplash doesn't give me a prompt to enter the passphrase (which I just filed a wishlist bug about), but whats much worse, when I manually switch to the text console and enter the passphrase, it is shown in clear on the screen and doesnt work. When switching to the text console before the passphrase is prompted, it works. I filed this bug as important because of these two issues together: it breaks functionality and additional has the potential to leak a probably very complicated passphrase. If it just wouldn't work, I would have used normal severity. regards, Holger P.S.: I'm sorry to be so unspecific, I've done this install more than two weeks ago and forgot to file the bugreport. pgpFqe7zMg7os.pgp Description: PGP signature
Bug#379839: vim: Bogus color schema
On Mon, Dec 04, 2006 at 05:53:23PM -0500, James Vega wrote: tag 379839 wontfix thanks It's OK for me to ignore the insufficient contrast introduced by more supported color modes but please note that this bug report was initially about a wrong color scheme. On Mon, Dec 04, 2006 at 11:35:47PM +0100, Jens Seidel wrote: On Mon, Dec 04, 2006 at 09:03:24AM -0500, James Vega wrote: On Mon, Dec 04, 2006 at 01:40:59PM +0100, Jens Seidel wrote: On Tue, Jul 25, 2006 at 09:50:24PM +0200, Jens Seidel wrote: Hi, I noticed that the default color schema of vimdiff is wrong, since added lines in one of the files are not visible because foreground and background color are identical. This isn't a won't fix! The contrast is nevertheless bad. Bright blue on blue or pink on red are not optimal. The older settings where better. I agree that the contrast is bad, but there's only so much you can do with the limited color set available in a terminal. More syntax I'm tagging this as wontfix since there's not much to do about it even though I agree that it can be problematic. It applies not to the initial problem. If you have a patch and want to see this in Etch I could provide a German translation update if necessary to bypass the freeze :-) Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347569: VDE2 package
Hi. I've found that you uploaded new vde2 package. I didn't find the source for the package, so I'd like to ask: * Does the vde2 package interfere with vde package? * Does it contain some additional patches? * Does it provide /etc/network/interfaces support? * Does it support non-root users? * Is it uploaded to experimental or sid? For last two weeks I worked on vde2 package. I didn't uploaded it yet because the etch was freezed. I've noticed that your package is slightly different that mine: * Your package is splitted on 3 different binary packages. Why? I think the vde2 package should provide all files. * New vde2 package doesn't provide upgrade path for users of old vde package. I would like to offer my help and patches. My vde2 package is available at http://people.debian.org/~dexter/vde2 The SVN source is available at svn://svn.debian.org/cvsdebuild/trunk/debian/dists/vde2 My proposition is: Please reconsider the package splitting. Please let the ftp-master know, that he should remove currently uploaded vde2 package from NEW queue. Please, review my patches and /etc/network scritps. I think we could join the forces to make a better vde2 package. Greets, -- .''`.Piotr Roszatycki : :' :mailto:[EMAIL PROTECTED] `. `' mailto:[EMAIL PROTECTED] `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402996: frozen-bubble: lan game impossible
Hello Josselin Mouette, Le jeudi 14 décembre 2006 à 02:47 +0100, Christoph Thielecke a écrit : Package: frozen-bubble Version: 2.1.0-1 Severity: normal *** Please type your report below this line *** if I start a LAN game and a remote server in local lan host a game I cant find the game. The remote server is reachable and if I telnet to the ip address on port 1511 I got a connect. I'm afraid I don't understand what you are trying to do. Is there a public server running in your local LAN? If this is the case, you should run it with the -l option so that it is usable for LAN games as well. I simply start a LAN gam on other machine in LAN and try to join but my version doesnt find it. I had tried 2.0.0 and this version works fine: [EMAIL PROTECTED]:~$ ls -l1 frozen-bubble* -rw-r--r-- 1 crissi crissi 147010 2006-10-30 18:17 frozen-bubble_2.0.0-1_i386.deb -rw-r--r-- 1 crissi crissi 19260960 2006-12-14 03:01 frozen-bubble-data_2.0.0-1_all.deb Maybe there is a problem in 2.1.0? Best regards Christoph -- Linux User Group Wernigerode http://www.lug-wr.de/ pgpmeIrM6Uxei.pgp Description: PGP signature
Bug#403017: Patch to flash-kernel for nas100d support
* Rod Whitby [EMAIL PROTECTED] [2006-12-14 15:38]: Could you please apply the attached patch to flash-kernel? Yes, but after RC2 is out. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402545: Nope
* Philippe Perrin wrote: Using compiz 0.3.4 does not solve my black screen issue... You could try unsetting the compiz gconf settings by running something like this: $ gconftool-2 --recursive-unset /apps/compiz and perhaps for gtk-window-decorator: $ gconftool-2 --recursive-unset /apps/gwd If that doesn't work out, I've heard that removing the gnome config (~/.gnome, ~/.gnome2, ~/.gconf and friends) *may* solve the black screen problem. There seems to be one remaining issue where the NVIDIA driver crashes compiz or the gtk-window-decorator when returning from a VT, but that is more likely a bug in the non-free driver because this does not seem to happen with any of the free drivers. Thierry signature.asc Description: Digital signature
Bug#353961: manpages-de: Please synchronise German manpages with upstream CVS
severity 353961 normal thanks On Fri, Mar 17, 2006 at 11:42:42AM +0100, Daniel Kobras wrote: On Wed, Feb 22, 2006 at 10:31:52AM +0100, Jens Seidel wrote: Many issues in the current manpages-de packages are fixed in Joeys upstream CVS since a long time. So I performed for example multiple checks (mostly typo related), converted to New German orthography, ... Please package these new manual pages, version 0.4 was released 2002-01-01! While I didn't keep the Debian package completely in sync with upstream CVS, I've been pulling patches that I consider relevant, and I certainly don't intend to ignore contributions that add significant benefit in the future, either. Other patches will be added when they're part of an upstream release. Since a new upstream version is available which fixes really many minor issues and adds new translations we need this version in Etch. I planned to see my Old to New German orthography changes already in Sarge but Joey missed my patch at this time. A further delay is not acceptable. If you need help merging local changes to upstream I'm willing to help. Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403046: dependency problem installing egroupware on 64bit debian etch
Package: egroupware Version: 1.2-105.dfsg-4 Hello all, I want to install egroupware on a 64bit etch but getting dependencies errors: apt-get install egroupware Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: egroupware: Depends: egroupware-core but it is not going to be installed Depends: egroupware-addressbook but it is not going to be installed Depends: egroupware-bookmarks but it is not going to be installed Depends: egroupware-calendar but it is not going to be installed Depends: egroupware-developer-tools but it is not going to be installed Depends: egroupware-emailadmin but it is not going to be installed Depends: egroupware-etemplate but it is not going to be installed Depends: egroupware-felamimail but it is not going to be installed Depends: egroupware-filemanager but it is not going to be installed Depends: egroupware-infolog but it is not going to be installed Depends: egroupware-manual but it is not going to be installed Depends: egroupware-mydms but it is not going to be installed Depends: egroupware-news-admin but it is not going to be installed Depends: egroupware-phpbrain but it is not going to be installed Depends: egroupware-phpsysinfo but it is not going to be installed Depends: egroupware-polls but it is not going to be installed Depends: egroupware-projectmanager but it is not going to be installed Depends: egroupware-registration but it is not going to be installed Depends: egroupware-resources but it is not going to be installed Depends: egroupware-sambaadmin but it is not going to be installed Depends: egroupware-sitemgr but it is not going to be installed Depends: egroupware-timesheet but it is not going to be installed Depends: egroupware-wiki but it is not going to be installed Depends: egroupware-workflow but it is not going to be installed E: Broken packages cheetah:/var/www/sn2.aspedia.local/snortcenter-release# when I do: cheetah:~# apt-get install egroupware-core Reading package lists... Done Building dependency tree... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. Since you only requested a single operation it is extremely likely that the package is simply not installable and a bug report against that package should be filed. The following information may help to resolve the situation: The following packages have unmet dependencies: egroupware-core: Depends: libapache2-mod-php5 ( 5.2) but 5.2.0-7 is to be installed or libapache-mod-php5 ( 5.2) but 5.2.0-7 is to be installed or libapache2-mod-php4 (= 4:4.3) but it is not going to be installed or libapache-mod-php4 (= 4:4.3) but it is not going to be installed E: Broken packages cheetah:~# and it is also not possible tun run apache -php4 and -php5 at same time! thank you stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402829: mantis: not supportable by the security team
2006/12/14, schönfeld / in-medias-res.com [EMAIL PROTECTED]: Until the next release of Debian I will try to keep mantis packages as up-to-date as possible and then we will hopefully re-integrate it. Patrick, This will still help Debian users, especially if you provide a backport for Etch. Just remember that there is no security support for that (except the one you/upstream provide). dam
Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up
Package: wpasupplicant Version: 0.5.5-3 Severity: normal Tags: patch I have configured a roaming wpa configuration on my laptop using allow-hotplug wlan0 iface wlan0 inet manual wpa-driver wext wpa-roam /etc/wpa_supplicant.conf in /etc/network/interfaces. If a disconnect event occurs, wpa_action is called with the action DISCONNECTED, which ifdowns the interface and then should immediately re-enable the scanning mode by calling /etc/wpa_supplicant/functions.sh::if_post_down_up the problem is, at least in my case, that the link is _down_ afterwards, so wpasupplicant is not able to scan further. This seems to be caused by the interface not being completely downed yet when ifdown finishes; putting a 'sleep 1' into functions.sh::ifdown immediately after the call to /sbin/ifdown solves this problem. Furter system configuration info: - madwifi-ng wlan, using wpa_supplicants 'wext' driver - dhcpcd dhcp client -- 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.18-3-686 Locale: LANG=C, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages wpasupplicant depends on: ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii libdbus-1-3 1.0.1-2 simple interprocess messaging syst ii libncurses5 5.5-5 Shared libraries for terminal hand ii libreadline5 5.2-1 GNU readline and history libraries ii libssl0.9.8 0.9.8c-4SSL shared libraries ii lsb-base 3.1-22 Linux Standard Base 3.1 init scrip Versions of packages wpasupplicant recommends: pn dhcp3-client none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403044: hpodder: Podcasts are downloaded but not saved to disk
Package: hpodder Version: 0.99.1 Severity: grave Justification: renders package unusable When I try to fetch the podcasts I get: curl: (18) transfer closed with outstanding read data remaining for every podcast and none is saved on disk nor marked as donwloaded in the database -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages hpodder depends on: ii curl 7.15.5-1 Get a file from an HTTP, HTTPS, FT ii id3v2 0.1.11-3 A command line id3v2 tag editor ii libc6 2.3.6.ds1-9GNU C Library: Shared libraries ii libgmp3c2 2:4.2.1+dfsg-4 Multiprecision arithmetic library ii libsqlite3-0 3.3.8-1SQLite 3 shared library hpodder recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#365365: ITA: galternatives -- graphical setup tool for the alternatives system
retitle 365365 O: galternatives -- graphical setup tool for the alternatives system noowner 365365 thanks On Thu, Oct 26, 2006 at 08:17:01 +0200, Matej Vela wrote: On Sat, Jul 22, 2006 at 20:17:40 -0400, Alejandro Garrido Mota wrote: retitle #365365 ITA: galternatives -- graphical setup tool for the alternatives system Do you still intend to adopt galternatives? (This is just a ping, I'm not interested in adopting it myself.) I haven't heard back from you, so I'm assuming you're no longer interested. If you are, feel free to retitle the bug again. Thanks, Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402994: use new libpaper hook to track system paper size
On Thu, Dec 14, 2006 at 08:23 +0100, Frank Küster wrote: texconfig and therefore the paperconfig hook do *not* control the paper size that is used for typesetting (i.e. when TeX runs and calculates where to put the characters relative to the paper origin). It only takes effect when a PostScript or PDF file is created from the result. ACK. This is an important distinction to make. First of all, texconfig paper $PAPER only allows letter and a4. So either we need to change the hook script to check for that - or we patch texconfig to recognize more paper sizes. The current limitation is pdftex, which can have it's default papersize changed only by changing pdftexconfig.tex and redumping all formats. The different pdftexconfig.tex files needed for a4 and letter are hardcoded into texconfig. Second, the files that are affected are currently not configuration files, which is a bug. But what should we do? If we make them conffiles, users will get configuration file changed by you or a script if the file is changed upon upgrade. Although the statement is true, it won't help people very much who never looked at that file, in particular since the right choice would be to accept the new version from the package - it will be changed again right away by the libpaper hook. How about having the original files in TEXMFDIST and change texconfig such, that it writes the new files to TEXMF(SYS)VAR? That way the user will not have to deal with the files. But if needed, these files can be overruled by a file in TEXMF(SYS)CONFIG. One problem that I see right now is what texconfig(-sys) should do when such a file exists in TEXMF(SYS)CONFIG. Tricky ... One approach would be to separate the papersize setting out of the existing files, let texconfig paper act on the extracted files (which would reside in /var, not /etc) and let the programs read both the main config file and the papersize file. But I'm not sure whether this can be done without code changes to dvips/dvipdfm? dvipdfm allready links against libpaper. For dvips I currently see no possibility to have one configuration file specify another one, that should also be read. cheerio ralf
Bug#368070: #368070: O: aqsis -- suite of applications implementing the RenderMan Interface
retitle 368070 O: aqsis -- suite of applications implementing the RenderMan Interface noowner 368070 thanks On Wed, Nov 01, 2006 at 23:12:53 +0100, Matej Vela wrote: On Tue, May 30, 2006 at 04:19:51 +0200, David Martinez Moreno wrote: retitle ITA: aqsis -- suite of applications implementing the RenderMan Interface Do you still intend to adopt aqsis? (This is just a QA ping, I'm not interested in adopting it myself.) I haven't heard back from you, so I'm assuming you're no longer interested. If you are, feel free to retitle the bug again. Thanks, Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403047: iceape-browser's description doesn't mention its also a WYSIWYG web editor
Package: iceape-browser Version: 1.0.6-1 Severity: normal iceape-browser's description doesn't mention that it is also a composer, a WYSIWYG web editor. Seeing as there is only this and OpenOffice providing a WYSIWYG web editor in Debian, I belive this is information well worth communcating. For many people a WYSIWYG editor is a hugely significant portion of software functionality expected in a distribution; I personally don't like using OpenOffice's web editor, which leaves only iceape-'browser' (that I know of).
Bug#402075: dovecotpw only prints help message on powerpc
* 2006-12-08 00:14, Koen Vermeer wrote: Package: dovecot-common Version: 1.0.rc15-1 Severity: Important Hi Koen, When running dovecotpw on powerpc (a Buffalo Linkstation HG), no matter what command line parameters I pass, I always get the help message. For example: # dovecotpw -l usage: dovecotpw [-l] [-p plaintext] [-s scheme] [-u user] [-V] -lList known password schemes -p plaintext New password -s scheme Password scheme -u user Username (if scheme uses it) -VInternally verify the hash When doing the same on i386, it does work correctly, so it seems architecture-dependent. I'm not able to test dovecotpw on powerpc because I am away from my usual workstation so I can't connect to debian.org machines. I'll test it next week, in the meanwhile could you please check if previous versions worked correctly? Thanks, -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
Bug#402983: texlive-bin: ttf2afm, and all of ttfutils, is missing
On Thu, Dec 14, 2006 at 00:02 +0100, Norbert Preining wrote: In the tpm2deb.cfg it is written: # collection psutils and ttfutils die, should be proper debian packages but at least ttfutils seem to be not to go this way. We should include this in our packages, or create a new binary package texlive-ttf-utils or whatever. ttfutils seems to come from different places: ttf2afm (pdftex, in tetex-bin, texlive should provide it) ttf2pk (freetype1, in freetype1-tools) ttf2tfm (freetype1, in freetype1-tools) ttfdump (no idea where that comes from, no idea what it is) cheerio ralf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402707: rtorrent: Hash check fails on every download with kernel 2.6.19
[hint: do a reply-to-all to keep the bug in the loop] On Thu, Dec 14, 2006 at 07:13:50PM +1000, Lem wrote: Hi Filippo, On Tue, 2006-12-12 at 19:55 +0100, Filippo Giunchedi wrote: On Tue, Dec 12, 2006 at 05:52:57PM +1000, Lem wrote: Package: rtorrent Version: 0.6.4-1 Severity: normal After upgrading my kernel from 2.6.18 to 2.6.19, downloads with rtorrent fail hash check on completion (all downloads). The following message is then reported by rtorrent: on which filesystem the torrents are? is the 2.6.19 the vanilla one? 2.6.19.1 just released, perhaps it is worth a try. The torrents are on an ext3 filesystem. I have tried with 2.6.19.1 and I still have the same problem. Not all torrents fail though, only some (usually larger ones, greater than 100mb, maybe this is an intermittent problem and the bigger torrents live long enough to experience the problem?) do you mind trying with a debian kernel currently in the archive? like linux-image-2.6.18, I am currently unable to reproduce this bug filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: I worked myself up from nothing to a state of extreme poverty. -- Groucho Marx signature.asc Description: Digital signature
Bug#403048: linux-wlan-ng: init deprecation warning for 85-linux-wlan-ng.rules
Package: linux-wlan-ng Version: 0.2.6+svn20061108-1 Severity: normal In Debian sid with kernel 2.6.18 (non-vanilla, version is 2.6.18-kanotix-1) at boot time (after INIT starts), this message is displayed in the console: udev: add_to_rules: PHYSDEV* values are deprecated and will be removed from a future kernel, please fix it in /etc/udev/rules/85-linux-wlan-ng.rules. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (200, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-kanotix-1 Locale: LANG=C, LC_CTYPE=en_US.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages linux-wlan-ng depends on: ii libc62.3.6.ds1-9 GNU C Library: Shared libraries ii udev 0.103-1 /dev/ and hotplug management daemo ii wireless-tools 28-1Tools for manipulating Linux Wirel Versions of packages linux-wlan-ng recommends: pn linux-wlan-ng-doc none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402983: texlive-bin: ttf2afm, and all of ttfutils, is missing
Hi Ralf! On Don, 14 Dez 2006, Ralf Stubner wrote: In the tpm2deb.cfg it is written: # collection psutils and ttfutils die, should be proper debian packages but at least ttfutils seem to be not to go this way. We should include this in our packages, or create a new binary package texlive-ttf-utils or whatever. ttfutils seems to come from different places: ttf2afm (pdftex, in tetex-bin, texlive should provide it) Well, this is definitely missing. ttf2pk (freetype1, in freetype1-tools) ttf2tfm (freetype1, in freetype1-tools) Hmm, that means that I have blacklisted bin-ttfutils, but this makes tt2afm not available. I will have to undo this change, and blacklist the single files. Thanks for reminding me that the others are already in cluded in Debian. Best wishes Norbert --- Dr. Norbert Preining [EMAIL PROTECTED]Università di Siena Debian Developer [EMAIL PROTECTED] Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 --- Three things are certain: Death, taxes and lost data. Guess which has occurred. --- Windows Error Haiku -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#323477: ITA: rioutil -- Talk to USB based Diamond MM products
retitle 323477 O: rioutil -- Talk to USB based Diamond MM products noowner 323477 thanks On Wed, Nov 01, 2006 at 23:01:38 +0100, Matej Vela wrote: On Tue, Aug 08, 2006 at 14:43:26 -0600, Nathan Hjelm wrote: retitle 323477 ITA: rioutil -- Talk to USB based Diamond MM products Do you still intend to adopt rioutil? (This is just a ping, I'm not interested in adopting it myself.) I haven't heard back from you, so I'm assuming you're no longer interested. If you are, feel free to retitle the bug again. Thanks, Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403049: Iceweasel don't works
Package: iceweasel Version: 2.0+dsfg-1 I have installed Iceweasel. But when i won't to start the Browser, the Briwser won't start. I have try it in Terminal to get more infos/messages or errors but nothing appears. So that i cannot give you any error message. I had to a iceweasel strace. I'll put it on my server because the File is too bigto post it. http://www.fedora-club.de/uploads/iceweasel.strace.txt I'am using GNU/LINUX DEBIAN SID/UNSTABLE with Kernel 2.6.18-3-K7 an KDE 3.5.5.dfsg-1.5 as Default Desktop Env. regards, jovan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341961: Module sym53c8xx: phase change messages on Iomega ZIP drive
On Fri, Oct 27, 2006 at 06:56:21PM +0200, David Schmitt wrote: In preparation of the upcoming etch release, would you please test if either 2.6.17-9 from testing or 2.6.18-3 from unstable fixes your problem with your ZIP drive? I tested it with linux-image-2.6.17-2-486 from testing and the error is gone. Thus I think we can close this bug. Hans -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402994: use new libpaper hook to track system paper size
Ralf Stubner [EMAIL PROTECTED] wrote: First of all, texconfig paper $PAPER only allows letter and a4. So either we need to change the hook script to check for that - or we patch texconfig to recognize more paper sizes. The current limitation is pdftex, which can have it's default papersize changed only by changing pdftexconfig.tex and redumping all formats. The different pdftexconfig.tex files needed for a4 and letter are hardcoded into texconfig. What's the problem? This is the relevant part from texconfig: case $3 in letter) w=8.5 true in; h=11 true in setupTmpDir fmgrConfigReplace pdftexconfig.tex pdfpagewidth '\pdfpagewidth='$w wChanged=$fmgrConfigReplaceChanged fmgrConfigReplace pdftexconfig.tex pdfpageheight '\pdfpageheight='$h if $wChanged || $fmgrConfigReplaceChanged; then fmtutil --all fi ;; a4) w=210 true mm; h=297 true mm fmgrConfigReplace pdftexconfig.tex pdfpagewidth '\pdfpagewidth='$w wChanged=$fmgrConfigReplaceChanged fmgrConfigReplace pdftexconfig.tex pdfpageheight '\pdfpageheight='$h if $wChanged || $fmgrConfigReplaceChanged; then fmtutil --all fi ;; ) echo $help 2; rc=1;; *) echo $progname: unknown PAPER \`$3' given as argument for \`$progname pdftex paper' 2 echo $progname: try \`$progname pdftex paper' for help 2 rc=1 ;; esac ;; Why can't we just add settings for other papersizes here (or let it read them from a separate file)? Second, the files that are affected are currently not configuration files, which is a bug. But what should we do? If we make them conffiles, users will get configuration file changed by you or a script if the file is changed upon upgrade. Although the statement is true, it won't help people very much who never looked at that file, in particular since the right choice would be to accept the new version from the package - it will be changed again right away by the libpaper hook. How about having the original files in TEXMFDIST and change texconfig such, that it writes the new files to TEXMF(SYS)VAR? That way the user will not have to deal with the files. But if needed, these files can be overruled by a file in TEXMF(SYS)CONFIG. One problem that I see right now is what texconfig(-sys) should do when such a file exists in TEXMF(SYS)CONFIG. Tricky ... Hm. Doesn't look very elegant to me. dvipdfm allready links against libpaper. Err, right. We probably should disable texconfig dvidpdfm paper, then. For dvips I currently see no possibility to have one configuration file specify another one, that should also be read. Will it read multiple config files, e.g. in TEXMFSYSVAR and TEXMFSYSCONFIG/TEXMFDIST? Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#379804: [EMAIL PROTECTED]: Re: openoffice.org: Export as PDF dialog missing text labels]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 severity 379804 important reassign 379804 openoffice.org-l10n-en-gb,openoffice.org-l10n-en-za reassign 381369 openoffice.org-l10n-en-gb,openoffice.org-l10n-en-za forwarded 379804 http://www.openoffice.org/issues/show_bug.cgi?id=66919 user [EMAIL PROTECTED] usertags 379804 + status-STARTED merge 379804 381369 thanks Since merged bugs get only the oldest shown and this is this one, but more info is in 381369, this forward to 379804 again. Merging both bugs. - - Forwarded message from Rene Engelhard [EMAIL PROTECTED] - Date: Thu, 14 Dec 2006 12:01:17 +0100 From: Rene Engelhard [EMAIL PROTECTED] To: Ryan Hayle [EMAIL PROTECTED], Bruno Harbulot [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: openoffice.org: Export as PDF dialog missing text labels User-Agent: Mutt/1.5.13 (2006-08-11) forwarded 381369 http://www.openoffice.org/issues/show_bug.cgi?id=66919 severity 381369 important reassign 381369 openoffice.org-l10n-en-gb, openoffice.org-l10n-en-za user [EMAIL PROTECTED] usertags 381369 + status-STARTED thanks [ sorry for the late answer ] Hi, Ryan Hayle wrote: chose Export as PDF, after chosing a filename, the dialog is presented without may of the text labels making it nearly impossible to work with. If I just hit the blank OK button, it appears to work fine, so I imagine it just has something to do with the language files (I use en-GB). Screenshot is attached below. ^ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) ^^ ?? Did you set your locale in the UI? Don't do that :), set your locale properly. If you didn't write that you used en-GB I wouldn't have been able to know that. Anyway, this issue was just mentioned on OOos mailing lists (related to the 2.1 release where this bug is still present), and this is http://www.openoffice.org/issues/show_bug.cgi?id=66919... Bruno Habulot wrote: The same bug appears in 'testing' with version 2.0.3-6. It does indeed happen after setting the language of the user interface to English (UK), but it doesn't when using English (USA) or French (France), for example. According to http://www.openoffice.org/servlets/ReadMsg?list=releasesmsgNo=10324 en-ZA is also affected.. Hmm... Regards, Rene - - End forwarded message - -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgTQE+FmQsCSK63MRAvG2AJ9T97IzclkTl8xyATFcWvTy62efHACcCzdC UuLRV2ytHwlIaCInUjJ8BMg= =38T6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403039: libjaxen-java: could you provide -beta12 it fixes a bug
reassign 403039 dom4j retitle 403039 dom4j: jaxen classes missing severity 403039 serious tag 403039 pending thanks Hi, the problem is in the dom4j package in Debian, which is missing a few classes. In the future, please report problems with Debian packages to the Debian bug tracking system (using reportbug). The maintainer will determine if it's an upstream or Debian problem. Thanks for the report. Marcus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288053: network-console - Regression: is not correctly added in menu
On Mon, Jan 03, 2005 at 12:07:05AM +0100, Frans Pop wrote:
The original issue appears to be not a problem in network-console, but in
main-menu.
Currently the order of menu items appears to be based on:
- number in installer-menu-item
- dependencies
Maybe a third factor should be taken into account: not before the menu
item that was responsible for installing the component.
These could be load-floppy, load-cdrom, download-installer and maybe
others.
This bug was introduced due to the fix for #224633. Perhaps the existing
fix for that is too crude. The basic goal there is that if a menu item
fails but a later one has succeeded, main-menu shouldn't keep on setting
the earlier failing one as the default. At the moment, main-menu does
this by remembering the last successful item and never defaulting to an
earlier one.
I don't really want to hardcode knowledge of the retriever items in
main-menu, though. I think this could equally be achieved by remembering
all failed items and never defaulting to any of them. The chief visible
difference from the current behaviour would be that if you drop to
expert mode and skip over an item by hand, you'd have to keep skipping
over it. Alternatively, we could make main-menu's defaulting behave
differently in expert mode, but that would mean that we wouldn't get
this fix for network-console in expert mode and it may not be worth it.
I suppose this wouldn't be an entirely trivial change.
One even more conservative possibility would be to remember what menu
items we've seen at all, and avoid suppressing any new items that appear
just because they're earlier in the menu order than the last successful
item. Here's an untested patch:
Index: main-menu.c
===
--- main-menu.c (revision 43061)
+++ main-menu.c (working copy)
@@ -31,6 +31,7 @@
const int RAISE = 1;
const int LOWER = 0;
+di_hash_table *seen_items;
int last_successful_item = -1;
/* Save default priority, to be able to return to it when we have to lower it
*/
@@ -61,6 +62,13 @@
return strcmp(p1-p.package, p2-p.package);
}
+static void seen_items_key_destroy (void *key)
+{
+ di_rstring *s = key;
+ di_free(s-string);
+ di_free(s);
+}
+
int isdefault(di_system_package *p) {
int check;
@@ -128,7 +136,8 @@
//di_log(DI_LOG_LEVEL_DEBUG, not menu item; or not
installed);
continue;
}
- if (p-installer_menu_item last_successful_item
+ if ((p-installer_menu_item last_successful_item
+!di_hash_table_lookup(seen_items, p-p.key))
p-installer_menu_item NEVERDEFAULT) {
//di_log(DI_LOG_LEVEL_DEBUG, not in range to be
default);
continue;
@@ -582,9 +591,14 @@
menu_startup();
+ seen_items = di_hash_table_new_full(di_rstring_hash, di_rstring_equal,
+ seen_items_key_destroy, NULL);
+
allocator = di_system_packages_allocator_alloc ();
packages =
di_system_packages_status_read_file(DI_SYSTEM_DPKG_STATUSFILE, allocator);
while ((p=show_main_menu(packages, allocator))) {
+ di_slist_node *node;
+
ret = do_menu_item(p);
adjust_default_priority();
switch (ret) {
@@ -608,7 +622,17 @@
notify_user_of_failure(p);
modify_debconf_priority(LOWER);
}
-
+
+ /* Remember all the packages we've seen so far */
+ for (node = packages-list.head; node; node = node-next) {
+ di_system_package *seen = node-data;
+ di_rstring *seen_name = di_new0(di_rstring, 1);
+ seen_name-string = di_stradup(seen-p.key.string,
+ seen-p.key.size);
+ seen_name-size = seen-p.key.size;
+ di_hash_table_insert(seen_items, seen_name, seen_name);
+ }
+
di_packages_free (packages);
di_packages_allocator_free (allocator);
allocator = di_system_packages_allocator_alloc ();
Cheers,
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403046: dependency problem installing egroupware on 64bit debian etch
Stefan Fuhrmann wrote: The following packages have unmet dependencies: egroupware-core: Depends: libapache2-mod-php5 ( 5.2) but 5.2.0-7 is to be installed or libapache-mod-php5 ( 5.2) but 5.2.0-7 is to be installed or libapache2-mod-php4 (= 4:4.3) but it is not going to be installed or libapache-mod-php4 (= 4:4.3) but it is not going to be installed E: Broken packages cheetah:~# and it is also not possible tun run apache -php4 and -php5 at same time! De-install php5 and install php4. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402519: Bug #402519 kernel-patch-debianlogo: doesn't apply with 2.6.18
Package: kernel-patch-debianlogo Version: 1.5 Followup-For: Bug #402519 dear Philip, I am just testing the new release of kernel-patch-debianlogo (which is going to be renamed to linux-patch-debianlogo) which is thought to patch the kernel from 2.6.18. It was first thought to be relased for Etch+1, but in this case it is needed for Etch If you would like you can test the code from Alioth's svn repos: svn.debian.org/svn/pkg-debianlogo You am going to inform as soon as possible of ruslts. cheers SteX -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-stex Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to it_IT.UTF-8) -- Stefano Melchior, GPG key = D52DF829 - [EMAIL PROTECTED] http://etinarcadiaego.dyndns.org -- [EMAIL PROTECTED] Skype ID stefanomelchior signature.asc Description: Digital signature
Bug#402337: Home page is gone in transition from Mozilla to Iceape
I'm not sure this is fixable for people who have the old mozilla homepage. The page was located in /usr/share/doc/mozilla and as far as I know, this location doesn't exist anymore. You could for instance ln to the new doc location, but a some point in time, maybe with a next upgrade, this will break! Also, if you do this again on a new location, there is a good chance that will break too with a next upgrade. The enhanced about: page is probably a good idea. so far my $0,02 ;-) Hendrik-Jan 2006/12/14, Mike Hommey [EMAIL PROTECTED]: On Wed, Dec 13, 2006 at 10:40:58PM +0100, Alexander Sack [EMAIL PROTECTED] wrote: On Sat, Dec 09, 2006 at 04:51:01PM +0100, Sergio wrote: The home page file was: /usr/share/doc/mozilla-browser/localstart.html So ... do we still want this homepage or something else? I prefer to use an enhanced about: page as homepage, but that won't solve the problem for people who have this old localstart homepage in prefs.js in their profile... Mike ___ pkg-mozilla-maintainers mailing list [EMAIL PROTECTED] http://lists.alioth.debian.org/mailman/listinfo/pkg-mozilla-maintainers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403050: kmail: NTLM authentication fails
Package: kmail Version: 4:3.5.5.dfsg.1-3 Severity: normal I've been trying to get Kmail to work with my company's MS Exchange 2003 server, using NTLM. I always get that the password is invalid. Just changing the authentication to plaintext (not re-entering the pw) makes everything work fine. I've got no problem using fetchmail with NTLM. This bug has also been reported in the KDE BTS: http://bugs.kde.org/show_bug.cgi?id=132391 Kind regards, Jan -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.1 Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15) Versions of packages kmail depends on: ii kdebase-kio-plugins4:3.5.5a.dfsg.1-3 core I/O slaves for KDE ii kdelibs4c2a4:3.5.5a.dfsg.1-5 core libraries and binaries for al ii kdepim-kio-plugins 4:3.5.5.dfsg.1-3 KDE pim I/O Slaves ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libaudio2 1.8-2 The Network Audio System (NAS). (s ii libc6 2.3.6.ds1-9 GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1 generic font configuration library ii libfreetype6 2.2.1-5 FreeType 2 font engine, shared lib ii libgcc11:4.1.1-21GCC support library ii libice61:1.0.1-2 X11 Inter-Client Exchange library ii libidn11 0.6.5-1 GNU libidn library, implementation ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libkcal2b 4:3.5.5.dfsg.1-3 KDE calendaring library ii libkdepim1a4:3.5.5.dfsg.1-3 KDE PIM library ii libkleopatra1 4:3.5.5.dfsg.1-3 KDE GnuPG interface libraries ii libkmime2 4:3.5.5.dfsg.1-3 KDE MIME interface library ii libkpimidentities1 4:3.5.5.dfsg.1-3 KDE PIM user identity information ii libksieve0 4:3.5.5.dfsg.1-3 KDE mail/news message filtering li ii libmimelib1c2a 4:3.5.5.dfsg.1-3 KDE mime library ii libpng12-0 1.2.15~beta5-0PNG library - runtime ii libqt3-mt 3:3.3.7-1 Qt GUI Library (Threaded runtime v ii libsm6 1:1.0.1-3 X11 Session Management library ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-4 X11 client-side library ii libxcursor11.1.7-4 X cursor management library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxft22.1.8.2-8 FreeType-based font drawing librar ii libxi6 1:1.0.1-4 X11 Input extension library ii libxinerama1 1:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-5 X11 RandR extension library ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii perl 5.8.8-7 Larry Wall's Practical Extraction ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages kmail recommends: ii procmail 3.22-16Versatile e-mail processor -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402829: mantis: not supportable by the security team
Damyan Ivanov wrote: 2006/12/14, schönfeld / in-medias-res.com [EMAIL PROTECTED]: Until the next release of Debian I will try to keep mantis packages as up-to-date as possible and then we will hopefully re-integrate it. Patrick, This will still help Debian users, especially if you provide a backport for Etch. Just remember that there is no security support for that (except the one you/upstream provide). Yeah, thats true. And i *will* provide the best support that i can provide and also a backport. -Patrick signature.asc Description: OpenPGP digital signature
Bug#402983: texlive-bin: ttf2afm, and all of ttfutils, is missing
Ralf Stubner [EMAIL PROTECTED] wrote: ttfdump (no idea where that comes from, no idea what it is) It seems to be available only in TeXlive now, not even separately on CTAN. And the project it was once supposed to be part of of doesn't seem to exist, and the developer is MIA: All changes since 1998 have been done by Werner Lemberg. And the purpose of ttfdump is to dump the various table in a TrueType font file in ASCII form. Regards, Frank -- Dr. Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#402115: gsoap: Request newer version. 2.7.9a available. NMU packages available.
Thanks for packaging gsoap for debian. I've tested it but /usr/include/gsoap/stl*.h files are not present (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=330886) Patch for debian/rules is attached It would be great if you'll apply this to your packages Pavel --- gsoap-2.7.9a.orig/debian/rules 2006-12-14 12:09:30.0 +0300 +++ gsoap-2.7.9a/debian/rules 2006-12-14 11:27:25.0 +0300 @@ -79,8 +79,8 @@ mkdir -p $(CURDIR)/debian/gsoap/usr/share/doc/gsoap # Install .h files required for soapcpp2 - not needed anymore since 2.7.6c - # mkdir -p $(CURDIR)/debian/gsoap/usr/include/gsoap - # cp soapcpp2/stl*.h $(CURDIR)/debian/gsoap/usr/include/gsoap + mkdir -p $(CURDIR)/debian/gsoap/usr/include/gsoap + cp soapcpp2/import/stl*.h $(CURDIR)/debian/gsoap/usr/include/gsoap # Install upstream changelog and convert it to text (policy 12.7) html2text soapcpp2/changelog.html $(CURDIR)/debian/gsoap/usr/share/doc/gsoap/changelog
Bug#367872: FTBFS (alpha): too few arguments to function 'bfd_hash_table_init'/invalid lvalue
Falk Hueffner [EMAIL PROTECTED] writes: [...] dldbfd.c: In function 'alphaelf_init_got_info': dldbfd.c:1518: error: too few arguments to function 'bfd_hash_table_init' Upstream applied the patch from #367872 in 1.2.1, so this part is fixed. dldbfd.c: In function 'alphaelf_create_got': dldbfd.c:1597: error: invalid lvalue in assignment This is a reincarnation of #336086. I'll see if I can fix it today. Thanks, Matej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403051: linux-image-2.6.18-3-686: lm78 hwmon driver stopped working on upgrade from Sarge
Package: linux-image-2.6.18-3-686 Version: 2.6.18-7 Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 lm78 hwmon stopped working after upgrading from Sarge (kernel-image-2.6.8-3-686 version 2.6.8-16sarge6) to Etch (linux-image-2.6.18-3-686 version 2.6.18-7). The system is an Asus P2L97S, having a LM78-J on ISA port 0x290. This used to show up as the directory /sys/bus/i2c/drivers/lm78/0-0290/. After upgrading, this directory has disappeared: canardo:/home/bjorn# lsmod|grep lm78 lm78 15988 0 i2c_isa 5152 1 lm78 hwmon_vid 2784 1 lm78 i2c_core 19680 6 lm78,i2c_dev,i2c_algo_bit,i2c_isa,eeprom,i2c_piix4 canardo:/home/bjorn# ls -l /sys/bus/i2c/drivers/lm78/ total 0 - --w--- 1 root root 4096 2006-12-14 12:20 bind lrwxrwxrwx 1 root root0 2006-12-14 12:20 module - ../../../../module/lm78 - --w--- 1 root root 4096 2006-12-14 12:20 unbind sensors-detect still finds the chip: ... Some chips are also accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (YES/no): Probing for `National Semiconductor LM78' at 0x290... No Probing for `National Semiconductor LM78-J' at 0x290... Success! (confidence 6, driver `lm78') Probing for `National Semiconductor LM79' at 0x290... No ... Driver `lm78' (should be inserted): Detects correctly: * ISA bus address 0x0290 (Busdriver `i2c-isa') Chip `National Semiconductor LM78-J' (confidence: 6) ... But sensors can't read anything (as expected since the sysfs entries are missing): canardo:/home/bjorn# sensors No sensors found! Make sure you loaded all the kernel drivers you need. Try sensors-detect to find out which these are. Let me know if you need more information about the system. Bjørn - -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (700, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages linux-image-2.6.18-3-686 depends on: ii coreutils 5.97-5 The GNU core utilities ii debconf [debconf-2.0] 1.5.8 Debian configuration management sy ii initramfs-tools [linux-initra 0.85c tools for generating an initramfs ii module-init-tools 3.3-pre3-1 tools for managing Linux kernel mo Versions of packages linux-image-2.6.18-3-686 recommends: pn libc6-i686none (no description available) - -- debconf information: linux-image-2.6.18-3-686/postinst/bootloader-error-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-dir-initrd-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/kimage-is-a-directory: linux-image-2.6.18-3-686/postinst/old-system-map-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/create-kimage-link-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/bootloader-test-error-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/abort-overwrite-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/old-initrd-link-2.6.18-3-686: true shared/kernel-image/really-run-bootloader: true linux-image-2.6.18-3-686/preinst/elilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/lilo-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/postinst/depmod-error-initrd-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/bootloader-initrd-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/removing-running-kernel-2.6.18-3-686: true linux-image-2.6.18-3-686/prerm/would-invalidate-boot-loader-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/abort-install-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/overwriting-modules-2.6.18-3-686: true linux-image-2.6.18-3-686/preinst/initrd-2.6.18-3-686: linux-image-2.6.18-3-686/preinst/lilo-has-ramdisk: linux-image-2.6.18-3-686/preinst/already-running-this-2.6.18-3-686: linux-image-2.6.18-3-686/postinst/depmod-error-2.6.18-3-686: false linux-image-2.6.18-3-686/preinst/failed-to-move-modules-2.6.18-3-686: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFgThz10rqkowbIskRAucmAKCS/YiFi5tVyuL/XHnDO8Vu4cEcsACfdtrr TvPdOWSXIMYTf3kgkedikP8= =tBXe -END PGP SIGNATURE-
Bug#402653: Fwd: Bug#402653: kdvi crashes on startup
severity 402653 important tags 402653 + moreinfo unreproducible thanks Hi, On Tue, Dec 12, 2006 at 10:00:26AM -0800, Slaven wrote: I should add that I was able to reproduce this behavior only after a fresh install of kdvi. On all machines where I upgraded kdvi from older version, the new version worked fine. My guess is that the most recent kdvi may be missing some configuration file. The machine where this problem occurs is running clean and up to date Etch. I just installed a fresh etch install (chroot via deboostrap), and kdvi worked fine. So i'm downgrading this bug. Your configuration files were fine, so the problem is in another place. Are you suffering this problem with more packages? Did this happen to you in only a single installation? Ana -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403034: Deep MIME Nesting Content Filter Bypass
This one time, at band camp, Hendrik Weimer said: While the new 0.88.7 version fixes CVE-2006-6406 and CVE-2006-6481 the update introduces another flaw that lets viruses pass undetected. If a virus is nested deeper than the --max-mail-recursion limit, the file will pass and ClamAV's exit code indicates that the file was scanned properly. Again, details, PoC, and discussion can be found at http://www.quantenblog.net/security/virus-scanner-bypass. I'm not sure what clamav should do here. What algorithm do you suggest for infinitely recursive scanning without memory exhaustion or other physical limits being hit? We could return OverNesteded.MIME as the virus name, I suppose, but I have had plenty of complaints over the years about the various block max settings, so I'm not sure this is always the right thing to do either. We could change clamscan's exit code, but that of course doesn't do anything for the people who don't use clamscan - exiscan uses a direct socket to clamd, dansguardian uses a public library API, etc. So, suggestions? -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - signature.asc Description: Digital signature
Bug#363424: [EMAIL PROTECTED]: Re: Bug#362590: FTBFS on m68k]
On Tue, Oct 03, 2006 at 02:29:29PM -0500, Stephen R Marenka wrote: On Tue, Oct 03, 2006 at 04:26:01PM +0200, Jeroen van Wolffelaar wrote: On Wed, Apr 19, 2006 at 12:25:36AM +0200, Reinhard Tartler wrote: Please remove the following m68k binary packages from unstable. Discussion about this happened here: http://lists.debian.org/debian-68k/2006/04/msg00021.html xpilot-ng-client-x11_1:4.7.2-1.1 xpilot-ng-client-sdl_1:4.7.2-1.1 rss-glx_8.0.5-5 python-openal_0.1.5-1 libosgal-cvs1_20060215-5 libopenalpp-cvs1_20060217-2 libopenal-dev_0.2005080600-2.1+b1 flightgear_0.9.9-1 crystalspace_0.98-20040623-2.1 chromium_0.9.12-11 openal has been marked 'not-for-us' and should be in p-a-s soon, so those binaries should not come back. Well, m68k is still building those, so if I'd remove them now, they'd return. Please ensure m68k is actually really FTBFS'ing, preferably by having some self-test that will fail because m68k is unsupported, or if that isn't doable, just exit 1'ing when you're building on m68k. Once the package is outdated on m68k, I can remove it. As it is now, it'd return in the same version, causing all kinds of awkwardies. There was a bit of a disagreement among the m68k porters as to whether they should go or not. xpilot-ng ftbfs due to an ICE that gets about five packages. osgal-cvs is dep-waited. I don't know what the deal is with crystalspace, but we're hardly the only arch with problems there. All the other packages seem to build fine now. This particular bug was marked fixed in July. So... this bug can be closed, or...? --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#368786: openscenegraph: FTBFS on GNU/kFreeBSD
found 368786 1.2.0-2 reopen 368786 thanks Hi, the current version again fails to build on GNU/kFreeBSD. Please use the same patch as before to fix that. Failure in patching of OpenSceneGraph/src/osgPlugins/net/sockstream.cpp ignore, source file have been changed by upstream and now it is fine also for GNU/kFreeBSD. It would also be nice if you can ask upstream to include this changes. Thanks in advance Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403056: wengophone: FTBFS: CMake Error: Error in cmake code at [..]./cmake/Modules/FindAlsa.cmake:24:Unknown CMake command check_library_exists.
Package: wengophone Version: 2.0.0~rc5-svn8108-2 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. Relevant parts: -- Looking for C++ include sys/asoundlib.h -- Looking for C++ include sys/asoundlib.h - found -- Looking for C++ include alsa/asoundlib.h -- Looking for C++ include alsa/asoundlib.h - found CMake Error: Error in cmake code at /build/root/wengophone-2.0.0~rc5-svn8108/./cmake/Modules/FindAlsa.cmake:24: Unknown CMake command check_library_exists. -- Configuring done make: *** [obj-i486-linux-gnu/CMakeCache.txt] Error 255 The full build log is available from http://blop.info/bazaar/buildlogs/20061214/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401266: Bug#393422: Contains non-free files
if you belive that the files used to build debians packages are free then wouldn't the obvious thing to do be to remove everything else from the source packages? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#376497: Reported upstream.
close 402941
forcemerge 400878 376497
thanks
On Wed, Dec 13, 2006 at 06:05:16PM +0100, Raúl Sánchez Siles wrote:
forward 376497
https://sourceforge.net/tracker/index.php?func=detailaid=1614925group_id=245atid=100245
clone 376497 -1
reassign -1 aspell-es
block 376497 -1
thanks
I think aspell-es package maintainer should be informed about this bug.
Thanks for that, I already read Debian aspell bugs
Even this is an aspell-es bug, I don't think libaspell should crash like that
for this reason.
This bug report seems caused by a bug in aspell -m option, which I already
reported upstream,
https://sourceforge.net/tracker/index.php?func=detailaid=1565738group_id=245atid=100245
and is already fixed by Kevin Atkinson. Fix will go in aspell-0.60.5.
$ echo table | aspell -m -a -dspanish
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.4)
table 26 0: tablea, tablee, tableo, tableé, tableó, tabule, tabulé, tabla,
tabalea, tabalee, tabaleo, tabaleé, tabaleó, tabelle, tablao, tabula,
tabulo, tabuló, tale, atable, talle, bable, cable, dable, hable, sable,
tablar-^L^F+e
Installing upstream patch and rebuilding aspell,
$ echo table | aspell -m -a -dspanish
@(#) International Ispell Version 3.1.20 (but really Aspell 0.60.4)
table 26 0: tablea, tablee, tableo, tableé, tableó, tabule, tabulé, tabla,
tabalea, tabalee, tabaleo, tabaleé, tabaleó, tabelle, tablao, tabula,
tabulo, tabuló, tale, atable, talle, bable, cable, dable, hable, sable,
tablar-ar+e
as expected.
Closing this bug report and doing some other administrative work on it.
I am attaching the relevant patch.
--
Agustin
Index: prog/aspell.cpp
===
RCS file: /sources/aspell/aspell/prog/aspell.cpp,v
retrieving revision 1.103.2.2
diff -u -r1.103.2.2 aspell.cpp
--- prog/aspell.cpp 19 Jun 2005 12:00:46 - 1.103.2.2
+++ prog/aspell.cpp 23 Nov 2006 14:36:57 -
@@ -870,7 +870,8 @@
if (ci-pre_strip_len 0)
guess.append('-').append(ci-word.str(), ci-pre_strip_len);
if (ci-suf_strip_len 0)
-guess.append('-').append(ci-word.str() - ci-suf_strip_len, ci-suf_strip_len);
+guess.append('-').append(ci-word.str() + ci-word.size() - ci-suf_strip_len,
+ ci-suf_strip_len);
if (ci-suf_add ci-suf_add[0])
guess.append('+').append(ci-suf_add, ci-suf_add_len);
real_speller-lang().fix_case(casep, guess.data(), guess.data());
Bug#289267: Debian #289267: ntpdate should use ifupdown instead of rcS to start
* Scott James Remnant Matt's asked me to jump in here to explain the Ubuntu changes, and our long-term plan for such thing; as there seems to be a little confusion and/or argument on this topic. Thanks, I appreciate it. Our reason for moving this to an if-up.d script is because we're increasingly relying on udev to drive the hardware parts of our boot sequence; this meant that there was no point in the SysV boot sequence where networking was up, so no point to run the ntpdate script. Moving to an if-up.d script meant that the clock would be adjusted during boot when the each ethernet card came up; the first not being sufficient as that one might not actually get an IP. I know, but see below for comments. This isn't ideal either, as now ntpdate gets run every time you fiddle with an interface. Our preferred solution is to use upstart to manage the ntpdate task, and don't run it once it has succeeded at least once. I'm not familiar with upstart, I'm afraid, so I can't comment on that. We use -b because it was what was suggested in the manual page: -b Force the time to be stepped using the settimeofday() system call, rather than slewed (default) using the adjtime() system call. This option should be used when called from a startup file at boot time. The if-up.d ntpdate script is intended to set the clock at boot time, once the first interface with a reachable ntp server has come up. But right now it does not check if any of this is true, which is my main grief here. When the services are done being started (and I think you'll have to assume they do during bootup), it is not safe to step the clock. I think it would be reasonable to assume that this is a concern primarily for server systems that are probably always connected anyway, and thus it would be okay to step the clock later if there was no network at boot (even though this can cause trouble for desktop systems too in some cases, see #364288 for an example). In any case, though, it should not be stepped unless deemed necessary by ntpd[ate] because of a large offset. So if there's a chance of ntpdate being run after bootup, it shouldn't use -b. Default behaviour is okay. I've cooled down a bit now, so I'll moderate myself a bit about demanding -B. :-) * Tore Anderson If no NTP server is available at bootup, well, then you'll just have to wait for a network connection and possibly step the time then. * Scott James Remnant That's what we're trying to do with the ntpdate script. My opinion is that ntpd is better used for this. When I run ntpd, I expect it to do so if necessary. When I run ifup I expect it to do just that - bring an interface up. Not meddle around with system time, or do any other things unrelated to bringing the interface up. I'm a sysadmin. I don't like surprises. Having my clock stepped on ifup is definetively a surprise, and a nasty one too (offlined half our office). Besides, using ntpd for this would handle the situation where a route to the NTP server is provided by something else than ifupdown, such as a routing service (my case), a PPP[oE] daemon (common xDSL/GSM setups here in Norway at least), and probably other situations too. Finally, ntpd is more accurate than ntpdate - at least it says so in the manual page. Given the above, how would you recommend we sync the clock during boot if no clock adjustments would be preferred? Note gratuitous. I realise that's a matter of personal opinion, but I agree both with you and ntpdate's manual page that stepping on bootup is fine. On the other hand, I think stepping at an arbitrary time after the system is up and running is just asking for trouble, at least for production systems (and again, it might be for desktops too). If I understand you correctly you/Ubuntu think this is an acceptable trade- off and I obviously disagree with you on that. So my recommendation would be to call ntpdate on bootup after udev was started (maybe using Required-Start: $network instead if that's working). If it failed, oh well, start ntpd -g anyway and it'll synchronise when/if the time server becomes reachable at some later point. And most importantly - it will not step unless it feels it needs to do so because of a large offset, and paranoid me, running services I know depend on clock sanity, can add -x to the the ntp- server init script and be safe no stepping will occur after initial boot. If you insist on coupling this to ifup, though: Check to see if the ifup is related to time server reachability at all (in my case it wasn't, which made the whole ordeal feel even more pointless). In pre-up.d do ip route get time server, see if there's already a route there, and if so just skip syncing (or at least, drop -b) in post-up.d. Also you could make the script see if /etc/nologin is present, if not, it's likely not running at system bootup, skip
Bug#403053: ITP: qct -- GUI commit tool for mercurial
Package: wnpp Severity: wishlist Owner: Vincent Danjean [EMAIL PROTECTED] * Package name: qct Version : Not yet released Upstream Author : Steve Borho [EMAIL PROTECTED] * URL : http://hg.borho.org/qct/ * License : GPL Programming Lang: Python (with PyQt4) Description : GUI commit tool for mercurial qct is a new project. Its aim is to provide a graphical way to commit changesets to mercurial (a distributed source management software packaged by me). qct is similar to gct (already packaged by me as 'commit-tool'). The main differences are : * commit-tool targets several VCs (git, mercurial, ...) qct is specific to mercurial (so it can have speficif options) * qct is under active development * qct aims to be the 'standard' way to commit with mercurial My goal is to package this tool to allow easy testing of it. I will do it in experimental. If 'qct' keeps a separate projet, and when it will be released, I will upload to unstable. But if qct is merged with mercurial, I will include it directly in my mercurial package. Vincent PS: here is a possible long description: qct is a GUI enabled commit tool for Mercurial (hg). It should be available on all plateform where Mercurial works (*nix, Mac, Windows, ...). It allows the user to view diffs, select which files to commit (or ignore / revert), write commit messages and perform the commit itself. . Homepage: http://hg.borho.org/qct/ -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403059: simpledb: FTBFS: b-dep on libstdc++6-4.0-dev | libstdc++5-3.3-dev, neither of them is available
Package: simpledb Version: 1.5-1 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. It build depends on libstdc++6-4.0-dev | libstdc++5-3.3-dev, neither of which is available in testing. The full build log is available from http://blop.info/bazaar/buildlogs/20061214/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396427: smstools do not support PDU messages
Hi, Smstools (also 1.x) supports PDU messages and this mode is also a default. Older versions of smstools supports ASCII mode also, but this should be used for testing purposes only. Current versions (2.x and 3.x) do not support ASCII mode anymore. If an ASCII mode is defined, modem is initialized to the ASCII mode. However, if a received message contains characters outside ascii table, message is still received as PDU from the modem. Smstools 1.x is unable to check this and therefore a PDU is stored to the incoming message file. So my quess is that you have mode = ascii set in your smsd.conf and in this case you should remove this setting or change it to mode = new. After this change no external character set conversion is required unless UTF-8 is used as locale. Smstools uses ISO character set in the files and necessary conversion can be done by using the checkhandler and eventhandler features. Take a look at the next releases, they will include instructions about how this conversion can be done. Instructions can also be found on the support website. Hope this helps. Regards, Keke Author of smstools v3.x http://smstools3.kekekasvi.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403055: ITP: array-info -- command line HP (Compaq) SmartArray status checker
Package: wnpp Severity: wishlist Owner: Raphaël Pinson [EMAIL PROTECTED] * Package name: array-info Version : 0.12 Upstream Author : Benoit Gaussen [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/array-info * License : GPL Description : command line HP (Compaq) SmartArray status checker Array-info is a command line tool to retrieve informations and logical drives status from several RAID controllers (currently HP Compaq IDA and CISS). . It displays informations about the firmware version, Rom revision, number of physical and logical drives on the controller, aswell as the fault tolerance, size, number of physical disks and status for each logical drive. -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.14 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Bug#403036: uswsusp: Bogus warnings about CONFIG_SOFTWARE_SUSPEND during package upgrade
retitle 403036 Only warn on install for missing kernel support thanks On Thu, 14 Dec 2006 10:24:21 +0100 Guus Sliepen [EMAIL PROTECTED] wrote: Package: uswsusp Version: 0.3~cvs20060928-6 Severity: normal When I upgrade the uswsusp package, I get a debconf warning that I don't have CONFIG_SOFTWARE_SUSPEND enabled in my kernel TWICE. First of all, if my kernel is configured incorrectly, and if you want to warn about it, please only do so during the first time you install the package, not during every upgrade. Hmm, yes that would be better. Second, looking at the uswsusp.config script, I see it doesn't really test for CONFIG_SOFTWARE_SUSPEND, it tests whether there is snapshot support or not, and then shows the debconf template uswsusp/no_snapshot. Maybe the template is wrong? It confuses me. And why is this debconf message critical? No, the template is not wrong. If you have CONFIG_SOFTWARE_SUSPEND, you'll have /sys/class/misc/snapshot/dev. It is needed for userspace software suspend. Testing for that file in /sys is the simplest way to see if your system is capable of doing uswsusp. Third, whether or not I have snapshot support or not, this package may be perfectly useful to me. The s2ram utility for example does not require any special kernel support. I'd rather not see any warning at all. The name of this package is 'uswsusp', which is (an ugly) abbreviation of Userspace Software Suspend (implemented in s2disk and s2both). Software suspend is indeed its primary purpose. Upstream even supplies s2ram as a 'testing utility'. I was tired of getting bug reports of people that said that `It doesn't work', when in fact they didn't have support in their kernel. The warning stays. I think however, that I will adopt your suggestion to only show it on install. grts Tim signature.asc Description: PGP signature
Bug#403057: azureus: throws java.lang.NoSuchMethodError: fixedClassInitProc exception on startup (amd64 specific)
Package: azureus Version: 2.5.0.0+0-1 Severity: important Hello, I don't exactly know it's azureus or swt-gtk bug. Please reassign if appropriate. Azeurus throws this exception on start (with sun-java5-jre): java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.gudy.azureus2.ui.common.Main.directLaunch(Main.java:225) at org.gudy.azureus2.ui.common.Main.main(Main.java:132) Caused by: java.lang.NoSuchMethodError: fixedClassInitProc at org.eclipse.swt.internal.Callback.bind(Native Method) at org.eclipse.swt.internal.Callback.init(Callback.java:123) at org.eclipse.swt.internal.Callback.init(Callback.java:78) at org.eclipse.swt.internal.Callback.init(Callback.java:60) at org.eclipse.swt.widgets.Display.createDisplay(Display.java:807) at org.eclipse.swt.widgets.Display.create(Display.java:781) at org.eclipse.swt.graphics.Device.init(Device.java:145) at org.eclipse.swt.widgets.Display.init(Display.java:452) at org.eclipse.swt.widgets.Display.init(Display.java:443) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.init(SWTThread.java:82) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread.createInstance(SWTThread.java:61) at org.gudy.azureus2.ui.swt.mainwindow.Initializer.init(Initializer.java:110) at org.gudy.azureus2.ui.swt.Main.init(Main.java:147) at org.gudy.azureus2.ui.swt.Main.main(Main.java:162) ... 6 more Start fails: com.aelitis.azureus.core.AzureusCoreException: Azureus core already instantiated at com.aelitis.azureus.core.impl.AzureusCoreImpl.create(AzureusCoreImpl.java:89) at com.aelitis.azureus.core.AzureusCoreFactory.create(AzureusCoreFactory.java:46) at org.gudy.azureus2.ui.common.Main.main(Main.java:137) I manage to fix it by recompiling swt-gtk source package (java-gcj-compat javac) after setting env variable by export SWT_PTR_CFLAGS=-DSWT_PTR_SIZE_64; dpkg-buildpackage ... and installing result packages: libswt-gtk-3.2-java_3.2.1-3_amd64.deb libswt-gtk-3.2-jni_3.2.1-3_amd64.deb Don't know if it's proper fix or it broke other packages. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-amd64 Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Versions of packages azureus depends on: ii gij [java-virtual-machine] 4:4.1.1-13 The GNU Java bytecode interpreter ii gij-4.1 [java2-runtime] 4.1.1-17 The GNU Java bytecode interpreter ii java-gcj-compat 1.0.65-8 Java runtime environment using GIJ ii libcommons-cli-java 1.0-8API for working with the command l ii liblog4j1.2-java1.2.13-3 Logging library for java ii libseda-java3.0-3the Staged Event-Driven Architectu ii libswt-gtk-3.2-java 3.2.1-3 Standard Widget Toolkit for GTK Ja ii sun-java5-jre [java2-runtim 1.5.0-08-1.1 Sun Java(TM) Runtime Environment ( azureus recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403058: xtla: FTBFS: b-dep on emacs-snapshot, which is not in testing
Package: xtla Version: 1.2.1-1 Severity: serious Justification: FTBFS on i386, very likely to fail everywhere else Usertags: grid5000 Hi Matthieu, During a rebuild of all packages in etch, I discovered that your package failed to build on i386. It build-depends on emacs-snapshot, which is not available in testing (see #321676). The full build log is available from http://blop.info/bazaar/buildlogs/20061214/ About the archive rebuilt: The rebuilt was done on about 30 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing an etch i386 environment (not unstable). Internet was not accessible from the build systems. The builds were processed as root. About Grid'5000: Grid'5000 is an highly reconfigurable experimental Grid platform gathering 9 sites and featuring a total of 5000 CPUs. It serves as a testbed for research in Grid Computing. See https://www.grid5000.fr/ -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#286379: Lintian insecure removal bug (#286379)
No reply to this in nearly 2 years. My opinion didn't change, IMHO it is user-requested behaviour to get things writable by group is you set umask to 02 -- that's what umask *does*. If anybody disagrees, you can do either of these three: 1) convince the security team to rule that this is indeed a security bug and behaviour must be changed 2) convince lintian maintainers likewise. Nobody so far disagreed here in this buglog or tended to this bugreport, so I assume the team agrees with me here: you'd most likely need new argumentation for that 3) Appeal to tech-ctte if the above fails Otherwise, I'll close this bugreport by the end of the year. --Jeroen On Tue, Dec 21, 2004 at 03:34:54PM +0100, Jeroen van Wolffelaar wrote: On Tue, Dec 21, 2004 at 03:26:12PM +0100, Martin Schulze wrote: I haven't verified that this code is executed for each lintian execution. However, if it is, then its an issue since the process does not fail if mkdir fails, instead the directory is used. This is simply not true, see [1]. This code is executed every lintian invocation, but a failing mkdir _will_ abort lintian. The current discussion is about whether or not it is okay for lintian to use a directory made with current umask, since for example an umask of 02 would render you vulnerable to attacks by members of the same group[2]. In my opinion, this is a user-error having 02 umask with untrusted members of the same group[3], but the bug submitter disagrees[4]. Sorry for the mess that this buglog is, at the moment... --Jeroen [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286379msg=12 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286379msg=24 [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286379msg=27 [4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286379msg=36 -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
