[00:10] <infinity> cjwatson: FWIW, the current level of the haskell transition is stuck on asn1-types being in Debian/NEW.
[00:11] <infinity> cjwatson: I was thinking of just packaging it from upstream+darcs and giving it a non-ubuntu version, so it can be synced over.
[00:29] <infinity> (and done)
[02:20] <cjohnston> knome: and anyone else. For a blueprint for UDS (and summit.ubuntu.com), it needs to be <track>-<cycle/uds(s/1305)>-name. For status, naming doesn't matter unless it's a topic. If it's a topic it should be topic-s-<category>-name where category would be something like flavor, unity, community, etc.
[02:24] <cjohnston> knome: when you come online, please ping me
[04:53]  * infinity curses haskell-conduit's FTBFS on armhf.
[04:53] <infinity> Laney: Any insight into the above?
[05:59] <infinity> cjwatson: I nudged the haskell transition along a fair bit, but stalled it intentionally at dep level 24ish, since half the rest of the world build-deps on conduit, which is FTBFS on armhf.
[05:59] <StevenK> ... dep level 24.
[07:05] <Mirv> the 6 unity raring SRU packages are still hopeful of getting in. I understood two weeks ago that the scripts would be up to the task in theory, but please let us know if we should do something more regarding the first raring SRU.
[07:06] <Mirv> up to the task since it's the new style sync requests from the daily process PPA
[08:55] <cjwatson> infinity: Well, that's just boring.  (Thanks)
[09:00] <knome> cjohnston, ping
[09:01] <knome> cjohnston, our umbrella blueprint is https://blueprints.launchpad.net/ubuntu/+spec/topic-saucy-flavor-xubuntu. shall i go and change the name?
[10:41] <cjwatson> infinity: conduit fails with the LLVM backend on i386 too, it seems - it's just that armhf is our only architecture that requires that
[10:42] <cjwatson> I think it's something to do with the way it handles variadic open
[10:58] <cjwatson> Ah yes, works if I avoid that
[11:21] <cjohnston> knome: hey, still here?
[11:32] <knome> cjohnston, now i am
[11:35] <cjohnston> knome: I think that the name is fine
[11:35] <knome> cjohnston, ok. let me know if we need to change some stuff :)
[11:36] <cjohnston> knome: my question is that xubuntu-dev doesn't seem to be used... http://status.ubuntu.com/ubuntu-s/xubuntu-dev.html  it all seems to be going to xubuntu-team...
[11:36] <cjohnston> Can we remove xubuntu-dev from status?
[11:36] <knome> cjohnston, at the moment, yes.
[11:36] <knome> cjohnston, i don't think we need that to show in the status specifically though
[11:37] <knome> cjohnston, i'm trying to avoid assigning to teams where possible, but... meh. :)
[11:37] <cjohnston> The BP as a whole should be assigned to a team normally, that way any work items that may not be 'spoken for' are assigned to the team
[11:38] <cjohnston> So I will remove xubuntu-dev and leave xubuntu-team
[11:39] <knome> cjohnston, yes, agreed with the assigning stuff :) thanks
[11:40] <cjohnston> ty
[11:40] <zequence-s> cjohnston, Are you the man to talk to about approving blueprints for saucy? - I'd like to set up blueprints for Ubuntu Studio soonish
[11:41] <cjohnston> infinity: would you like to handle this, or do you want me to?
[11:42] <knome> cjohnston, i understand it's not possible to have userpages for "everybody", but would it be too hard to pick the launchpad "realnames" to listings like "Status by assignee" here: http://status.ubuntu.com/ubuntu-s/xubuntu-team.html ?
[11:43] <cjwatson> infinity: OK, haskell-conduit 1.0.5-2 will fix this when it's autosynced
[11:43] <cjohnston> knome: your talking for noskaj?
[11:44] <knome> cjohnston, and xubuntu-team
[11:44] <knome> cjohnston, i mean i'm not asking to create those userpages.
[11:44] <knome> cjohnston, just that the LP nicks would be replaced with LP realnames in all listings generally
[11:44] <knome> consider as wishlist
[11:47] <cjohnston> knome: I don't know why xubuntu-team does, as xubuntu-team is a team that is being imported.. as far as for users, if you could file a bug http://launchpad.net/launchpad-work-items-tracker please
[11:47] <knome> i'll do that sometime this week. cheers!
[11:47] <cjohnston> ty
[11:48] <zequence-s> I need to log out for a while, so will come back about blueprints..
[11:54] <knome> cjohnston, i just wish it was written in PHP so i could help with it...
[11:55] <cjohnston> ;-)
[11:55] <cjohnston> I want to rewrite it using django
[12:19] <ogra_> cjwatson, could you take a look at http://paste.ubuntu.com/5706604/ .... the target is to keep a clean tarball but generate boot images per subarch
[12:21] <cjwatson> ogra_: looks mostly ok; the two things I noticed are that the wildcards in that rm line won't be expanded because you have them inside the quotes (fix: just move the -* outside the quotes), and that perhaps you could make it faster by running update-initramfs for just the appropriate -k rather than -k all
[12:22] <cjwatson> some kind of quoting and error handling around the assignment to kpkg would be a good idea too
[12:22] <ogra_> well, getting the version for -k would add some extra code i wanted to avoid
[12:22] <cjwatson> ogra_: you've already gone to most of the effort there in assigning to kpkg
[12:22] <cjwatson> isn't it just ${kpkg#linux-image-} ?
[12:23] <ogra_> hmm, indeed it is
[12:23] <cjwatson> alternatively: refactor the loop to install all the kernel packages you care about, update the initramfses for all of them, and copy them all out in one go
[12:23] <cjwatson> should save you time apt-get installing and removing stuff each time round the loop
[12:28] <ogra_> well, but that would leave me with two loops ... one for installing, one for removing, i guess it will be the same time wise in the end ... i could split off the crda and wireless-regdb stuff though
[12:31] <ogra_> whopps, the apt-get calls need to be chrooted indedd
[12:31] <ogra_> *indeed
[12:35] <cjwatson> If nothing else you could save installing/removing crda and wireless-regdb over and over
[12:35] <cjwatson> Yeah
[12:35] <cjwatson> I was just thinking that it would allow you to use -k all if you wanted
[14:59] <tseliot> infinity, cjwatson: can you approve the following packages in NEW please? nvidia-graphics-drivers-319 nvidia-settings-319 nvidia-modprobe nvidia-persistenced and nvidia-prime
[15:05] <tseliot> or Laney ^
[15:15] <Laney> I cannot
[15:15] <ogra_> try harder
[15:19] <tseliot> :D
[16:11] <ogra_> gar
[16:11] <ogra_> so seems my kver stuff also needs to be chrooted :P
[16:34] <infinity> cjwatson: Ooo, that conduit made it just under the publisher wire too.  I'll get back to tossing builds back in a bit too, you can blissfully ignore it again.
[16:34] <infinity> cjwatson: (Seems like a good use of my Monday morning brain)
[16:36] <cjwatson> I'll be around for a bit, already have the first batch queued up :)
[16:36] <cjwatson> But yeah, I'll ignore it this evening after this
[16:37] <cjwatson> I think the only other piece of manual work needed is a sync of haskell-hakyll *after* I manage to construct a working source+binary upload to Debian (build-deps are uninstallable in unstable at the moment)
[16:38] <cjwatson> I really have very little brain today anyway
[16:45] <infinity> I need to go renew my passport today too, or I'm not travelling anywhere this summer.
[17:11] <cjwatson> infinity: Actually, don't rush.  Joachim just did another 13 uploads to bring us up to the current upstream haskell-platform release, so that'll be some rebuilds :-/
[17:11] <infinity> cjwatson: Heh.
[17:11] <infinity> cjwatson: My assumption is that if we finish off our self-imposed ABI transition, any subsequent syncs/uploads will Just Work without any babysitting.
[17:12] <cjwatson> Any new upstream of haskell-$foo is an ABI change for all the stuff that depends on it.
[17:12] <infinity> Oh, right.
[17:12] <cjwatson> Or any interface change in a patch.
[17:12] <infinity> Such an awesome design.
[17:14] <cjwatson> Since Debian was uploading everything anyway, it was actually easier to force a compiler ABI change at the same time; it meant that everything failed until its deps were ready, rather than requiring 0-change uploads.
[17:16] <cjwatson> So we could rush and get this one done before the next auto-sync, but meh if we're going to have to do all of haskell-text's rdeps again anyway
[17:17] <cjwatson> And it was all going so well ...
[17:21] <infinity> Right, time to wake up and shower and see if I can go for a third passport photo in a row where I mysteriously look exactly the same as I did 11 years ago.
[17:53] <phillw> cjwatson: just a quick question... can launchpad ppa area compile up a PPC version from source if asked?
[17:59] <stgraber> phillw: devirt PPA can be used for that but they're restricted to Canonical employees as they use the same builders as the distro
[18:02] <cjwatson> And because they have effectively no (or very weak) security against a malicious user installing some kind of persistent process that fiddles about with future builds.
[18:03] <phillw> stgraber: thanks. It's just the PPC guys have asked to have a play with xombrero which julien does keep at https://launchpad.net/~lubuntu-dev/+archive/non-official-apps whilst Luis Henriques battles with licensing issues to have the new version accepted into debian :)
[18:03] <cjwatson> This is really a #launchpad question, but the answer is going to be no due to long-standing policy, I'm afraid.
[18:04] <phillw> cjwatson: thanks, it was worth asking :)
[18:06] <phillw> one of the ppc guys is going to have to learn https://help.ubuntu.com/community/CompilingEasyHowTo one of them has offered, but he is busy in RL for a couple of weeks. No worries, it is of very low urgency (aka wish-list).
[18:06] <cjwatson> Eh, just have somebody set up sbuild, not that hard
[18:07] <phillw> cjwatson: but does it not have to build on a PPC machine?
[18:07] <cjwatson> Install sbuild package, 'mk-sbuild saucy', fiddle with /etc/schroot/chroot.d/<whatever the new file is called> if need be, sbuild -d saucy foo.dsc
[18:09] <cjwatson> phillw: Yes, in general.  But one might hope that your ppc guys have such things.
[18:10] <cjwatson> ("in general" because it is possible to play tricks with qemu and/or cross-building in some cases.)
[18:10] <cjwatson> (but I wouldn't recommend starting there.)
[18:11] <phillw> cjwatson: they do, but none of the devs have. Would it be possible using  https://wiki.ubuntu.com/Lubuntu/Testing/PPC%26Mac64#How_to_test_on_any_architectures_.28using_qemu.29
[18:11] <cjwatson> "CompilingEasyHowTo" seems designed to make it sound as scary as possible.
[18:11] <cjwatson> phillw: In principle you could do it in a VM, sure.  It would be very slow.
[18:12] <phillw> h eh, do you know of better documentation?
[18:12] <phillw> more than 12 hours?
[18:12] <phillw> as in slow ^^
[18:12] <cjwatson> That would obviously rather depend on the package!
[18:12] <cjwatson> https://help.ubuntu.com/community/SbuildLVMHowto - if you don't have LVM set up then drop the --vg=blah argument
[18:13] <cjwatson> 'mk-sbuild --arch=powerpc saucy' will have a go at setting things up with qemu user-mode emulation.  Might work.  Known to have trouble with sufficiently complicated packages that rely on decent threading support during the build, but works with a fair number of simpler things.
[18:14]  * infinity notes that quantal has a higher version than raring in that PPA.
[18:14] <phillw> thanks, that gives various options. shame that openbios-ppc is only there as a .deb. I'd run a VM on my server area, but it is CentOS (red-hat)
[18:15] <cjwatson> It's perfectly possible to pick apart .debs on RH machines.
[18:15] <phillw> not for me, it isn't :D
[18:16] <infinity> Or just install it on an Ubuntu machine, and grab the binary you want from /usr/share/openbios-ppc
[18:16] <cjwatson> Ten seconds' googling found http://www.thegeekstuff.com/2010/04/view-and-extract-packages/ (e.g.)
[18:17] <phillw> cjwatson: I did have a try, but my knowledge is insufficient. I managed a compile of pcmanfm with a LOT of help.
[18:18] <phillw> infinity: if I cp that over, would virt-manager be able to use it?
[18:18] <infinity> No idea, I don't use either virt-manager or RHEL.
[18:19] <cjwatson> Might be more sensible to ask in some RHish channel ...
[18:19] <phillw> infinity: thanks, I'll go do some digging, but TBH. centos people are not the most helpful on irc :)
[18:19] <cjwatson> Ubuntu people aren't going to be helpful about CentOS, I'm afraid.
[18:20] <cjwatson> Your problem :)
[18:20] <phillw> unless I have a bug fix for a kernel problem from red-hat :D
[18:20] <phillw> I do understand. But when I'm on there, it is for CentOS issues :)
[18:21] <infinity> phillw: http://lucifer.0c3.net/~adconrad/xombrero/
[18:21] <infinity> phillw: Enjoy.
[18:21] <infinity> (That was built on raring)
[18:22] <phillw> infinity: PPC?
[18:22] <cjwatson> Try looking at the directory listing ...
[18:22] <infinity> Yes...
[18:23] <phillw> infinity / cjwatson you people are stars of the 1st magnitude. Thanks!
[18:23]  * cjwatson wonders whether this would work in qemu, and tries.
[18:23] <tumbleweed> qemu's PPC emulation seems *very* slow
[18:24] <cjwatson> I mean user mode.  I can't be bothered with full-system emulation.
[18:24] <phillw> tumbleweed: it is, but it has a lot to do!
[18:24] <infinity> tumbleweed: Is it even worse, clock-for-clock than ARM (I'd expect it to be, I guess, given that people emulate ARM for a reason, emulating PPC just means you're too cheap to buy a computer)
[18:25] <phillw> tumbleweed: many years ago, windows would run faster in the newest PPC chipsets than it could on the intel based ones. That was REALLY weird (But we talking win 3.1 as to how long ago).
[18:26] <phillw> +under emulation
[18:26] <tumbleweed> yeah, user-mode
[18:27] <infinity> phillw: Nothing all that weird about it, PPC740/750 was wildly faster than the Pentiums of the time.
[18:28] <infinity> (POWER7 and the upcoming POWER8 still eat Intel's lunch too, for that matter, as long as you don't mind running a trunk cable from the local nuclear reactor to your living room)
[18:29] <phillw> But, I have distracted you all for far too long. Many thanks for all the information and I'll let the PPC testers know of the xombrero link for them to try. At least that way they can decide if they want to give time and effort into testing it.
[18:31] <phillw> infinity: lol ^^ :D
[20:03] <stgraber> infinity: hey, aware of any script that lets you grab the latest lp-buildd chroots from the API and set them up as local sbuild chroots?
[20:04] <stgraber> would like to cron something like that on some of my boxes so I don't have to care about updating my chroots and can ensure I'm relatively close to our buildd chroots
[21:28] <infinity> stgraber: No, but if you're doing sbuild backed by tarballs, the chroots from the API should just feed in unmodified.
[21:29] <infinity> (Oh, they might also barf on CurrentlyBuilding not being set up, you might want a setup.d snippet to make that happen)
[21:30] <infinity> stgraber: I had always meant to do an lp-buildd emulation wrapper for sbuild to do basically what you're talking about.
[21:31] <infinity> stgraber: Though, it would work even better if you mixed it up with a local nameserver that gimped name resolution the same way the DC does, as that's a cause of some curious build failures.
[21:32] <stgraber> infinity: yeah, currently the only things I changed here are removing CurrentlyBuilding and /etc/apt/sources.list.d/bootstrap.list and then update sources.list to include all the bits I want (typically all 4 components for the release and updates pocket)
[21:34] <infinity> stgraber: The last bit I handle with Andy's handy dandy setup snippet.
[21:35] <infinity> stgraber: http://paste.ubuntu.com/5708191/
[21:35] <infinity> stgraber: That allows one to override if you don't want all components or don't want proposed, or whatever.
[21:36] <stgraber> oh, nice
[21:37] <infinity> (And means the base chroot can stay as main/release, so upgrading it doesn't accidentally pollute it)
[21:37] <infinity> Which is the big reason I use this.
[21:39] <infinity> cjwatson: Did you ever get anywhere interesting with automating cdimage archival, or should I go ahead and do oneiric by hand?
[21:39] <infinity> cjwatson: (IS informs me they have migrated to a machine with room and they're ready now)
[21:56] <cjwatson> infinity: Not started on it yet, sorry - do it by hand, and just keep the notes in EOLProcess up to date so they get as close as possible to an algorithm
[21:56] <cjwatson> I hear syncproxy is low enough on space that I'd better not block
[21:59] <infinity> cjwatson: Mmkay.  I'll go ahead and do the manual archival dance.
[21:59]  * infinity chuckles at today's xkcd.