[00:16] <YokoZar> Does bzr 4.2.2 fix this crash over 4.2.0 (currently live on launchpad build daemons): https://launchpadlibrarian.net/89179259/buildlog.txt.gz (bzr: ERROR: exceptions.AttributeError: 'cStringIO.StringI' object has no attribute 'split')
[00:17] <YokoZar> *2.4.2 over 2.4.0
[07:58] <vila> hi all
[07:59] <vila> hmm, so, lifeless, regarding pqm, when you say 'pqm uses a temp dir to do the work' do you mean the merge happens in a branch that is created from scratch (but still use some shared repo I presume ?) ?
[08:01] <lifeless> yes, and no
[08:01] <lifeless> yes new branch cloned from the target (which is on local disk in the bzr config)
[08:01] <lifeless> there is no shared repo
[08:01] <vila> ok
[08:01] <lifeless> (And can't sensibly be, because the tests run in a chroot
[08:02] <vila> does this temp branch use a predictable path ?
[08:02] <lifeless> either the test executing wouldn't have access to the repo, or we couldn't trust the repo for the next test run
[08:02] <lifeless> vila: yes, it is.
[08:02] <vila> wgz: ^ here we go, so the settings should go in locations.conf
[08:03] <vila> lifeless: thanks, do you happen to remember which path is used ?
[08:03] <lifeless> or make them inherit from branch.conf when a new branch is cloned
[08:03] <lifeless> uhm, it will be the wordir + -- + the branch name, I think.
[08:03] <vila> yeah :-/
[08:03] <lifeless> however
[08:03] <lifeless> you don't need the exact path
[08:03] <vila> but we have no mechanism to propagate settings from branch to branch
[08:03] <lifeless> just set it to / ?
[08:04] <vila> it is different for 2.5/2.4 etc
[08:04] <lifeless> why?
[08:05] <lifeless> can you not just list all the news files and it will do the magic on whichever ones are there
[08:05] <vila> we can set the news_merge_files list to bzr-2.5.txt, bzr-2.4.txt and so on so it will take the first one that exists in the branch
[08:05] <vila> :)
[08:05] <lifeless> it should take them all surely
[08:05] <lifeless> projects may have more than one file
[08:06] <vila> should work
[08:07] <vila> so, summarizing, the merge happens inside the chroot so the chroot locations.conf is where the settings should go, correct ?
[08:07] <lifeless> no
[08:07] <lifeless> the merge is done by pqm, the tests run in the chroot
[08:08] <lifeless> the path that the merge is done in is within what will be chrooted
[08:08] <vila> ha, so host locations.conf
[08:08] <lifeless> yup
[08:08] <lifeless> its a fairly paranoid system
[08:09] <vila> is it: merge in host/tests in chroot/commit in host or merge in host/commit in host/tests in chroot ?
[08:09] <lifeless> the former
[08:10] <lifeless> gpg key for signing is in the host, not the chroot.
[08:10] <vila> pfew, finally, I think I get it now
[08:10] <lifeless> it is
[08:10] <lifeless> trusted code in host, untrusted code in chroot
[08:10] <vila> yeah, it's always clearer once you understand ;)
[09:03] <vila> wgz: around ?
[09:29] <mgz> morning all
[09:29] <vila> heya mgz !
[09:30] <vila> You may want to read the logs here to get more understanding of the news_merge issues
[09:33] <mgz> thanks
[09:49] <vila> ARGH, http://forums.crucial.com/t5/Solid-State-Drives-SSD/0x00000f4-error-on-M4-64GB/td-p/76392/page/16 discovered less than 2 hours ago seems to kill my SSD just *now* :-( :-(
[09:50] <vila> screen turned black :-(
[10:16] <mgz> any better vila? that ssd bug sounds fun.
[10:16]  * vila backups like mad, hopefully the 1 hour window will allow...
[10:17] <vila> after that I'll try to re-install on a different /
[10:18] <vila> with a bit of luck I won't have to unplug it if it's not the boot disk anymore
[10:20] <vila> alternatively I can migrate my home dir to my laptop and install some alternate mail handling setup and I'll be good for at least next week
[10:21] <vila> dang it, when I read the report this morning I saw I was at 216.8 days and hoped I would be immune...
[10:22] <vila> in one sense I'm lucky it happens now instead of next week...
[10:23] <vila> home backup successful, ticked
[10:24] <vila> 30 minutes left, what's next ?
[10:45] <vila> attempting backup to laptop while the clock is tickling (20 mins to go)
[10:45] <fullermd> Why not just reset the clock back?  Makes it way easier...
[10:46] <mgz> fullermd always manipulates time :)
[10:47] <fullermd> Yeah, cesium is my bitch.
[10:55] <vila> bam, just at the th 1 hour mark :-(
[10:57] <vila> and screen goes to black a couple of minutes after, definitely the same symptoms :-( :-(
[11:07] <mgz> vila: babune is down?
[11:07] <vila> oh yes :(
[11:08] <vila> that's where it's running
[11:08] <vila> well, usually :)
[11:16] <fullermd> Funny.  After all those years of laughing at and then igoring people who kept saying that MLC's very limited erase cycles would never be a problem in practice, it turns out they were absolutely right.
[11:16] <fullermd> Any SSD is going to have such completely broken firmware/controller that it craps itself long before the flash wears out.
[11:17] <vila> hehe
[11:17] <vila> recovery plans needs to be practiced to be effective...
[11:18] <vila> that's the only way to know they work
[11:18] <mgz> clearly the fail_after_warrenty_expires() function in the firmware had a date bug
[11:33] <vila> the amazing part is that I didn't buy it *just* when it was released but more something like several months after that so many more people should have encounter the issue before *me* :)
[11:33] <vila> this probably means they use theirs on machines that don't stay up 24/7...
[11:36] <fullermd> What a bunch of wimps.
[11:50] <mgz> vila: so, on the news merge side
[11:50] <mgz> do you know where the inside-the-chroot branches are?
[11:51] <vila> no
[11:51] <mgz> because I'm not clear from the log what those paths are, the branches we were looking at yesterday were the permanent ones
[11:51] <mgz> okay, so we need to find that out, then we can explain to gnuoy and try again?
[11:51] <vila> lifeless said the merge occurs on the host in the branch where the chroot will find it
[12:00] <mgz> I'm not sure how we know what the right values to put in location.conf are though
[12:00] <mgz> or how to find out.
[12:00] <vila> as long as you specify a directory *above* all of them and specify *all* news files, we should be fine
[12:01] <mgz> ah, okay, so that's a change of thingy
[12:01] <vila> yeah, my first proposal was conservative but a broader one should work as well
[12:01] <mgz> perhaps update the rt with new guidance?
[12:27] <vila> mgz: will do (in the middle of reinstalling so half-working setup on *this* desktop too)
[12:28] <vila> mgz: what's the rt number ?
[12:30]  * vila shudders
[12:31] <mgz> right, after you're all sorted :)
[12:31] <vila> it seems that even without booting from it, the ssd (m4 crucial 256 GB, let's advertise ;) bricks the desktop after 1 hour
[12:31] <mgz> the... rt# doesn't seem to be in the email
[12:31] <vila> 51... something, it shoudl
[12:32] <mgz> rt #50151
[12:32] <vila> hehe, just found it by searching my mail *files* (don't want to start my MUA for now)
[12:33] <vila> crap, can't boot anymore :-(
[12:33] <mgz> :(
[12:34] <vila> back to bios ...
[12:35] <vila> can't enter bios setup ???
[12:39] <vila> weird, settings have changed their (third reboot was the charm to enter bios setup)
[12:39] <vila> something related to disk order... could be related to the ssd being awol during boot... may be
[12:39] <vila> booting now, pfew
[12:45] <vila> right, disk order have changed indeed, lucky me for using the LABEL trick on all my disks I can keep track of the /dev/sdx used
[12:54] <vila> mgz: updated
[12:57] <mgz> cool.
[14:42] <mgz> jelmer's going hooking mad
[14:43] <mgz> I still sorta-want a repository open hook, but I'm not sure anyone else would have a need for it.
[14:43] <fullermd> Yeah, he seems a little hooked up.
[14:44] <mgz> we might even call him captain hook.
[14:55] <jelmer> ouch, that are some bad puns right there
[14:58]  * vila loves hooks
[14:58] <fullermd> Knew that would hook you in.
[14:59] <fullermd> Anyway, there are no bad puns, only bad people.
[14:59] <vila> I just put  one on my wall with a little 'crucial' note on it
[15:00] <fullermd> Solid plan.
[15:06] <jelmer> thanks for the review mgz
[15:08] <jelmer> we should now handle quilt patches much more cleanly if bzr-builddeb is installed
[15:39] <vila> for those following the m4 crucial saga, booting from another hard drive works, the ssd still goes AWOL one hour after reboot though
[15:40] <vila> ... and crucial announced a fw update for 2012-01-16
[15:41]  * vila notes: next time, shut down for 3 more weeks so we get the fw update *before* the crash 
[15:45] <mgz> what machine is this in exactly vila?
[15:45] <mgz> not your fancy air thing?
[15:45] <vila> nope
[15:45] <mgz> so, won't matter for next week anyway
[15:45] <vila> my main dev desktop where babune runs
[15:45] <vila> well, that's where I handle mail too, both fetching and sending
[15:45] <mgz> email holiday!
[15:46] <vila> hehe
[15:47] <vila> I'm blindly re-installing the ~1000 packages that the default install didn't provide...
[15:47] <vila> ... I wonder if using an SSD there will be faster... err wait
[15:55] <mgz> jelmer: any ideas on report from buildd issue previously: http://paste.ubuntu.com/794972
[15:59] <vila> jelmer: seen the debian bug  about pristine-tar for kde tarballs being closed  ?
[16:00] <mgz> yeah, I did a quiet woho when I saw that in bug mail this morning.
[16:01] <mgz> André seems to have a talent for finding weird errors, the last .bzr.log he posted makes no sense to me at all,
[16:01] <vila> can't remember which version we run on jubany...
[16:01] <mgz> can't tell if all the bzr-svn errors are relevent or not.
[16:01] <vila> bug # ?
[16:01] <vila> (still no mail here)
[16:02] <mgz> bug 814408 comment 5
[16:03] <mgz> but he ends up with a totally borked tree and dirstate file somehow
[16:11] <vila> package install finished, let's see what blows up on reboot...
[16:14] <vila> can't reboot :)
[16:15] <fullermd> Hey, that means nothing blows up.  Awesome!
[16:16] <vila> ..unless I power-off, so the trick is that the ssd requires a power off, but then, the bios lose it's boot disk order, fun :)
[16:19] <fullermd> Gaah.  And so it took me a good minute to figure out why 'bzr diff' wasn't working in a mtn tree...
[16:19] <vila> teach you to use the right tools ;)
[16:20] <fullermd> The right tool as near as I can figure, is "strong-arm Samba into moving into mtn, so that jelmer writes bzr-mtn"   :p
[16:28] <vila> hehe
[16:28] <vila> pfew, desktop works again, now for all the rest
[17:00] <jelmer> mgz: sorry, was away for a bit
[17:00] <jelmer> mgz: that's still waiting for python-debian to be deployed on the buildds
[17:00] <jelmer> vila: no, I didn't - why?
[17:00] <jelmer> (why did they close it?)
[17:02] <vila> jelmer: apparently they fixed it
[17:02] <mgz> ...ah, it's a pre-python-debian changelog module? I'd expect everything to be broken then.
[17:02] <mgz> or do other callsites pass str or something?
[17:03] <vila> jelmer: i.e. a newer pristine-tar should now be able to import the kde tarballs produced on suse
[17:03] <mgz> I think Joey Hess introduced a binary diff fallback as is used for gzip
[17:04] <mgz> I didn't look at the change in detail though
[17:11] <jelmer> mgz: other callsites pass str
[17:11] <jelmer> mgz: ah, cool
[17:20] <vila> damn, 1 hour is short :-/
[18:10] <fbond> So ... the PHP PECL code repository looks like one big shared SVN repo used by all projects.
[18:10] <fbond> Branching from it with bzr-svn is taking an extremely long time because it is caching all the revisions.
[18:11] <fbond> Is there any way to make it only download the revisions that actually affect the project I'm after?
[18:43] <jelmer> fbond: hi
[18:44] <jelmer> fbond: you can disable the cache completely
[18:44] <fbond> jelmer: Hello.
[18:44] <jelmer> fbond: set 'use-cache = False' ~/.bazaar/subversion.conf
[18:44] <fbond> jelmer: Okay, thanks!
[18:46] <fbond> jelmer: Much better.