Bug#601456: Link to a solution
You may want to look at this answer: http://askubuntu.com/questions/24594/lo-disabled-privacy-extensions-and-ipv6-disabling It solve the issue for me (even if on another distribution) Bruno. -- Des infos sur la musique ancienne -- http://www.musique-ancienne.org Des infos sur les logiciels libres -- http://www.HyPer-Linux.org Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575716: RFP: libprojectbuilder-perl -- Perl module providing multi-OSes (Linux/Solaris/...) Continuous Packaging
Package: wnpp Severity: wishlist Version: N/A; reported 2010-03-28 * Package name : libprojectbuilder-perl Version: 0.9.8 Upstream Author : Bruno Cornec br...@project-builder.org * URL: http://www.project-builder.org * License: GPL Description: Perl module providing multi-OSes (Linux/Solaris/...) Continuous Packaging ProjectBuilder is a perl module providing set of functions to help develop packages for projects and deal with different Operating systems (Linux distributions, Solaris, ...). It implements a Continuous Packaging approach. -- Open Source Linux Profession Lead EMEA / http://opensource.hp.com HP/Intel/Red Hat Open Source Solutions Initiative / http://www.hpintelco.net http://www.HyPer-Linux.org http://mondorescue.org http://project-builder.org La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544129: mondo: license audits necessary
The MondoRescue project is licensed under the GPLv2. The file COPYING at the root of the archive is clear about it. Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560716: updating mondo for the new upstream version
Hello Rogério, Rogério Brito said on Mon, Jan 11, 2010 at 11:25:31PM -0200: Great. I have to mirror your svn repository with the git repository that I'm using, but this mirroring is very slow. Do you happen to think about transitioning to git at some point or another? No. I don't like that much DVCS myself, and prefer SVN. Even SVK sometimes gives me strange results I do not like. Git looks to me over complicated for the needs I have. But, I may be convinced later ;-) However, I do not understand why you want to replace calls to /bin/sh in all backup scripts by calls to /bin/bash. I think that at restore time, bash is not mandatory. Actually, that was inherited from Andree, if I am not mistaken. I am more of a purist person and I would love to have everything depending on the least amount of things (e.g., bare sh etc). So what do you think we should do here ? I know that Ubuntu people are considering dash as well. I think as you that we should have /bin/sh used in scripts, and check that it works with dash/bash correctly (so avoid bashisms, even if I don't think there are too many). Can you comment a little bit more regarding the disappearance of busybox? This is a pretty major change, of course. Yes. Busybox has some annoying problems with symlinks e.g. and also create a dependency that some distributions dislike. Using the std tools, instead of busybox occupy a bit more space, but gives you access to all options of those tools, and make coding more easy, as well due to that. BTW, this is a pet peeve of mine: the check command for availability in mondo has to change to be more generic (and, as a side effect, eliminate some repetitive code): it should not check for only a single command and, if that exists, set some variable to that command. It should accept a list of commands and, the first one that is found (if there is any) is returned, so that we can put that command to use. Only if none is found we bail out and give an error. This way, we get a lot better with the possible availability of programs under many different names. Also, the system administrator can set his preferred command (e.g., if he has, for some reason, installed something on /usr/loca). Seems a good idea. Would you like to propose a patch for that ? Mine was to externalize that in conf files, in order to give more power to the end user (and also more risks ;-) But I'm a bit reluctant to code that in C, and would prefer to make it part of the perl-rewrite, as I already have tested code for conf file handling. (devel branch is a begining of what I have in mind). That would be a better solution, IMVHO. Also, it struck me that you were reimplementing some functions from the standard library with a custom prefix. Is there any real need for that? Independance, and error checking. Could make it much easier to port to say FreeBSD, e.g. 2.2.9 is entering a really stable life now. I have some patches for an upcoming 2.2.9.2. So I won't take patches that change too much the code for that branch anymore. OK, no problems with that. Do you have any plans on releasing that? I'm still fighting to fix 2 issues, one with SElinux and extended attributes, the other one with LVM devices exclusion. Once those are good to go, I'll freeze and publish 2.2.9.2. Should have already been done, but those bugs are harder than I thought. The rest of the dev is done in 2.2.10 and devel branches now. FYI. Nice. Just FYI, a git kernel tree from Linus Torvalds just introduced a new compression scheme for the kernel images: lzo. This is a good chance to make the detection of signatures and so on a bit more flexible and general. Thanks for sharing that. Will have to adapt mindi then. I think that mindi/mondo need some good user-level document regarding the changes between versions (not something which is technical like: Removes the useless uid field of the mountlist_line struct). I can help with some of that, if desired. Indeed any help to improve that is welcome. I try to publish more user friendly doc for changes in my announce to the ML. Best regards, Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560716: updating mondo for the new upstream version
Hello Rogério, Rogério Brito said on Fri, Dec 11, 2009 at 02:05:36PM -0200: I just took some time yesterday to update mondo to a newer version in Debian. Thanks for taking care of that. I see that the patches that I had in 2.2.7 are still appliable to 2.2.9.1. They cover things that we need to consider for mondo as upstream and, while appropriate for Debian, they should be cleaned up for general use. I have appliced the patch 00-escape-hyphens-in-manpages.patch upstream in rev [2543]. However, I do not understand why you want to replace calls to /bin/sh in all backup scripts by calls to /bin/bash. I think that at restore time, bash is not mandatory. I'v not checked all scripts, but IIRC there were made to be relatively agnostic in term of shell (bash, bourne, dash, ...) So I din't applied it for the moment, and would like confirmation that it's indeed needed. If we can stay more generic the better, especially in prevision of 2.2.10 where busybox will disappear. Concerning the last patch, it will just break support of other older distributions (including older Debian, Ubuntu ones). So it needs to be handled in a more gentle way that a simple replacement of cdreord by wodim. Isn't there any compatibility package in Debian to maintain availability of calls to cdrecord and mkisofs, such as what exists on my Mandriva: r...@victoria2 ~]# ll /usr/bin/cdrecord lrwxrwxrwx 1 root root 26 2007-05-19 18:43 /usr/bin/cdrecord - /etc/alternatives/cdrecord* [r...@victoria2 ~]# ll /etc/alternatives/cdrecord lrwxrwxrwx 1 root root 14 2009-11-16 18:42 /etc/alternatives/cdrecord - /usr/bin/wodim Let me come up with something more suited for that problem. Also, there seems to be a desperate need to refine the code and I have just mirrored the SVN repository with git, to start working on it. 2.2.9 is entering a really stable life now. I have some patches for an upcoming 2.2.9.2. So I won't take patches that change too much the code for that branch anymore. The rest of the dev is done in 2.2.10 and devel branches now. FYI. And there we can make lots of modifications (and lots have already been done, but status is that only mindi has been tested correctly up to now in 2.2.10. Thanks for your help, Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#519548: Getting mondo updated
Hello, Rogério Brito said on Tue, Sep 08, 2009 at 10:47:23AM -0300: I'm not a pure expert, but know where I want the code to go. And my will is: remove useless static memory allocation (tricky) I'm not sure about which static memory allocation you mean. Do you mean char foo[BIG_SIZE_HERE]? Yes; It has caused many different issues in the code (strcat without checks leading to seg fault, stupid limitations in sizing, huge allocation of memory where it's not useful, ...) Depending on the situation, just including some malloc's/free's are gratuitous artificial complexity. Well if it's done at a sufficiently low level, it's not a problem IMO. It's relatively fast, you use what you need only, and adapt to machine resources, not to fixed barriers (nobody will ever need more than 640KB syndrom ;-) And, anyway, if said code is not used in a non-standard ways, it is marked auto by the compiler and disposed when the scope of the function ends. THere were some recursive and interesting usage + some statics. I usually favor statically compiled languages, but I'm not opposed to Perl, *if* the programs don't inflate the memory requirements of the interpreter too much. Will have to measure that. But frankly looking at the code since 8 years now, and more precisely during the last 4, most of what was written in C should never have been written in C !! : The code still contains more than 600 system calls ! Or how to use C as a scripting language. There are some parts that could benefit from staying in C, but only a few IMO. We would like to want the code to work even on small platforms, after all. Yes but nowadays it's far from being the majority of users. Now we could target netbooks, phones, ... why not. But that would anyway require a good re-architecture/re-write. And perl is available on so many platform it shouldn't be a problem. And I always found the perf great (never looked too much at the memory side). Sure, but I'd guess that they may not be that interesting, now that the versions have diverged a bit. I'm including it here anyway. Please, note that the patch has already three patches in it (patch in patch format, to be handled with quilt). I don't know quilt myself. IIUC it aggregates patches. Why not, as Andree can say to you, I tend to prefer single (small ;-) patches in order to study them before inclusion. It seems that the lzma file is not clean: lzma: Decoder error Could you resend it again please ? (start is on control file modifications, and I'll apply them without issue). Very nice. I am short on space and like to keep my backups under 500MB, so that I can use dvdisaster (yes, I am a bit paranoid). BTW, by using dvdisaster, one can create solid archives (like I mentioned with you many moons ago). And the backups are smaller themselves. Sorry forgot about that. Indeed looks very interesting. Will package it for my Mandriva which doesn't seem to have it. Would you like to contribute a mondo extension allowing its joint usage ? OK, in a slightly tangent comment, it seems that the version 2.2.7 has problems with Linux images that have not been compressed with gzip (newer kernels allow bzip2 and lzma compressed images). Do you have support for that? Humm. Not at the moment. Right now, mondo dies trying to be smart about the kernel that I compiled if I use one of those images, but it is wrong in its decision. It's in GetInitrdFilesystemToUse and only supports gziped compressed kernel. Can easily be adapted (this code was made by Andree BTW for Debian originaly and was merged ;-) And, BTW, why are there differences regarding burning CDs/CD-RWs? I can't really see the point (besides the fact that CD-RWs may have to be blanked before writing them). I know there are diffs for drive that can eject/inject or not but I also never understood why they were considerd separately indeed. Probably more cleanup to do. I absolutely agree that sane defaults are essential. But letting the experienced user override the defaults is important to have a good share of the target market for this tool. Which is aplea for config file which are right now missing in mondo. It's in my trunk tree (useless BTW except for taking some ideas I tried). No problems with postponing things. But I am much more favorable to gradual changes than to radical changes. +1 ! Over-engineering is a problem that should be avoided. A certain degree of generality is good, but not that much. Vast question ;-) Great. Now that GCC 4.4 has test coverage, we can see which paths are used and which ones are not. I'm interested if you can give example of how we could apply that to mondo. Size is still important (and will always be), but 1MB of a 650MB CD wouldn't make that much difference. It's a bit more today. mindi is around 30MB. It's still less than 10% of a CD and nothing of a DVD/USB key. * cleaning the logs a little bit. You mean the project logs or Debian
Bug#519548: Getting mondo updated
Hello, Andree Leidenfrost said on Mon, Aug 31, 2009 at 07:18:58PM +1000: 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. Yes. 2.2.9 is in a frozen state now. I just want to fix a last remaining bug seen on a customer site. Then publish. I'm also working in // on 2.2.10 which already contains a large number of modifications. On Wed, 2009-08-26 at 06:05 -0300, Rogério Brito wrote: 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. Well, I'm also interested to provide to Debian the latest packages as soon as possible. Thanks to Andree's work, I have a whiole build infrastrcuture in place to produce packages for Debian 3.1, 4.0 and 5.0. So Iwas considering the possibility to become a Debian Maintainer (Cf: http://wiki.debian.org/Maintainers) in order to be able to help. WDYT ? 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 Personaly, I have no issue for that, of course. And feel free to involve me around bugs seen in Debian for Mondo/Mindi. 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). I'm not sure what you mean here. Mondo/mindi is already in a public repo (http://trac.mondorescue.org/browser/branches/2.2.9). Even my build system is in a public repo (http://trac.project-builder.org/browser/projects/mondorescue/pbconf/branches/2.2.9 e.g. for the upcoming stable version). Do you think of the specific Debian build files ? Knowing that my goal is to reduce as much as possible the differences between upstream and packages. Andree helped me a lot in that perspective, and his contribution has been very valuable for the project, as well as for Debian. What do you think? I would also be willing to spread the word so that we can get some more contributions (and/or users). Yes ! Yes !! Once it's ready, we can at least announce on our ML that we have another DD with Andree working on the packaging. I'll let you do the same on the Debian side. Happy to see continuous interest from Debian to our project ! Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Ambassador \ EMEA CME Sol. Center http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpBKU7zCq7Mf.pgp Description: PGP signature
Bug#423505: Mondo mangles /etc/udev/rules.d/z25_persistent-net.rules upon restore
mark david mcCreary said on Mon, Dec 01, 2008 at 07:50:23AM -0600: The z25/z70 issue does not bother me, and I think that is documented now in the FAQ. Reading you correctly, what do you think of the following patch then: === --- mindi/mindi (révision 2068) +++ mindi/mindi (copie de travail) @@ -2195,7 +2195,7 @@ LogIt udev device manager found tar cf - /etc/udev 2 /dev/null | tar xf - # This avoids NIC remapping if on another machine at # restore time on Debian at least - rm -f ./etc/udev/rules.d/z25_persistent-net.rules + rm -f ./etc/udev/rules.d/z??_persistent-net.rules tar cf - /lib*/udev 2 /dev/null | tar xf - if [ -x /sbin/udevd ]; then lis2=`grep -Ev '^#' $MINDI_CONF/udev.files` Concerning your restore issue, please feel free to followup with us or the mondo mailing list providing log files if possible. Best regards, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423505: Mondo mangles /etc/udev/rules.d/z25_persistent-net.rules upon restore
Andree Leidenfrost said on Sun, Nov 30, 2008 at 06:46:01PM +1100: However, we delete in the restore environment only and do not change the udev config of the restored system. At least I think this is what we do - Bruno, do you think this is right or am I overlooking something here? I think you're perfectly right on this Andree. Maybe this should just be done in a cloning siution, but as we can't determine them atm, I'd agreed to remove that file. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpy9oRZiBpCD.pgp Description: PGP signature
Bug#475221: mondo: CVE-2008-1633
This bug will be fixed by the upcoming debian package for Lenny which is based on 2.2.7 so post 2.2.5 which doesn't contain the issue anymore. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414948: mondorestore hangs when trying to create a new RAID array
I think you should try with an upstreal test Debian package available at ftp://ftp.mondorescue.org/test/debian/4.0 to check that it's indeed fixed or not. TIA, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409291: Archiving to tape leaves out most files (biggiefiles are ok)
The tests I made with upstream version 2.2.6 do not exhibit this bug anymore. Could any of you test the version available at ftp://ftp.mondorescue.org/test/debian/4.0 (upstream .deb packages - NOT OFFICIAL Debian packages that Andree is currently working on). I closed upstream bug report 82. So if you exhibit the issue again, please reopen it with log files attached. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#440463: mondo fails to recognize USB DVD during restore, starts requesting floppies
This has long been fixed upstream and should then be in your upcoming new Debian packages. You can test an upstream unofficial debian package at ftp://ftp.mondorescue.org/test/debian/4.0 and give feedback. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#466401: patch
dann frazier said on Thu, Feb 28, 2008 at 04:04:50PM -0700: I backported a couple of changsets to 2.6.18 that add support for these cards. I did some light testing on a low profile model, and it seems to work fine. Any possibility to have a temporary .deb kernel to test ? Would make it easier on the target machine if possible. Thanks for your quick feedback, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429308: mondo: incorrectly guesses names for assembled RAID-1 devices during restore
Tim Freeman said on Sat, Jun 16, 2007 at 03:29:03PM -0700: The workaround was to give these commands: mdadm --stop /dev/md0 mdadm --stop /dev/md1 mdadm --assemble /dev/md3 /dev/hda3 /dev/hdc3 mondoarchive I think mondoarchive should save /etc/mdadm/mdadm.conf during the backup and consult it during the restore so it can give the RAID devices the same names they had during backup. Could you try adding it to your /etc/mindi/deplist.txt to see if that workaround fixes your issue ? Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#431505: mondo: should create solid archives
Rogério Brito said on Wed, Jul 04, 2007 at 06:26:37AM +: Not only that, but some of the files on the afio archives were compressed, while others were not. True. I think that the overhead for compressing all files (and not choosing which one should and which one shouldn' t) would be negligible and would potentially make the backups smaller (and faster, but I don't know how much of the time is spent choosing which files are or which files aren't going to be compressed). I think there could be a big change. Why compressing already compressed formats ? Especially when you use bzip2 which is quite slow. I guess that the criterium is that files smaller than a frame/page aren't compressed, is that right? No. Criteria is a set of file extensions (it's documnted in afio man page, and mondo adds some other extensions to the list. I plan to re-work that anyway for 3.0.x as there are some bugs in that part). First this is an upstream problem, not a Debian one IMO. Not to sound harsh here, but the maintainers are the interface between the users and upstream. That's because we have wishlist bugs and the ability to forward the bugs to upstream in Debian's BTS. Again, this isn't meant to sound harsh. Ok. I don't know obviously the Debian process tat well ;-) But what I think should be done in such a case is open a bug in our trac system so that it can be discussed upstream, with a link in the BTS no ? I think that an option to do what I ask wouln't hurt. After all, I take backups every single day in ISO images (since the other bug that I filed for mondo to call cdrecord with the -dao option is approximately 1 year and a half without action) and burn them on CD and verify the MD5 sums with either readom (from the cdrkit package) or with dvdisaster. I'm working on separating all those parmeters (_dao and the like) from the code and put them in config files. It takes time, and it's only for v3.0.x. As I have focussed up to June on 2.2.x, it ddn't progress a lot. I just began during my vacations to work again on 3.0.x. Hop to propose a version by September for testers. On the problem in itself, CD/DVD damage during time. You may have them corect in MD5SUM at the time you burn it and incorrect 2 years later. That's where the feature would play nicely ;-) What we could do is rename the files to make them not having the suffix. But that should be an upstream enhancement request IMO. At least, this would be a step on the right direction, since the way it is, it is misleading. Ok. Would you like to fill a bug upstream ? Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
Bug#431505: mondo: should create solid archives
Rogério Brito said on Tue, Jul 03, 2007 at 03:40:03AM -0300: Much to my surprise, the files that with names number.afio.bz2 were *not* compressed with bzip2. Instead, they were pure afio files with only some files inside the afio archive compressed. True. THat's on purpose since the origin of the tool. Since I have many files that in a given directory that share much of the same content, I think that reversing the order of the actions (that is, creating first the afio archive and then compressing it) would be really helpful for creating smaller ISO files (which is, for me, the deciding factor if I keep or not a package). First this is an upstream problem, not a Debian one IMO. So then speaking as the upstream project lead, I think what we have is the most effective way to ensure that in case of media error, you'll be able to retrieve your content anyway as most as possible. If we adopt your view, that won't be true anymore. So I don't think it's a good idea. What we could do is rename the files to make them not having the suffix. But that should be an upstream enhancement request IMO. I am sure that other people would find this a great feature for mondo. No I don't think so sorry ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
Bug#426908: Any progress ?
Vincent Bernat said on Tue, Jun 26, 2007 at 08:41:41PM +0200: Is there any progress on this bug ? For interested readers, here is a simple patch fixing this issue : [...] 2.2.3 upstream was really about fixing that bug. Other diffs are really minimal, so I advise that Debian uses 2.2.3 (aka 2.23) as an upgrade. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#425648: 100% reproducible grub-install hang when run in x86_64 qemu
Just to confirm I see the same problem when I try to install Debian 4.0 (Etch) on QEmu on x86_64. The same issue is also detected when installing a SuSE 10.2 in QEMU. However it works when I install fedora 6, mandriva 2007.9/.1 or rhel 4/5. Hope it gives some directions. Bruno. -- Des infos sur la musique ancienne -- http://www.musique-ancienne.org Des infos sur les logiciels libres -- http://www.HyPer-Linux.org Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)
Bug#426908: mondo: Mondorestore creates /tmp but does not restore files
[EMAIL PROTECTED] said on Thu, May 31, 2007 at 07:27:19PM +0200: Package: mondo Version: 2.22-1 Severity: normal That version has a fatal bug when using bzip2 compression already fixed upstream in 2.2.3. Andree is aware of it and will provide updates as time permits. Cf: http://trac.mondorescue.org/changeset/1353 Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#269193: Proposal of patch
Hello,
I'm not a Debian contributer, but a Mandriva one.
Here is the patch I made for the Mandriva cooker package.
Maybe it could be useful, or at least serve as a base for discussion:
--- vsftpd-2.0.5/postlogin.c.orig 2007-05-02 19:43:54.0
+0200
+++ vsftpd-2.0.5/postlogin.c2007-05-02 19:44:28.0 +0200
@@ -1009,7 +1009,7 @@
/* Are we required to chown() this file for security? */
if (p_sess-is_anonymous tunable_chown_uploads)
{
-vsf_sysutil_fchmod(new_file_fd, 0600);
+vsf_sysutil_fchmod(new_file_fd, (0777 ~tunable_anon_umask));
if (tunable_one_process_model)
{
vsf_one_process_chown_upload(p_sess, new_file_fd);
HTH,
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416092: mondo: Editor hardcoded to 'vi' [Patch attached]
Andree Leidenfrost said on Wed, Mar 28, 2007 at 08:04:28PM +1000: - strcpy(editor, vi); // find_my_editor() ); + strcpy(editor, find_my_editor() ); Tien. Not the same patch. What does this mean? Forget that remark, I was upset, and I made a confusion between Hugo and the other person flaming on the ML. Sorry for that. If you want, you can look at what I did for the stable branch. I think that's the good approach (using indeed find_my_editor , and that function now looks for EDITOR). I probably need to retrofit it in upcoming 2.2.2 Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpmccKk6e9uq.pgp Description: PGP signature
Bug#416044: mondo: fails with multiple dvd's
hugo vanwoerkom said on Sat, Mar 24, 2007 at 04:24:58AM -0600: But when I backup something large, that needs more than one DVD, mondo behaves strange: It puts up Blanking DVD, then Waiting for drive to settle, then says it can't write to the DVD[1]. You should not use a size greater than 4380 (MB) for creating physical media. 4600 does NOT fit on a DVD (Cf mondo doc/faq) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414948: mondorestore hangs when trying to create a new RAID array
John Pearson said on Mon, Mar 26, 2007 at 10:29:29AM +0930: The fix you provided allows me to get further: I can now allocate devices to the array, but mondorestore segfaults when I choose 'OK' after specifying the devices to use; I've tried with both existing RAID autodetect partitions, and with empty disks that I've 'added' RAID partitions to using mondorestore's partition editor. Ok. Other fixes have been made to the Raid support recently in waht will be 2.2.2. What I can propose to you is wait till 2.2.2 is out (early April) and try again with it instead so that we know if we fixed it for good or not. Sorry for the inconvenience, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416092: mondo: Editor hardcoded to 'vi' [Patch attached]
hugo vanwoerkom said on Sat, Mar 24, 2007 at 01:04:53PM -0600: It would seem unnecessary to have to learn 'vi' just because one uses mondo as a backup tool. Please Andree, refer to the mondo ML (and the related thread) before acting on this. - strcpy(editor, vi); // find_my_editor() ); + strcpy(editor, find_my_editor() ); Tien. Not the same patch. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#414948: mondorestore hangs when trying to create a new RAID array
John Pearson said on Thu, Mar 15, 2007 at 08:59:20AM +1030:
Ran 'ps fx' on another tty, which showed commands like
grep /proc/mdstatraid1 /dev/null 2/dev/null
It looks like this should be
grep raid1 /proc/mdstat
Oh yes. I fixed that in the stable SVN branch since, but I didn't for
the future 2.2.2. Thanks for reporting that. I've now committed it as
rev 1253 of SVN - http://trac.mondorescue.org/changeset/1253
Could you try to add the patch to your tree:
--- mondo/src/common/libmondo-raid.c(révision 1247)
+++ mondo/src/common/libmondo-raid.c(copie de travail)
@@ -80,13 +80,13 @@
int res;
command = malloc(MAX_STR_LEN * 2);
- strcpy(command, grep \ /proc/mdstat);
+ strcpy(command, grep \);
if (raidno == -1) {
strcat(command, linear);
} else {
sprintf(command + strlen(command), raid%d, raidno);
}
- strcat(command, \ /dev/null 2 /dev/null);
+ strcat(command, \ /proc/mdstat /dev/null 2 /dev/null);
log_it(Is raid %d registered? Command = '%s', raidno,
command);
res = system(command);
paranoid_free(command);
--
Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
Bug#403454: mindi does rm -Rf /home !
Andree Leidenfrost said on Sat, Dec 23, 2006 at 09:47:48AM +1100: 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. Well upstream is the king. Let me propose you something: I can publish a new 2.2.0-3 which is equal to 2.2.1 if it's more convenient for you. Of course I'm cheating. But I have a problem if Etch only contains 2.2.0 on my side. I'd prefer that we fix the remaining differences in mindi ;-) Maybe this could be something to sort out during LCA2007? That was in my planning for LcA 2007 ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpzjzMZvXi0e.pgp Description: PGP signature
Bug#403454: mindi does rm -Rf /home !
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. 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 ;-) 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. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398425: mondo: Crash during backup : *** glibc detected *** free(): invalid next size (fast): 0x080e1898 ***
Olivier LARRIGAUDIERE said on Wed, Nov 15, 2006 at 11:22:04AM +0100: Could you please give me more detailed instructions on how to produce a backtrace ? Please look at http://trac.mondorescue.org/wiki/AndreesStuff Bruno -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpSsrULbwtNh.pgp Description: PGP signature
Bug#385790: mondoarchive behaves badly with afs
Andree Leidenfrost said on Wed, Sep 13, 2006 at 11:35:27PM +1000: Do you mean 787? The latest I get on trac right now is 786, which is probably just a refresh/timing issue. Right : rev 787. Did you approach things similarly to what I did? Did you notice the find change which is of general applicability (and which can speeds things up be some minutes)? Nearly, excpt the find thing. Given that 2.2.0 will probably not be ready for a while (or could I be wrong here?!?), would you be happy to comment on the patch anyway, because this is what might ship with etch? Well I'm halfway for the 2.2.0 release. I'll re-read the patch and comment asap. Off to bed now... ;-) Same for me :-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpcysN4196uy.pgp Description: PGP signature
Bug#385790: mondoarchive behaves badly with afs
FYI, I have just commited rev 78787 which should allow for a better AFS support. Will be part of 2.2.0. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#355751: mondo: insanely slow!
Rich Walker said on Tue, Aug 15, 2006 at 03:32:52PM +0100: At the moment, mondoarchive does take a phenomenally long time to archive a few hundred thousand files. Removing the extended attribute handling makes a big difference! I suggest that describing it as a general-purpose backup solution is a bit misleading, and noting the attribute handling-slowdown feature might be useful. I think there is a glitch in the way those attributes are handled. It always make request to find getfacl, ... which is dumb. Andree Could you open a bug report upstream for that please ? TIA, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379966: Proposed New Function mr_stresc()
Andree Leidenfrost said on Thu, Aug 03, 2006 at 09:51:01PM +1000: Version 5 is attached. I've reverted to a constant for the escape character. I've also gotten rid of all casts you mentioned. I had to remove the 'const' for 'escape_list' in main though, otherwise I'd still get the warning for 'toesc'. So, once we start the cycle for 2.0.9 would you be ok for me to commit in mr_string.c (also moving mr_strtok)? Yep. It looks nice now ;-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpZDuS4z86pj.pgp Description: PGP signature
Bug#379966: Proposed New Function mr_stresc()
Andree Leidenfrost said on Wed, Aug 02, 2006 at 08:54:06PM +1000:
That fixes which one is used (and should be LSB/FSH compliant) and allow
for some exotic distro to change that conf file only to make it work.
Definitively for 3.0.x
I am certainly happy for you to make that design decision. I only
caution that it is a balancing act. If we define too many things
statically in configuration we might end up in some sort of maintenance
hell where we constantly have to adjust configuration to all sorts of
(distribution) changes. (But maybe I am too negative and it will all be
good.)
Well, I think that this maintenance is also something done outside of
the project.
If a new distro wants mondo, and they are not LSB compliant (or LSB
doesn't define something and it's different for them - tyically parted -
then it's way more easy to change one line in an external config file,
rather than to explore all of the code as we do today to solve the issue
!!
So I bet it will reduce our maintenance burden rather than increasing
it.
But that's for 3.0.x and I can't give you code to review right now in
order to help convince ;-)
inptr = (char *)instr;
You don't need to cast here.
I was surprised, too. Without the cast I get this with gcc 4.1.2 -Wall:
mr_stresc_demo4.c:17: warning: assignment discards qualifiers from
pointer target type
Hummm. It makes the code less readable IMO. Casting is normally done
when objects have potential different types, but in fact are the same
(void * being a good example).
I wonder why they add the check between const char * and char *.
In our case, wouldn't it be more simple to remove the const from the
function prototype ? I know it's stupid, but I find more stupid to have
to cast everywhere due to that. It's really makes code unreadable.
*retptr++ = escchr;
Rather: *retptr = ESCCHR;
Hm, why limit ourselves unnecessarily? escchr is currently an argument
to the function, i.e. the escape chararcters could be different. Don;t
you think that's a good thing?
Well here there is room for discussion.
I was more thinking to make a global define and then use it directly.
If you pass it to the function, then your approach is better. In my case
I was removing one parameter from the call. (I think that the ESC char
will always be \\
But you can keep your approach. It's wider.
What we could then do, is restrict the use in the mr_system function (to
be created)
Interesting. Probably another opportunity to improve my understanding of
things. Why is a define better than a constant? (Probably dumb but I
honestly don't know.)
The difference I see, is that defines are handled by the preprocessor,
when variables are handled way later.
Now as said above, it depends on the interface we want.
Keep your previous version for a 3 params func.
Great. Please find revised new version attached (also escapes now). If
you have an idea about the cast I'd be keen - they are still in because
of the warning mentioned above.
remove the const for me is the way to go.
I'd suggest mr_string. for this function.
Right, yeah, that might be a good idea, indeed.
Do you mean mr_string.c and a corresponding mr_string.h?
Yes, I meant mr_string.c.
For the include, I'm not very fond of the way it's done right now
(external, non-external, it's a mess).
For our case, create a mr_string.h describing the interface of the
function, so that when we want to use it, we just #include mr_string.h
// Returns the string fed to it 'inptr' with all characters to escape given
// in 'toesc' prepended by escaping character 'escchr'.
// (Prepare strings for use in system() or popen() with this function.)
I'll also look at doxygen, as it seems to be already supported by the
rest of the code, to see how to use it really !
char *mr_stresc(const char *instr, const char *toesc, const char escchr) {
= char *mr_stresc(char *instr, char *toesc, char escchr)
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
pgpoUil08REEi.pgp
Description: PGP signature
Bug#380703: mondo: Mondo/Mindi detects my serial ATA hard disk as an IDE.
Andree Leidenfrost said on Wed, Aug 02, 2006 at 08:58:06PM +1000: Note that the original message has the mondo-archive.log and mindi.log inline: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380703 Yes sorry. Mistake on my side. I couldn't find anything suspicious - maybe you can. Well, I don't think we have a full system backup here with the options used. That may be a problem. But without knowing what is tried during restore (screenshot and logfile) I can't comment more. mondo-restore.log would certainly be good, though. Indeed. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpg5i2iKVYaT.pgp Description: PGP signature
Bug#380703: mondo: Mondo/Mindi detects my serial ATA hard disk as an IDE.
Andree Leidenfrost said on Wed, Aug 02, 2006 at 08:00:47AM +1000: Upon booting from a DVD image of my entire system, mondo/mindi detects my SATA (Serial ATA) hard disk as an IDE drive. Without any log file, I have problems understanding that. Please Could you provide /tmp/mondo-restore.log when restoring, as well as /var/log/mondo-archive.log when backuping to help in diags. Do you mean that your sda (if that's the way your SATA drive is seen) is now seen as hda ? 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. Well afio format is ALWAYS readable, if you need access to your data. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpKrB3kFcGy5.pgp Description: PGP signature
Bug#379966: Proposed New Function mr_stresc()
Hello,
Andree Leidenfrost said on Mon, Jul 31, 2006 at 09:37:47PM +1000:
To the contrary, e.g. using a function that submits
things to 'sh -c' means we have a sane environment like a PATH and so
forth.
Yeah, well ... that depends on whether you can presume the user does
have a sane PATH variable. I'm inclined to believe the opposite,
actually.
Interesting territory we are entering here me thinks. Why would you be
inclined to say that something as fundamental as the PATH variable can
not be assumed to be sane?
Well, I would tend to also agree on the fact mondo should avoid trusting
too much users, when it doesn't make sense.
That's why I think we should use a config file to include all the
commands used by mondo, and provide the full path name to these
commands.
That fixes which one is used (and should be LSB/FSH compliant) and allow
for some exotic distro to change that conf file only to make it work.
Definitively for 3.0.x
char *mr_stresc(const char *instr, const char *toesc, const char escchr) {
char *inptr = NULL;
char *retstr = NULL;
char *retptr = NULL;
char *escptr = NULL;
int cnt = 0;
inptr = (char *)instr;
You don't need to cast here.
Add: // Counting how many char to escape are in instr
while (*inptr != '\0') {
escptr = (char *)toesc;
You don't need to cast here either.
while (*escptr != '\0') {
if (*inptr == *escptr++) {
Add: // found it. No need to continue.
Also I would increment escptr separately (I don't like ++ on a same
line as something else ;-)
cnt++;
break;
}
}
*inptr++;
No * here needed.
}
inptr = (char *)instr;
You don't need to cast here either.
retstr = (char *)malloc(strlen(inptr) + cnt + 1);
retptr = (char *)retstr;
You don't need to cast here either.
while (*inptr != '\0') {
escptr = (char *)toesc;
You don't need to cast here either.
while (*escptr != '\0') {
if (*inptr == *escptr++) {
*retptr++ = escchr;
Rather: *retptr = ESCCHR;
retptr++;
break;
}
}
*retptr++ = *inptr++;
Idem.
}
*retptr = '\0';
return retstr;
}
int main() {
const char escchr = '\\';
#define ESCCHR '\\'
const char escape_list[3] = `$\\;
char string[44] = These need escaping: `$\\, these don't: abc.;
char *result;
printf(Before: %s\n, string);
result = mr_stresc(string, escape_list, escchr);
printf(After: %s\n, result);
free(result);
return 0;
}
Seems good to me.
But not before 2.0.9 ;-)
Also could we begin maybe to put these new revised and correct functions
in new source files rather, so that we can purge the older files during
time ?
I'd suggest mr_string. for this function.
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
pgpUnWOS4Ta5f.pgp
Description: PGP signature
Bug#379966: mondoarchive mishandles a filename containing back-quote character
Hello, Sorry to come back to you only now. This bug has also an entry in the main mondo bug system (https://developer.berlios.de/bugs/?func=detailbugbug_id=7421group_id=2524) The main issue is with popen system calls which do not provide any way to protect against those types of chars :-( Solution is to replace those calls as well as system probably, even if I think I already corrected some of them in SVN (but I do not remember the attr things :() One possibility is to replace use of system() by fork() and exec(). Exactly. But I have to look more closely at how to do that properly. Not having looked at the mondo code, I have no idea how much work this would be. A lot. Less that the asprintf thing, but still a lot. We should re-code the paranoid_system entry into a mr_system (as I already began to do for other calls in the code) and replace as well the single system (there are some) and popen. It's a common need, so I suspect that such a function exists, in many languages.The fork/exec solution likewise probably exists, too. Will look at it. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#292782: Successful Testing of Patch
Andree Leidenfrost said on Thu, Jul 06, 2006 at 09:02:28PM +1000: Following up on my previous response, I've now successfully restored from a series of two MondoRescue DVDs with the previously sent patch applied. I did this is qemu on the laptop, so had to eject from the host, but mondorestore within qemu was happy once the new media was available. So, I believe we can definitely count this as success. Great news ! I will therefore apply the previously sent patch to stable. I hope this is in line with your original response and your expectations. Exactly. Thanks again for your work, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpKqG1BnSdLM.pgp Description: PGP signature
Bug#369321: mondo: Tape catalog limited to 4096 entries
Andree Leidenfrost said on Thu, Jul 06, 2006 at 08:53:38PM +1000: I will commit the patch to stable as I believe it is in line with our previous discussion of the topic. I hope that's fine with you. That's fine with me ! Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpapsJtLzNSA.pgp Description: PGP signature
Bug#292782: Fix for dreaded DVD/manual tray/BurnProof issue
Hello Andree, Andree Leidenfrost said on Sun, Jun 25, 2006 at 11:38:03AM +1000: I've looked into Debian bug #292782 (again) which is also Berlios bug #6118. First question: Is there a way to avoid duplication ? I mean, as you're part of the project, can't we have a rule so that upstream bugs are only reported upstream, on packaging bugs to BTS ? What is the Debian rule for that ? I was also considering adding trac to manage bugs and Wiki in the future. And there is also a subversion interface. (Cf: https://dev.scicraft.org/trac/about_trac). It would be great to get rid of the limitations of berlios alltogether and have our own infrastructure completely. WDYT ? Essentially, the problem is that you get a pop-up asking 'Is your computer a laptop, or does the CD writer incorporate BurnProof technology?' not only for CD(RW)s which is fine but also for DVDs which is wrong because BurnProof does not exist for DVDs and manual trays seem to work for DVD writing just fine (at least I have not seem any reports that suggest otherwise). Are you sure that BurnProof does not exist for DVDs ? IIRC with my drive its working, but I may be wrong on that. So, the only thing the attached patch does is make it so that the above mentioned pop-up does not appear anymore if we are archiving to DVD. This should address the issue which really only occurs in situations where mondoarchive is called without options and the user is guided through the setup process. As usual, my question goes: WDYT? ;-) I wonder if the patch is correct. I would keep both tests: if ((bkpinfo-backup_media_type != dvd) (archiving_to_media)) rather as I think the same code is used in both restore and archive path. If you agree, please add it to SVN. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpZamyAl53Ev.pgp Description: PGP signature
Bug#369321: mondo: Tape catalog limited to 4096 entries
Andree Leidenfrost said on Sun, Jun 25, 2006 at 01:57:16PM +1000: Thanks a lot for your feedback! You're welcome. Hm, I see what you mean, mountlist_line is 640 bytes + 1 long long int, that's certainly too big to go to 65k entries. (s_tapecat_entry is much smaller.) Yeah, just 42 MB for that is silly :-( Maybe we double it to 8192 for starters? In that context, did you see my Yes. I think it's more reasonable as an interim proposal. other message to this bug about the maximum filesize? Would increasing Yes, but I wasn't awake enough to understand it ;-) the filesize make it so that less entries in the tape catalog would be used because we'd have fewer archive files in the first place? Maybe doubling the filesize AND doubling MAX_TAPECATALOG_ENTRIES would be the way to go? As you have already looked at it, can we do that only for tapes ? What is the impact for CDs ? (I assume DVDs are not a problem). Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpxt90ot5CZu.pgp Description: PGP signature
Bug#222052: Bug #222052: mondo: uses insane grep constructs instead of regexps
Hello, Andree Leidenfrost said on Sat, Jun 24, 2006 at 01:49:20PM +1000: [Bruno: As usual my request for approval. Fairly obvious and low risk I believe. Can I submit attached patch to stable?] Yep. I generally use egrep myself rather than grep -E, but they are similar (from the man page). ~/mondo/svn/branches/stable grep -r egrep . | grep -v \.svn ./mindi/mindi: tr ' ' '\n' $outfile.pre | tr -s '/' '/' | fgrep -vx | sort -u | egrep -v /libX11|/libXext|/libXi|/libgtk|/libgdk $outfile ./mindi/mindi: | egrep -v ((none|/tmp|/ISOs|/proc|/dev/root) )|/mnt/ \ ./mindi/mindi: j=`find $imagesdir -type f | fgrep /mindi-boot | egrep -v '2880|5760'` ./mindi/mindi: for fname in `find $root -maxdepth 2 -type f | fgrep lin | egrep -v '^/proc/|^/net/'` ; do ./mindi/mindi:[ -f $MINDI_LIB/vmlinuz ] FAILSAFE_KVER=`strings $MINDI_LIB/vmlinuz 2 /dev/null | egrep 2\.[46] | cut -d' ' -f1` ./mondo/mondo/common/libmondo-devices.c:(parted2fdisk -l 2/dev/null | grep '^/dev/' | egrep -qv '(MS|DOS|FAT|NTFS)'); [...] So if you don't mind, I would prefer to standardize on this, except if you prefer to do the reverse (change all occurences of egrep with grep -E) Anyway, a patch such as the one you propose, should go in SVN clearly. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpSSH2QKtW6X.pgp Description: PGP signature
Bug#222052: Bug #222052: mondo: uses insane grep constructs instead of regexps
Andree Leidenfrost said on Sat, Jun 24, 2006 at 09:46:01PM +1000:
To be honest, I would prefer to standardise on 'grep -E' instead of
egrep and 'grep -F' instead of fgrep.
Ok why not.
The reason is that I believe that it is not necessarily clear what egrep
and fgrep really are, e.g. on Debian sarge and Mandriva 2006 (yep, I
just installed it in qemu, as that's what you are using... ;-) ) they
are just scripts that use grep:
cat /bin/egrep
#!/bin/sh
exec grep -E ${1+$@}
cat /bin/fgrep
#!/bin/sh
exec grep -F ${1+$@}
Oh. That's a good reason indeed. Always thought it was a
softlink/hardlink testing its name. I never had the curiosity to look at
t closely. So as it's just a compatibility thing, we have to reove it
for perf.
In this case, spawning another shell can be quite a bit of overhead
especially in loops, so not so good, really.
Yes. right.
My understanding is further that egrep and fgrep have been deprecated
some time ago by POSIX in favour of 'grep -E' and 'grep -F'
respectively. I don't have access to POSIX standards or changelogs,
unfortunately. Do you have access via HP maybe (, could be useful for
other things as well)?
Hummm, need to search. Maybe in libraries here.
I would be happy to go through SVN stable and change all occurrences
along with applying the patch itself, if you are happy with this.
If you don't mind and have energy to do it, please do ;-)
(there are more that what I showed previously)
Now, I have to change my habit ;-)
Greetings,
Bruno.
--
Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET
http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net
Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux
La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org
pgpbaAPqcUOSJ.pgp
Description: PGP signature
Bug#369321: mondo: Tape catalog limited to 4096 entries
Andree Leidenfrost said on Tue, Jun 13, 2006 at 01:04:58AM +1000: [Bruno: Would be great if you could comment on this one. Looks to me like we may only have to bump up a number, but maybe there are implications that I'm not aware off...] Ok. Thanks a lot for your bug report and your analysis of the problem. I don;t have any experience with tapes and Mondo Rescue, but I can confirm that the following is still even in the latest SVN in mondo/common/my-stuff.h: #define MAX_TAPECATALOG_ENTRIES 4096 /// The maximum number of entries in the tape catalog. So, the question would be what a reasonable value for this couldlook like. Would 65536 be ok? The problem I see is that mondo will then create an array of 65k structuresi ./mondo/mondo/common/mondostructures.h: struct mountlist_line el[MAX_TAPECATALOG_ENTRIES]; ./mondo/mondo/common/mondostructures.h: struct s_tapecat_entry el[MAX_TAPECATALOG_ENTRIES]; that's where my new work on dynamic memory allocation will definitively help. I know, but it's not ready for prime time yet :-( I fear that by increasing that way we consume a lot of memory which wwill be most of the time useless, creating other types of bugs. Do we need to go from 4096 to 65k directly. Isn't there a middle point which could solve the issue as well as limit the memeory consumed ? Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgp3N0ZwQIlHn.pgp Description: PGP signature
Bug#331002: On second thought...
Andree Leidenfrost said on Mon, Jun 19, 2006 at 09:33:35PM +1000: Just found this in mondostructures.h of mondo 2.0.8 (not sure when this actually changed): I know :-) : r514 | bcornec | 2006-04-30 23:53:09 +0200 (dim, 30 avr 2006) | 2 lines Chemins modifiés : M /branches/stable/mondo/mondo/common/mondostructures.h Increase include|exclude_path (multiply x4) to avoid some reported bugs Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpchyFoccXr2.pgp Description: PGP signature
Bug#351687: mindi: fails to find LVM tools
Andree Leidenfrost said on Sat, Jun 17, 2006 at 08:24:04PM +1000: [Bruno, would be great if you could your feedback on this one (or simply the thumbs up for SVN if you are happy).] _ / \ | |___ | |___| | |___| | |___| \ /___| - Sort of :-) Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpDFc9lFAeji.pgp Description: PGP signature
Bug#362926: mondo: fails to restore lvm2 when 'mapper' is referenced in fstab
[Sorry for answering that later - hectic week ;-] Andree Leidenfrost said on Tue, Jun 13, 2006 at 12:32:20AM +1000: [Bruno: It would be great if you could also give feedback and in particular let me know whether this can go into SVN as is.] Well, your much more advanced than I'm on those topics, so I just trust you :-) My only point would be that if you commit it to stable, you change the comments and remove Debian from it, as I think it is also a problem for other distributions using /dev/mapper (not sure, but I think there were messages around that in the ML). So your fix is aimed at being a general one. The question I now have is : is it indeed the case :-) But we could see that later. It already fixes a support issue for Debian, which is sufficient to put it upstream. If another distro uses it slightly differently, then we'll have to remember to adapt it to those needs as well. Thanks for finding and solving that out. Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpPXbzbCP66c.pgp Description: PGP signature
Bug#325877: Proposed Implmentation for mr_strtok()
Andree Leidenfrost said on Mon, May 15, 2006 at 11:05:10PM +1000: Salut Bruno, Halo Andree ! J'espère que tu as passé un bon week-end! Ya es war ganz gut hier auch ;-) Please find attached my suggestion for mr_strtok() which features the following improvements over strtok(): - thread-safety - input string remains unchanged - concise code Integrated in stable r557. Will be in 2.0.8. to me, no compiler warnings with '-Wall', but there are valgrind errors (see mr_strtok_demo.valgrind in attached tar ball) for both strspn() and strcspn() which may or may not be genuine but at any rate should be about bespoke functions rather than my use of them. (I may be wrong though.) I do not have those error with my valgrind: ==21555== Conditional jump or move depends on uninitialised value(s) ==21555==at 0x1B8F56BF: index (strchr.S:177) ==21555== ==21555== Conditional jump or move depends on uninitialised value(s) ==21555==at 0x1B8F56D0: index (strchr.S:183) string=|md0 : active raid10 hda1[0] hda12[3] hda6[2] hda5[1] | ==21555== ==21555== Conditional jump or move depends on uninitialised value(s) ==21555==at 0x1B901285: strlen (mac_replace_strmem.c:243) ==21555==by 0x1B9611F2: vfprintf (in /lib/tls/libc-2.3.6.so) ==21555==by 0x1B966682: printf (in /lib/tls/libc-2.3.6.so) ==21555==by 0x8048641: main (mr_strtok_demo.c:44) token=|md0|, lastpos=4 token=|active|, lastpos=13 token=|raid10|, lastpos=20 token=|hda1[|, lastpos=26 token=|]|, lastpos=28 token=|hda12[3]|, lastpos=37 token=|hda6[2]|, lastpos=45 token=|hda5[1]|, lastpos=53 ==21555== ==21555== ERROR SUMMARY: 10 errors from 3 contexts (suppressed: 17 from 2) ==21555== malloc/free: in use at exit: 0 bytes in 0 blocks. ==21555== malloc/free: 10 allocs, 10 frees, 205 bytes allocated. ==21555== For counts of detected errors, rerun with: -v ==21555== No malloc'd blocks -- no leaks are possible. It would be super cool if you could take the sample code for a spin and let me know what you think! Or, to talk in (hopefully correct French) acronyms, QTP*? I would say QPT ** ? Answer is : Très bien !! I put the test program in my trunk tree (local) and will sync it with the rest later on. À la revoyure! Oh, nice one :-) Tschüß, Bruno. * Quesque tu pense? ** Qu'en penses-tu ? -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpnLt9pY69xj.pgp Description: PGP signature
Bug#325877: [UPDATE] New parse_mdstat() function for Mondo Rescue
Andree Leidenfrost said on Sun, May 14, 2006 at 09:21:18PM +1000: Sorry for the delay, I was flat out with CeBIT Australia. And I was way too busy this week. The attached patch is what is in mondo-2.07-2 for Debian. It does not include your suggestions below. I decided to release something (for Debian) to keep some momentum and because I am not sure how much time I'll have in the near future. I hope that is ok. That's GREAT ! Hm, I think the memmove command is watertight. But if you want to standardise on using asprintf pretty much exclusively that's ok with me, too. It's just a bit clumsier (but probably less error-prone, so fair enough). Ok, I changed the memmove to asprintf. Please check if it's still correct. I wonder if I'll not commit a first set of asprintf changes from trunk to stable, now that we go to 2.2.0. WDYT ? I think this would be really, really. I am all for 'release early, release often' which in this case would mean to phase the asprintf things in - the code will become safer with every asprintf that we put in. So, go for it! Ok. So what I do now, is that stable is really what the title suggests: stable ;-) No new big modif will go in it, only bug fixes of 2.0.x. I've reverted all my recent modificatios in it and put them in trunk only. trunk will become the next 2.2.x serie. So it will include all aspintf modifs I've made since now. Beware that it may not compile. And if it compiles, it will NOT work now. I need to address the structures before being able to have something. Maybe we should write our own mr_strtok function which will do it correctly ? That may be the best thing to do. Ok I integrated your patch, and replace calls to strtok by calls to mr_strtok. Could you chack it still works for you ? (I didn't know the strspn functions you used, nice catch :-) I'll see whether I can work on an updated patch incorporating your latest suggestions, but thought I send this through first (including the current patch). No worry I did it, I hope correctly. At least it will be in 2.0.8. I may integrate a last correction for x86_64 for mindi, and work on finishing the multi-distro env. I'll ping you for the Debian script integration. Or can I use the one yo uproduce and just put them in the tree ? I'm working on gentoo currently and hope to have something working next week for that. As for debian, it should be quicker with your content. Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpDg2cMTk1uQ.pgp Description: PGP signature
Bug#325877: [UPDATE] New parse_mdstat() function for Mondo Rescue
On Sun, May 07, 2006 at 06:18:27PM +1000, Andree Leidenfrost wrote: - replaced fgets with getline() to avoid static strings and thus overflows Good point ! I've done some more testing, valgrind is still happy, so I think this is as good as it gets at the moment. If there is anything that I've overloooked, please let me know. Well, in order just to be picky, I would declare each variable on a single line (personal preference): char *token, *string = NULL, *pos, type; = char *token; char *string = NULL; char *pos; char *type; I find it more readable IMHO. Other point. I'm not sure of the usage of memove and the memory management it implies. I would rather do: asprintf(str2,pos); rather than memmove(string, pos, strlen(string)); potentially followed by paranoid_free(string); string = str2; if you find it more readable. because I'm not not sure what will happen of the first part of the string, when you will free string later on. I fear a memory leak again. I'd prefer to create more tmp variables, it's more work, but it's more convenient, and thus we know what we allocated, and what to free. So in clear we should be able to deal nearly only with asprintf and getline, as memory string functions. memcpy could still be used for structure copy, but that's another story. I wonder if I'll not commit a first set of asprintf changes from trunk to stable, now that we go to 2.2.0. WDYT ? I can't merge the latest modifications as they do not work, but most of first where working, and it could be time to migrate them from trunk to stable. It wil also ease the use of trunk for dealing with the rest of memory management, minimizing the time to merge the patches from stable to trunk. Also wouldn't getdelim be useful for what you try to do ? Also in the man page of strtok: BUGS Never use these functions. WDYT ? ;-) (Again I fear the following free, will it free the whole memory ? We need to pass to free the pointer to the begining of the thestring allocated by asprintf or getline) Maybe we should write our own mr_strtok function which will do it correctly ? That's where perl is so efficient compared to C :-( I know I'm surely too picky (as usual) but memory management has been so strangely handled in mondo, that I would like to change that. OTOH, I still wonder whether we should write everything in C (when it's mainly string management, perl is really much better) Not to refrain you, but I think it's the right moment to consider that quite important point, and agree on it before going further. Waiting your opinion on this, Greetings Bruno. -- Des infos sur la musique ancienne -- http://www.musique-ancienne.org Des infos sur les logiciels libres -- http://www.HyPer-Linux.org Home, sweet musical Home -- Lover of Andromède, Béatrice, Early Music, Josquin, Linux, Mélisande, Recorder, and Ségolène (not in that order)
Bug#325877: Feedback Sought: RAID mdadm support for Mondo Rescue
Andree Leidenfrost said on Sat, May 06, 2006 at 10:40:28AM +1000: Sorry it has taken my longer than announce but here is finally my response: Hey no pb. You're generally quicker than what I can handle in term of charge and load, so great !! On Sun, 2006-04-30 at 22:41 +0200, Bruno Cornec wrote: There are limitations (pre-existing, not introduced by my changes): - chunk size is hard coded to 4k Onc my set of conf files work, please remind us to put that in it. As a side note, the system default if you don't specify anything is 64k. Ok so in the conf file, I'll need to put 64k by default + an example line to show that it can be changed to 4k e.g. Ok, I'll include multipath support than. It's already in parse_mdstat() and shouldn;t be too hard to add to the rest. Super :-) It could be part of a further version of course. Ok, no worries. Internationalisation sounds great by the way! Yes. It's now in stable (but not in tthe 2.0.8 I created. Marketing choice ;-) So a side remark, if you want to add messages, please look at how they are done now (in short we call the _ function before sending a msg. e.g. printf(_(Hello World\n)); And it will allow you to do the german .po file ;-) The person who did that work as already provided a fr.po. It would be great if you could let me know what you think, in particular whether you'd be sufficiently happy for this to go into the next stable version. So, I'd say, put it in stable *and if you have time 2.0.8 *and* trunck. I know, it's a bit too much, but my plans are to keep 2.0.8 as the stable version, potentially correcting some bugs on it for a 2.0.9, 2.0.10, but no evolution. Stable in the Debian sense of the word ;-) stable will become 2.2.0 with intl, conf files, and I hope /dev/mapper support. If I have time, and not too many things happen in the mean time, even truck could become 2.2.0, with on top a new memory management system !! You're testing first raidstart, and then assume that it's lvmv1 Erm, I'm testing for raidstart and in its absence use mdrun. I have not touches any lvm related bits, so if lvm1 is assumed than that's unchanged from before. (RAID and LVM are independent, no?) Heu yes. I tend to make a confusion between LVM v1/2 and Raid v1/mdadm. Sorry for that, my fault. I was thinking to systems that could mix Raid v1 (with raidtools) and Raid v2 (with mdadm). I'm not even sure it exists. But for compatibility purposes, a system could live and implement booth during time. Hey wait, I'm not even sure it can work. An idea on that ? Anyway It could be a further improvement as you suggest. I tend to want everything from start. I'm probably still too young ;-) If we store it in a conf file, that would have to be read by mindi, mondoarchive, mondorestore and init. Yes, that's the plan. I have begin to code the mindi conf file for the moment (easiest as it's done in shell and sourced in fact). But that content has also to be read by mondoarchive as it needs some parameters to work corectly (temporary path such as our /var/cache evolution). I'm not so sure for the restore part, as we already hhave a conf file for that, and everything should be there. So if things are currently missing, I'll have to add them. Can we maybe phase it in? I.e. could we use the 'look for raidtools2 programs and only use mdadm in their absence'-approach for now and revisit inclusion into the conf file later on? I suppose you meant look for raid1 and if not mdadm ? Yes I agree with you. Pragmatism is on your side ;-) (propably the german quality compared to the french idealism :-) me, slapping my forehead Of course, memory needs to be freed! Thanks a lot for pointing that out! I hope the updated attached version is correct in regards to that (please tell me if it's still not good!)... I need to be useful sometimes ;-) I think the new patch is just what we need. Please commit it asap as I promised to create the 2.0.8 version this week end, and as I won't be available next week for package production, it would be great if I could make it now. ...and it also inlcude the sync and wait and implements most of the missing bits. Perfect. Thanks again, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpKqykpgQ1JL.pgp Description: PGP signature
Bug#325877: Feedback Sought: New parse_mdstat() function for Mondo Rescue
Andree Leidenfrost said on Wed, May 03, 2006 at 07:29:25AM +1000: Thank you very much for your feedback about the first patch! I shall respond to it in detail including a fixed patch hopefully later today. Okidoki (as someone I know generaly said ;-) In the meantime please find attached a replacement for read_mdstat() called parse_mdstat() which is a complete reimplementation of the former that also adds support for the missing parameters (including multipath). I have tested it with various RAID combinations and run it under valgrind which says it's happy with. Valgrind is an excellent idea !! I planned that for trunk. It also includes an updated mondostructures.h with fields added to the RAID-related structures. I have not checked thus far whether there may be side effects caused by this. I do hope that not. You can commit this one without issue I think. Does it break compatibility with previously made archives somehow ? If yes, we need to take extreme care, and update the major number of mondo. If not, everything is nice. I'd also like that you commit your modif on my-stuff.h. This is a nice one ;-) Note that this is _only_ the routine to read mdstat. What is still outstanding is adding support for the new parameters to the code that writes and reads the raidtab file. I'll work on that next. Ok. If you could have a look and let me know what you think (and maybe run it on some systems that have RAID and check the output), that would be great! My general remark is that I'd like to avoid as much as possible static allocation for future evolutions of mondo. So using asprintf, and no more malloc_string, MAX_STR_LEN and the like. Do not worry for the moment, but I'd like to edit the patch in that sense before inclusion. Thanks for the work ! Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgppOn51GwucP.pgp Description: PGP signature
Bug#325877: Feedback Sought: RAID mdadm support for Mondo Rescue
Andree Leidenfrost said on Sat, Apr 29, 2006 at 05:32:55PM +1000: Please find attached a patch that implements mdadm support whilst fully retaining raidtools2 support. Many thanks for your work in this Andree ! With the changes detailed in the patch, I have just successfully archived and restored a RAID1 and a RAID0 array consisting of two drives each on Debian sid amd64, but I expect all Linux distribution with mdadm to work as well (famous last words ;-) ). Great ! After much going back and forth I have decided to extend what is already there rather than recode much of the RAID functionality. The reasons are mainly that I have only limited time and wanted results rather sooner than later but even more so that I didn't want to change the raidtools2 side of things because I can't/won't test this and I didn't want to spend any effort on raidtools2 because it's officially deprecated (cf. http://people.redhat.com/mingo/raidtools/). No problem. That's a wise decision I think. With this said, the patch utilises existing capabilities for parsing /proc/mdstat and for reading and writing /etc/raidtab. mdadm works without a config file and even 'mdadm --detail --scan --verbose' does not give all the (relevant) information that can be gathered from mdstat. I could have come up with a new file (format), but I think raidtab is fine (it shouldn't be in /etc really). I am introducing a new function create_raid_device_via_mdadm() that will create a single RAID array using mdadm and that gets called in format_device() in case mkraid cannot be found. Same goes for 'mdadm -S' versus raidstop. An equivalent for raidstart is not really required as 'mdadm --create' starts the array straight away. There are limitations (pre-existing, not introduced by my changes): - chunk size is hard coded to 4k Onc my set of conf files work, please remind us to put that in it. - spare devices are ignored - the parity algorithm is ignored - multipath is not supported Ok. To overcome these limitations, I will need to change some data structures and expand the mdstat parser - in fact, I have already written an experimental stand-alone parser for this purpose. I'm not sure whether multipath is worth it; it is not even really a RAID level. No, but it's extremely useful for HA solutions. So if it's not a big effort, I'd like to see it one day. Further, I had to include a few more modules for RAID in mindi and init needed a little change. No pb. I'll commit those changes right now, as they are obvious Finally, device mapper is not supported. I understand you are working on this, so I haven't looked into it. Well I'll work on it, when I'm done with all the other patches I have to integrate (internationalization !!! done by an old relative, and also Labeled swap fs). It won't be in 2.0.8, but in the next, I hope, which should be 2.2.0 It would be great if you could let me know what you think, in particular whether you'd be sufficiently happy for this to go into the next stable version. patch mindi: taken and applied. patch init: I have a question: You're testing first raidstart, and then assume that it's lvmv1 What about if both tools were installed ? Couldn't we get it more surely from another parameter ? Shouldn't we store it and pass it throught our conf file to init ? No problem, OTOH with the patch itself patch mondo-prep.c : when you use asprintf, the devices string is allocated. So before re-using it, you need to call paranoid_free on it. If not, we're creating memory leaks. In your case, you need 2 variables. Take an example in trunk to see how to deal with it. You also have the same problem with program. That's why it takes time to do that in trunk :-)) Maybe the sync could also be kept for mdadm ? Just to let time to the system to flush al the buffers. I would take the opportunity that you test mkraid vs mdadm to create an option somewhere that we could use in init. WDYT ? Greetings, Bruno. -- Linux Profession Lead EMEA / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpwR3nSTHgvx.pgp Description: PGP signature
Bug#357785: mondoarchive exits with fatal error :Can't loopmount /tmp/mindilinux/8087/mountpoint8087
Andree Leidenfrost said on Mon, Apr 03, 2006 at 09:37:16PM +1000: 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)? Yes you can commit it to stable and trunk. Please wait till my green light as I want to keep the same number that we have now (r460) to regenerate all the packages (should be finished today I hope). Then I will unfreeze again. Bruno. -- Linux Solution Consultant / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpnraEIu8nIo.pgp Description: PGP signature
Bug#357785: mondoarchive exits with fatal error :Can't loopmount /tmp/mindilinux/8087/mountpoint8087
mahashakti89 said on Sun, Mar 19, 2006 at 08:11:19PM +0100: Could you retry without the FAILSAFE option please ? Already done this morning before I decided to post a bug report. I tried it one more time = same result Ok, will leave it to Andree when he comes back from vacations then, as I know he worked in that erea before leaving, and this is IMO a problem due to the Debian env. rather than an upstream pb (At least I think). Bruno. -- Linux Solution Consultant / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- 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
Hello, [Main] mondo-cli.c-handle_incoming_parameters#270: -k FAILSAFE Could you retry without the FAILSAFE option please ? Bruno. -- Linux Solution Consultant / Open Source Evangelist \HP CI EMEA IET http://www.mondorescue.org / HP/Intel Solution Center \ http://hpintelco.net Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#315733: Debian BTS #315733: mondoarchive crash during backup to hdd
Hello, Andree Leidenfrost said on Tue, Feb 28, 2006 at 11:22:22PM +1100: So, creating the floppies implies mounting the floppy images which means we need vfat support in case syslinux is used. Is that also your opinion? Yes. If yes, what do you think would be the best place to put this in the doco? Do you think amending '3.6.2. Kernel Requirements' with the following would work: * vfat support in the running kernel for creating syslinux boot floppies (either module or built-in) Yes. You've done it correctly in r431. Bruno. -- Linux Solution Consultant / Open Source Evangelist \HP CI EMEA ISG HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpCl7XzL5HuB.pgp Description: PGP signature
Bug#352323: FW: Bug#352323: mondo: ---FATALERROR--- Pre-param initialization phase failed. Please review the error messages above, make the specified changes, then try again. Exiting...
Andree Leidenfrost said on Sun, Feb 12, 2006 at 07:16:35PM +1100: Btw. the code I use is taken from libmondo-archive.c where we check in the same fashion the outcome of calling 'mindi -custom ...'. What do you say? Ok. Apply it. And as usual if you could adapt with asprintf for trunk, that would be great. Bruno. -- Linux Solution Consultant / Open Source Evangelist \HP CI EMEA ISG HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgp502lkvoevO.pgp Description: PGP signature
Bug#351446: mindi: LVM failing
Andree Leidenfrost said on Sat, Feb 11, 2006 at 10:17:25PM +1100: Bruno: Everything in the path in Debian needs a manpage, so I can't really put analyze-my-lvm in /usr/sbin. For other distributions it might also be nice to have it in /usr/lib/mindi because it really is for mindi and mindi only, no need to put it in the path, it just adds clutter. Do you agree? Are you ok for me to commit the attached patch to SVN? I agree with your conslusions after re-reading it. Pleae apply the patch proposed. I'll adapt the .spec for RPMs afterwards. Bruno. -- Linux Solution Consultant / Open Source Evangelist \HP CI EMEA ISG HP/Intel Solution Center http://hpintelco.net Hewlett-Packard Grenoble/France Des infos sur Linux? http://www.HyPer-Linux.org http://www.hp.com/linux La musique ancienne? http://www.musique-ancienne.org http://www.medieval.org pgpPaU2gXyeRi.pgp Description: PGP signature
