[04:03] <i-node> helo
[04:03] <i-node> hello*
[06:41] <twb> Does qemu-system-arm work *at all* on lucid?
[06:51] <twb> Hm, same behaviour on sid
[07:30] <twb> I give up, qemu-system-arm won't work for me on lucid, and the only non-lucid host I have, is a shitty little Atom netbook (where it works, but unbearably slowly)
[07:30] <twb> I will just reflash the TF101 again with ubuntu so that I have something to actually do compiles on
[17:36] <MMlosh> Grr..  the Oneiric kernel froze again..  (pandaboard with 2 DVB-T tuners atached)
[19:26] <Daviey> janimo: Hey!  Can you confirm the bump is correct on linux-ac100?
[19:26] <Daviey> New package: linux-ac100 (universe) [2.6.38-1.3 → 2.6.38-1000.1]
[19:26] <janimo> Daviey, yes
[19:26] <Daviey> janimo: What is the reasoning?
[19:26] <janimo> I am about to upload the linux-meta-ac100 so it is in universe by tomorrow
[19:27] <janimo> Daviey, I started with a new packaing using git
[19:27] <janimo> and followed a tutorial and existing ubuntu/linaro numbering convention
[19:27] <janimo> probably not needed in this case but I played it safe
[19:27] <Daviey> janimo: I don't follow?  Where does it state jump to 1000?
[19:27] <janimo> being my first time packaging a kernel by lots of trial and error eve
[19:28] <janimo> Daviey, it doe snot, the linaro template I started with uses 1000.0
[19:28] <janimo> and all linaro kernels use such large abi numbers afaik
[19:28] <janimo> omap 1200, landing team ones 1400 etc
[19:29] <Daviey> seems odd, but ok
[19:29] <Daviey> infinity: ^^
[19:30] <janimo> Daviey, tbh it seemed odd to me too, but if I were to question or dig into everything that seems odd to me in kernel packaging it would take me a lot more to get something ready
[19:31] <janimo> not one of the tutorials were 100% correct or covered the various cases, jcrigby's one is the closest and best yet
[19:32] <janimo> Daviey, at leats this package is now maintained in git and more or less in sync with how the kernel team and linaro manage their kernels
[19:32] <infinity> That works for me.
[19:32] <Daviey> janimo: heh, it's a black art that i don't understand either... The changelog generation blows me :)
[19:32] <janimo> I even plan to upload it to the kernel repos so it is not only on my disk
[19:33] <janimo> Daviey, I thought I understood everything about the changelog, when an innocent change in it (well version number addition _before_ the last one) tripped the ABI checker
[19:33] <infinity> Would it surprise you to know that most of the kernel team doesn't know how the packages are built either? ;)
[19:33] <infinity> A lot of that stuff is from BenC and I fiddling years ago.
[19:33] <janimo> at which point I deferred work to next morning being an unexpected error after I thought I had ironed out all issues and built the package a few times already
[19:33] <janimo> so I try to touch as little as possible
[19:33] <infinity> The fact that it's survived is a testament to opaque code that no one wants to touch.
[19:33] <Daviey> heh
[19:33] <janimo> and learn more as I upload new revisions
[19:34] <janimo> infinity, that would not surprise me in the least actually
[19:34] <infinity> janimo: To fully understand it, you have to first understand Ben Collins.  After rooming with him at many conferences, I don't recommend it.
[19:35] <janimo> and also it does not scale well
[19:35] <janimo> would need many many conferences or very large rooms
[19:35] <infinity> (That's not to say that I have anything against the guy, we're great friends, just warning that insanity may ensue)
[19:36] <Daviey> infinity: I think you might want to room with lag.
[19:36] <infinity> I don't need to corrupt any more Canonical employees, past, future, or present.
[19:37] <infinity> For the good of the company, I should probably always room alone. :P
[19:38] <Daviey> heh
[19:38] <janimo> infinity, how selfless, you are.
[19:38] <Daviey> infinity: I was more worried he'd corrupt you. :)
[19:38] <infinity> Seems unlikely.
[19:38] <infinity> But I'm always willing to be surprised.
[19:39] <infinity> jcrigby: LINARO: always build debug packages
[19:40] <infinity> jcrigby: ^-- From your recent uploads.  Don't we have that turned off for distro kernels (to avoid duplication of massive packages between -dbg and .ddeb)?
[19:40] <jcrigby> crap
[19:41] <jcrigby> that was a change for linaro ppa
[19:41] <infinity> I figured.
[19:41] <jcrigby> because we wanted the debug stuff
[19:41] <jcrigby> infinity, ok educate me
[19:41] <infinity> Because PPAs don't do ddebs, yes.  Longstanding feature request for that in LP. :P
[19:41] <jcrigby> so my fix didn't fix because it still goes to ddeb
[19:42] <jcrigby> it just always does it
[19:42] <infinity> Oh, in which case, these are fine for the primary archive. ;)
[19:42] <jcrigby> right
[19:42] <infinity> And you still need a better fix for your PPA, I guess.
[19:42] <jcrigby> so two wrongs make a right
[19:42] <jcrigby> yes, I need to not do the rename to ddeb
[19:42] <jcrigby> in ppa
[19:43] <jcrigby> so the debug stuff will just stick around like a normal deb
[19:43] <infinity> You can cheat and use archive_purpose to conditionally rename.
[19:43] <infinity> I'm a bit shocked the default templates don't do that.
[19:43] <jcrigby> you can tell me what the current stuff does
[19:44] <jcrigby> it looks in / for some file
[19:44] <jcrigby> let me look
[19:44] <infinity>  /CurrentlyBuilding
[19:44] <jcrigby> yes
[19:44] <jcrigby> and uses that to decide if it is a local developer build or an archive build
[19:45] <jcrigby> if that file exists it sets fullbuild or somesuch
[19:45] <infinity> Kay, but if you check the value of it, you can get more in-depth.
[19:45] <jcrigby> then later do_debug get set or not based on full_build
[19:46] <janimo> infinity, jcrigby a meta package should just need a changelog bump and debian/rules will DTRT on build?
[19:46] <infinity> janimo: Depends on the meta source.  But that's how most work.
[19:47] <janimo> ok, this is ogra's ac100 meta. Should work as it has no magic besides the debian/ dir in it
[19:47] <infinity> jcrigby: You can see in build logs that Purpose is actually set to a value in that file.
[19:47] <jcrigby> ok so packages are ok except for crappy short changelog
[19:47] <infinity> jcrigby: (Check the sbuild call for '--purpose='
[19:48] <infinity> jcrigby: For instance for primary archive, it's --purpose=PRIMARY
[19:48] <jcrigby> ahh
[19:48] <janimo> infinity, linux-meta-ac100 uploaded, fingers crossed, etc
[19:48] <infinity> jcrigby: For PPAs, it should be PPA, but double-check one of your build logs. :P
[19:48] <jcrigby> wow, I need to hang out with infinity for a week of intense training
[19:48] <jcrigby> ok, I'll do that
[19:48] <jcrigby> infinity, is this documented anywhere?
[19:48] <jcrigby> or just in package masters heads?
[19:48] <infinity> jcrigby: *mumbles something about the launchpad source code*
[19:49] <jcrigby> :)
[19:49] <infinity> jcrigby: I'd be willing to bet that about 5 people know how this works, and 2 don't work here anymore.
[19:54] <infinity> jcrigby / janimo : Kernels all accepted, after some very generous review.  May $diety have mercy on your souls if they all break. :P
[19:55]  * infinity really goes to find food this time.
[19:56] <janimo> infinity, thanks
[19:57] <infinity> jcrigby: Even for subarches like this where we're not building official images, it would be swell if, next cycle, you keep slightly more in sync.  Diffs that large a 2 weeks before RC are a bit scary.
[19:58] <infinity> s/a 2/2/
[19:59] <jcrigby> I agree
[20:00] <jcrigby> I need to make the ubuntu upload part of my normal workflow even though we (linaro) consume kernels from ppa
[20:04] <infinity> Certainly until we hit kernel freeze, anyway.
[20:04] <infinity> Then you need to get picky and potentially fork.
[20:29] <jcrigby> infinity, are you back from lunch
[20:29] <jcrigby> ?
[20:30] <infinity> jcrigby: I keep forgetting to start lunch.
[20:30] <infinity> jcrigby: 'sup?
[20:31] <jcrigby> so did I understand that I can look inside /currentlywhatever to figure out if I am ppa or normal or ...
[20:31] <infinity> jcrigby: Yup.
[20:32] <infinity> jcrigby: "Purpose: PPA" or "Purpose: PRIMARY" for PPA versus primary archive.  There are a few other possible values (PARTNER, etc), but those are probably the only two you care about.
[20:32] <infinity> jcrigby: And no /CurrentlyBuilding at all can generally be assumed to be "user machine, or non-LP buildd".
[20:32] <jcrigby> ok those two are all I need, thanks
[20:32] <jcrigby> right
[20:32] <jcrigby> thanks, I now need to go fix debug for ppa again
[20:33] <jcrigby> but conditionaly so i don't break primary
[20:33] <infinity> If and when we get around to merging the archive sbuild and the buildd sbuild, this might become more easily testable.
[20:33] <jcrigby> sure
[20:34] <infinity> And someone should probably hack up some CurrentlyBuilding support into pbuilder for similar "pretend I'm a buildd" testing reasons.
[20:34] <Daviey> infinity: I started doing that for sbuild
[20:34] <infinity> The upshot of that is that it would de-facto document it all.
[20:35] <infinity> Daviey: You're not the only one. :P
[20:35] <Daviey> infinity: CurrentlyBuilding support requires to know the component, which means it is network bound - or you have to delcare it at spawn, i guess?
[20:35] <infinity> Daviey: On the buildds, it's declared when you start the job.
[20:36] <infinity> Daviey: --component=foo --purpose=bar
[20:36] <Daviey> yeah, but launchpad is lucky enough to know the compoent.
[20:36] <Daviey> :)
[20:36]  * Daviey looks up what a compoent is
[20:36] <infinity> Daviey: That's more than enough to get people to be able to match the archive behaviour for reproducibility.
[20:37] <infinity> Daviey: I'd argue that if you don't know what component your source package is in, you probably shouldn't be uploading it. :P
[20:37] <Daviey> infinity: Incidently, i came acorss a package which built fine in pbuilder and sbuild, but failed on the buildd's.  Grabbing the LP chroot, and throwing it into pbuilder allowed me to debug it
[20:38] <Daviey> infinity: Well, my usecase was automated builds.. so thar! :)
[20:38] <infinity> Daviey: Yeah, for doing automated rebuilds or something, you could still cheat with the apt Sources.gz and grep-dctrl or some such.
[20:38] <infinity> Daviey: It wouldn't be up-to-the-minute accurate, but close enough.
[20:39] <infinity> But you'd want that sort of logic in a wrapper, not in pbuilder/sbuild themselves.
[20:39] <infinity> pbuilder and sbuild should just trust user input.
[20:39] <infinity> Not be clever.
[20:40] <Daviey> Oh aye.. that is what i was doing
[20:41] <Daviey> infinity: Incidently, i'd like to steal LP's Architecture: $target handling.. Need to see if/how that is exposed via API.
[20:42] <infinity> Hrm?
[20:43] <infinity> Not sure I know which Arch handling you're referring to.
[20:44] <infinity> You mean the part where it selects arch_indep for i386, and passes '-A' to sbuild?
[20:47] <infinity> If so, that's exposed via the API.  See is_nominated_arch_indep at https://api.launchpad.net/devel/ubuntu/oneiric/i386
[20:47] <infinity> Daviey: Was that what you were driving at? ---^
[20:49]  * infinity lunches for real this time.  Honest.
[20:59] <Daviey> infinity: Well that yes, but also processing of linux-any, and the others
[20:59] <Daviey> Although, not really an sbuild issue itself.
[21:00] <Daviey> for each package
[21:03] <infinity> Daviey: http://paste.ubuntu.com/463055/ <-- The patch that was applied to lp-buildd's sbuild to handle linux-any.
[21:03] <infinity> Though, I'd assume the distro sbuild does the right thing anyway.
[21:05] <Daviey> ah, nice