[08:18] <jibel> slangasek, I found a problem when several packages are uploaded at the same time and trigger a test of the same package (eg. gobject-introspection depends on glib2.0 and libffi) only the first dep on the list is considered and others are ignored
[08:19] <jibel> slangasek, I'll add new tests and provide a fix
[08:19] <infinity> jibel: Eek.
[09:57] <infinity> rsalveti: Why is that i386 touch subarch "generic_x86" instead of just "generic", aligning with the kernel flavour?
[10:09] <ogra_> infinity, thats the android device name ... generic is the armhf device name
[10:09] <ogra_> (yay for consistency)
[10:09] <infinity> ogra_: Err.  Lolwut?
[10:09] <ogra_> it was renamed from goldfish to generic
[10:09] <infinity> ogra_: Kay.  I assumed it related to kernel names, since it does for the armhf ones (flo, manta, etc).
[10:10] <infinity> ogra_: Oh.  Okay, so shouldn't it be goldfish from our POV?
[10:10] <ogra_> yeah, i'm curious how ricardo will solve that :)
[10:10] <ogra_> it was goldfish until android 4.2.2 ... with kitkat it was renamed to generic
[10:10] <ogra_> we use 4.4 ... so we use the device names it uses
[10:10] <infinity> Well, but it's still "golfish" as far as our kernels.
[10:11] <infinity> Since in our world, generic means something entirely different.
[10:11] <ogra_> yeah
[10:11] <infinity> But okay, if this livecdrootfs stuff is about Android platform names, and has nothing to do with kernel flavours, I guess the patch is "right".
[10:11] <infinity> Just confusing as all hell.
[10:11] <ogra_> thats why i say i', curious how rsalveti will solve it ... patching the name in the android tree would be quite a patch i think
[10:11] <ogra_> (to rename it back to goldfish)
[10:12] <ogra_> yeah, touch is full of confusion ...
[10:12] <ogra_> the ubuntu rootfs lives in a system.img ... in which you have an android system.img ...
[10:13] <ogra_> (and now explain to a porter that he has to replace his system.img :P )
[10:13] <ogra_> naming things isnt our strenght in touch
[10:13] <infinity> ogra_: I've been mostly ignorant of all of this for a long time, I can't decide if I should learn how it's all put together (thus perhaps leading to anger and/or sadness), or just keep ignoring it.
[10:14] <ogra_> well, i expect the image design to take over on the desktop too over the next releases
[10:14] <infinity> ogra_: Yeah, so, there's going to be a long and angry conversation about that.
[10:14] <ogra_> (probably less insane ... with proper readonly partitions etc)
[10:15] <infinity> With the current state of affairs, the response to "we should use system images in the distro" would be "over my dead body", so we'll need to do a lot of discussion to see if it's viable and, if so, how.
[10:16] <ogra_> i dont think it is wrong to have a fixed core ... but getting dpkg into play here will be a hell lot of work
[10:16] <infinity> ogra_: Conceptually, a readonly core is fine but, yes, making dpkg happy with that is not an easy problem to solve.
[10:17] <infinity> And "everything that's not core can be click!" is not an answer, as click was intentionally designed to be limited in scope and just plain can't do some of the things we want in more complex packages.
[10:17] <ogra_> well
[10:17] <ogra_> everything thats UI should be click is my opinion
[10:17] <ogra_> at least over the years
[10:17] <infinity> Define "UI".
[10:17] <infinity> You mean "apps"?
[10:17] <infinity> Or you mean kubuntu should distribute KDE as click packages? :P
[10:17] <ogra_> also libreoffice
[10:17] <ogra_> or chromium
[10:18] <ogra_> no
[10:18] <ogra_> i mean that desktop and touch apps should be click ... everything that you can install on a desktop ... click integration needs to be seamless enough that kubuntu *can* use it if they like
[10:19] <infinity> I don't think we should stand in the way of people who want to make things clicky.  But we also shouldn't fetishize it and fork Debian packages into click packages Just Cause.
[10:20] <ogra_> well, i think we should encourage click to UI app people
[10:20] <infinity> And if we come up with a solution that makes dpkg happy on a readonly system-image, we don't NEED to make those decisions, or needlessly fork.
[10:20] <infinity> Cause people with root and no need for containment can then run debs on phones, and people can run clicks on desktops, and everyone wins.
[10:20] <ogra_> you wont have dpkg on a (converged) phone
[10:21] <infinity> ogra_: See, no, that's wrong.  Flat-out wrong.
[10:21] <ogra_> i think even in desktop mode you want the phone to oly run converged apps
[10:21] <infinity> Convergence implies that the phone and desktop will become one platform.
[10:21] <ogra_> simply for security reasons
[10:21] <infinity> If my desktop can't install debs, it's useless.
[10:21] <infinity> Period.
[10:22] <infinity> Note that I did say "if you have root".  I expect the average phone user to never exercise ring0.
[10:22] <ogra_> i'm not sure i agree here, you would ship quite a giatn security hole unless you strictly cage both systems ...
[10:22] <infinity> But the facility should be there for it to act just like my development desktop.
[10:22] <infinity> ogra_: You're implying that my entire laptop is a gaping security hole. :P
[10:23] <ogra_> oh, sure, there should be a developer mode
[10:23] <ogra_> in which you can probably drop the gurads ...
[10:23] <infinity> ogra_: Right, but "developet mode" can't just be "make it read-write and disable system images", or the previous 100 lines of conversation was meaningless.
[10:23] <ogra_> we do that today (apart from the odd hardlink issues dpkg has)
[10:23] <infinity> (Which is what developer mode is currently)
[10:24] <ogra_> but in a deffault phone even with converged desktop mode, i wouldnt expect debs
[10:24] <infinity> ogra_: Well, in a converged product aimed at appliance consumers, I don't expect anyone to ever need root, no.
[10:24] <ogra_> and the majority of users wont need the dev mode (hopefully)
[10:24] <infinity> ogra_: But this system also needs to be usable by me.
[10:25] <ogra_> indeed
[10:25] <infinity> ogra_: And by all the people who run Ubuntu as a useful dev platform, not an appliance.
[10:25] <ogra_> but people like you and me hopefully only make up a really really minor portion of users
[10:25] <infinity> One of the most exciting things about this, really, is that if we do it right, the phone is self-hosting.
[10:25] <infinity> Which no other Mobile OS platform has been.
[10:26] <infinity> (Maemo should have been, but lolscratchbox)
[10:26] <ogra_> if we are more than 0.001 per mille we have failed in the phone business :)
[10:26] <ogra_> (we developers)
[10:26] <infinity> Sure, we should be a minority.  I still want to do it right for everyone. :P
[10:26] <ogra_> indeed
[10:26] <infinity> And a self-hosting platform is also a big step in "doing it right", for me.
[10:27] <ogra_> as long as ubuntu gets developed on ubuntu i expect such modes to exist
[10:27] <ogra_> scratching our own itches still ...
[10:27] <infinity> I was amazingly disappointed when I did Maemo stuff for Nokia to discover that a platform that was essentially Debian couldn't actually build its own binaries.
[10:29]  * ogra_ glares at his desktop
[10:29] <ogra_> ogra@anubis:~/Devel/branches/project-rootstock-ng$ ps ax|grep qemu
[10:29] <ogra_> 11106 ?        Ssl    0:00 /usr/bin/qemu-arm-static /usr/sbin/rsyslogd
[10:29] <ogra_> 11181 ?        Ss     0:08 /usr/bin/qemu-arm-static /usr/sbin/cron
[10:29] <ogra_> now how got this there
[10:29] <ogra_> they both even respawn
[10:29] <infinity> Lack of policy-rc.d in that chroot?
[10:29] <ogra_> yeah, could be
[10:30] <infinity> cat trusty-amd64/usr/sbin/policy-rc.d
[10:30] <infinity> #!/bin/sh
[10:30] <infinity> while true; do
[10:30] <infinity>     case "$1" in
[10:30] <infinity>       -*) shift ;;
[10:30] <infinity>       makedev) exit 0;;
[10:30] <infinity>       x11-common) exit 0;;
[10:30] <infinity>       *) exit 101;;
[10:30] <infinity>     esac
[10:30] <infinity> done
[10:30] <infinity> Enjoy.
[10:33] <ogra_> right, that implies i dont forget about ti next time i roll a chroot in a hurry :)
[10:33] <ogra_> debootstrap should have a switch to put that in place
[10:36] <ogra_> lol
[10:37] <infinity> ogra_: debootstrap --include=policyrcd-script-zg2 might give you what you want.
[10:37] <ogra_> so when issuing "sudo reboot" in the terminal app on the phone the keyboard autocorrection prints my password (in the terminal) when typing
[10:37] <infinity> Except that's in universe, so you also need to add universe. :/
[10:37] <infinity> Oh, wait.  No.  It's in main now.
[10:37] <infinity> \o/
[10:37] <ogra_> :)
[10:38] <infinity> Not sure why it's in main...
[10:38] <infinity> Can't find it seeded, nor any rdeps.
[10:38] <ogra_> interesting
[10:39] <infinity> Oh, it's in platform, I was looking at Ubuntu.
[10:40] <infinity> ... and it's been seeded since 2009, I might live slightly in the past.
[10:40] <ogra_> haha
[10:42] <ogra_> upgrade these gutsy installs
[11:20] <doko> jibel: a lot of autopkg tests are marked as running for some time now ...
[12:10] <doko> infinity, you did trade in the lintian ftbfs to a dep-wait ...
[12:11] <infinity> doko: Hrm?  See the upload in the queue.
[18:29] <rsalveti> infinity: ogra_: it's a lot of work to rename it to generic
[18:29] <rsalveti> the android build system doesn't support a device with the same name but different arch
[18:29] <ogra_> heh, yeah
[18:30] <ogra_> and I guess the other way round its not less work
[18:31] <rsalveti> and for the kernel is indeed confusing, but the upstream name is indeed just goldfish
[18:31] <rsalveti> so the android generic build runs with the goldfish kernel
[18:32] <rsalveti> would love to get this a bit more sane though, maybe next cycle
[19:59] <infinity> rsalveti: Wait, I'm confused.  "the upstream name is indeed just goldfish".  Isn't that what we want it to be?
[20:00] <infinity> rsalveti: I was complaining that having something called "generic" that has no relation to our "generic" kernel is confusing. :)
[20:01] <ogra_> infinity, the upstream kernel name
[20:45] <infinity> Who accepted that account-plugins upload without a changelog entry? :/
[20:58] <slangasek> how can an upload have no changelog entry?
[20:59] <slangasek> wow
[20:59] <slangasek> ok then
[20:59] <slangasek> and account-plugins isn't whitelisted?
[20:59] <slangasek> infinity: oh, but it's a sync, so good luck reviewing it ANYWAY
[21:00] <infinity> slangasek: I review syncs...
[21:01] <slangasek> infinity: and good luck to you!
[21:01] <infinity> I obviously didn't do that one. :P
[21:01] <slangasek> infinity: how do you review them?  Last I knew, you couldn't fetch sources or diffs from the queue
[21:01] <infinity> slangasek: One somewhat nice thing about the silos is that if you follow the queue link to the origin PPA, it's usually only got a couple of packages in it, unlike the old upstream merged that had hundreds, so it's not too hard, UI-wise, to get to the diff.
[21:02] <slangasek> ok
[21:02] <infinity> (And I think queuediff also tries to follow it back somehow, but I tend to just use the web UI for this)
[21:02] <slangasek> right, good to know you can get there via the web ui; that's better than nothing
[21:03] <slangasek> (though having to shell out to a browser (er...) to trace it is still annoying)
[21:03] <infinity> It's seven kinds of not ideal, we're well aware.
[21:19] <infinity> Hey, lazyIRC, is there a HOWTO on the wiki somewhere for doing autopkgtests at home?
[21:19] <infinity> Possibly ECHAN...
[21:43] <Laney> slangasek: infinity: queue fetch can fetch sync sources
[21:43] <Laney> it definitely works for CI train syncs
[21:44] <slangasek> also good to know
[21:44] <slangasek> does that mean 'queuediff' works now?
[21:44] <Laney> Nein
[21:44] <slangasek> ok
[21:45] <Laney> I wrote a shell alias that does that or fetch / pull-lp-source && debdiff as appropriate
[21:45] <slangasek> infinity: 'doing autopkgtests at home' == 'adt-run /path/to/package.dsc --- adt-virt-schroot trusty-amd64'
[21:45] <slangasek> Laney: fie, instead of submitting a fix to queuediff? :)
[21:46] <Laney> Orders of magnitude quicker :P
[21:47] <Laney> Last I looked queuediff was a screen scraper
[21:49] <slangasek> yeah
[21:50] <Laney> You could bolt some shelling out onto it though, I guess
[21:54] <rsalveti> infinity: yeah, sorry, by upstream name I mean the upstream name for the kernel
[22:14] <infinity> slangasek: Do you know anything about this efitools in the queue?
[22:59] <cjwatson> account-plugins might have been me, I complained about the lack of changelog for one such package on #ubuntu-ci-eng but I decided I was OK with the rest of the diff and it wasn't worth redoing it
[22:59] <cjwatson> slangasek: "queue fetch" works on syns
[23:00] <cjwatson> *syncs
[23:00] <cjwatson> oh Laney said that
[23:00]  * slangasek nods
[23:00] <slangasek> infinity: efitools> um no
[23:00] <cjwatson> (I use queue fetch --source to stop it fetching the binaries too)
[23:05] <infinity> slangasek: Given your love of EFI and SB, care to look at the FFe and evaluate the assertion that we need this package before I go trying to review the package itself?
[23:07] <slangasek> infinity: I'm familiar with the tools in question, and even have a copy checked out locally, but there were no explicit plans to use these in Ubuntu; would like to know what jpds's larger plans are here...
[23:09] <slangasek> I mean, I don't really see any reason not to include them as a package in Ubuntu, but the claim in the FFe bug that they "will be needed for enterprise platforms" is eyebrow-raising
[23:12] <infinity> slangasek: Right, inclusion or not is entirely up to it passing an AA review and, really, if it's going to be a leaf package in universe, it doesn't need an FFe.
[23:12] <infinity> slangasek: But the wording of said FFe seems to imply it might want to be in main for some reason or other that I can't fathom and thought you might know (but apparently don't).
[23:12] <slangasek> infinity: it should not be in main
[23:13] <slangasek> if jpds thinks otherwise, he should discuss with the foundations team :)
[23:13] <ScottK> infinity: Generally we have been asking for an FFe for new packages, but I almost always approve conditional on finding a willing AS.
[23:14] <ScottK> AS/AA
[23:15] <infinity> ScottK: I suspect I view feature freeze a bit differently, in the sense that if nothing depends on a new leaf package, and it's not in a supported seed, it's not really a new feature from the POV of people installing/upgrading and getting a new behaviour.
[23:15] <infinity> (I certainly don't ask for FFes for people syncing new shiny from Debian)
[23:19] <infinity> ScottK: Seems to be a fair tradeoff for me being a perfectionist control freak about packages that *are* seeded. :P
[23:19] <ScottK> When MOTU was a separate team we insisted on people at least asking because there were people who screwed stuff up otherwise.
[23:19] <infinity> ScottK: (Please do apologise to your new contributor about my anal-retentive reject of calligra, though they did reupload a fixed version, so yay)
[23:20] <ScottK> k.
[23:21] <infinity> The number of things I reject for during hard freezes really makes me wish we had the human bandwidth to do queue reviews all cycle. :/
[23:21] <knome> mmyes
[23:21] <ScottK> :'(
[23:22] <infinity> Huh, look at that.  I was planning to blame Intel for the ppc64el acpcia-unix FTBFS, but it's totally the fault of the packaging.
[23:26] <infinity> ^-- Someone want to review that and let it in?
[23:28] <cjwatson> haha, done