[For the start of the part relevant for #292782, search for 'See my other message']
Hello Bruno, I hope you enjoy the singing! :-) On Sun, 2006-06-25 at 11:36 +0200, Bruno Cornec wrote: > 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 ? In Debian, there are the tags 'upstream' and 'fixed-upstream'. Also, the bug can be forwarded by sending an email to [EMAIL PROTECTED] (and the upstream email address of course). The bug stays in Debian BTS until it is explicitly maked as closed or done via the standard methodologies. The following page has some more background info: http://www.debian.org/Bugs/Developer#tags and http://www.debian.org/Bugs/Developer#forward So, in short, I can forward a bug to upstream but would only close it in Debian BTS once it is fixed in the Debian package either upstream or in the package directly. I guess this makes sense form a Debian perspective. It would be nice to be also to enter the bug into the upstream Mondo Rescue bug tracking system via email because of the above mechanism. > 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 ? Given that even NASA is using it, it should be good enough for us, I reckon. ;-) I don't particularly like the Berlios Wiki I must admit, I'm less fussed about the bug tracking in Berlios, especially because the numbers seem to be fairly low, but this may of course change. Do you believe the whole Mondo Rescue website could be turned into a tracwiki? This would essentially mean we would get all of the following out of using trac: - website (including download page pointing to ftp) - wiki - bug tracking - subversion repository Is this correct? To be honest, my only concern is how much effort this would take away from hacking on Mondo Rescue versus what benefits we'd be getting in other areas. If you think it worth it, I'm certainly fine. If there is anything you want me to do, just let me know, I'll be very happy to help. > > 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. See my other message regarding this topic. http://www.digital-sanyo.com/BURN-Proof/ has lots of details on BurnProof. As mentioned in the other message, I believe that DVD writers always have standardised buffer underrun protection built in. If you see BurnProof as a logo on your drive or as part of the specs, it's probably because it is also a CD writer, not just a DVD writer. (At least this is my understanding after skimming groups.google.com and the above site.) > > 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. Erm, not sure whether I understand you right here, it's probably just me being silly, anyway, here goes: The patch changes code within the 'if (archiving_to_media) {', so it will only come into effect if we are in archiving mode. I only added a distinction for 'dvd' so that the behaviour for 'cdr' and 'cdrw' is preserved. The code makes very similar distinctions for 'dvd' in relation to other aspects further down in the code. I have tested the above successfully on a laptop with writing DVDs directly (and writing ISOs for regression testing). However, I have only been able to test the archive part but not the restore part. I don't have a laptop with a DVD writer, I just took one from work on which I can't really do potentially destructive testing. Do you think a restore in qemu using the drive could/should work? I could try a restore this way, I guess. > Bruno. Cheers, Andree
signature.asc
Description: This is a digitally signed message part
