Bug#519548: Getting mondo updated
Hi Rogério, That sounds all good to me! Please go ahead. I am also CC'ing upstream and I suggest the of you communicate directly, especially but not limited to issues that could possibly be addressed upstream - Bruno is planning a new release shortly. Thanks a lot best regards, Andree On Wed, 2009-08-26 at 06:05 -0300, Rogério Brito wrote: Hi, Andree. It is strange, but I have not received any mails on my account. Please, reply with a CC to my address rbr...@users.sf.net so that I have more chance of seeing the messages (apparently, my University's mail server has a problem). Anyway, back to the subject of maintaining mondo, yes, I would like to work on it a little bit. I'm still not sure if I can co-maintain it (most probably, I can), but I would like to delve further in the code. That being said, if I decide to co-maintain the package, can I put my name in the uploaders field and add the DMUA: yes (as I am a DM)? In fact, I think that a good thing would be to have mondo/mindi/etc in a public repository (I would suggest that we create one named pkg-mondo in alioth). What do you think? I would also be willing to spread the word so that we can get some more contributions (and/or users). Regards, Rogério Brito. -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#519548: patch to fix mondo
Hi Rogério, If you want to do an NMU of this one I am perfectly happy with this, in fact I would be grateful. I have had virtually no time to spend on my packages at all for the last three or four month but hope this will change soon. I am wondering: Would you consider becoming co-maintainer of the Mondo Rescue Debian packages? Best regards, Andree On Wed, 2009-08-26 at 04:45 -0300, Rogério Brito wrote: Hi, Andree. I hope that you're doing well. On 2009-04-22, at 11:05, Andree Leidenfrost wrote: Sounds all great! I think BTS is the way to go: Just file more bug reports and attach the patches. I'll look over them when I return. (...) As I have not heard from you for some months, I just thought that maybe it would be a good time to get in touch again. Are you fine with a NMU of mondo, including the patch that I sent you earlier this year? This would fix an RC bug and would get us one step closer to our next release. Please, reply ASAP. Thank you very much, Rogério Brito. -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#519548: patch to fix mondo
Hi Rogério, Sounds all great! I think BTS is the way to go: Just file more bug reports and attach the patches. I'll look over them when I return. However, really most issues with mondo need to be addressed upstream ultimately. So, you could also consider starting to contribute to upstream directly. (But I am happy for you to file via BTS and then I push to upstream.) Best regards, Andree On Tue, 2009-04-21 at 11:42 -0300, Rogério Brito wrote: Dear Andree, On Apr 21 2009, Andree Leidenfrost wrote: Nice to hear from you again! Nice to know that you're maintaining mondo. I think that it would be a nice thing to have it support backups on powerpc's... I have three here that would be nice to be backed up. Thanks a lot for the patch! I thought I had it all covered but not so, obviously. Thanks again. I think that you missed it because the code seems (at least at a first glance) to be much more complicated than necessary, with some duplication of code. Also, it seems that the code could be cleaned up a little. I've revamped my computer over Easter (read: I didn't have a working one) and have thus not been able, unfortunately, to release a new package version with your patch included. I am going away on Thu only to return on 11 May. But I will definitely release a new version with your patch soon after. Nice. I am very glad that mondo is dropping a dependency. :-) Other than that, I would be very happy to receive more patches from you in the future! I will chase some warnings and see what can be fixed. Where would you prefer me to send you patches? Here in Debian's BTS? Directly to your personal e-mail? Thanks, -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#519548: patch to fix mondo
Hi Rogério, Nice to hear from you again! Thanks a lot for the patch! I thought I had it all covered but not so, obviously. Thanks again. I've revamped my computer over Easter (read: I didn't have a working one) and have thus not been able, unfortunately, to release a new package version with your patch included. I am going away on Thu only to return on 11 May. But I will definitely release a new version with your patch soon after. Other than that, I would be very happy to receive more patches from you in the future! Thanks a lot for your help! Best regards, Andree On Wed, 2009-04-08 at 08:00 -0300, Rogério Brito wrote: tags 519548 +patch thanks Here is a patch to fix mondo so that it stops seeing if cdrecord is available on systems that have wodim installed. I just tested it now and it seems to work fine, but I really think that mondo should have a function to check alternative names for some utilities (the case of wodim, cdrecord, dvdrecord, whatever) is potentially just one of these cases. I may be submitting other patches to the project, if this is desired. Regards, -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: New mindi-2.20-2 Uploaded
Hi Matija, Thank you very much for sending those patches through! They look pretty straight forward and I believe I understand what they do, so i have applied them and released mindi-2.20-2 which should currently be in. If you have the possibility, I would much appreciate you testing the new package in your environment to double-check. Happy Christmas thanks a lot for your help! Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: mindi does rm -Rf /home !
Hi Bruno, Thanks a lot for your response! On Thu, 2006-12-21 at 23:23 +0100, Bruno Cornec wrote: Matija Nalis said on Thu, Dec 21, 2006 at 09:35:08PM +0100: both have been fixed promptly in upstream. Ok I'm happy that they are now indeed fixed. I really like debian users as they give feedback ;-) I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I think you don't need to pass time on that Andree. I'll publish soon 2.2.1 which will fix that. You'll just have to update your packages. Unfortunately, a new upstream version in Debian is not currently an option as we are in freeze. I can really only fix RC bugs at the moment. I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I'd prefer that we fix the remaining differences in mindi ;-) Maybe this could be something to sort out during LCA2007? FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Great ;-) But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Yep, I'll be there too ;-)) Bruno. -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: mindi does rm -Rf /home !
Hi Matija, Thanks a lot for your response! On Thu, 2006-12-21 at 21:35 +0100, Matija Nalis wrote: On Thu, Dec 21, 2006 at 10:38:35PM +1100, Andree Leidenfrost wrote: Looking at the mailing list thread it looks like the patch listed in both the mailing list thread and in trac ticket 100 is the same and did not work because you wrote in the mailinglist thread in response to the patch: [...] Mondo doesn't run now, but at least it does not destroy the /home. Last version that I had used before, and which had created backups successfully was 2.06-4 (Andree's debian package, rebuilt for sarge) [...] No, that patch actually DID fix the rm -Rf /home problem correctly. It is just that I had _two_ major problems to start with: (1) the critical one in trac ticket 100 about rm -Rf /home, (I reported this one in Debian BTS as #403454) (2) the important bug about misdetection of LABEL= in /etc/fstab on debian because of hardcoded /bin/cut path (wrong path on debian) see http://sourceforge.net/mailarchive/message.php?msg_id=37518492 (I did not report this one on Debian BTS yet. Should I?) Yes, that would be very good. We are in freeze, so having bugs properly documented before I can address them was one essential prerequisite to get the fix into Etch before the release. both have been fixed promptly in upstream. Ok, I see. Thanks for clarifying that. I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. I can run tests (one run per day -- big server, takes a long time) and give feedback until 28 Dec; after that I'll be unavailable until end of January. FYI, the server currently runs your mindi 2.20-1 recompiled for sarge with only patches for above two problems, and it works ok. Would you be able to send your two patches to the BTS, one attached to #403454 and the second one attached to a new bug report for the LABEL issue? I think this way we'd minimise the risk of me getting it wrong. (I am a bit nervous because of the freeze as I have really only one shot to get it right.) Andree Leidenfrost @ Debian Developer Sydney - Australia But I'll be visiting LCA2007 in Sydney in mid-January, so direct interrogation is an option :) Hey, I'll be there as well, so it would be great to catch up! :-) However, I defintiely want to fix the issue at hand and the label issue as well as soon as possible. -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#403454: mindi does rm -Rf /home !
tags 403454 + pending thanks Hi Matija, Thank you for reporting this bug and for giving the pointers below. Looking at the mailing list thread it looks like the patch listed in both the mailing list thread and in trac ticket 100 is the same and did not work because you wrote in the mailinglist thread in response to the patch: [...] Mondo doesn't run now, but at least it does not destroy the /home. Last version that I had used before, and which had created backups successfully was 2.06-4 (Andree's debian package, rebuilt for sarge) [...] So, I need to look into this in a bit more detail. In the latest stable mindi SVN revision [1005] it looks like the code has just been commented out: FindIsolinuxBinary FindLiloBinary fi # BERLIOS: Remove as too dangerous and now useless #grep -F $MINDI_TMP /proc/mounts | grep -F tmpfs /dev/null 2 /dev/null MINDI_TMP=/home/tmpmondo mkdir -p $MINDI_TMP LogIt Changing MINDI_TMP to $MINDI_TMP because you're using tmpfs for /tmp \n ; # tmpfs doesn't like Mindi and /tmp, for some reason trap Aborted SIGTERM DONE=\r\t\t\t\t\t\t\t\tDone. I am just not sure whether commenting this out depends on other changes or not. [Bruno: Would you be able to shed some light on this?] I might send you a patch to try against mindi-2.20-1. Would you be able to test it? I intend to get this fixed over the weekend, i.e. no later than 24 Dec 06. Best regards, Andree On Sun, 2006-12-17 at 11:22 +0100, Matija Nalis wrote: Package: mindi Version: 2.20-1 Severity: critical Sometimes mindi decides to set TMP_ROOT to /home (if /tmp is mounted as tmpfs), and then at the cleanup phase does rm -Rf $TMP_ROOT. In practice, this resulted in losing whole /home directory. thread describing the problem in detail can be found at http://sourceforge.net/mailarchive/message.php?msg_id=37329155 The bug has since been fixed upstream, see http://trac.mondorescue.org/ticket/100 -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Fwd: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing]
Hm, reading through the entire bug report again (I only subscribed to it sometime yesterday, so didn't get the messages, sorry) I now understand that: - Anton thinks it is safe to not set the VOLUME_MOUNTED_ON_NT4 ever in ntfsresize. - Szaka believes it might not be safe and wants confirmation from MS. - David volunteered to take this up with an internal contact at MS if he were to receive a summary of the issue at hand. - David later suggested to just apply the patch and release a new Debian package - Frans cautioned that upload to experimental first would be better which David agreed to do Any ETA for this, David? I'm more than happy to test the package once it hits experimental. (Sorry for the hassling!) (I understand that there is also #380226, but taking one step at a time probably makes for a good approach.) Cheers, Andree Forwarded Message From: Andree Leidenfrost [EMAIL PROTECTED] To: Szakacsits Szabolcs [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing Date: Sat, 09 Dec 2006 16:42:13 +1100 Ok, I've now also successfully tested this with win2000 in addition to Vista in response to Frans' concern. Szaka, I would assume that your patch should work for XP and 2003 as well. Do you agree? What about NT4? (VOLUME_MOUNTED_ON_NT4 appears to be some sort of compatibility flag?) Cheers, Andree On Sat, 2006-12-02 at 15:36 +0200, Szakacsits Szabolcs wrote: On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote: Apparently Vista refuses to boot if an NTFS volume was mounted on NT4 earlier. This is also what ntfsresize lied to trick Windows to be compatible with itself. Could you please try the below patch against ntfsprogs 1.13.1 that the theory is correct? Thank you. I put a statically linked version here to ease the testing. http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz Thanks, Szaka --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.0 +0200 +++ ntfsprogs/ntfsresize.c 2006-12-02 00:09:44.058395088 +0200 @@ -2289,8 +2289,6 @@ u16 flags; flags = vol-flags | VOLUME_IS_DIRTY; - if (vol-major_ver = 2) - flags |= VOLUME_MOUNTED_ON_NT4; printf(Schedule chkdsk for NTFS consistency check at Windows boot time ...\n); -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
Ok, I've now also successfully tested this with win2000 in addition to Vista in response to Frans' concern. Szaka, I would assume that your patch should work for XP and 2003 as well. Do you agree? What about NT4? (VOLUME_MOUNTED_ON_NT4 appears to be some sort of compatibility flag?) Cheers, Andree On Sat, 2006-12-02 at 15:36 +0200, Szakacsits Szabolcs wrote: On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote: Apparently Vista refuses to boot if an NTFS volume was mounted on NT4 earlier. This is also what ntfsresize lied to trick Windows to be compatible with itself. Could you please try the below patch against ntfsprogs 1.13.1 that the theory is correct? Thank you. I put a statically linked version here to ease the testing. http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz Thanks, Szaka --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.0 +0200 +++ ntfsprogs/ntfsresize.c 2006-12-02 00:09:44.058395088 +0200 @@ -2289,8 +2289,6 @@ u16 flags; flags = vol-flags | VOLUME_IS_DIRTY; - if (vol-major_ver = 2) - flags |= VOLUME_MOUNTED_ON_NT4; printf(Schedule chkdsk for NTFS consistency check at Windows boot time ...\n); -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
Szaka, David, Frans, Okidoki, what happens now? I'd be keen to see this in the package and then in the installer ASAP. Is there going to be a new upstream release? Is the patch just going to be applied to the Debbian package? (Looks easy enough to me.) If there is anything I can do to help, please let me know. Cheers, Andree On Sun, 2006-12-03 at 18:42 +0200, Szakacsits Szabolcs wrote: Hi Andree, On Sun, 3 Dec 2006, Andree Leidenfrost wrote: I've tested and all looks well! When booting into Vista after a resize, chkdsk is started and after another reboot the system starts as usual. You are a star Thanks for the testing but I object the last sentence because I think this was quite a team work ;-) Cheers, Szaka -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
Hi Szaka, Thanks a lot for the static binary! I've tested and all looks well! When booting into Vista after a resize, chkdsk is started and after another reboot the system starts as usual. You are a star Cheers, Andree On Sat, 2006-12-02 at 15:36 +0200, Szakacsits Szabolcs wrote: On Sat, 2 Dec 2006, Szakacsits Szabolcs wrote: Apparently Vista refuses to boot if an NTFS volume was mounted on NT4 earlier. This is also what ntfsresize lied to trick Windows to be compatible with itself. Could you please try the below patch against ntfsprogs 1.13.1 that the theory is correct? Thank you. I put a statically linked version here to ease the testing. http://www.ntfs-3g.org/ntfsresize-1.13.1.1.tgz Thanks, Szaka --- ntfsprogs/ntfsresize.c.orig 2006-04-19 00:03:09.0 +0200 +++ ntfsprogs/ntfsresize.c 2006-12-02 00:09:44.058395088 +0200 @@ -2289,8 +2289,6 @@ u16 flags; flags = vol-flags | VOLUME_IS_DIRTY; - if (vol-major_ver = 2) - flags |= VOLUME_MOUNTED_ON_NT4; printf(Schedule chkdsk for NTFS consistency check at Windows boot time ...\n); -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] Bug#379628: CALL FOR HELP: Vista beta compatibility testing
Hi Szaka, No, this does unfortunately not make Vista boot for me. :-( Cheers, Andree On Sat, 2006-11-25 at 04:03 +0200, Szakacsits Szabolcs wrote: Hi, Could you please try this after running ntfsresize and before booting Vista: dd if=PARTITION bs=512 count=1 | dd of=PARTITION seek=LAST_SECTOR where LAST_SECTOR is the last sector on PARTITION. It can be calculated by running sfdisk -d DISK | grep PARTITION and then by subtracting 1 from the value of 'size'. Please let me know if this makes Vista boot or not. Thanks, Szaka -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#400024: mondo 2.20: wrong mountlist
[Bruno: If you have anything to add or correct, please let us know.] Hi Hugo, Would be great if you could cc the bug report. Other than that, thanks a lot for sending the additional information through! I think I know what is going on now: The key point is that all filesystems that are not part of the mountlist have the 'noauto' flag set. I assume that they are not mounted when mondoarchive/mindi runs. mindi's behaviour is actually as designed: Filesystems that have the 'noauto' option set in /etc/fstab and that are NOT mounted will not be included in the mountlist. So, the mountlist you are getting is actually correct in that it only contains the filesystems that don't have the 'noauto' option set and assuming that none of the filesystems that have the 'noauto' option set are mounted. (I have tested this on my end and it works as expected. It would be great if you could confirm that you have none of the 'noauto' filesystems mounted when mindi runs, though.) For the record, the code to explicitly check the above condition went into mindi in SVN revision 717: http://trac.mondorescue.org/changeset/717 I don't think that mindi's behaviour is a bug or could be improved really: mondoarchive (and with it mindi) is not mounting or unmounting any filesystems of the system it runs on. This is left to the administrator and, as I believe rightfully so - bad things can happen if filesystems are willy-nilly mounted and unmounted. So, in your situation, in order to get everything archived you want to, my recommendation would be to manually (or using a script) mount the filesystems in question prior to running mondoarchive. (Alternatively, in case you don't want to mount them, you might also be able to use '-x' but that would create rather inflexible dd images of those partitions.) Also, please note that the mountlist generated is only used for the restore process. /etc/fstab in a restored system will look exactly the same as before. I may have overlooked something, and if so would be keen to find out. Either way I'd much appreciate your feedback on the above. Best regards thanks a lot, Andree On Fri, 2006-11-24 at 07:50 -0600, hugo vanwoerkom wrote: On 11/23/06, Andree Leidenfrost [EMAIL PROTECTED] wrote: reassign 400024 mindi thanks Hello Hugo, Thank you for reporting this problem. It would be great if you could run the following command (as root): mindi --makemountlist /tmp/mount.lst and send me: - the screen output Script started on Fri 24 Nov 2006 07:27:15 AM CST executing /root/.bashrc /Fri Nov 24-07:27:15HDC3# mindi --makemountlist /tmp/mount.lst lilo.real found; will be used instead of lilo (*grumble* *mutter*) Your mountlist will look like this:- Hang on... DEVICE MOUNTPOINT FORMAT SIZE (MB) LABEL BLKGETSIZE ioctl failed on proc /dev/hdc3 / ext2 7632 /dev/hda9 swapswap953 /dev/sda7 /sda7 ext2 38154 /Fri Nov 24-07:27:21HDC3# exit exit Script done on Fri 24 Nov 2006 07:27:27 AM CST - /tmp/mount.lst /dev/hdc3 / ext2 7815622 /dev/hda9 swap swap 976712 /dev/sda7 /sda7 ext2 39070048 - /var/log/mindi mindi v2.2.0-r881 i686 architecture detected mindi called with the following arguments: --makemountlist /tmp/mount.lst Start date : Fri Nov 24 07:27:19 CST 2006 MINDI_LIB = /usr/lib/mindi MINDI_SBIN = /usr/sbin MINDI_CONF = /etc/mindi MONDO_SHARE = Found isolinux.bin at /usr/lib/syslinux/isolinux.bin lilo.real found; will be used instead of lilo (*grumble* *mutter*) Your raw fstab file looks like this:- # /etc/fstab: static file system information. # # file system mount point type options dump pass proc/proc procdefaults 0 0 /dev/hdc3 / ext2defaults,errors=remount-ro 0 1 /dev/hda9 noneswapsw 0 0 /dev/hdd /cdrom iso9660 ro,user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 # 80GB PATA Maxtor disk /dev/hda1 /hda1 ext2 defaults,user,noauto,errors=remount-ro0 1 /dev/hda5 /hda5 ext2 defaults,user,noauto,errors=remount-ro0 1 /dev/hda6 /hda6 ext2 defaults,user,noauto,errors=remount-ro0 1 /dev/hda7 /hda7 ext2 defaults,user,noauto,errors=remount-ro0 1 /dev/hda8 /mnt/win_F vfatuser,noauto,exec,umask=0 0 0 #/dev/hda10 /hda10 ext2auto,user,exec 0 0 /dev/hda10 /hda10 ext2 defaults,user,noauto,errors=remount-ro0 1 # 80GB PATA
Bug#379628: Problem persists with Vista Final
Hi Szaka, I can confirm that unfortunately the problem persists in the final version of Vista. :-( Regards, Andree PS: I was given the opportunity to test this but have not purchased a copy of Vista and don't intend to. I can possibly do some more testing but it would be easier (and quicker) if someone else stepped up that owns a copy him- or herself. This could of course also be a company. -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#400024: mondo 2.20: wrong mountlist
reassign 400024 mindi thanks Hello Hugo, Thank you for reporting this problem. It would be great if you could run the following command (as root): mindi --makemountlist /tmp/mount.lst and send me: - the screen output - /tmp/mount.lst - /var/log/mindi Also, unless I am mistaken you are not running a stock Debian kernel but a custom one. Is there any particular reason for this? Could you retest with a stock Debian? Finally, I'd just like to confirm that what you are saying is that if you downgrade to 2.0.8 and run it on your *current* system, it works ok but 2.0.9 and 2.2.0 don't. Best regards, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#398425: mondo: Crash during backup : *** glibc detected *** free(): invalid next size (fast): 0x080e1898 ***
tags 398425 + confirmed thanks Hi Olivier, Ok, I've now finished the etch i386 install and have tested. I can confirm the issue and attach a backtrace (so no need for you to do this - but thanks a lot for your willingness to help!). The backtrace indicated to me that this is the same as http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=379938. So I installed the libfribidi0 package, and indeed the issue went away. If you could therefore install the libfribidi0 package as well and let me know how that affects things, that would be really great. Thanks a lot best regards, Andree On Wed, 2006-11-15 at 11:22 +0100, Olivier LARRIGAUDIERE wrote: Hello Andree, First of all, thank you for your answer. The hardware I use it's a Dell PE SC440 Celeron D336 with two disks in mirroring. The RAID is done by a hardware card SAS 5iR. Effectively I use debian i386 etch. Could you please give me more detailed instructions on how to produce a backtrace ? Best Regards, -- Andree Leidenfrost @ Debian Developer Sydney - Australia mondoarchive_#398425.trc Description: Binary data signature.asc Description: This is a digitally signed message part
Bug#398425: mondo: Crash during backup : *** glibc detected *** free(): invalid next size (fast): 0x080e1898 ***
Salut Olivier, Thank you for your bug report. I have so far unsuccessfully tried to reproduce on amd64 etch and i386 sid. I am currently setting up an i386 etch to test on what I believe you are using. Is there anything unusual about your system you can think of from the top of your head? It would be very helpful if you could send me a backtrace of the crash. Easiest would be to build the package yourself and run the unstripped mondoarchive binary from with the package build directory in gdb (or attach gdb to the running process). (Please let me know if you need more detailed instructions - I'm a bit in a hurry right now.) Regards, Andree On Mon, 2006-11-13 at 20:23 +0100, Olivier LARRIGAUDIERE wrote: Package: mondo Version: 2.20-1 Severity: grave Justification: renders package unusable Hi, Mondo crash during backup of my system with the message during Generation boot+data disks with the message: *** glibc detected *** free(): invalid next size (fast): 0x080e1898 *** I try to backup to Hard disk with maximum compression all my data. Thanks for your help. Best Regards, -- Olivier LARRIGAUDIERE -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition ...)
Hi Szaka, On Sat, 2006-11-11 at 21:43 +0200, Szakacsits Szabolcs wrote: Hi, On Sat, 11 Nov 2006, Andree Leidenfrost wrote: I had another look and used F6-F8-Safe Mode with Command Prompt. In the attached screenshot you can see that it stops after it loaded crcdisk.sys. Google says other people experience the same. Thanks, I've checked some Google posts. There are quite many different scenarios when boot hangs at crcdisk.sys. This is how the drivers should be loaded usually around crcdisk.sys: Loaded driver \Windows\System32\Drivers\spldr.sys Loaded driver \Windows\System32\Drivers\Mup.sys Loaded driver \Windows\system32\drivers\disk.sys Loaded driver \Windows\system32\drivers\CLASSPNP.SYS Loaded driver \Windows\system32\drivers\crcdisk.sys Loaded driver \SystemRoot\system32\drivers\Wdf01000.sys Loaded driver \SystemRoot\system32\drivers\intelppm.sys Loaded driver \SystemRoot\system32\drivers\uagp35.sys One can notice the path change right after loading crcdisk.sys. What is SystemRoot? There isn't such directory on NTFS. Microsoft says Set the current directory to the systemroot folder of the Windows installation you are logged on to. There is also one important thing to know. The windows boot process is an old legacy. It's not a modern one, for example, what Linux has. In the early boot phrase a mini ntfs driver loads the real drivers and at some point the boot process starts to use them. Apparently this point is right after crcdisk.sys, so that's why so many people have problem there. Millions of things can go wrong during the driver switch and they indeed do go wrong but the fault will always point to crcdisk.sys. All posts I've seen was old, or if it wasn't then it used old Vista Beta. GParted was used with Vista RC1 in the below article. Same hang but chkdsk fixed the boot problem: http://opensource.apress.com/article/163/taking-a-look-at-vista-part-iii If one could send me the two ntfs images, before and after running chkdsk, The problem for me is how to run chkdsk after the resize. If you can tell me how I'll do it. then I could add the needed support, suppose the problem is indeed due NTFS changes. Instructions how to create the images are here: http://wiki.linux-ntfs.org/doku.php?id=ntfsclone#store_only_ntfs_metadata How about I do this before and after the resize? But the most important thing would be still to reproduce the problem with the latest Vista, so we could confirm that we indeed have a problem. Which means that we still haven't received any information how ntfsresize works with the latest Vista. Just in case anybody reading this would be interested: If anyone has a Vista installation that I could destroy in Sydney in order to confirm the issue on the final version, drop me a message! Btw, it would be also nice to test ntfsclone, if one is interested: 1) ntfsclone --overwrite vista.img vista_partition 2) zero the entire vista partition (not the disk!): dd if=/dev/zero of=vista_partition 3) ntfsclone --overwrite vista_partition vista.img 4) vista should boot fine Yep, tried that and it works fine. :-) Cheers, Szaka -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: [Linux-NTFS-Dev] CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)
Hi Szaka, Thanks a lot for your response! On Mon, 2006-11-06 at 01:57 +0300, Szakacsits Szabolcs wrote: Hi Andree, On Sun, 5 Nov 2006, Andree Leidenfrost wrote: I have made a Vista partition 1MB smaller as per your instructions. I can confirm that Vista does not boot anymore after this. Rather it hangs on the black screen with the 'golden' progress bar with 'C 2006 Microsoft Corporation. All rights reserved.' written underneath. Thank you for testing! Btw, it would be nice to know if this is valid only for boot or also for data partitions? Ok, I've reinstalled and created a 10GB E: drive in Vista after that. Surprisingly enough (at least to me), after reducing the size by 1MB following your original instructions, Vista does not boot anymore either. :-( So, it seems we should plan and implement denial of the resizing for Vista, asap. This is not so bad, because Vista started to include a non-destructive resizer. As a Debian developer, i.e. looking at things from a distribution angle, I am somewhat more concerned: Installing Linux on a PC should be as easy as possible. To this date, ntfsresize has done an excellent job in resizing an NTFS partition 'on the fly' as part of the Linux installation process. It would be really sad to not have this functionality anymore. Frans, how do you detect Vista? My idea is to check for the transactional directory. However this won't be enabled by default, so it may not exist at all. I have tested this with Vista Pre-RC1, Build 5536 using ntfsresize 1.3.1 I checked for the latest Vista beta, which is RC2 Build 5744 currently. So we still have hope that Microsoft has fixed this serious problem. I somewhat doubt that MS views this as a serious problem. I'd even suspect they might have changed something on purpose to make it harder for us to get this to work. (Then again I may be getting paranoid...) It also seems that only the members of the beta testing programme can submit bug reports. Szaka Best regards, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#379628: CALL FOR HELP: Vista beta compatibility testing (was: Re: Bug#379628: ntfsresize: resizing a Vista NTFS partition leads to corrupted partition)
Hi Szaka, I have made a Vista partition 1MB smaller as per your instructions. I can confirm that Vista does not boot anymore after this. Rather it hangs on the black screen with the 'golden' progress bar with 'C 2006 Microsoft Corporation. All rights reserved.' written underneath. I have tested this with Vista Pre-RC1, Build 5536 using ntfsresize 1.3.1 as it comes with GParted LiveCD 0.3.1. Best regards, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#391127: mondo: Segmentation fault after selecting CDRW size
tags 391127 + confirmed, patch, pending thanks Hi Tim, Thanks a lot for your bug report! I have reproduced the issue. The problem is that a text string is too long and the code doesn't handle this properly. I have addressed this by replacing strcpy() with strncpy() and by shortening the offending string accordingly. The attached fix will be in the next package version. Best regards, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia mondo_2.09-3_#391127.diff Description: Binary data signature.asc Description: This is a digitally signed message part
Bug#389931: Hardware info of submitter
I am using the following hardware: Board: ASUS A8V Deluxe BIOS: Revision 1017 CPU: Athlon64 X2 4800+ Please note that the my board has the same chipset as Johan's, namely: VIA K8T800Pro + VT8237 So, this might be where the issue lies. Cheers, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#389729: openafs-modules-source: Fails to build for 2.6.18 kernel on amd64
Package: openafs-modules-source Version: 1.4.2~fc2-1 Severity: grave Justification: renders package unusable Dear Sam, I am trying to build the afs modules using the instructions in README.modules in regards to the module-assistant. Whilst this works without a problem for 2.6.17 kernels, I get the following errors that make the build fail: [...] /usr/src/modules/openafs/src/afs/afs_prototypes.h:1033: warning: function declaration isn’t a prototype /usr/src/modules/openafs/src/afs/afs_prototypes.h:1034: warning: function declaration isn’t a prototype /usr/src/modules/openafs/src/afs/afs_prototypes.h:1035: warning: function declaration isn’t a prototype /usr/src/modules/openafs/src/afs/afs_prototypes.h:1036: warning: function declaration isn’t a prototype /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:604: error: ‘__NR_ia32_close’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:604: error: ‘__NR_ia32_chdir’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: ‘__NR_ia32_break’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: (near initialization for ‘ia32_zapped_syscalls[0]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: ‘__NR_ia32_stty’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: (near initialization for ‘ia32_zapped_syscalls[1]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: ‘__NR_ia32_gtty’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: (near initialization for ‘ia32_zapped_syscalls[2]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: ‘__NR_ia32_ftime’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:612: error: (near initialization for ‘ia32_zapped_syscalls[3]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: ‘__NR_ia32_prof’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: (near initialization for ‘ia32_zapped_syscalls[4]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: ‘__NR_ia32_lock’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: (near initialization for ‘ia32_zapped_syscalls[5]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: ‘__NR_ia32_mpx’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:613: error: (near initialization for ‘ia32_zapped_syscalls[6]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:619: error: ‘__NR_ia32_mount’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:619: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:619: error: (near initialization for ‘ia32_unique_syscalls[1]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:620: error: ‘__NR_ia32_open’ undeclared here (not in a function) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:620: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:620: error: (near initialization for ‘ia32_unique_syscalls[4]’) /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:620: error: initializer element is not constant /usr/src/modules/openafs/src/libafs/MODLOAD-2.6.18-1-amd64-MP/osi_probe.c:620: error: (near initialization for ‘ia32_unique_syscalls[5]’)
Bug#380703: mondo: Mondo/Mindi detects my serial ATA hard disk as an IDE.
Hi Robert, Thank you for reporting this bug. On Mon, 2006-07-31 at 18:02 -0700, Robert Jeffrey Miesen wrote: Package: mondo Version: 2.08-2-3 Severity: critical Justification: breaks the whole system I am afraid that this is not a critical bug. Rather it is an important bug as it makes mondo completely unusable for some people, i.e. you in this case, but it certainly doesn't effect your _running_ system at all. (I have just completed a full archive and restore run using a PATA-only setup with no problem to confirm that their is no general problem.) Upon booting from a DVD image of my entire system, mondo/mindi detects my SATA (Serial ATA) hard disk as an IDE drive. (I do not currently have a SATA disk unfortunately, so I can't try this myself at the moment.) Am I getting this right that you are saying that your SATA disk which is sda in your system appears as hda when restoring to that very same system? Could you describe how you perform the restore? This would include any changes that you make to the hardware like replacing or turning-off disks and such. Also, could you take a photo of the monitor to illustrate the problem. Further to that, could you boot into expert mode by entering 'expert' at the rescue media boot prompt and hitting enter. Once the system has booted could you do: fdisk -l /dev/hda and fdisk -l /dev/sda and send post the output. Could you do the same in your normal system? If you have sda as your disk, then hda would quite likely be your optical drive (maybe in your case your DVD writer). Maybe what really happens is that the SATA disk is not recognised at all and hda is the optical drive. Again, it would be helpful to understand better how you are restoring. As an example you wouldn't just overwrite your SATA disk I presume. So, do you change disks or do you turn them off? (It's that sort of things that I really need to understand better.) Could you also send me the output of lsmod when in your normal system and when booted into the restore system in expert mode as described above. This makes my backup virtually worthless in the event of a catastrophic failure of my system (whether from me messing it up or my hard disk failing). That is why I called this bug a critical bug, because it does break the whole system when you can't restore your system. Please see the top of my response. I can understand that you consider this serious and for you it likely is. For Debian as a whole, however, it is not. Note that this does not influence my commitment to fixing the problem - I do definitely find this important. If there is anything else that you can think of that could be related, please mention it! The more information we have the more likely we can fix this. Best regards, Andree -- Andree Leidenfrost @ Debian Developer Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#366634: mindi: Filesystem to use for initrd is UNSUPPORTED
Hi Tim, Thank you for getting back to me. I'm glad that things work for you now. I will close the bug accordingly. Best regards, Andree On Tue, 2006-05-16 at 01:37 -0400, Tim Caulder wrote: Yes this is a custom kernel. I seem to have had some issues with part of a previous kernel still on my system. I have fixed it and can now create the boot+data disks. I no longer get the error reported. From: Andree Leidenfrost [EMAIL PROTECTED] To: Tim Caulder [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: Bug#366634: mindi: Filesystem to use for initrd is UNSUPPORTED Date: Sun, 14 May 2006 22:03:03 +1000 MIME-Version: 1.0 Received: from omta03sl.mx.bigpond.com ([144.140.92.155]) by bay0-mc4-f4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 May 2006 05:03:10 -0700 Received: from emden2.ostfriesland ([60.225.20.168]) by omta03sl.mx.bigpond.com with ESMTP id [EMAIL PROTECTED]; Sun, 14 May 2006 12:03:08 + Received: from aurich.ostfriesland (aurich.ostfriesland [192.168.1.101])by emden2.ostfriesland (Postfix) with ESMTP id 49EC53EED;Sun, 14 May 2006 22:03:04 +1000 (EST) X-Message-Info: LsUYwwHHNt3EetPZtykPjOdkZ+lqfSw5tcEAMFhU8t4= References: [EMAIL PROTECTED] X-Mailer: Evolution 2.0.4 Return-Path: [EMAIL PROTECTED] X-OriginalArrivalTime: 14 May 2006 12:03:10.0798 (UTC) FILETIME=[5EC856E0:01C6774E] Hi Tim, Thank you for your bug report. Please send me your logs: /var/log/mondo-archive.log /var/log/mindi.log From what I can see so far, my first suspicion is that you don't use a standard Debian kernel but a self-compiled one. Is this true? If so, please read the first section of the mindi package's README.Debian that explains the situation and also the documentation that comes with mondo-doc. You are lacking support for a filesystem required for the initrd image. If not, you may have found a bug in the mindi package, more specifically in /usr/lib/mindi/TryToBeCleverAboutInitrd. Please let me know how you go either way. Regards, Andree On Tue, 2006-05-09 at 19:31 -0400, Tim Caulder wrote: Package: mindi Version: 1.07-2 Severity: grave Justification: renders package unusable mondo fails after calling MINDI to create boot+data disks. Alert Fatal error. Filesystem UNSUPPORTED not supported for initrd image. Terminating. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mindi depends on: ii binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina ii bzip21.0.3-2 high-quality block-sorting file co ii dosfstools 2.11-2.1Utilities to create and check MS-D ii file 4.17-1 Determines file type using magic ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii mindi-busybox1.00-6 Collection of shell utilities in a ii mkisofs 4:2.01+01a03-5 Creates ISO-9660 CD-ROM filesystem ii module-init-tools3.2.2-2 tools for managing Linux kernel mo ii ms-sys 2.1.0-1 Write a Microsoft compatible boot pi nano 1.3.11-2free Pico clone with some new feat ii parted 1.6.25.1-2 The GNU Parted disk partition resi ii syslinux 3.11-3 Bootloader for Linux/i386 using MS Versions of packages mindi recommends: ii cpio 2.6-11 GNU cpio -- a program to manage ar pn linux-image-2.6-amd64-generic none (no description available) pn mdadm none (no description available) ii ntfsprogs 1.12.1-1 tools for doing neat things in NTF -- no debconf information signature.asc signature.asc Description: This is a digitally signed message part
Bug#366634: mindi: Filesystem to use for initrd is UNSUPPORTED
Hi Tim, Thank you for your bug report. Please send me your logs: /var/log/mondo-archive.log /var/log/mindi.log From what I can see so far, my first suspicion is that you don't use a standard Debian kernel but a self-compiled one. Is this true? If so, please read the first section of the mindi package's README.Debian that explains the situation and also the documentation that comes with mondo-doc. You are lacking support for a filesystem required for the initrd image. If not, you may have found a bug in the mindi package, more specifically in /usr/lib/mindi/TryToBeCleverAboutInitrd. Please let me know how you go either way. Regards, Andree On Tue, 2006-05-09 at 19:31 -0400, Tim Caulder wrote: Package: mindi Version: 1.07-2 Severity: grave Justification: renders package unusable mondo fails after calling MINDI to create boot+data disks. Alert Fatal error. Filesystem UNSUPPORTED not supported for initrd image. Terminating. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages mindi depends on: ii binutils 2.16.1cvs20060413-1 The GNU assembler, linker and bina ii bzip21.0.3-2 high-quality block-sorting file co ii dosfstools 2.11-2.1Utilities to create and check MS-D ii file 4.17-1 Determines file type using magic ii gawk 1:3.1.5.dfsg-4 GNU awk, a pattern scanning and pr ii mindi-busybox1.00-6 Collection of shell utilities in a ii mkisofs 4:2.01+01a03-5 Creates ISO-9660 CD-ROM filesystem ii module-init-tools3.2.2-2 tools for managing Linux kernel mo ii ms-sys 2.1.0-1 Write a Microsoft compatible boot pi nano 1.3.11-2free Pico clone with some new feat ii parted 1.6.25.1-2 The GNU Parted disk partition resi ii syslinux 3.11-3 Bootloader for Linux/i386 using MS Versions of packages mindi recommends: ii cpio 2.6-11 GNU cpio -- a program to manage ar pn linux-image-2.6-amd64-generic none (no description available) pn mdadm none (no description available) ii ntfsprogs 1.12.1-1 tools for doing neat things in NTF -- no debconf information signature.asc Description: This is a digitally signed message part
Bug#362125: gksu fails because it looks for xauth in wrong location
Package: gksu Version: 1.3.7-1 Severity: grave Justification: renders package unusable Hi Gustavo, As of today, I can't use the synaptic menu entry in Gnome anymore. Running the command in a ternimal gives: [EMAIL PROTECTED]:~$ gksu -u root /usr/sbin/synaptic sh: /usr/X11R6/bin/xauth: No such file or directory sh: /usr/X11R6/bin/xauth: No such file or directory Xlib: connection to :0.0 refused by server Xlib: No protocol specified (synaptic:7345): Gtk-WARNING **: cannot open display: xauth is actually in /usr/bin/xauth now: [EMAIL PROTECTED]:~$ dpkg -S xauth xutils: /usr/bin/xauth_switch_to_sun-des-1 libpam-modules: /lib/security/pam_xauth.so xbase-clients: /usr/share/man/man1/xauth.1x.gz xbase-clients: /usr/bin/xauth Creating the following link is a workaround for the problem: ln -s /usr/bin/xauth /usr/X11R6/bin/xauth The location of xauth may have changed in xbase-clients 1:7.0.0-1. Maybe a fix would be to add /usr/bin/xauth to the places that gksu looks for xauth or to just rely on the path to contain xauth in the first place. Please let me know in case more information is required. Please note that #349652 may be related to this. Best regards, Andree -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-k7-smp Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages gksu depends on: ii gconf2 2.14.0-1 GNOME configuration database syste ii libatk1.0-0 1.11.4-1 The ATK accessibility toolkit ii libc6 2.3.6-6 GNU C Library: Shared libraries ii libcairo2 1.0.4-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-5.1generic font configuration library ii libfreetype62.1.10-3 FreeType 2 font engine, shared lib ii libgconf2-4 2.14.0-1 GNOME configuration database syste ii libgksu1.2-01.3.7-1 library providing su and sudo func ii libgksuui1.0-1 1.0.7-1 a graphical fronted to su library ii libglib2.0-02.10.2-1 The GLib library of C routines ii libgnome-keyring0 0.4.9-1 GNOME keyring services library ii libgtk2.0-0 2.8.16-1 The GTK+ graphical user interface ii liborbit2 1:2.14.0-1 libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.0-2 Layout and rendering of internatio ii libpng12-0 1.2.8rel-5.1 PNG library - runtime ii libpopt01.7-5lib for parsing cmdline parameters ii libx11-62:1.0.0-5X11 client-side library ii libxcursor1 1.1.5.2-2X cursor management library ii libxext61:1.0.0-3X11 miscellaneous extension librar ii libxi6 1:1.0.0-3X11 Input extension library ii libxinerama11:1.0.1-2X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-3 X11 RandR extension library ii libxrender1 1:0.9.0.2-2 X Rendering Extension client libra ii sudo1.6.8p12-3 Provide limited super user privile ii zlib1g 1:1.2.3-11 compression library - runtime gksu recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357785: mondoarchive exits with fatal error :Can't loopmount /tmp/mindilinux/8087/mountpoint8087
Salut Claude! Thank you for reporting this issue. In /var/log/mondo-archive.log (towards the end) I see: Creating data disk #1...mount: unknown filesystem type 'ext2' Fatal error. Can't loopmount //tmp.mondo.8159/tmp.mondo.26756/mindilinux/6170/mountpoint.6170; does your kernel support loopfs? If not, please recompile your kernel. Your Linux distro is broken. This indicates that the mounting of the image file fails because ext2 is not available in the running kernel (not because of missing loopfs support). mindi requires ext2 in the running kernel. I attach a patch that hopefully makes the error message unambiguous. [Bruno: Do you you agree with this and are you happy for me to commit to SVN (both trunk and stable)? Oh, and thanks for looking into this in the first place!] I will reassign the bug to mindi because this is where the issue occurs. I will downgrade the bug to severity 'normal' because this issue will not occur with standard Debian kernels but is caused by the self-compiled kernel you are using. Best regards, Andree -- Andree Leidenfrost Sydney - Australia mindi-#357785.diff Description: Binary data signature.asc Description: This is a digitally signed message part
Bug#354145: mindi: Cdrom not detected after cdrom boot
G'day Yann, Excellent! Thanks a lot for your feedback! I'll put this in 1.06-4 then. Cheers, Andree On Mon, 2006-02-27 at 18:47 +0100, Yann Aubert wrote: Salut Andree, Your patch is working ok! I've tested a complete restore without problem. Cheers Yann Le dimanche 26 février 2006 à 12:25 +1100, Andree Leidenfrost a écrit : Salut Yann, Thanks a lot for reporting this issue and for mentioning the workaround you found! I can confirm the problem and it's all my fault: When I made the change in 1.06-2 to get DMA to work on VIA chipsets, I relied on the ide-generic module to get loaded later, which is wrong as the CD can't be accessed because of the missing ide driver - catch 22. Silly me! mindi unfortunately uses a brute force approach to load modules and to satisfy inter-module dependencies. It does not allow for loading modules in a particular order. This, however, is exactly what is required to get DMA working on VIA chipsets: module via82cxxx needs to get loaded before ide-generic does. The attached patch init_#354145.diff makes it so that ide-core and via82cxxx get loaded before the rest of the essential modules. It works for me and I believe it should not impact things on non-VIA chipset systems. (mindi_#354145.diff simply puts ide-generic back into IDE_MODS.) It would be great if you could apply the two patches, try again and let me know the outcome. This would confirm that it does work on non-VIA systems as well - something I can't test myself. (The mindi patch may not be required as you've already added ide-generic back in.) Thanks a lot best regards, Andree On Thu, 2006-02-23 at 19:00 +0100, Yann Aubert wrote: Package: mindi Version: 1.06-3 Severity: grave Justification: renders package unusable When booting from a cdrom burned with mondorescue.iso, the kernel and initrd are loaded without problems. But after that, when looking after the other files on the cdrom, the system ask for the floppies. I don't have a patch but can give a hint. For my setup, I had to put ide-generic back in mindi (IDE_MODS) in order to make the cdrom works correctly. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.14-2-686-smp Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages mindi depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii bzip2 1.0.2-7high-quality block-sorting file co ii dosfstools2.11-2 Utilities to create and check MS-D ii file 4.12-1 Determines file type using magic ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii mindi-busybox 1.00-6 Collection of shell utilities in a ii mkisofs 4:2.01+01a01-2 Creates ISO-9660 CD-ROM filesystem ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo ii ms-sys1.1.3-1Write a Microsoft compatible boot ii nano 1.2.4-5free Pico clone with some new feat ii parted1.6.21-1 The GNU Parted disk partition resi ii syslinux 2.11-0.1 Bootloader for Linux/i386 using MS -- no debconf information -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#354145: mindi: Cdrom not detected after cdrom boot
Salut Yann, Thanks a lot for reporting this issue and for mentioning the workaround you found! I can confirm the problem and it's all my fault: When I made the change in 1.06-2 to get DMA to work on VIA chipsets, I relied on the ide-generic module to get loaded later, which is wrong as the CD can't be accessed because of the missing ide driver - catch 22. Silly me! mindi unfortunately uses a brute force approach to load modules and to satisfy inter-module dependencies. It does not allow for loading modules in a particular order. This, however, is exactly what is required to get DMA working on VIA chipsets: module via82cxxx needs to get loaded before ide-generic does. The attached patch init_#354145.diff makes it so that ide-core and via82cxxx get loaded before the rest of the essential modules. It works for me and I believe it should not impact things on non-VIA chipset systems. (mindi_#354145.diff simply puts ide-generic back into IDE_MODS.) It would be great if you could apply the two patches, try again and let me know the outcome. This would confirm that it does work on non-VIA systems as well - something I can't test myself. (The mindi patch may not be required as you've already added ide-generic back in.) Thanks a lot best regards, Andree On Thu, 2006-02-23 at 19:00 +0100, Yann Aubert wrote: Package: mindi Version: 1.06-3 Severity: grave Justification: renders package unusable When booting from a cdrom burned with mondorescue.iso, the kernel and initrd are loaded without problems. But after that, when looking after the other files on the cdrom, the system ask for the floppies. I don't have a patch but can give a hint. For my setup, I had to put ide-generic back in mindi (IDE_MODS) in order to make the cdrom works correctly. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.14-2-686-smp Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) Versions of packages mindi depends on: ii binutils 2.15-6 The GNU assembler, linker and bina ii bzip2 1.0.2-7high-quality block-sorting file co ii dosfstools2.11-2 Utilities to create and check MS-D ii file 4.12-1 Determines file type using magic ii gawk 1:3.1.4-2 GNU awk, a pattern scanning and pr ii mindi-busybox 1.00-6 Collection of shell utilities in a ii mkisofs 4:2.01+01a01-2 Creates ISO-9660 CD-ROM filesystem ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo ii ms-sys1.1.3-1Write a Microsoft compatible boot ii nano 1.2.4-5free Pico clone with some new feat ii parted1.6.21-1 The GNU Parted disk partition resi ii syslinux 2.11-0.1 Bootloader for Linux/i386 using MS -- no debconf information -- Andree Leidenfrost Sydney - Australia init_#354145.diff Description: Binary data mindi_#354145.diff Description: Binary data signature.asc Description: This is a digitally signed message part
Bug#354145: Bug#268308: dvd+rw-tools: growisofs prejudiced against sudo
Hi Daniel, I just stumbled across this bug whilst looking into an issue with the mondo package that I maintain and writing DVDs under sudo which does not work because of the situation described in this bug. I believe that rather than applying a patch as suggested by LaMont, all that would be required is to specify -DI_KNOW_ALL_ABOUT_SUDO when compiling. This has been in since version 5.20 according to the changelog in growisofs.c. Other than that, it is really a matter of policy, I guess. And it appears that upstream by providing the above define implicitly acknowledges that three may be an issue. Best regards, Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#352323: mondo: ---FATALERROR--- Pre-param initialization phase failed. Please review the error messages above, make the specified changes, then try again. Exiting...
] libmondo-files.c-register_pid#800: Unregistering PID [Main] libmondo-files.c-register_pid#802: Error unregistering PID running: umount /mnt/cdrom /tmp/mondo-run-prog-thing.tmp 2 /tmp/mondo-run-prog-thing.err start of output- umount: /mnt/cdrom: not mounted end of output-- ...ran with res=256 running: rm -Rf /mondo.scratch.* /tmp.mondo.* /tmp/mondo-run-prog-thing.tmp 2 /tmp/mondo-run-prog-thing.err start of output- end of output-- ...ran just fine. :-) running: rm -Rf/tmp/mondo-run-prog-thing.tmp 2 /tmp/mondo-run-prog-thing.err start of output- end of output-- ...ran just fine. :-) [Main] libmondo-tools.c-do_libmondo_global_strings_thing#1580: libmondo-tools.c, do_libmondo_global_strings_thing, 1580: Freeing globals = = Fileystem information: Sys. de fich.1K-blocs Occupé Disponible Capacité Monté sur /dev/hdb3 19228308 1527184 16724372 9% / tmpfs 517440 0517440 0% /dev/shm /dev/hdb1 135468 1705091 14% /boot /dev/hdb5 28834716 14537780 12832212 54% /home /dev/hdb6 11535344 32960 10916416 1% /tmp /dev/hdb7 3842376238696 3408492 7% /opt /dev/hdb8 5763616 3109404 2361432 57% /usr /dev/hdb9 6728280 1893692 4492808 30% /var tmpfs10240 224 10016 3% /dev /dev/hda8 5632464 2221268 3411196 40% /mnt/sda8 /dev/hda9 5627920 1477504 4150416 27% /mnt/sda9 -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (750, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-ck3 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages mondo depends on: ii afio 2.5-3 archive file manipulation program ii binutils 2.16.1cvs20060117-1 The GNU assembler, linker and bina ii buffer 1.19-7 Buffering/reblocking program for t ii cdrecord 4:2.01+01a03-5 command line CD writing tool ii dosfstools 2.11-2.1Utilities to create and check MS-D ii gawk 1:3.1.5-1 GNU awk, a pattern scanning and pr ii libc62.3.5-13GNU C Library: Shared libraries an ii libnewt0.51 0.51.6-31 Not Erik's Windowing Toolkit - tex ii lzop 1.01-4 fast compression program ii mindi1.06-2 creates boot/root disks based on y Versions of packages mondo recommends: ii dvd+rw-tools 6.1-1 DVD+-RW/R tools Versions of packages mindi depends on: ii bzip2 1.0.3-2high-quality block-sorting file co ii file 4.15-2 Determines file type using magic ii gawk 1:3.1.5-1 GNU awk, a pattern scanning and pr ii mindi-busybox 1.00-6 Collection of shell utilities in a ii mkisofs 4:2.01+01a03-5 Creates ISO-9660 CD-ROM filesystem ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii ms-sys2.1.0-1Write a Microsoft compatible boot ii nano 1.3.10-2 free Pico clone with some new feat ii parted1.6.25.1-2 The GNU Parted disk partition resi ii syslinux 3.11-3 Bootloader for Linux/i386 using MS -- no debconf information -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#352323: mondo: ---FATALERROR--- Pre-param initialization phase failed. Please review the error messages above, make the specified changes, then try again. Exiting...
Hi again, On Sat, 2006-02-11 at 12:07 +0100, mahashakti89 wrote: On Sat, Feb 11, 2006 at 09:21:40PM +1100, Andree Leidenfrost wrote : Hi, Thanks a lot for reporting this bug. Could you run /usr/lib/mindi/DebFindFailsafe directly and let me know what the outcome is, i.e. mail the output? Perhaps we have the solution , output of /usr/lib/mindi/DebFindFailsafe gives following output : /usr/lib/mindi/DebFindFailsafe FATAL ERROR: Failed to get real kernel package for virtual kernel package candiate(s) linux-image-2.6-486 kernel-image-2.6-386 linux-image-386. Terminating. I am remembering, aptitude mentioned, one of the packages listed in the error message were recommanded, but would not be installed. Should I try with one of these packages installed ? Yes, please. As you appear to be running a (self-compiled) 2.6.15 kernel and are on sid, could you install linux-image-2.6-486 and try again? We recommend one of these kernel packages to not enforce the installation for people who don't need it and a space-conscious. But in general, a recommends should be followed, really. Whether a 2.6 or a 2.4 kernel should be used, depends on what the machine in question is running. We could of course recommend a 2.4 _and_ a 2.6 kernel but I sincerely hope, that 2.4 will be removed from sid/etch soon anyway. (I think I may have to redirect the output of DebFindFailsafe to /var/log/mindi.log so that this is visible in the standard log.) Regards, Andree In the system information it says: Shell: /bin/sh linked to /bin/bash So, you do have bash installed, don't you? What happens when you run /bin/bash? (I'm sure it's fine, just double-checking.) No particular message. Seems to be O.K (REMINDER TO MYSELF: check bash dependencies and necessity!) Maybe it has to do with your locale. Could you set: export LANG= export LC_CTYPE= and check whether that makes a difference? No changes , I am running in the same error. Thanks mahashakti89 Regards, Andree On Sat, 2006-02-11 at 10:33 +0100, mahashakti89 wrote: Package: mondo Version: 2.06-2 Severity: grave Justification: renders package unusable Sorry to report this bug, I hoped it would work so fine as with version 2.05, but I cannot make a right start, it stops me after 30 seconds ! Also hope you have all informations you need. Thanks mahashakti89 -- Package-specific info: Contents of /var/log/mindi.log: mindi v1.06-r266 i686 architecture detected mindi called with the following arguments: --makemountlist /tmp/mountlist.txt.test MINDI_LIB = /usr/lib/mindi MINDI_SBIN = /usr/sbin MINDI_CONF = /etc/mindi MONDO_LIB = /usr/lib/mondo MINDI_VERSION is 1.06-r266 Fatal error. DebFindFailsafe failed. Please e-mail a copy of /tmp/mindi.err.30168.tgz to the mailing list. See http://www.mondorescue.org for more information. WE CANNOT HELP unless you enclose that file. = Contents of /var/log/mondo-archive.log: running: dmesg -n1 /tmp/mondo-run-prog-thing.tmp 2 /tmp/mondo-run-prog-thing.err start of output- end of output-- ...ran just fine. :-) Mondo Archive v2.06-266 --- http://www.mondorescue.org running on i386 architecture --- NB: Mondo logs almost everything, so don't panic if you see some error messages. Please read them carefully before you decide to break out in a cold sweat.Despite (or perhaps because of) the wealth of messages. some users are inclined to stop reading this log. If Mondo stopped for some reason, chances are it's detailed here. More than likely there's a message at the very end of this log that will tell you what is wrong. Please read it! -Devteam --- Zero... [Main] main.c-welcome_to_mondoarchive#179: One... [Main] main.c-welcome_to_mondoarchive#180: Two... [Main] main.c-welcome_to_mondoarchive#181: Three... [Main] main.c-welcome_to_mondoarchive#182: Four... [Main] main.c-distro_specific_kludges_at_start_of_mondoarchive#199: Unmounting old ramdisks if necessary running: umount `mount | grep shm | grep mondo | cut -d' ' -f3` /tmp/mondo-run-prog-thing.tmp 2 /tmp/mondo-run-prog-thing.err start of output- Usage: umount [-hV] umount -a [-f] [-r] [-n] [-v] [-t vfstypes] [-O opts] umount [-f] [-r] [-n] [-v] special | node... end of output-- ...ran with res=512 running: mount | grep cdrom
Bug#352323: mondo: ---FATALERROR--- Pre-param initialization phase failed. Please review the error messages above, make the specified changes, then try again. Exiting...
Hi, On Sat, 2006-02-11 at 15:08 +0100, mahashakti89 wrote: Hi, Andree! I installed linux-image-2.6-486 and its dependance linux-image-2.6..15-1 and it works, I mean I am not encountering the error which made me post this reportbug. But I have no time now to test it thoroughly and to make a full system backup, as I am leaving for two weeks. We will see in time. I'm glad it works for you now. Thanks for your help You are welcome. I interpret this as the bug can be closed now. (Pending the error messages not appearing in mindi.log that is.) mahashakti89 PS = Will this dependance on linux-image-2.6-486 now stay ? Yes, and it will automatically make it so that always the latest 2.6 486 kernel is available as failsafe. On Sat, Feb 11, 2006 at 10:59:08PM +1100, Andree Leidenfrost wrote : Hi again, On Sat, 2006-02-11 at 12:07 +0100, mahashakti89 wrote: On Sat, Feb 11, 2006 at 09:21:40PM +1100, Andree Leidenfrost wrote : Hi, Thanks a lot for reporting this bug. Could you run /usr/lib/mindi/DebFindFailsafe directly and let me know what the outcome is, i.e. mail the output? Perhaps we have the solution , output of /usr/lib/mindi/DebFindFailsafe gives following output : /usr/lib/mindi/DebFindFailsafe FATAL ERROR: Failed to get real kernel package for virtual kernel package candiate(s) linux-image-2.6-486 kernel-image-2.6-386 linux-image-386. Terminating. I am remembering, aptitude mentioned, one of the packages listed in the error message were recommanded, but would not be installed. Should I try with one of these packages installed ? Yes, please. As you appear to be running a (self-compiled) 2.6.15 kernel and are on sid, could you install linux-image-2.6-486 and try again? We recommend one of these kernel packages to not enforce the installation for people who don't need it and a space-conscious. But in general, a recommends should be followed, really. Whether a 2.6 or a 2.4 kernel should be used, depends on what the machine in question is running. We could of course recommend a 2.4 _and_ a 2.6 kernel but I sincerely hope, that 2.4 will be removed from sid/etch soon anyway. (I think I may have to redirect the output of DebFindFailsafe to /var/log/mindi.log so that this is visible in the standard log.) Regards, Andree In the system information it says: Shell: /bin/sh linked to /bin/bash So, you do have bash installed, don't you? What happens when you run /bin/bash? (I'm sure it's fine, just double-checking.) No particular message. Seems to be O.K (REMINDER TO MYSELF: check bash dependencies and necessity!) Maybe it has to do with your locale. Could you set: export LANG= export LC_CTYPE= and check whether that makes a difference? No changes , I am running in the same error. Thanks mahashakti89 Regards, Andree On Sat, 2006-02-11 at 10:33 +0100, mahashakti89 wrote: Package: mondo Version: 2.06-2 Severity: grave Justification: renders package unusable Sorry to report this bug, I hoped it would work so fine as with version 2.05, but I cannot make a right start, it stops me after 30 seconds ! Also hope you have all informations you need. Thanks mahashakti89 -- Package-specific info: Contents of /var/log/mindi.log: mindi v1.06-r266 i686 architecture detected mindi called with the following arguments: --makemountlist /tmp/mountlist.txt.test MINDI_LIB = /usr/lib/mindi MINDI_SBIN = /usr/sbin MINDI_CONF = /etc/mindi MONDO_LIB = /usr/lib/mondo MINDI_VERSION is 1.06-r266 Fatal error. DebFindFailsafe failed. Please e-mail a copy of /tmp/mindi.err.30168.tgz to the mailing list. See http://www.mondorescue.org for more information. WE CANNOT HELP unless you enclose that file. = Contents of /var/log/mondo-archive.log: running: dmesg -n1 /tmp/mondo-run-prog-thing.tmp 2 /tmp/mondo-run-prog-thing.err start of output- end of output-- ...ran just fine. :-) Mondo Archive v2.06-266 --- http://www.mondorescue.org running on i386 architecture --- NB: Mondo logs almost everything, so don't panic if you see some error messages. Please read them carefully before you decide to break out in a cold sweat.Despite (or perhaps because of) the wealth of messages. some users are inclined to stop reading this log. If Mondo stopped for some reason, chances are it's detailed here
Bug#349675: gparted: Missing dependency on package libparted1.6-13 on AMD64
Package: gparted Version: 0.0.9-1 Severity: serious Justification: Policy 3.5 Hi David, gparted fails to start with the following error: gparted-bin: error while loading shared libraries: libparted-1.6.so.13: cannot open shared object file: No such file or directory Installing package libparted1.6-13 fixes the problem. However, things may not be as simple as they seem: When building the gparted package, I get: dh_shlibdeps dpkg-shlibdeps -Tdebian/gparted.substvars debian/gparted/usr/bin/gparted-bin dpkg-shlibdeps: warning: could not find any packages for /usr/lib/libparted-1.6.so.13 (libparted-1.6.so.13) dpkg-shlibdeps: warning: unable to find dependency information for shared library libparted-1.6 (soname 13, path /usr/lib/libparted-1.6.so.13, dependency field Depends) After installing package libparted1.6-13, I get for 'dpkg -L libparted1.6-13': /. /lib /lib/libparted-1.6.so.13.11.1 /usr /usr/share /usr/share/doc /usr/share/doc/libparted1.6-13 /usr/share/doc/libparted1.6-13/copyright /usr/share/doc/libparted1.6-13/changelog.Debian.gz /usr/share/doc/libparted1.6-13/changelog.gz /lib/libparted-1.6.so.13 So, it looks like dh_shlibdeps lloks for the the libparted library in /usr/lib but the package has it in /lib. The latter might be wrong, not sure. Feel free to reassign to package libparted1.6-13 or dpkg-dev as you see fit - I'm only reporting against gparted because this where I entcountered to problem. Also, please let me know if you need more information. I understand that amd64 is now an official architecture. Regards Andree -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-amd64-k8 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Versions of packages gparted depends on: ii gksu 1.3.6-1graphical frontend to su ii libatk1.0-0 1.10.3-1 The ATK accessibility toolkit ii libc6 2.3.5-12 GNU C Library: Shared libraries an ii libcairo2 1.0.2-3The Cairo 2D vector graphics libra ii libfontconfig 2.3.2-1.1 generic font configuration library ii libfreetype6 2.1.10-1 FreeType 2 font engine, shared lib ii libgcc1 1:4.0.2-7 GCC support library ii libglib2.0-0 2.8.6-1The GLib library of C routines ii libglibmm-2.4 2.8.2-2C++ wrapper for the GLib toolkit ( ii libgtk2.0-0 2.8.10-1 The GTK+ graphical user interface ii libgtkmm-2.4- 1:2.6.5-1 C++ wrappers for GTK+ 2.4 (shared ii libpango1.0-0 1.10.2-1 Layout and rendering of internatio ii libpng12-01.2.8rel-5 PNG library - runtime ii libsigc++-2.0 2.0.16-2 type-safe Signal Framework for C++ ii libstdc++64.0.2-7The GNU Standard C++ Library v3 ii libuuid1 1.38+1.39-WIP-2005.12.31-1 universally unique id library ii libx11-6 6.9.0.dfsg.1-4 X Window System protocol client li ii libxcursor1 1.1.3-1X cursor management library ii libxext6 6.9.0.dfsg.1-4 X Window System miscellaneous exte ii libxi66.9.0.dfsg.1-4 X Window System Input extension li ii libxinerama1 6.9.0.dfsg.1-4 X Window System multi-head display ii libxrandr26.9.0.dfsg.1-4 X Window System Resize, Rotate and ii libxrender1 1:0.9.0.2-1X Rendering Extension client libra ii menu 2.1.27 generates programs menu for all me ii zlib1g1:1.2.3-9 compression library - runtime gparted recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336277: FTBFS: Missing build-dependency on gcc-3.3
Hi Matt, Thanks for reporting this issue and sorry for not having fixed it yet. What's holding it up is that I can't build a fixed package because of bug #328707. Once this is fixed, you can expect an upload shortly after. Best regards Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#324302: Just one sed command...
Hi Thierry On Wed, 2005-10-12 at 01:54 +0200, thierry lathuille wrote: [...] With this latest patch, we keep only the first part of ldd's output, so the libs in /tls don't get included. So it is OK for FAILSAFE and other 2.4 kernels. I tried with a 2.6 kernel, it doesn't seem to complain that there is no /lib/tls, and the mindi CD seems to work all right. But can we be really sure that we can suppress /lib/tls, without bad consequences, with any kernel, current or future ? 1 - If we can suppress /lib/tls : then we simply need to keep the first part of ldd's output, as this latest patch does, which can be made shorter with : sed 's/(.*)//; s/[[:blank:]]//g; /=$/d; s/=.*/ /' (tested to work in all cases) 2 - If we have to keep /lib/tls : then we can use the last patch I submitted - with one more command to avoid having twice the same lib : sed 's/(.*)//; s/[[:blank:]]//g; /=$/d; s/=/ /; s/\(..*\) \1/\1/' (tested as well) As I really don't know if option 1 is safe, I would keep 2. OTOH, if 1 is safe, then it should probably be prefered - more simple, and less libs means less space used on the small image... I leave it to you all who know better ! All good points. mindi doesn't include anything from /lib/tls in the original ProcessLDD as far as I can see. Also, from my understanding, libraries in /lib/tls have their non-threaded counterparts in /lib, so there shouldn't be a problem. I think I go for saving space and keeping mindi's current behaviour. Finally, could you repeat once again what the exact circumstances are for which first patch doesn't work? I know, I'm a pain. It's good to have things put down clearly, please don't apologize ! :-) The thing is that the patch is actually suggested by other people as well and it is relatively short and elegant. All good reasons to use it. But if it doesn't work, we have to do something else... It fails when : - you run a 2.6 kernel and - you make a mindi CD with a FAILSAFE kernel Righto. I've tested on Sarge running a 2.6 kernel and creating a CD with the FAILSAFE kernel with my latest patch and it works. So, the very thing I know now that one shouldn't do. But as long as it's possible (and people use it, as I innocently did two years long), I think that it should work and not leave you with a rescue CD that can't boot... But I completely agree with you, if it's something to avoid, it has to be made very clear ! Thierry Thanks a lot for your help! New packages will hopefully hit the archive shortly. Best regards Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#324302: Why the first patch doesn't work for me
.
Thierry
Cheers
Andree
--
Andree Leidenfrost
Sydney - Australia
--- TryToBeCleverAboutInitrd.orig 2005-10-10 20:58:54.0 +1000
+++ TryToBeCleverAboutInitrd 2005-10-10 21:17:12.0 +1000
@@ -92,7 +92,7 @@
# If we are using the FAILSAFE kernel, only ensure the correct config files for
# isolinux and syslinux are used and continue in mindi. Otherwise try to be
# clever first (and then continue in mindi).
-if [ ${kernelname} == FAILSAFE ] ; then
+if [ ${kernelname} == FAILSAFE -o ${kernelpath} = $MINDI_HOME/vmlinuz ] ; then
UseExt2
else
# What filesystem we are after.
signature.asc
Description: This is a digitally signed message part
Bug#324302: Just one sed command...
Hi Thierry again Thanks a lot for sending this through! It's one call of sed and that's it, so that's cool. However running it, we get e.g. for 'ldd /bin/grep'): libc.so.6 /lib/tls/libc.so.6 /lib/ld-linux.so.2 /lib/ld-linux.so.2 which means that things appear effectively twice for every row. The attached new patch mindi_patch_BTS324302_v5.diff makes it look like this: libc.so.6 /lib/ld-linux.so.2 Also, the latest patch tries to precisely address the different situations we may encounter: '[[:blank:]]*.*[[:blank:]]*=[[:blank:]]*(.*/d' just get's rid of things that are just in the kernel, i.e. point to a hex address. 's/[[:blank:]]*\(.*\)[[:blank:]]*=[[:blank:]]*\/.*/\1/' deals with normal library lines and ld-linux under old libc6. 's/[[:blank:]]*\(\/.*\)[[:blank:]]*(.*/\1/' handles ld-linux under new libc6. What do you think? Finally, could you repeat once again what the exact circumstances are for which first patch doesn't work? I know, I'm a pain. The thing is that the patch is actually suggested by other people as well and it is relatively short and elegant. All good reasons to use it. But if it doesn't work, we have to do something else... Cheers Andree On Sat, 2005-10-08 at 01:02 +0200, thierry lathuille wrote: Hello, So, here is the same patch, where I replaced the small pipes with only one sed invocation. Still easy to read... ;-) Thierry -- Andree Leidenfrost Sydney - Australia --- mindi-1.04.orig/mindi +++ mindi-1.04/mindi @@ -2252,17 +2265,13 @@ main_fname=$1 read incoming while [ $incoming != ] ; do - incoming=`echo $incoming | tr -s ' ' '\t'` - i=`echo $incoming | cut -f2` - if [ $i = = ] ; then -# was cut -f1,3 - for fname in `echo $incoming | cut -f1,3` ; do - fname=`LocateFile $fname` - for f in $fname ; do - [ -e $f ] echo $f - done + incoming=`echo $incoming | sed '/[[:blank:]]*.*[[:blank:]]*=[[:blank:]]*(.*/d ; s/[[:blank:]]*\(.*\)[[:blank:]]*=[[:blank:]]*\/.*/\1/ ; s/[[:blank:]]*\(\/.*\)[[:blank:]]*(.*/\1/'` + for fname in `echo $incoming` ; do + fname=`LocateFile $fname` + for f in $fname ; do + [ -e $f ] echo $f done - fi + done read incoming done } signature.asc Description: This is a digitally signed message part
Bug#324302: mindi image broken with libc6 2.3.4
Hi Rogério, all There will be an upload soon, don't worry. I would just like to make sure that the problem is addressed properly and without regressions. I noticed that you tried to merge bugs 324302 and 329246. You can only merge bugs that are assigned to the same package which is not the case here, you'd first have to reassign 329246 from mondo to mindi. I am happy for you to do this, because it would be factually correct. However, I would like to point out that reassigning and merging bug reports are actions supposed to help the package maintainers, they are not really for users. Asking (which you did) and a day later doing it without consent from at least one of the package maintainers, i.e. Hector or myself in this case, may lead to some irritation. Mind you, I'm not pissed off at all in this case, as it would be the correct thing to do, this is just a general remark. Best regards thanks a lot for your testing and input! Andree On Tue, 2005-10-11 at 02:11 -0300, Rogério Brito wrote: Hi, Thierry and others. On Oct 11 2005, Rogério Brito wrote: I am burning a CD generated with mindi + your patch. I will report back with the results that I get. I am using, BTW, my own 2.6 kernel. Just doing what I promised, it worked fine with your patch too. I think that we can have an upload to unstable with emergency medium or high, as this package broken in testing may be preventing a lot of people of taking their backups (I can say that it made my life harder, especially when my system suffered from some instabilities that even caused filesystem corruption). Regards, Rogério Brito. -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#329246: Most likely a problem with changed ldd output
Dear all Thanks a lot for reporting and discussing this. I've been on vacation until last week and haven't had a change to look into this before. Apologies. It looks like the underlying problem may be changed ldd output and mindi's failure to parse the new format correctly when assembling the list of libraries to include. This has been reported as 324302 to which I have just added some more information and more importantly a patch to mindi that I believe overcomes the issue. It would be great if one (or more) of you could try this patch against mindi and check whether this does actually fix this problem. Cheers Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#318551: Debian BTS #318551, mindi-busybox: FTBFS: Conflicting types for 'build_bl_tree'
Further to my previous message the attached patch is required to fix another FTBFS issue which I believe was introduced with gcc-4.0, version 4.0.1.-3 (or a related package). Cheers Andree -- Andree Leidenfrost Sydney - Australia --- applets.c.orig 2005-08-04 19:38:46.0 +1000 +++ applets.c 2005-08-04 19:39:06.0 +1000 @@ -45,6 +45,7 @@ #undef APPLET #undef APPLET_NOUSAGE #undef PROTOTYPES +#include config.h #include applets.h signature.asc Description: This is a digitally signed message part
Bug#290722: Reopened because the problem is still there
Hi Alastair Jim Unfortunately the problem persists and I therefore reopen this bug: When libfribidi0 is not installed, a segmentation fault occurs which does not happen when libfribidi0 is installed on the system. So the situation is unchanged. I have experienced that with the following package versions: [EMAIL PROTECTED]:~$ dpkg -s libslang2 Package: libslang2 Status: install ok installed Priority: standard Section: base Installed-Size: 888 Maintainer: Jim Mintha [EMAIL PROTECTED] Architecture: i386 Source: slang2 Version: 2.0.4-4 Depends: libc6 (= 2.3.2.ds1-21) Recommends: libfribidi0 [...] [EMAIL PROTECTED]:~$ dpkg -s libnewt0.51 Package: libnewt0.51 Status: install ok installed Priority: standard Section: base Installed-Size: 704 Maintainer: Alastair McKinstry [EMAIL PROTECTED] Architecture: i386 Source: newt Version: 0.51.6-28 Replaces: libnewt-utf8, libnewt0 Depends: libc6 (= 2.3.2.ds1-21), libslang2 (= 2.0.1-1) [...] gcc is: [EMAIL PROTECTED]:~$ gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c ++,java,f95,objc,ada, treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls --without-included-gettext --enable-threads=posix --program-suffix= -4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk --with-jav a-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr --disable-werro r --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.0.1 (Debian 4.0.1-2) and mondoarchive linked like this: [EMAIL PROTECTED]:~$ ldd /usr/sbin/mondoarchive libmondo.so.2 = /usr/lib/libmondo.so.2 (0xb7f92000) libmondo-newt.so.1 = /usr/lib/libmondo-newt.so.1 (0xb7f88000) libnewt.so.0.51 = /usr/lib/libnewt.so.0.51 (0xb7f78000) libdl.so.2 = /lib/tls/libdl.so.2 (0xb7f75000) libpthread.so.0 = /lib/tls/libpthread.so.0 (0xb7f66000) libc.so.6 = /lib/tls/libc.so.6 (0xb7e31000) libslang.so.2 = /lib/libslang.so.2 (0xb7d6c000) libm.so.6 = /lib/tls/libm.so.6 (0xb7d49000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0xb7fea000) Please let me know what other information I can provide to help fixing this. Thanks a lot sorry for being a pain... Cheers Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
Bug#318551: mindi-busybox: FTBFS: Conflicting types for 'build_bl_tree'
Hi Daniel Thanks a lot for reporting this bug and even more so for pointing out the solution as well. ;-) With the attached patch which is a much stripped down version of what's in #294474, mindi-busybox compiles fine with gcc-4.0. Best regards Andree On Fri, 2005-07-15 at 21:25 -0700, Daniel Schepler wrote: Package: mindi-busybox Severity: serious Version: 1.00-4 From my build log: ... gcc -I/tmp/buildd/mindi-busybox-1.00/include -I/tmp/buildd/mindi-busybox-1.00/include -I/tmp/buildd/mindi-busybox-1.00/libbb -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wstrict-prototypes -Wshadow -Os -march=i386 -mpreferred-stack-boundary=2 -falign-functions=0 -falign-jumps=0 -falign-loops=0 -fomit-frame-pointer -D_GNU_SOURCE -DNDEBUG -c -o /tmp/buildd/mindi-busybox-1.00/archival/gzip.o /tmp/buildd/mindi-busybox-1.00/archival/gzip.c /tmp/buildd/mindi-busybox-1.00/archival/gzip.c:2166: warning: type qualifiers ignored on function return type /tmp/buildd/mindi-busybox-1.00/archival/gzip.c:2166: error: conflicting types for 'build_bl_tree' /tmp/buildd/mindi-busybox-1.00/archival/gzip.c:1643: error: previous declaration of 'build_bl_tree' was here make[1]: *** [/tmp/buildd/mindi-busybox-1.00/archival/gzip.o] Error 1 make[1]: Leaving directory `/tmp/buildd/mindi-busybox-1.00' make: *** [build-stamp] Error 2 This looks like it's probably the same problem as in bug #294474; try the patch there. -- System Information: Debian Release: testing/unstable Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11-9-amd64-k8 Locale: LANG=en, LC_CTYPE=en (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) -- Andree Leidenfrost Sydney - Australia gzip.c+ifupdown.c-#318551.diff Description: Binary data signature.asc Description: This is a digitally signed message part
Bug#314782: Re: Your Debian mondo bugs
Hi Markus On Wed, 2005-07-13 at 06:50 -0400, Markus Waldeck wrote: Dear Andree I don't believe this is comparable: mondo works fine without the ... snort works fine without database support, too!!! But I have the possibility to choose a package WITH database support! But mondo works fine with and without the dvd+rw-tools package installed; there is no need for two mondo packages. The only difference is that without the dvd+rw-tools package installed it can't create DVDs. As a side note, the nautilus-cd-burner package does exactly the same thing as the mondo package: it depends on cdrecord but only recommends dvd+rw-tools. This means that normally the dvd+rw-tools package would get installed along with mondo but someone that doesn't want it, e.g. because of space constraints does not have to install it. I think the best space constraint is to avoid the installation of mondo at all! That would mean to forego the option to use a powerful and versatile disaster recovery suite. Certainly we don't want that! ;-) You ought to close the bug report! Seriously though, I am not sure that I have convinced you but will take your suggestion at face value. Dr. Markus Waldeck Best regards Andree -- Andree Leidenfrost Sydney - Australia signature.asc Description: This is a digitally signed message part
