[04:56] <kate`> can i bzr merge multiple things simultaneously, or must i merge one, commit, and then merge the next?
[06:17] <fullermd_> kate`: You _can_.  Rarely a good reason for it though, IMO.
[06:26] <kate`> fullermd_, in this case i started development with three independent repositories, in parallel. they're all of equal status; i want to move them all to the same repository (and discard their origional repositories)
[06:27] <kate`> so i thought it'd make sense to merge them all simultaneously if i can, because there's no reason i'd order one over the other two
[06:27] <kate`> they all contain independent files, too. no paths in common
[06:29] <kate`> ah. i see --force mentioned in 'help merge'
[06:29] <kate`> what an ominous name
[06:31] <fullermd_> It used to be called --brute-force, but we decided to reserve that for the rumored "every-which-way" merge.
[06:31] <kate`> it's really "even though i have uncommitted changes", isn't it?
[06:32] <fullermd_> Just so.
[06:34] <spiv> It's not a great option name, but it's familiar from some other tools like dpkg.
[06:35] <spiv> Or even coreutils like rm, I suppose.
[06:35] <kate`> personally i'm terrible at naming things
[06:35] <kate`> i had a desktop with the hostname "what" at one company :/
[06:35] <kate`> "can i get to what?"
[06:35] <kate`> imagine the confusion
[06:36] <spiv> "You want me to connect to what?"
[06:36] <spiv> I can imagine :)
[06:36] <kate`> "what's down" <- this never happened, but i wanted it to :)
[06:37] <spiv> There's always "what's up"
[06:37] <kate`> "nothing!"   What's in a second.
[06:40] <kate`> i've 20 or so svn repositories i'm converting to bzr. some of them have (or rather would have, if svn could express it) pretty complex histories
[06:41] <kate`> so i'm converting them by cutting them apart, and splicing them back together with manually-inserted branches and merges and things, which is what i would have done at the time, but couldn't
[06:41] <kate`> that way i'll have a history which actually shows what i was intending, rather than just one linear changelog with unrelated things interspersed
[06:41] <kate`> it's very tedious doing this, but it'll make me a happy bunny
[06:43] <kate`> for a few i reorganised the top-level layout occasionally, and (as in the case i just mentioned with the three seperate repositories being joined), various other things automated tools don't understand
[06:54] <kate`> ok. so i'm confused. if i have a repository which contains /a, and another which contains /b, i would expect that i can merge both to a checkout of another copy (which itself has neither /a nor /b)
[06:54] <kate`> but issuing those two seperate merges, i'm told i have conflicts for paths under /a, when i merge in b's repository
[06:54] <kate`> how can that be?
[06:55] <kate`> if i checkout b's repository and look through the log, it only contains stuff under /b
[07:38] <LarstiQ> kate`: might conflict on the root, that is, / being in a different location?
[07:44] <kate`> hm. i don't understand that; how can / be in a different location?
[07:45] <spiv> kate`: like any other file/dir, it is possible to rename, and bzr will track that.  Not sure that'
[07:45] <spiv> s the case here though; if you're able to pastebin a couple of lines of the conflict details it might help diagnose.
[07:51] <kate`> let me see if i can do that in an understandable manner...
[07:53] <kate`> http://codepad.org/v6n152NN
[07:54] <kate`> lx.bzr contains /lx and all commits are under that path. -r2 is just mkdir for /lx
[07:54] <kate`> main.bzr has never had /lx at any point in its history
[07:55] <kate`> i don't understand what these conflict messages are telling me
[07:58] <kate`> lx.bzr was also created by svn-import
[07:58] <kate`> although with --layout=none, unlike main.bzr
[08:04] <kate`> huh. the range for -rx..y is inclusive, right?
[08:05] <kate`> geez. if i make that -r0..4 then "All changes applied successfully.". but 0 is an empty commit!
[08:18] <fullermd_> 0..X is what you want for bringing together unrelated histories, since you want to merge everything from nothing to now.
[08:26] <kate`> well r0 looks to be a completely empty commit, i think as a side effect of the filtering i did with svn... so i was trying to elide that
[08:35] <fullermd_> No, that's expected.    So asking for "merge -r0..1" means "merge the change from state 0 (nothing) to state 1 (first commit).
[08:37] <kate`> that makes sense
[08:37] <fullermd_> So 0..4 is "everything from start to rev4"
[08:38] <fullermd_> Ditto for "diff -r0..1" etc.
[08:39] <fullermd_> We all kinda fudge things when it comes to 'log' of course, since in your log for rev X you're really describing the change from (X-1) to X rather than the state X which is what you're actually recording, but...
[08:39] <fullermd_> At least, everyone I've ever known does.  Otherwise, by rev 1000 or so your log message is gonna be _really_ long  ;>
[08:40] <kate`> you know, if there's one thing i consistently get wrong with programing - in any language - it's off-by-one errors when i'm thinking about sets of items, iterating through them, and what i consider an item or the distance between items
[08:41] <kate`> (i'm not talking about 0-indexed versus 1-indexed arrays)
[08:42] <fullermd_> Everybody does  :)
[08:42] <kate`> like for example if i'm implementing binary search, and i need to consider the middle element of a range. i find that sort of thing super difficult
[08:42] <fullermd_> That's why you write scripts to help you debug, that just load up your program and add a "-1" to a random line to see if it helps.
[08:43] <kate`> do you do that? i tend to assert everything is in the range i expect it to be
[08:43] <fullermd_> Or just stick random values in $[
[08:43] <fullermd_> But that really annoys people.
[08:44] <fullermd_> Not really.  But I've thought about it.  Mostly avoided it because I was afraid it would sooner or later _work_, and that would just drive me insane.
[08:47] <kate`> i prefer some sort of illusion of a scientific approach...
[08:48] <kate`> okay. here's the origional conflict problem i mentioned, which is confusing me still: http://codepad.org/cT2Rffdt
[08:48] <fullermd_> That's why I imagine that the gnomes that sneak in during the night and break my code are wearing labcoats.
[08:48] <kate`> there you can see i merge in libre.bzr, commit it, and merge in lx.bzr
[08:49] <kate`> libre.bzr only contains paths starting with /libre in its history, and lx.bzr only contains paths starting /lx
[08:49] <fullermd_> lx.br sure looks like it's touching all kinda of stuff in libre.
[08:50] <kate`> yeah, it does. but it's not!
[08:51] <fullermd_> The mods in the files suggest bzr thinks they're related files.  The path conflict suggests an unrelated file with the same name.
[08:52]  * kate` increases in confusion
[08:52] <fullermd_> My work here is done   8-}
[08:53] <kate`> can i show you a screenshot?
[08:53] <kate`> this is really silly
[08:53] <fullermd_> What's the provenance of the xyz.bzr's; are those from a svn conversion too?
[08:53] <kate`> they are, yes
[08:54] <kate`> they come from the same repository, actually. but svndumpfiltered to just include that path
[08:54] <fullermd_> So, there's apparently only 4 revs in lx.bzr (at least, only 4 you care about here), so I'd start looking there.
[08:54] <kate`> oh so i bet the repository's UUID is carried over...
[08:55] <fullermd_> UUID won't matter to bzr (in this meaning anyway)
[08:56] <fullermd_> The important thing to bzr will be the revs themselves, and since you're forcing the range from 0 that's probably not at the forefront.  What will be is fileids.
[08:56] <kate`> this is the log for lx.bzr, which i just checked out so i can 'bzr explore' it: http://dioptre.org/tmp/lx-bzr.png
[08:56] <fullermd_> But, start with revs, just to be sure.  See what, if any, is common between libre and lx
[08:56] <kate`> revision '1' there is the empty revision i mentioned. no message, and no tree
[08:57] <kate`> so i think i want to merge from -r1:4 (i don't want revisions 5 onwards)
[08:57] <fullermd_> (e.g., "cd libre.bzr ; bzr missing /where/ever/lx.bzr")
[08:57] <kate`> hm ok
[08:58] <fullermd_> If bzr really thinks they're unrelated (which I wouldn't unsuspect, but might as well be sure) both lists will start from rev 1 onward.
[08:58] <fullermd_> And if that's the case, you've probably got fileids lining up somewhere you don't expect.
[08:58] <kate`> is a fileid a hash?
[08:59] <fullermd_> No, pseudorandom uuid.
[08:59] <kate`> hmmm
[09:00] <fullermd_> But the svn conversion complicates (or simplifies) things in that it'll try to take hints from svn about what files may be the same.
[09:00] <fullermd_> Which means a heuristic, which is such a nice polysyllabic word for "wrong".
[09:01] <fullermd_> Anyway.
[09:01] <fullermd_> Looking at something like "log -v --show-ids -r0..4" for lx might give some hints, as may poking around 'ls --show-ids' in the current of libre.
[09:02] <fullermd_> It seems at a glance the fruitful course would be poking around those two and ignoring trunk (though that could be wrong, and it could be a trunk/lx conflict, but it _seems_ like libre/lx)
[09:06] <kate`> should these two suspiciously hashy looking numbers be identical? http://codepad.org/YPWcS047
[09:07] <kate`> that's the UUID from my svn dump
[09:10] <fullermd_> That could be the way bzr-svn synthesizes fileids on import.
[09:10] <fullermd_> Once in bzr-land, it's not a svn rev or uuid or path anymore though, it's just an opaque string.
[09:10] <fullermd_> So those two are different.
[09:11] <kate`> hm. so the :%2Flx at the end is part of the string?
[09:11] <fullermd_> But look for that lx'd id across all the revs in lx.
[09:11] <fullermd_> Yes.
[09:12] <fullermd_> bzr's standard generation ends up looking something like "basename-datestamp-randombits".  The svn conversion looks like rev@uuid:path.  But either way, it's functionally opaque; just a pile of bytes to identify it.
[09:13] <kate`> ok, cool. so all the fileids for 'bzr log -v --show-ids -r1..4' for lx.bzr are dinstinct from libre.bzr's fileids
[09:13] <kate`> now i'm wondering about revision-ids
[09:15] <kate`> ...and the revision-ids are of the form svn-v4:UUID:rev where rev is the svn revision
[09:15] <kate`> so... both lx.bzr and libre.bzr contain the same revision-ids. i think these should be distinct, right?
[09:15] <fullermd_> That seems odd.  the lx merge is modifying libre/src/Makefile and libre/src/cli/main.c etc, so it apparently has some file that matches that file-id.
[09:16] <fullermd_> Well, they are; if they weren't, there'd be nothing to merge.
[09:16] <kate`> right. i think merge is confused because the revision-id for the incoming lx changeset is the same as the revision-id as one of libre.bzr's changesets
[09:16] <kate`> so the conflict is mistakenly looking at the wrong one...
[09:16] <kate`> i think
[09:17] <fullermd_> That wouldn't be confusing, that would be "nothing to do".
[09:17] <kate`> hm
[09:17] <fullermd_> Check the missing output; if the revid's are the same, those revs wouldn't be in it.
[09:18] <kate`> well i'm just looking at log --show-ids, and i can see revision-id there
[09:19] <kate`> okay. well my best hypothesis so far is that the UUID being the same is causing some problem *somehow*, and i can test that easily enough by substuting different UUIDs for each of my dumps
[09:19]  * kate` does so
[09:19] <fullermd_> If you've got two revs that really have the same revid, and different contents, then you've got corrupted data.
[09:19] <kate`> revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::2
[09:19] <kate`> revision-id: svn-v4:aadcad11-ff25-de11-bfba-00163e66cb13::1
[09:19] <kate`> that's how they look
[09:20] <kate`> (for both lx.bzr and libre.bzr)
[09:20] <fullermd_> If you made two different svn dumps with the same uuid and different contents, that would be one way to get things all squirreled up.
[09:20] <kate`> right. that's what i've done
[09:20]  * kate` unsquirrels them
[09:20] <fullermd_> (it is of course Obviously(tm) a bug that bzr would do something as foolish as trust svn, but there ya go...)
[09:22] <kate`> i think a --ignore-uuids option to svn-import wouldn't go amiss
[09:24] <kate`> the use-case is for when somebody has filtered a single svn dump into several distinct streams, and wishes to import each of those
[09:25] <kate`> HAH!
[09:25] <kate`> it works :D
[09:26] <kate`> i modified the UUIDs in each of the streams i use to create lx.bzr and libre.lx, so that they're distinct
[09:28]  * fullermd_ takes the credit.
[09:29]  * kate` beams
[09:29]  * mgz ducks
[09:29] <mgz> careful with those beams!
[09:29] <kate`> ducks are probably more harmful
[09:29] <fullermd_> Hey, worry about your own mote before concerning yourself with... wait...
[10:27] <kate`> ok. so now i'm 'svn-import'ing another dump which i'd like to continue linearly in my bzr repository's history, just as if i commit things by hand
[10:27] <kate`> i think i checked before, but i'm still not sure. can i svn-import into a repository which already has some commits?
[10:28] <kate`> do my svn revision numbers matter?
[10:32] <jelmer> kate`: just reading up on backlog...
[10:33] <jelmer> if you modified the UUID in a svn repository to have the same UUID as another svn repository that doesn't have the exact same contents, you're very likely to break bzr-svn (if not now, then you'll hit bumps at some point in the future)
[10:33] <jelmer> kate`: svn-import can importing into a repository that already has commits
[10:34] <jelmer> kate`: do svn revision numbers matter for what specifically?
[10:34] <kate`> jelmer, this is a one-way conversion of an svn repository which i want to be store henceforth canonically in bzr - so i think the UUID doesn't matter
[10:35] <kate`> ok. well svn-import of a svn dump which has changesets that mv around a few files (these files are already present in my bzr repository): bzr: ERROR: subvertpy.SubversionException: ('Relative source revision -1 is not available in current repository', 160006)
[10:36] <jelmer> kate`: the UUID does matter - bzr-svn will assume that two svn repositories with the same UUID have the same contents
[10:36] <jelmer> kate`: and it relies on this; the error you just saw is very likely caused by modification of the repository UUID
[10:36] <kate`> right. i modified my UUIDs to make them distinct
[10:36] <jelmer> ah, if you made them distinct it shouldn't be an issue..
[10:37] <kate`> hm. so i want that new incoming dump to have the same UUID as my bzr repository, perhaps
[10:37] <kate`> possibly maybe
[10:43] <kate`> hm no. the UUID doesn't seem to relate to that Relative source revision -1 error
[10:44] <kate`> i think that might be due to my dump referring to a previous revision which is not present, because i filtered it out
[10:44]  * kate` investigates
[10:46] <kate`> ah. i bet it's the Node-copyfrom-rev: references
[10:46] <kate`> i could just recreate these particular commits by hand, i suppose
[10:52] <jelmer> kate`: you also might want to import this into a svn repository rather than calling bzr svn-import on it directly
[10:53] <kate`> hm. and then how would i get those commits to my bzr repository?
[10:55] <jelmer> kate`: bzr svn-import works on svn repositories fine too
[10:56] <jelmer> kate`: in fact, if you give it a svn dumpfile, it will create a svn repository first, and then import from that svn repository
[10:56] <kate`> ok. but as far as i can see that would import from the very first revision --until something, right?
[10:56] <jelmer> kate`: yes, but it will skip any revisions already present in the bzr repository
[10:56] <jelmer> kate`: the behaviour (and code paths involved) are exactly the same as with a svn dump file
[10:57] <kate`> ooh. that's the bit i didn't know :)
[10:57] <kate`> the skipping part, that is


[00:00]  * cody-somerville nods.
[00:00] <cjwatson> lool: merged, thanks; I'm too tired to do a manual run now, cron can do it
[00:00] <cjwatson> cody-somerville: basically the Debian Live guys worked on casper for a while and made some efforts to contact us, but at the time we were going through various reorganisations and nobody responded to them for a while, so they got (not entirely unjustifiably) pissed off and renamed
[00:01] <cjwatson> cody-somerville: then we made some efforts to merge but they had decided that they were taking over upstream now
[00:02] <cjwatson> cody-somerville: so TBH I think the sanest approach is to cherry-pick fixes that make sense, but casper is important to us and I don't particularly want to bin our history in favour of Debian's
[00:02] <cjwatson> cody-somerville: in general, most of our live CD infrastructure predates Debian's
[00:04] <cody-somerville> What do you mean by bin our history? Do you mean we keep casper around for sentimental reasons?
[00:10] <cody-somerville> It seems unfortunate they ended up diverging
[00:11] <cjwatson> no, I mean we keep it around because we have a number of changes in it that are actually kind of important :P
[00:11] <cjwatson> it is in general more important not to introduce regressions than it is to invest lots of effort syncing up with a renamed package in Debian
[00:11] <cjwatson> they've gone their own way and that's fine
[00:12] <cjwatson> the platform team does not have an interest in pedalling hard to stand still
[00:19] <cjwatson> you've asked quite a number of these questions: "why do we use <foo> rather than <bar>". The answer in general is that <foo> was there first, and when <bar> came along it was not sufficiently compelling for us to invest effort into switching to it when what we already had was perfectly serviceable
[00:19] <cjwatson> and in particular when <foo> was an in-house development there was generally no problem with understanding it well enough to maintain it
[00:29]  * cody-somerville nods.
[01:02] <Giotrader> hi
[01:02] <Giotrader> allo
[01:02] <Giotrader> help install?
[01:02] <Giotrader> I have a RAID 0 and 2 IDE drives, Ubuntu alternate CD only see 1 IDE drives and gives me an error message when trying to partition the RAID 0
[01:08] <cjwatson> if the installer only sees one of two IDE disk drives, then my usual guess is that that is a kernel problem and you need to ask the kernel guys
[01:10] <Giotrader> ok
[01:15] <Giotrader> well I can't see the cache memory of the missing drive
[01:15] <Giotrader> I think i destroyed that 8 MB cache part when formatting with Partition Magic
[01:17] <cjwatson> is the actual disk device missing, or just the partitions on it?
[01:18] <Giotrader> no I can see it with partition magic
[01:18] <Giotrader> it's juste that usually you see your drive and a small 8 mb cache part aside
[01:18] <Giotrader> the 8 mb part is gone
[01:19] <cjwatson> I mean missing from the point of view of Linux
[01:19] <Giotrader> like you know the "unallocated space" usually 8mb is the cache drive
[01:20] <cjwatson> I need to know whether Linux can see the disk device
[01:20] <Giotrader> no it can't
[01:20] <cjwatson> specifically that, as opposed to the partitions on it
[01:20] <Giotrader> doesn't see the disk at all
[01:21] <cjwatson> ok, definitely sounds like a kernel problem then
[01:21] <cjwatson> if the installer can't see the device there's nothing it can do itself; it's up to lower layers to expose that properly
[01:22] <Giotrader> Ok I will recreate the 8 MB unallocated space at the beginnign of the drive and see if it will fix it
[01:22] <Giotrader> because you know a hard drive today always comes with a sort of unallocated space called the cache
[01:22] <Giotrader> and I think that the fact that i destroyed it causes ubuntu not to see the drive
[01:22] <cjwatson> never seen that
[01:23] <cjwatson> IMO such things should not be visible in partitioners, but what do I know
[01:23] <Giotrader> ok i'll try that and i'll get back to you :)
[01:25] <Giotrader> ok I think it has nothing to do with the cache
[01:25] <Giotrader> you're right
[01:26] <Giotrader> the 8 MB unallocated space gets created by default when you do a logical parition
[01:26] <Giotrader> I had 2 primary partition ont he drive i guess that's why linux don't see it
[01:27] <Giotrader> you think it's work to format in ext3?
[01:27] <cjwatson> I think you're reading too much into this
[01:27] <Giotrader> it's worth I meant
[01:27] <cjwatson> unallocated space is not actually "created"
[01:27] <cjwatson> partitioners may show you it, but it doesn't have an existence in the partition table
[01:27] <cjwatson> it's just an absence of partitions
[01:27] <Giotrader> euh yes that's what I meant
[01:28] <Giotrader> it's a hole
[01:28] <Giotrader> empty
[01:28] <cjwatson> it's not something you can create or destroy
[01:28] <cjwatson> two primary partitions should not cause Linux any problem at all
[01:28] <Giotrader> damn
[01:28] <cjwatson> Giotrader: this is why I am trying to clarify this question: can Linux see the physical disk device? That is, does /dev/sdb (or whatever) exist?
[01:29] <cjwatson> Giotrader: if /dev/sdb (or whatever the appropriate disk device name is) exists, then it is possible that the partition table is something that the installer can't understand. If it doesn't, then the problem can't have anything to do with the contents of the partition table, and it is a lower-level problem
[01:30] <cjwatson> so it is vitally important to distinguish carefully and accurately between those two cases
[01:30] <Giotrader> ok
[01:31] <Giotrader> got it
[01:31] <Giotrader> ok I'll try again and see
[01:31] <Giotrader> be back later
[01:32] <cjwatson> see also the FAQ linked from the topic which has a brief section about the case where the partition table is something that the installer can't understand
[02:00] <CIA-28> ubiquity: cjwatson * r3193 gdm-signal/ (19 files in 9 dirs):
[02:00] <CIA-28> ubiquity: * GTK frontend:
[02:00] <CIA-28> ubiquity:  - Copy-and-paste gdm-signal from powermanagement-interface, since that
[02:00] <CIA-28> ubiquity:  package is no longer in main and is slated to go away. In future we
[02:00] <CIA-28> ubiquity:  ought to be able to use gnome-session D-BUS calls or similar for this
[02:00] <CIA-28> ubiquity:  work (LP: #357101).
[02:28] <CIA-28> ubiquity: cjwatson * r3193 ubiquity/ (d-i/manifest debian/changelog): Automatic update of included source packages: user-setup 1.23ubuntu17.
[02:31] <CIA-28> ubiquity: cjwatson * r3194 gdm-signal/ (bin/ubiquity-wrapper debian/changelog):
[02:31] <CIA-28> ubiquity: Use gksudo --preserve-env / sudo -E so that we can check DESKTOP_SESSION
[02:31] <CIA-28> ubiquity: from the GTK frontend, and use other desktop environment variables in
[02:31] <CIA-28> ubiquity: future.
[02:33] <CIA-28> ubiquity: cjwatson * r3194 ubiquity/debian/changelog: releasing version 1.12.5
[08:24] <Mirv> evand: could you see about my suggestions to 356333 as NonLanguagePackTranslationDeadline is tomorrow (even though you can choose to extend it for debian-installer of course)?
[08:26] <evand> Mirv: will do
[08:26] <evand> I'm inclined to go with the first option
[08:26] <evand> "This will delete %s and install $s
[08:26] <evand> err %s
[08:28] <Mirv> well just an example, I don't know how such stuff is used there, but similar to strings which have eg. "on partion ${partition}" or something. and I explained the list could be make into a separate string from txt
[08:29] <Mirv> then txt would be gettext:d with the so-called %s:s intact. then in the translated version those can be substituted by the list and the Ubuntu release string
[08:30] <Mirv> but yes, that form of the string is quite clear and avoids the plural problem
[10:04] <lool> Folks, partman doesn't seem to see /dev/mmcblk0 on my babbage install; it's a SD card; it does see /dev/sda which is an USB stick; is it because it's hiding the boot media?
[10:07] <lool> The UI is broken for automatic login in step 5 (identity)
[10:07] <lool> (Two radio buttons with no text)
[10:08] <evand> regarding the two radio buttons, that's fixed in trunk
[10:08] <evand> well, worked around
[10:09] <evand> regarding hiding the boot media, I haven't fully read through cjwatson's changes to that bit of code yet, but if you run `sudo parted_devices` do you see /dev/mmcblk0?
[10:09] <lool> Thansk, I was searching open bugs
[10:10] <lool> evand: I see both
[10:10] <lool> /dev/mmcblk0 and /dev/sda
[10:10] <evand> then the installer probably is filtering it out.
[10:10] <evand> hrm
[10:11] <lool> evand: Ok; I don't mind that it's hidden, even if in theory it would be possible to install to it, however ubiquity hanged when there was no /dev/sda yesterday
[10:11] <lool> I'll check how the filtering looks like in ubiquity
[10:11] <evand> as in when there were no disks present?
[10:11] <lool> evand: As in UI was stuck
[10:12] <evand> right, but when you say there was no /dev/sda, do you mean there were no disks present?
[10:12] <lool> No CPU was used, but nothing more was displayed after "Starting the partitioner"
[10:12] <lool> evand: Yes exactly, as if I would have booted a system with just a CDROM drive and no disk
[10:12] <evand> ok, I'll try to reproduce that
[10:12] <lool> (Or just a USB stick since the SD is writable)
[10:19] <lool> Ok, I'm giving up on digging up that code, I'm not familiar enough with this stuff it will take me ages just to find it; sorry
[10:24] <evand> lool: you can tell the installer to not worry about mounted partitions by setting partman-base/filter_mounted to false
[10:25] <evand> (hit f6 at the isolinux boot splash and add partman-base/filter_mounted=false before the --)
[10:26] <lool> evand: Not sure it's what I want: will this help showing the unmounted second partition I created on the SD card?
[10:26] <evand> I was unable to reproduce the hang in KVM without any disks.  I'm going to try with a USB disk and no other disks.
[10:26] <lool> evand: Thanks a lot; the debug log wasn't showing anything when I tried on the SD yesterday
[10:26] <evand> lool: yes.  It's removing the entire disk because the first partition is mounted
[10:26] <lool> Oh I see
[10:27] <lool> evand: I did create an empty partition at the end of the SD card
[10:27] <lool> Perhaps that's needed to trigger the bug
[10:27] <evand> noted; I'll try that as well if this fails to reproduce it
[10:29] <lool> Argh; installing on USB triggered a "Read-only filesystem" error due to USB errors; that board is too unstable to install to USB *sigh*
[10:29] <lool> ogra: Are you using the mini USB connector?
[10:30] <ogra> yep
[10:30] <ogra> but with a powered hub
[10:30] <ogra> the mini port has less power than the big ones afaik
[10:36] <lool> Well I don't have the needed adapter; I'll have to go SATA, if that works
[10:52] <ogra> lool, SATA is attached to the same place the big USB ports are
[10:53] <cjwatson> lool: FWIW it's partman/filter_mounted rather than partman-base/filter_mounted
[10:54] <evand> whoops
[10:54] <evand> sorry about that
[10:54] <cjwatson> lool: the SD card shouldn't be filtered out if the installation medium doesn't fill the whole disk, though
[10:54] <cjwatson> that's a bug - can we have logs?
[10:55] <lool> cjwatson: Yup, will keep them on next test; note that I ran in debug mode and didn't see any error in the logs myself though
[10:57] <cjwatson> I wouldn't expect a visible error in the logs, but would like to check out the logic
[11:12] <ogra> lool, did you open a bug ? i have a complete installation log here
[11:12] <ogra> else i can push it to people for cjwatson
[11:13] <lool> ogra: I did not yet
[11:13] <lool> ogra: it was my first experience with ubiquity on the babbage, and I wasn't sure the system wasn't unstable for other reasons
[11:13] <ogra> i'll tar it up and push to people then
[11:13] <lool> (e.g. g-k-d)
[11:13] <ogra> if you kill g-k-d it cant get in your way
[11:14] <lool> I did, but I had to kill -9 it
[11:14] <ogra> right
[11:14] <lool> ogra: So you have a log with just booting from SD, without USB target device and you're opening a bug?
[11:14] <ogra> "pkill -9 gnome-keyring*" is what i put in the docs everywhere
[11:15] <ogra> no, i always install to usb target device
[11:15] <ogra> but cjwatson wanted logs to see the logic
[11:15] <lool> cjwatson: I see the errors in my mail now with the .list; comments on yesterday question on the approach to follow?  I think mdir isn't happy no PC part data, so either I build the .list earlier (but I have to change a lot of places) or I extract the vfat from the partitioned image
[11:15] <ogra> mmcblk0 isnt offered as install media here
[11:16] <ogra> so that should suffice to see stuff
[11:22] <ogra> cjwatson, http://people.ubuntu.com/~ogra/installer.tar.gz
[11:22] <ogra> the complete log from my last install
[11:25] <lool> cjwatson: oh it worked; I see mmcblkp0 now
[11:25] <ogra> how did you manage that ?
[11:25] <ogra> i didnt see it since the fix entered
[11:25] <lool> Nothing, just ran ubiquity --debug and it worked this time
[11:25] <ogra> strange
[11:26] <lool> It might be a race
[11:26]  * lool tries again
[11:26] <cjwatson> lool: for the time being maybe just make publish-daily ignore .list in this case
[11:27] <ogra> dont we have the .list file somewhere already  ?
[11:27] <cjwatson> .list is generated with isoinfo
[11:27] <ogra> oh, right
[11:27] <ogra> the advantage of just converting existing images :)
[11:28] <StevenK> cjwatson: I look at pi-makelist, and then ran screaming. Far away.
[11:28] <cjwatson> ogra: are you sure that mmcblk0 is filtered out in this installation?
[11:29] <cjwatson> ogra: are we talking about the automatic partitioner, or the manual partitioner, or both
[11:29] <cjwatson> ?
[11:29] <cjwatson> we don't offer mmcblk0 for automatic partitioning if the installation medium is mounted on it, but it should still be offered for manual partitioning in this case
[11:30] <lool> StevenK: it's overly complex because of the isoinfo output IIMO
[11:30] <lool> *IMO
[11:30] <lool> It would be much simpler with a simpler tool
[11:30] <StevenK> Its overly complex since it's horrid shell, too
[11:30] <lool> Actually it could probably be replaced with two lines of shell using bsdtar
[11:31] <cjwatson> AFAICS partman is working as intended in ogra's logs
[11:31] <lool> cjwatson: Yes, with an USB stick plugged everything works fine
[11:31] <cjwatson> lool: that wasn't what I asked ...
[11:31] <StevenK> lool: If you want to fix pi-makelist, be my guest.
[11:31] <lool> cjwatson: I know, which is why I'm running an install here to grab you useful logs :)
[11:32] <lool> cjwatson: But when I tried myself, I couldn't reproduce, it worked without USB stick this time, for the first time
[11:32] <cjwatson> #define worked
[11:32] <lool> cjwatson: I could reach the screen to chose which partition to install to, and that included mmcblk0
[11:32] <lool> In the past I wouldn't reach this screen
[11:32] <cjwatson> ok, the hang is slightly different from what I was initially looking at
[11:33] <lool> It would simply hang there
[11:33] <cjwatson> you were asking about mmcblk0 being hidden
[11:33] <lool> cjwatson: It was this morning when I installed on /dev/sda, and it's not anymore
[11:33] <lool> That's really weird
[11:33] <lool> I think I'll reflash the SD card
[11:34] <lool> Oh I know the difference
[11:34] <cjwatson> I was describing the intended behaviour, which is as follows: if a device contains the installation medium, then it will never be offered for *automatic* partitioning; furthermore, if and only if the installation medium spans essentially the whole disk, it will be filtered out of manual partitioning
[11:34] <lool> Hmm no I don't
[11:34] <cjwatson> does that help to clarify what you might be looking for?
[11:34]  * lool goes starting again from clean SD
[11:35] <lool> cjwatson: Ok; the two things which I saw and are weird: a) ubiquity hanging, not making any progress anymore, before displaying the partitioning screen; that's when I had no USB key plugged, but I couldn't reproduce right now b) on my first install with an USB stick, only the USB stick was shown, not the SD card
[11:35] <ogra> cjwatson, the partitioning screen doesnt offer mmcblk0 at all
[11:36] <lool> ogra: It did for me this time around
[11:36] <lool> Which is what it should do
[11:36] <lool> I just need to reproduce that hang now
[11:36] <ogra> well, he asked me which partitioning screen :)
[11:36] <ogra> the first one doesnt have it in the pulldown
[11:39] <ogra> cjwatson, so if i had selected a different radio button in the first partitioning screen it would have found it in the pulldown ? or would it only show up in the next screen for doing actual manual partitioning ?
[11:39] <ogra> s/it/i/
[11:41] <lool> cjwatson: The MID and UNR images were correctly .imgs today, could you please remove the old .isos from ubuntu-mid/daily-live/current/ and ubuntu-netbook-remix/daily-live/current/?  thanks!
[11:44] <cjwatson> ogra: if the installation medium is on mmcblk0, then mmcblk0 will only show up on the actual manual partitioning screen
[11:45] <ogra> aha, thats why i never saw it then
[11:45] <cjwatson> ogra: it would be a bug if it showed up in the drop-down for automatic partitioning, since automatic partitioning can't work on that device while the installation medium is mounted
[11:45] <ogra> i only looked in the pulldown
[11:46] <cjwatson> lool: done
[11:46] <lool> thanks
[11:54] <lool> I take back what I said about mtools, it can probably handle partitioned data
[12:11] <lool> It can
[12:19] <lool> cjwatson: Is unsorted output like http://paste.ubuntu.com/146875/ good enough?
[12:20] <lool> Oh actually you don't care about directories
[12:21] <lool> http://paste.ubuntu.com/146876/
[12:23] <cjwatson> lool: sure, the .list files for ISO images just seem to be in extent order (which is sorted after a fashion, but not lexicographically)
[12:24] <cjwatson> so yes, that looks perfect
[13:44] <evand> davmor2: http://people.ubuntu.com/~evand/wubi/jaunty/wubi-r118.exe - can you try this version to see if the uninstall option is working for you?
[13:51] <lool> ogra: I filed Bug #357690 for the boot slowness; LIVEMEDIA should really avoid it, but perhaps we need a rootdelay as well?
[13:51] <ogra> rootdelay to speed it up ???
[13:51] <lool> ogra: Currently if LIVEMEDIA isn't there when casper runs, it will skip to autodetect
[13:51] <ogra> i'm just dd'in an image that has no LIVEMEDIA on the cmdline
[13:52] <lool> I think if we'd add a couple of seconds rootdelay to get the device in place, it will work
[13:52] <ogra> and will check if there are any speed differences
[13:52] <ogra> i'll try both
[13:52] <lool> cjwatson: I really fail reproducing the issue with mmcblkp0; either the new image fixed it, or I'm unlucky, sorry
[13:52] <ogra> truncating the install media is annoing :/
[13:53]  * lool ignores the ubiquity warning and formats the boot SD
[13:54] <lool> ogra: BTW the vfat only has 20 MB free space; not sure why your image was much smaller
[13:55] <ogra> intresting
[13:55] <lool> ogra: perhaps you're not creating the actual FS in the same way?  say, fat32 versus 16 or something
[13:56] <ogra> hmm, looking at the recent images yours is actually smaller
[13:56] <lool> ogra: tools/make-vfat-img uses /sbin/mkdosfs, I think you were using mkfs.vfat
[13:56] <lool> Hmm no
[13:56] <ogra> right
[13:56] <lool> You're using mkdosfs as well
[13:56] <ogra> but i use dd
[13:57] <ogra> and *then* mkdosfs
[13:57] <ogra> instead of mkdosfs -C
[13:57] <ogra> i guess the latter is more efficient
[13:58] <davmor2> evand: np's I'll do that now
[13:59] <cjwatson> lool: ok
[14:00] <evand> thanks davmor2
[14:00] <davmor2> meh bloody alternate failed packages not installer
[14:01] <ogra> lool, not using LIVEMEDIA drops me into busybox
[14:01] <lool> ogra: that could be a casper bug with our SATA USB adapter
[14:01]  * cjwatson tries to parse davmor2's last comment and fails ...
[14:01] <ogra> or a casper bug with SD cards
[14:02] <ogra> i'm not sure it considers mmcblk at all
[14:02] <lool> ogra: /sys/block/*?
[14:02] <lool> It should certainly appear there
[14:02] <ogra> i see it in /dev/disk/by-uuid
[14:03] <lool> Oh
[14:03] <lool> Only mmcblk0 appears there
[14:03] <lool> Not mmcblk0p1
[14:03] <cjwatson> that's odd
[14:03] <ogra> yeah
[14:03] <cjwatson> implies that the kernel doesn't understand it as a partitionable device, but that clearly isn't normally the case
[14:03] <ogra> /dev/disk/by-uuid has the partition
[14:03] <davmor2> cjwatson: I just tried an alternate install and a package has prevented it from installing
[14:04] <lool> cjwatson: We might have a special driver for it
[14:04] <cjwatson> you mean the right module might not be loaded?
[14:04] <ogra> we definately have a FSL driver here
[14:04] <ogra> and its compiled in
[14:04] <lool> No, I mean the behavior might be specific to our hardware
[14:04] <lool> Because it might not be using a standard driver and this driver might have bugs
[14:04] <cjwatson> lool: but mmcblk0p1 is present in other contexts, isn't it?
[14:05] <lool> cjwatson: It is
[14:05] <lool> drivers/mmc/card/block.c seems to be our driver, doesn't sound babbage specific
[14:06] <ogra> mxsdci.0 does
[14:06] <ogra> err
[14:06] <ogra> mxsdhci.0
[14:06] <ogra> thats the platform device for it
[14:07] <lool> That's the block backing device, but the mmc driver should be the same I think
[14:07] <ogra> its mmc_host if i'm right
[14:08] <ogra>  /sys/devices/platform/mxsdhci.0/driver points to /sys/bus/platform/drivers/mxsdhci
[14:08] <davmor2> cjwatson: I am right in thinking this is a hash-sum error and therefore nothing to do with the install process and it is the package that caused the fail aren't I? http://www.davmor2.co.uk/syslog
[14:10] <cjwatson> davmor2: it's not the package's fault either
[14:10] <ogra> aha
[14:10] <cjwatson> davmor2: it's some kind of bizarre, probably transient, error
[14:10] <cjwatson> davmor2: it could be a problem with your CD disk or drive, or it might go away with the next build
[14:10] <ogra> mxsdhci: MXC Secure Digital Host Controller Interface driver
[14:10] <ogra> lool, ^^^ from dmesg
[14:10] <davmor2> cjwatson: I'll try 64bit instead
[14:11] <cjwatson> Apr  8 11:52:24 kernel: [  658.762977] Buffer I/O error on device sr0, logical block 73968
[14:11] <cjwatson> davmor2: fault with your CD or CD drive
[14:11] <cjwatson> chances are, anyway
[14:11] <cjwatson> Apr  8 11:52:24 kernel: [  658.762969] sr 5:0:0:0: [sr0] Add. Sense: L-EC uncorrectable error
[14:13] <lool> bug #357700
[14:15] <ogra> lool, booting with a rootdelay=5 now
[14:15] <ogra> doesnt seem to be faster
[14:17] <ogra> still sitting there
[14:17] <ogra> now it moves
[14:17] <ogra> trying 10sec
[14:18] <lool> ogra: I still think mmcblk0 is created by the drivers/mmc/card/block.c driver; the driver you mention is the one providing access to the MMC, the one I mention is the one doing the blcok device
[14:19] <ogra> i'll attach a full dmesg if i have a complete boot
[14:19] <lool> It's the one printing mmcblk0: mmc0:8fe4 SD08G 7.60 GiB on boot
[14:19] <ogra> 10 sec doesnt seem to change anything either
[14:20] <ogra> persia, you have a SATA disk on your board, right ?
[14:21] <lool> block/genhd.c is the one adding the p*
[14:22] <lool> cjwatson: The device appears in /proc/partitions; would it make sense to add this to casper for now?
[14:23] <lool> something like merging /sys/block names with /proc/partitions names
[14:23] <lool> (I hope it's ok to discuss casper on the installer chan, I could as well move to -devel if people here prefer)
[14:23] <cjwatson> I'd rather you checked this out with kernel folks before jumping to conclusions in userspace
[14:23] <cjwatson> it's very, very, very weird that the entry is missing from /sys/block/
[14:23] <lool> Ok
[14:25] <lool> cjwatson: It's a SD slot; on my desktop I have a SD reader and it also shows as /dev/sdd only
[14:25] <lool> cjwatson: I just tried popping in a SD card there; fdisk -l shows the parts, I see them in /dev, but not in /sys/block
[14:26] <cjwatson> I'd like to give the kernel people a chance to respond to that, as that will surely break all sorts of other things in various subtle ways
[14:26] <cjwatson> oh, hang on
[14:26] <cjwatson> /sys/block/mmcblk0 should be a symlink to the real device
[14:26] <cjwatson> and you should have /sys/block/mmcblk0/mmcblk0p1 under that
[14:27] <cjwatson> it won't appear directly in /sys/block
[14:27] <lool> cjwatson: correct
[14:27] <cjwatson> correct as in you do have /sys/block/mmcblk0/mmcblk0p1?
[14:27] <lool> I have it yes
[14:27] <cjwatson> then there is no kernel bug
[14:27] <cjwatson> I misunderstood you
[14:28] <cjwatson> casper does check subdevices
[14:28] <ogra> lool, are you in initramfs ?
[14:28] <lool> I see it now, silly me
[14:28] <lool> ogra: I'm not
[14:28] <cjwatson> ah, it's probably the is_nice_device function
[14:28] <ogra> aha
[14:28] <lool> ogra: I see it on the booted system
[14:28] <lool> ogra: You don't?
[14:28] <cjwatson> what does '/lib/udev/path_id /block/mmcblk0' say?
[14:29] <ogra> i dont think i saw it in initramfs, need to reset the cmdline again
[14:29] <lool> cjwatson: ID_PATH=paltform-mmc0:8fe4
[14:29] <lool> platform
[14:29] <lool> cjwatson: Ok, so just adding platform in is_nice_device?
[14:29] <lool> Or platform-mmc?
[14:30] <cjwatson> mm, platform-mmc I think
[14:31] <ogra> hmm, i think i have worn out my mmc
[14:33] <ogra>  /sys/block/mmcblk0/mmcblk0p1 is there, even in initramfs
[14:35] <lool> cjwatson: Mind if I upload casper with the revision I pushed?
[14:35] <cjwatson> lool: go ahead
[14:36] <lool> pushed
[14:36] <cjwatson> lool: I assume you'll reassign that kernel bug
[14:36] <lool> cjwatson: Oh that's done already
[14:36] <cjwatson> ok
[14:36] <lool> Cool, it even picked up the bzr branch; how cute
[14:37] <cjwatson> yeah, it does that if you use debcommit, or bzr ci --fixes
[14:37] <ogra> that wont solve our delay though i bet
[14:37] <lool> I knew about --fixes but didn't know debcommit would DTRT, which is excellent
[14:37] <lool> ogra: I fear the delay is when the driver comes up
[14:38] <ogra> the mmc driver is compiled in
[14:38] <ogra> it comes up before the initramfs
[14:38] <lool> ogra: Yes, and the SATA one as well is my guess
[14:38] <lool> cjwatson: So I remembered what I did which could cause that ubiquity hang
[14:38] <ogra> i think usb-storage is modular
[14:39] <lool> cjwatson: it's probably my fault; I'm creating a partition with fdisk before launching ubiquity
[14:39] <lool> That hangs ubiquity when it tries to display the partman screen
[14:40] <cjwatson> lool: you might have caused it but I wouldn't describe it as your fault :-)
[14:40] <cjwatson> lool: do you have logs? (for bonus points, logs with ubiquity --debug)
[14:40] <lool> I do have both ;)
[14:42] <cooloney> lool, i found your post on LP. thank
[14:42] <lool> Crap, no network and can't mount USB key
[14:43] <CIA-28> ubiquity: cjwatson * r3195 ubiquity/ (20 files in 10 dirs): merge gdm-signal branch
[14:44] <lool> hehe you can remount the SD rw
[14:48] <lool> cjwatson: bug #357725
[14:48] <lool> Hmm my bug title sucks
[14:51] <cjwatson> lool: FWIW generally I prefer it if people can attach logs as separate files
[14:51] <cjwatson> makes it easier to view in a web browser
[14:52] <lool> cjwatson: Will split them up
[14:52] <cjwatson> lool: I need syslog and partman as well
[14:52] <cjwatson> debug is not a superset of those
[14:52] <lool> I'm afraid they are gone  :-(
[14:52] <lool> I had to remove the SD card from the system
[14:52] <cjwatson> oh, please repeat them
[14:52] <cjwatson> then
[14:52]  * lool returns
[14:52] <cjwatson> I'm afraid I can't tell what's going on from just debug
[14:53] <cjwatson> /usr/lib/ubiquity/ubiquity/frontend/gtk_ui.py:196: PangoWarning: error opening config file '/root/.pangorc': Permission denied
[14:53] <cjwatson> wonder if that will be fixed by gksudo -k :)
[14:54] <lool> Perhaps, but I thought HOME was already copied
[14:54] <lool> (I saw this warning in earlier testing as well, but it's benign so didn't report it)
[14:54] <cjwatson> HOME was one of the differences I noticed when diffing gksudo env against gksudo -k env
[14:54] <lool> cjwatson: So /var/log is good enough or you need more?
[14:54] <cjwatson> note the bit immediately above my patch - it only passes -H to sudo if you *don't* say -k
[14:55] <cjwatson> lool: the three files I need are: /var/log/syslog /var/log/partman /var/log/installer/debug
[14:55] <lool> Ok
[14:56] <lool> ogra: I take back that comment on the driver; the initramfs is clearly running already: squashfs is being loaded
[14:56] <lool> and I even tsee "Running /scripts/init-premount"
[14:58] <lool> ogra: perhaps it's squashfs mounting being slow?
[15:11] <davmor2> evand: By jove I think you've cracked it :)
[15:11] <evand> davmor2: don't thank me, thank xivulon
[15:11] <evand> but good deal
[15:11] <evand> please post a comment on the bug to that effect
[15:15] <davmor2> d0ne :)
[15:18] <lool> cjwatson: attaching syslog, debug, and partman logs to https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/357725
[15:20] <ogra> lool, manually its as fast as anywhere else
[15:20] <lool> ogra: Perhaps we can set -x to casper?
[15:21] <ogra> sure
[15:21] <ogra> but thats some effort
[15:22]  * lool sees the terrible effort crush ogra on the floor like atlas carrying the earth
[15:22] <ogra> haha
[15:22] <ogra> well, i mean re-rolling initramfs flashing it etc ...
[15:22]  * ogra wishes for vi in initramfs once again
[15:23] <evand> don't we all
[15:23] <ogra> heh
[15:23] <evand> sed ftl
[15:23] <davmor2> evand: as soon as 118 hits the cd's for real let me know and I'll see if I can break it, with kubuntu over ubuntu etc
[15:23] <evand> ok
[15:24] <davmor2> evand: I'm just test that the cd I made will remove it now
[15:25] <evand> ok
[15:26] <cjwatson> lool: commented on 357725
[15:28] <lool> cjwatson: But... that's some effort!
[15:28] <lool> :-P
[15:35] <ogra> hmm
[15:35] <ogra> set -ex in casper somehow doesnt generate more output
[15:36] <cjwatson> it puts it in casper.log
[15:36] <ogra> meh, so i need a break statement as well
[15:37] <ogra> and then i dont have less in initramfs ... grmbl
[15:38] <ogra> if i ever find extra spare time somewhere i'll create a initramfs-debug package i can just install that copy_execs the most necessary tools
[15:39] <ogra> it really doesnt have to be that painful to debug an initramfs
[15:40] <ogra> WOW!
[15:40] <ogra> lots of modprobe usage messages at the top
[15:40] <davmor2> evand: Yay removed from wubi on cd too :)
[15:42] <ogra> hrm, it didnt take my set -ex
[15:42]  * ogra scratches head
[15:55] <ogra> gah ... now it kills init
[15:56] <lool> cjwatson: Could you check ~lool/cdimage/debian-cd latest revision?  Adds support for .list files for VFAT and partitioned VFAT
[15:56] <lool> I did a test build in my home, and got a .list file in return
[15:57] <lool> (but of course had other errors from the run)
[15:57] <lool> I /hope/ I didn't mail everybody this time around
[15:57] <lool> At least, I went past Publishing down to Purging old images etc.
[15:58] <lool> ogra: You don't want to set -e
[15:58] <lool> Just -x
[15:59] <ogra> well, i usually set -ex but init is a different thing ... +
[15:59] <cjwatson> when modifying an existing script, just set -x
[15:59] <lool> well init is a shell script which sources casper, so if casper fails it will fail init
[15:59] <cjwatson> that's different from what you would do in a script you write from scratch
[15:59] <ogra> right
[16:00] <cjwatson> lool: looks fine, thanks, merged
[16:00] <ogra> the odd thing is that i have to stqart over :(
[16:00] <cjwatson> lool: now that you're in the cdimage group, you can just bzr checkout sftp://antimony/srv/cdimage.ubuntu.com/bzr/debian-cd and commit directly, if you like
[16:01] <lool> cjwatson: Eh just asked about that in a private query :)
[16:01] <lool> cjwatson: Is something updating /srv/cdimage.ubuntu.com then?
[16:06] <cjwatson> manually, by bzr pull
[16:14] <ogra> so the set -e gets me output on the console now
[16:14] <ogra> sadly it seems to do absolutely nothing while it hangs
[16:14] <lool> set -x I gues
[16:14] <lool> ss
[16:15] <lool> ogra: What's the previous thing it does?
[16:15] <cjwatson> evand: can bug 334284 be closed?
[16:16] <cjwatson> evand: modulo the awkwardness around India mentioned near the end, which looks like a separate bug *in addition to* the one mpt links to
[16:16] <ogra> lool, i see mountroot, four execs after that and then the kernel messages
[16:16] <ogra> (for the usb to sata)
[16:17] <mpt> cjwatson, perhaps bug 342586
[16:17] <ogra> after that it just sits
[16:18] <evand> I think we what we have is the best solution we can hope for at the moment.  Things seem to be well placed enough, and kwwii has suggested changes to the time zone map that will increase the size of the point, allowing us some flexibility on positioning
[16:18] <evand> http://sinecera.de/time_mock2.png - needs to be approved by Mark first
[16:18] <cjwatson> mpt: originally filed on an old version which we know was broken, though
[16:18] <evand> regarding India, part of that bug, the not showing the highlight, is fixed with the addition of the UTC+5.5 image.
[16:18] <cjwatson> evand: ah, good
[16:19] <ogra> wow, cat'ing the log takes minutes
[16:19] <mpt> cjwatson, I was pretty sure it was distinct from 334284, because I was clicking where Ubiquity thought the city was, rather than where it actually was
[16:19] <cjwatson> I'm not sure how many more UI changes we can have for jaunty now, though, if any
[16:19] <mpt> but I haven't retested it lately
[16:20] <evand> cjwatson: indeed, but this is seemingly coming from sabdfl
[16:20] <lool> what execs?
[16:20] <lool> ogra: ^
[16:20] <cjwatson> evand: we still have a UI freeze ...
[16:20] <cjwatson> (which we've already violated a bit too often for my comfort)
[16:20] <evand> indeed
[16:20] <cjwatson> I mean, that was my fault too
[16:20]  * lool (lalala)
[16:21] <lool> I think the mobile team beats you in number of freeze violations!  :-/
[16:21] <ogra> ok, i have a 300k casper.log on my desktop :)
[16:21] <lool> and I also feel bad about them
[16:22] <evand> cjwatson: I've already pushed back on the more radical item (making it fade out when mousing over to match the new notifications), but if you think we should take a hard line on this I'm willing to communicate that to kwwii.
[16:23] <ogra> lool, casper.log and casper.vars attached to the bug
[16:23] <ogra> err, hrm ... .vars upload failed
[16:24] <lool> ogra: Where does it hang?
[16:24] <lool> (I tried searching for "mountroot" as you mentionned)
[16:24] <evand> This has to be the oddest way of filing a bug to date (found via robbiew's youtube video): http://www.youtube.com/watch?v=vkN5NFlrr6E&feature=related
[16:26] <ogra> lool, i dont think it shows everything on console
[16:26] <ogra> the log is likely more informative
[16:26] <ogra> sigh
[16:26] <ogra> why do we call modprobe with -Q ?
[16:27] <cjwatson> evand: the hard freeze is tomorrow, and I'd much rather we were fixing installer crashes
[16:27] <ogra> it doesnt know -Q
[16:27] <ogra> + modprobe -Q -b aufs
[16:27] <ogra> Usage: modprobe [-v] [-V] [-C config-file] [-d <dirname> ] [-n] [-i] [-q] [-b] [-o <modname>] [ --dump-modversions ] <modname> [parameters...]
[16:27] <ogra> modprobe -r [-n] [-i] [-v] <modulename> ...
[16:27] <ogra> modprobe -l -t <dirname> [ -a <modulename> ...]
[16:27] <cjwatson> evand: things that will actually prevent people installing Ubuntu
[16:27] <evand> noted
[16:27] <lool> Oh they have working GL screensaver in vbox
[16:29] <lool> ogra: Oh right, that was dropped in latest new upstream
[16:29] <lool> I had to fix acpid as well
[16:29] <ogra> thats no prob though, just noisy
[16:30] <lool> Well it's a problem if you don't have builtin aufs
[16:30] <ogra> what i see in the log is that tmppop gets filled several times in loops
[16:31] <ogra> i'd say in a rough guess it runs about 100 times through that loop
[16:32] <ogra> well, more like 50 but still a huge amount
[16:33] <lool> I've pushed a new casper using -q instead of -Q
[16:34] <ogra> after that endless looping it actually goes into casper-bottom
[16:38] <ogra> + check_dev null /dev/mmcblk0p1 skip_uuid_check
[16:38] <ogra> + sysdev=null
[16:38] <ogra> + devname=/dev/mmcblk0p1
[16:38] <ogra> + skip_uuid_check=skip_uuid_check
[16:39] <ogra> ...
[16:39] <ogra> mount -t vfat -o ro,noatime /dev/mmcblk0p1 /cdrom
[16:39] <ogra> thats happening pretty fast it seems
[16:39] <lool> ogra: I'm afraid you'll have to add timing information; perhaps launch a background loop writing `date` to the log?
[16:39] <ogra> i start to suspect the hang actually happens *after* we mounted /cdrom
[16:41] <ogra> lool, i'm knowing relaticvely well weher what in the log is ... you will see yourself that the aufs loading happens quite a while before the hang if you boot
[16:42] <lool> Ok; I'll leave it to you then
[16:42] <evand> cjwatson: do you think it would be worthwhile for me to attend debcamp?  You mentioned it would be before, but I just wanted to be sure nothing has changed and it's still a good place to start properly contributing to d-i.
[16:44] <ogra> lool, the hang must happen between line 235 and line 317 somewhere
[16:45] <ogra> lool, and i see a /sbin/udevadm settle on line 264+
[16:45] <ogra> s/+//
[16:45] <lool> That could be it
[16:45] <ogra> yes
[16:46] <ogra> i'll try to find it and roll a new initramfs
[16:47] <lool> scripts/casper-helpers:128
[16:47] <lool> ogra: The modprobe fix might have fixed your bug actuallly
[16:48] <lool> Ah no, loop isn't a module either anymore
[16:48] <lool> We could modprobe && udevadm settle if that's the only reason for it
[16:49] <cjwatson> evand: yes, I asked around a bit at the last d-i meeting and there were several of us planning to attend debcamp
[16:51] <evand> ok, I still need to think about it as it's a long time to be away from home, but noted.  Thanks!
[16:54] <ogra> geez, there is a lot of udevadm trigger/settle in casper
[16:56] <lool> Only three?
[16:56] <lool> ogra: The one in scripts/casper isn't for us I think
[16:57] <ogra> setup loop is it i think
[16:58] <ogra> setup_loop() even
[16:58] <lool> ogra: Yes, scripts/casper-helpers:128 as I said above
[16:58] <lool> Since it was setting up loops in your log around the line you mentionned
[16:58] <ogra> right
[16:59] <ogra> i wonder why its there at all
[16:59] <ogra> the function deliberately uses modprobe
[17:00] <ogra> these is no trigger anywhere
[17:00] <lool> It's there to ensure /dev/loop* are created as a result of the modprobe
[17:00] <ogra> no
[17:00] <ogra> its a nbonsense call
[17:00] <ogra> the settle will only answer to a trigger or until udev has created *all* devices
[17:00] <ogra> at least if i didnt massively misunderstooed Keybuk
[17:01] <lool> My understanding is that settle will exhaust the udev queue
[17:01] <ogra> lets ask Keybuk and meanwhile i'll roll a new initramfs and see if anything explodes
[17:01] <cjwatson> Keybuk is away this week
[17:02] <ogra> he was on yesterday just on SF time
[17:02] <cjwatson> on, but not paying lots of attention, IME;
[17:02] <cjwatson> lool is correct regarding settle, though
[17:03] <cjwatson> the triggers may be wrong, but I'm reluctant to remove them at this point
[17:03] <ogra> even if there is no trigger ?
[17:03] <cjwatson> yes!
[17:03] <cjwatson> settle waits for the udev event queue to empty
[17:03] <cjwatson> trigger looks through the entire system and creates udev events for all devices
[17:04] <cjwatson> settle can act as a sequence point to resolve race conditions, sometimes. trigger usually only creates problems, except in cases where new modules have appeared
[17:04] <ogra> right, but in our case since there is a stray settle it means we stop until udev is done with everything
[17:04] <cjwatson> as in, new .ko files actually being installed, as happens in the installer
[17:04] <cjwatson> ogra: *shrug* deal with it? :-)
[17:04] <cjwatson> there's no way to say "wait for just this device" except busy-waiting
[17:04] <ogra> thats what i'm trying to do :)
[17:05] <ogra> well i know how the device is called
[17:05] <cjwatson> if this is just slowness and not causing other problems, please leave it be for jaunty
[17:05] <ogra> so indeed you can go into a loop and wait until it appears in the fs
[17:05] <ogra> it adds 60-90 second bootime to the boot here
[17:06] <cjwatson> casper is delicate
[17:06] <ogra> i didnt stop it exactly, but its more than a min sitting there and sleeping
[17:06] <cjwatson> I'm very worried that any attempts to fiddle with its logic there will cause failures that we don't have time to deal with
[17:06] <cjwatson> besides, the same work would have to be done later anyway
[17:06] <ogra> and the fun is that the function cvalls mknod anywayx
[17:07] <ogra> if the device isnt there at the point it needs it
[17:07] <ogra> so that udevadm settle is pointless
[17:11] <cjwatson> that is not true
[17:11] <cjwatson> please don't fiddle with this if you don't understand it
[17:11] <cjwatson> if you try to use the device node before the kernel is ready for you to do so, even if the device node exists, you might get ENODEV
[17:12] <ogra> well, the module is loaded so i'd only expect udev to not be ready
[17:12] <lool> cjwatson: How can we tell what's being done on the system which takes so long?  It really seems long, even for our hardware
[17:12] <ogra> but not the kernel
[17:12] <cjwatson> ogra: and you're sure that nothing else in casper could possibly be relying on that settle, I suppose?
[17:12] <cjwatson> you've proven that?
[17:12] <cjwatson> the day before final freeze, this kind of change for an optimisation requires proof
[17:12] <cjwatson> lool: probably crank up the udev log level
[17:13] <lool> cjwatson: My idea for this particular settle was to only run it if the modprobe succeeds; if it fails then either loop is builtin or not built at all and we don't need to wait for it to be udev-ed
[17:13] <ogra> cjwatson, no and to take your fear away i dont plan to do any such intrusive hacks atm
[17:13] <lool> But I agree it's just pushing the problem further in the boot
[17:13] <ogra> cjwatson, i'm just trying to solve lool's bug
[17:13] <ogra> or find the cause at least
[17:13] <cjwatson> lool: I'm concerned that something later might be implicitly relying on settle having been run at least once
[17:13] <lool> cjwatson: Ack
[17:14] <cjwatson> the problem might well be the excess triggers, *not* the settles
[17:14] <lool> I agree we don't want to expose awful bugs like these at this point
[17:14] <cjwatson> each trigger causes an event storm
[17:14] <ogra> just on a sidenote commenting the settle had no effect
[17:14] <lool> ogra: So perhaps you might want to confirm that this settle is the one where we block and look at some udev debug output?
[17:15] <cjwatson> there are only two triggers, mind you
[17:15] <ogra> lool, yes i'm digging deeper
[17:15] <ogra> why are there two ?
[17:16] <cjwatson> because at one point somebody was under the impression that you always needed to do trigger; settle in order to create a sequence point
[17:16] <cjwatson> now we understand things better
[17:16]  * ogra wonders if the HW really can change that much that we need triggers at all
[17:16] <cjwatson> I *believe* that both of the triggers are unnecessary, but I have not proven it
[17:16] <cjwatson> and it's *not* dependent on the hardware changing
[17:17] <cjwatson> if new hardware appears, either the kernel will notice and create udev events anyway, or if it hasn't noticed when you run udevadm trigger then the trigger will not cause it to notice
[17:17] <ogra> thats what i meant
[17:18] <cjwatson> it is certainly curious that a mere two extra copies of each udev event make things go so slow for you
[17:18] <ogra> i actually see only one trigger ... or do we use lupin-helpers in std. casper ?
[17:19] <ogra> the trigget in casper seems to be for nfs root
[17:19] <cjwatson> ./scripts/casper-bottom/23networking:36:/sbin/udevadm trigger
[17:19] <cjwatson> ./scripts/casper:175:    /sbin/udevadm trigger
[17:19] <ogra> *trigger
[17:19] <cjwatson> presumably only the latter one is actually relevant to you
[17:20] <ogra> hmm, i was under the impression the hang is over if we get to -bottom
[17:20] <cjwatson> yeah
[17:21] <lool> cjwatson: Unfortuantely I fear 354226 was fixed in linux after the last d-i upload
[17:21] <ogra> but i see the settle in the log
[17:21] <lool> Which is why I didn't fix release it
[17:21] <ogra> and no trigger at all
[17:22] <TheMuso> cjwatson: I am wondering whether there is any way that the UbuntuStudio can add the initial user to the audio group, since realtime audio for jack is not PolicyKit aware yet, and users cannot run jack with realtime priority without being in this group.
[17:22] <cjwatson> lool: I didn't think that was the case
[17:22] <lool> Actually I might have looked at the wrong date
[17:22] <cjwatson> lool: wasn't it 2.6.28-11.39?
[17:23] <lool> cjwatson: Yes, I think I read the date near "superseded in", sorry
[17:23] <cjwatson> ah yes, that can be confusing
[17:23] <lool> fix released
[17:23] <TheMuso> s/UbuntuStudio/UbuntuStudio install/
[17:23] <cjwatson> TheMuso: hmm
[17:25] <cjwatson> TheMuso: done in debian-cd
[17:26] <TheMuso> cjwatson: Ah yes, thanks.
[17:26]  * cjwatson adds some more detailed commentary too
[18:07] <lool> cjwatson: Added set -x attachments to 357725
[18:26] <lool> Weird, the fix for .list on vfat didn't seem to wrok
[18:27] <lool> I suspect I have to revisit the thing to detect the image type
[18:38] <davmor2> evand: all three maps tie in nicely now normal, full screen, and oem
[18:38] <davmor2> I'll look at netbook tomorrow
[21:54] <cjwatson> lool: the most recent build actually slightly predates the fix, as far as I can tell
[21:55] <cjwatson> lool: so I'm not sure you need to worry?
[21:56] <lool> Ok, great
[21:56] <lool> I thought the other way around
[22:24] <CIA-28> partman-base: cjwatson * r153 ubuntu/ (debian/changelog init.d/parted): Ignore non-zero exit statuses from mapdevfs (LP: #357725).