[03:28] <evand> cjwatson: Shouldn't bug 117889 be warned that they currently wont get very far in testing the fix, given the unionfs issues?
[03:39] <cjwatson> evand: good point, done
[03:57] <CIA-18> ubiquity: cjwatson * r2243 ubiquity/ (debian/changelog ubiquity/frontend/gtk_ui.py): * Translate widgets from all glade files, not just the main one.
[04:30] <cjwatson> evand: bug 137878 may be something you run across - one of those grotty 64-bit arithmetic bugs that permeates into all sorts of hard-to-debug weirdness. I found a maybe-duplicate of it today.
[04:31] <evand> Indeed, I did notice it and spent a few minutes thinking, "wasn't this already fixed before with the exact same patch?"
[04:32] <evand> thanks for the heads up though
[04:32] <cjwatson> there was a similar bug in resizing which may be what you're thinking of
[04:32] <evand> probably
[04:32] <cjwatson> and indeed a very similar approach, replace shell arithmetic with expr
[04:32] <cjwatson> I'm beginning to think it might be easier to just dive in and fix dash, mind you
[04:35] <evand> haha, it'd be easier than having the issue crop up in odd bugs from time to time.  I can't guess at how hard it would be to fix the shell arithmetic though.
[04:35] <evand> too early apparently, that's just rewording what you just said
[04:35] <cjwatson> I don't remember but I suspect I looked before fixing it the first time. Probably horribly tedious
[04:36] <cjwatson> dash is somewhat ancestrally related to busybox sh I think, but we'd have to go through and sort out integer length throughout and ugh
[04:36] <cjwatson> busybox sh used to have the same problem and so partman was at one point fixed to avoid relying on 64-bit arithmetic
[04:37] <cjwatson> but a few things have crept back in
[06:52] <evand> cjwatson: you did do the rosetta update the other day, I don't need to remind you anymore, right?
[06:52] <cjwatson> yeah
[06:52] <evand> ok
[06:52] <cjwatson> it just needs a bit of back-and-forth through the system
[09:50] <evand> cjwatson: Is not copying /var/log/installer/debug to the target filesystem a design decision or just an oversight?
[10:02] <cjwatson> evand: partly an oversight, though I think I was a bit leery about how it contains the user's password if they're running in debug mode
[10:04] <evand> well, it would be 0600, but if you're leery then I don't see a major problem with keeping it as it is.
[10:13] <cjwatson> I just have bad memories of the breezy installer vulnerability that make me nervous about that sort of thing
[10:13] <evand> indeed, that's what I figured the reasoning behind it was
[10:13] <cjwatson> perhaps grep -v password or similar (that won't work, but in that spirit)? something to sanitise the debconf debugging that mentions the user's password
[10:13] <cjwatson> I can see how the information would be useful
[10:13] <evand> hrm
[10:14] <cjwatson> I did try to make debconf hide this itself but unfortunately the debugging is at a level where the code required is horrible
[10:14] <cjwatson> the code is in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357118 if you want to look
[10:15] <cjwatson> I kind of see joeyh's point though
[10:15] <evand> will do
[10:20] <evand> hrm
[10:22] <evand> I suppose it's ugly (it didn't look that bad to me, but I'm not intimate with that code, obviously), but it's cleaner than trying to remove the password after the fact in install.py.  Is Joey suggesting we strip the sensitive information in code, or that the user should know to?  I'm not big on arguments based on the latter.
[10:23] <evand> though we'd be out of luck if we ever actually did need the password
[10:24] <evand> wait nevermind, I'm completely neglecting the actual database
[10:25] <evand> meh, I'm happy to implement whatever you deem is reasonable, or leave it is if you feel the benefits don't outweigh the costs.