[00:31] <zul> what does the trying: sqlalchemy, skipped: sqlaclhemy mean in the update_output.txt report
[00:33] <micahg> zul: the dependencies listed aren't installable
[00:33] <micahg> that's weird, I uploaded alembic...
[00:34] <micahg> oh, it's probably the rdepends of alembic (openstack) which I didn't touch
[00:37] <zul> micahg:  i uploaded them on friday/today
[00:38] <micahg> zul: I'd suggest checking the entries of each one, nova isn't installable either
[00:42] <zul> micahg:  weird becaues i was able to install it
[00:42] <micahg> well, with everything else in proposed maybe
[00:44] <micahg> zul: cinder seems problematic
[00:44] <zul> micahg:  i thinks its because of the autopkgtest...anyways thanks ill look at it
[00:44] <micahg> yes
[01:51] <robert_ancell> Hi, lightdm 1.7.6-0ubuntu1 has a serious bug in it (bug 1203711) but neither the fix in 1.7.6-0ubuntu2 or 1.7.7-0ubuntu1 have moved out of -proposed into main. Is something blocking it?
[01:51] <ubot2`> Launchpad bug 1203711 in lightdm (Ubuntu) "uninitialised list pointer in configuration directory handling" [High,Fix committed] https://launchpad.net/bugs/1203711
[01:52]  * ScottK looks
[01:53] <ScottK> robert_ancell: No one has verified Bug 951000 is fixed in either release.
[01:53] <ubot2`> Launchpad bug 951000 in OEM Priority Project "disable guest session screen lock using gsettings" [High,In progress] https://launchpad.net/bugs/951000
[01:53] <micahg> ScottK: robert_ancell: block request for alpha2
[01:54] <micahg> I think...was by Laney
[01:54] <ScottK> Oh, Yes.
[01:54] <robert_ancell> micahg, ScottK, is there a way to let the saucy version through? It's an important fix that has no relation to that
[01:55] <ScottK> Looking again in the right place.
[01:55] <micahg> well, depending how bad, the ISOs should probably be respun
[01:55] <ScottK> It's only Monday.  I'll let it through.
[01:55] <robert_ancell> micahg, it was picked up in a test lab based on the ISOs
[01:57] <ScottK> If I got the syntax right, it'll be unblocked on the next publisher run.
[02:08] <robert_ancell> ScottK, thanks!
[02:18] <robert_ancell> ScottK, Appears to be in main now, thanks again!
[02:18] <ScottK> You're welcome.
[03:28] <jbicha> since it's still Monday here, here's an unblock list for Ubuntu GNOME http://paste.ubuntu.com/5902731/
[03:29] <micahg> jbicha: freezes generally start at 2100 UTC FWIW
[03:29] <jbicha> but gtk+3.0 is also blocked because notify-osd's test has been failing for a few weeks
[03:30] <jbicha> micahg: or we could release note them all :)
[03:31] <jbicha> and it's not clear when the Alpha Freeze exactly starts...
[03:32] <micahg> jbicha: I'm not saying they shouldn't necessarily be unblocked, but you seem unclear when freezes start :)
[03:32] <jbicha> yes, it's not on https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule
[03:32] <micahg> jbicha: second bullet point
[03:32] <jbicha> right, but there isn't an alpha freeze on the schedule
[03:33] <micahg> hrm, it's always been Tues before (Mon 2100)
[03:33] <jbicha> if gvfs didn't need to go through the new queue, it probably would have been in before the block this morning
[03:33] <micahg> but that is an oversight...
[03:34] <ScottK> jbicha: If you're still the release person for Ubuntu Gnome, I'll be glad ot unblock whatever you need.
[03:34] <ScottK> Just say go.
[03:34] <jbicha> ScottK: see it's still Monday for you too :)
[03:35] <micahg> jbicha: he's on the release team, he can let stuff through when it's needed :)
[03:35] <jbicha> ScottK: can we skip the notify-osd test?
[03:35] <ScottK> Oh, it's past when we freeze, but I'm easy about blocks this early.
[03:35] <ScottK> Is it a problem with the test, do we know?
[03:36] <jbicha> I have no idea https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-notify-osd/lastCompletedBuild/ARCH=i386,label=adt/console
[03:37] <micahg> jbicha: has that been escalated to whoever is in charge of those daily builds?
[03:38] <jbicha> micahg: no but I can make sure I tell people in the morning
[03:38] <ScottK> It looks like that test has passed before.
[03:39] <ScottK> So it should be investigated.
[03:39] <micahg> yeah, and there's a "please report" address at the bottom :)
[03:39] <ScottK> I'll do the unblocks, but not override the test failure.
[03:39] <jbicha> ScottK: thanks, that will work
[03:39] <ScottK> Once someone investigates, someone else can do that.
[03:40] <micahg> lubuntu would be affected by any GTK breakage, so that seems prudent
[03:41] <ScottK> .
[03:58] <jbicha> that email address bounces :(
[06:06] <bluesabre> hello, I'm on the Xubuntu Release team, and we would like to opt in for Alpha 2.  Whom should I email regarding this?
[06:33] <cjwatson> zul: You need to look at the "Trying easy from autohinter: sqlalchemy" block, not the part where it tries sqlalchemy on its own.
[06:35] <cjwatson> zul: But, indeed, the short answer is probably to figure out cinder's autopkgtest failure.
[08:56] <cjwatson> xnox: android-src-vendor's debian/copyright is fairly general.  Have we checked that all the licences in question permit us to redistribute the files on Ubuntu mirrors (not just Canonical)?
[08:57] <cjwatson> xnox: For the next version it would be nice to actually quote the licences.  debian/copyright isn't meant to have external references, except to /usr/share/common-licenses/.
[08:59] <xnox> cjwatson: ok. Let me dig out the original license texts for each and every blob. In general yes, one can redistribute them, as long as they are intended and used on the targeted Nexus series devices and no other.
[09:00] <cjwatson> Right.  Good enough for multiverse ...
[09:58]  * apw notes there is a block request on the current kernel, if the images have -4 that was not a very happy kernel
[10:05] <xnox> cjwatson: updated copyright. all of them allow "non-commercial redistribution". http://paste.ubuntu.com/5903575/
[10:12] <cjwatson> xnox: Thanks.  I hope you'll forgive me not reading through all that now :-)
[10:13] <infinity> apw: I'll make sure that gets through and people get fresh images.
[10:15] <apw> infinity, thanks... sorry for the timeing, only really getting proper confirmation that this is resolving peoples issues today
[10:15] <xnox> cjwatson: to be honest it's the same text for all of them. +/-  different name of the company with/without "no reverse engineering" clauses.
[10:15] <xnox> =)
[10:16] <infinity> jibel: The linux autopkgtest is still running out of space, which makes the sadness of my pandas great.
[10:18] <apw> infinity, perhaps we should just be removing that test if the system cannot cope with it
[10:19] <infinity> apw: Nah, we should fix jibel's system. :P
[10:20] <jibel> infinity, how much space will you pandas be happy with? will 20G be enough?
[10:20] <cjwatson> It's not obvious that that test is massively improving anyone's life, mind you.  Would it improve anyone's life even if it were fixed?
[10:21] <infinity> cjwatson: The idea of the test is to trigger kernel/glibc/gcc/binutils in a bit of a circle-jerk to make sure no one breaks the others.
[10:21] <infinity> cjwatson: The part where it's also triggered by linux-signed being uploaded is unfortunate. :P
[10:21] <infinity> jibel: No idea.  Build a kernel and see?  :)
[10:22] <cjwatson> infinity: Mm.  But it's only testing buildability, which we'd notice the next time we tried to upload anything anyway, not really anything that's going to break users if things are promoted.
[10:23] <infinity> Possibly, yeah.  I don't feel strongly about it.
[10:24] <infinity> It wasn't my test. :P
[10:24] <apw> the way pitti pitched it it was mostly useless for the kernel itself, in a perfect world it would not be triggered on the kernel for a kernel upload only on the uploads from the dependancy packages
[10:24] <apw> so if gcc changes we have to build the kernel to prove it is ok
[10:25] <apw> but there is no way to say in the autopkgtest control that we don't do it for us only others
[10:25] <cjwatson> Yeah, but like I say, you'd find that out at the next build anyway.
[10:25] <cjwatson> I don't really see "does it still build" as a terribly useful use of autopkgtest.
[10:25] <apw> cjwatson, well the point is to stop gcc from migrating when it is changed
[10:25] <cjwatson> But that makes no useful difference
[10:25] <cjwatson> Because you build with what's in -proposed anyway
[10:26] <cjwatson> Blocking migration is helpful when the migration is going to break users
[10:26] <apw> heh, point indeed.  so its useless for its intended use
[10:26] <cjwatson> But in this case it seems like a weird artificial thing that isn't helping much
[10:26] <apw> it is cirtainly not helping for its intended function it seems
[10:27] <apw> not considering how expensive and slow it is
[10:29] <infinity> apw: The kernel test being nothing but a build test, with no testsuite involved, it probably can just go, yeah.
[10:29] <apw> infinity, yeah as i under stood things it was meant to hold gcc or libc if things went wrong, but that doesn't do us much good
[10:29] <apw> so i am in your hands, if you think it is usless i am happy to wack it
[10:30]  * xnox 'd like to add autopkgtests to build dkms modules when new kernel is uploaded, to know which ones need fixing, but somehow not block kernel migration because of dkms modules =/
[10:30] <cjwatson> Honestly I think that would be better done in some other system ...
[10:30] <cjwatson> We don't have to hit all nails with the same hammer :-)
[10:31] <cjwatson> xnox: Huh, I thought saucy-preinstalled-touch-*.zip were the Ubuntu bits.  Did I misunderstand?
[10:31] <cjwatson> Oh, not saucy-preinstalled-touch-armel+*.zip
[10:31] <ogra_> cjwatson, -armhf.zip are the ubuntu bits
[10:31] <cjwatson> Yeah, my mistake
[10:32] <ogra_> cjwatson, btw, will it stay in multiverse or do we say "it is HW enablement" and can put it into restricted ?
[10:32] <ogra_> technically it is
[10:32] <ogra_> even though its way more than drivers
[10:33] <cjwatson> I understood there was an inclusion review already in progress
[10:33] <xnox> cjwatson: that android package builds both flipped & unflipped: the recovery and android portions. The ubuntu chroot is build by livefs/rootfs-builder. And we deliver both as *.zips to be compatible with adb way of upgrading android phones.
[10:34] <ogra_> xnox, uh, why unflipped ?
[10:34] <ogra_> kthats wasted buildtime imho
[10:34] <ogra_> we wont go back
[10:36] <cjwatson> xnox: Built-Using would be nice, not that we support it properly in Launchpad yet
[10:37] <cjwatson> xnox: I thought we were going to build the application-level stuff (e.g. openssl) as Arch: all -bionic binary packages built out of the corresponding Ubuntu source package?
[10:39] <cjwatson> xnox: Are there bugs for all of the external/* things?  I'm not happy about that staying there for release
[10:40] <xnox> cjwatson: where we can, yes. The priority is to convert - platform-api, libhybris, stgrabers upgrader / recovery bits to do that, to avoid building android package, just to update those faster moving bits. But that means that livefs builder should learn how to fetch -bionic binary packages and update/create .zip & .img files inplace.
[10:41] <cjwatson> It doesn't mean that
[10:41] <ogra_> does it need to ?
[10:41] <cjwatson> You could still assemble it all in the android binary package, just not ship copies of the sources in the android source package
[10:41] <ogra_> we might get away with the system-image.u.c machine doing that
[10:42] <cjwatson> I'm perfectly happy with the stuff in the android package that does assembly of other things
[10:42] <ogra_> since it modifies the files from cdimage anyway
[10:42] <cjwatson> This is a sane thing to do at package build time
[10:42] <xnox> cjwatson: i see what you mean. de-duplicate on source code level.
[10:42] <cjwatson> I just don't want copies of the sources there
[10:43] <xnox> cjwatson: ok. i'll do analysis on what we can do there. In parallel, i'd like to keep $ repo git forest tree working, to bootstrap/develop new devices.
[10:44] <xnox> ogra_: I am pondering about git-bzr support in repo tool
[10:44] <ogra_> well, preferably the bzr trees should vanish
[10:44] <cjwatson> I'll accept this since it's still an improvement on what we're already doing, but I do feel it needs to improve further, especially if we're contemplating moving it to restricted
[10:45] <cjwatson> xnox: Also, I'm happy-ish with the stuff you're doing in the android build that grabs source packages from elsewhere (although it's certainly creative), so you could do that instead if you prefer not to add loads more -bionic binary packages and awkward build-deps
[10:47] <xnox> cjwatson: yeah, i don't think it's wise to add gcc cross-toolchain and adroid build system as a build-dep for low-level packages like busybox / openssl / etc.
[10:47] <cjwatson> Arguably putting the bionic stuff in the android package is better than spreading it all over the archive, I don't know
[10:47] <cjwatson> Yeah
[10:48] <infinity> I think I prefer this crazy ia32-libs style method.
[10:48] <ogra_> well, we need s few bits built with the toolchain that might or might not need android headers
[10:48] <ogra_> (the above mentioned bzr trees should all go into packages)
[10:48] <ogra_> s/s/a
[10:49] <ogra_> (hybris and platform-api, i think the rest of bsr trees is dead anyway)
[10:49] <ogra_> *bzr
[10:50] <xnox> ogra_: but e.g. ondrejs patches to gnupg to add Android.mk, should be applied to gnupg src-package, which then is fetched by "android" package or "repo checkout" and built inline with everything else.
[10:51] <ogra_> oh, yeah, definitely
[10:57] <doko> infinity, eglibc ping
[11:02] <xnox> cjwatson: at the moment android package has the source and does four flavour builds (for each device). This can be "parallised" to have android package create android-src, and then have 4 device source packages, which build-dep on android-src and do only 1 flavour build each. Then the build time will be cut from 41min on one buildd, to 4x15minute builds across 4 buildds. Would that be a useful optimisation, or false economy with slightly increased
[11:02] <xnox> maintenance?
[11:04] <doko> I think that would be wrong. 41min is nothing to optimize
[11:05] <xnox> doko: ok.
[11:07] <cjwatson> xnox: Yeah, I wouldn't bother.  That sort of machine time isn't expensive compared to human time figuring it out later.
[11:08] <cjwatson> You could try parallelising the build on a single machine ...
[11:35] <xnox> cjwatson: well each flavour is build with "--parallel". So the compile steps are fast (the whole build system is single makefile with top level targets).
[11:36] <cjwatson> OK.  I wouldn't worry about it too much.
[11:36] <cjwatson> Are you building faster than Jenkins? :-)
[14:29] <slangasek> cjwatson, infinity: do you guys know what the current holdup is for the linux package? is it this out-of-date d-i that's the last blocker?
[14:30] <cjwatson> slangasek: blocked for alpha-2 AFAIK
[14:30] <cjwatson> oh, it's being unblocked
[14:30] <slangasek> yes
[14:30] <cjwatson> yeah, it's just d-i
[14:30] <slangasek> and d-i FTBFS on powerpc due to an oversized image :/
[14:31] <cjwatson> slangasek: right, infinity is fighting with that at the moment
[14:31] <slangasek> AIUI the -4 kernel has some serious video regressions (which is probably why the freeze has been overridden)
[14:31] <slangasek> cjwatson: so I should keep my nose out and let him work? :)
[14:31] <cjwatson> probably :)  he is swearing
[14:34] <slangasek> heh
[14:34] <infinity> slangasek: Yeah, I unblocked that kernel because of the nasty bug, but the d-i thing is irksome.
[14:34] <slangasek> yep
[14:34] <slangasek> infinity: it's not as simple as upping the size of the disk image?
[14:34] <cjwatson> it's by 150M
[14:34] <infinity> slangasek: If I want to increase it by 150MB, sure.
[14:35] <slangasek> blink
[14:35] <infinity> slangasek: Two of the four PPC flavours have spontaenously stopped being stripped.
[14:35] <infinity> slangasek: Not yet spotting an obvious reason why.
[14:35] <rbasak> Freeze? Because it's Alpha 2 week? The topic says "Archive: open". Is that for something else?
[14:35] <slangasek> and if we forced it with the ppc out-of-date, what would that break for flavors trying to do an alpha2 on ppc?
[14:36] <infinity> rbasak: The archive is open.  britney, on the other hand...
[14:36] <slangasek> rbasak: freeze on saucy-proposed -> saucy migrations, only for packages used in the images of those flavors that are doing the opt-in alpha2
[14:36] <rbasak> I see. Got it - thanks.
[14:37] <infinity> slangasek: Probably.
[14:37] <mlankhorst> can all the lts-raring packages be moved to -updates now?
[14:37] <slangasek> infinity: "what would that break" -- "probably" > ok, message received ;)
[14:40] <infinity> slangasek: I missed the "what". :)
[14:41] <infinity> slangasek: So, given that these are both -0 ABIs, but probably not ABI-compatible, the old d-i build (against 0.3) is likely to not work so well with the -0.5 udebs in the archive.
[14:41] <infinity> slangasek: So, fundamentally, any d-i-based install method would be broken.  Livecds would be fine, but massively oversized (so, broken from most tester's POV)
[14:41] <slangasek> powerpc CDs have been oversized for a while
[14:42] <infinity> Anyhow, I may just disable ppc/ppc64 flavours in d-i for now, declate that no one gets a PPC flavour for Alpha2, and investigate later.
[14:42] <slangasek> right, I'm inclined to think this would be the best option given the degree of breakage in the current -4 kernel
[14:43] <infinity> slangasek: Then again, -5 looks fun too.
[14:43] <infinity> slangasek: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1204005
[14:43] <ubot2`> Ubuntu bug 1204005 in linux (Ubuntu) "[saucy] kvm host hangs of guest boot with 3.10.0-5" [Critical,Triaged]
[14:43] <slangasek> and if we get fixed ppc kernels quickly, there might still be time to revisit for alpha2
[14:46] <infinity> slangasek: Spinning a quick test-build with ppc/ppc64 disabled and will upload that and give people the bad news. :P
[14:47] <slangasek> why do you need a rebuild?  You can just force the out-of-date in britney
[14:48] <infinity> slangasek: Because I'd rather have it build correctly.
[14:49] <slangasek> for the flavors that aren't oversized?
[14:50] <infinity> slangasek: Indeed.
[14:50] <slangasek> ok
[14:50] <infinity> slangasek: And I'd rather have it build, period.  forcing things should be a last-resort, not a knee-jerk go-to
[14:50] <slangasek> it's not a knee-jerk go-to to unbreak x86 kernels for users
[14:51] <slangasek> we can force it, *while* it's building on powerpc
[14:52] <infinity> slangasek: *shrug*... If you want to force it, go ahead.  Note that -5 will break for a different set of users.
[14:53] <infinity> (And people who are already broken have already rebooted into -3, or are stuck not being able to figure out how to upgrade to -5 at all)
[15:07] <slangasek> infinity: except for those of us who don't reboot that often and are still running -2, but don't want to be affected by this bug on next reboot ;-)
[15:08] <infinity> slangasek: Right, well, new d-i is uploading now anyway.
[15:08] <slangasek> ack
[15:08] <slangasek> how long does it take to build?
[15:09] <infinity> slangasek: ~60m on armhf.
[15:10] <slangasek> ok
[15:12] <stgraber> ScottK, Riddell: fine with me letting kubuntu-meta through once it's built? (it's currently part of the big block)
[15:21] <Riddell> stgraber: yeah but is it needed?
[15:31] <stgraber> Riddell: it's not strictly required but I'd love to get rid of appmenu and if I do it now I'll break your builds and from what I understand, the kernels are a bit broken at the moment so you're likely to need a respin anyway
[15:32] <infinity> No likely about it, everyone's getting a respin for the new kernel unless they make a REALLY good argument.
[15:33] <Riddell> stgraber: ok go for it
[15:33] <stgraber> Riddell: ok, doing then
[15:42] <jbicha> could I have empathy 3.8.3-0ubuntu5 unblocked for Ubuntu GNOME?
[15:43] <infinity> jbicha: Yep.
[15:57] <jbicha> could we get the UG cron job stopped too? thanks :)
[15:59] <infinity> jbicha: Sure. You're going to get new images for this kernel, probably.
[16:00] <Riddell> if we're letting new stuff in I might let in kde-runtime cos it didn't get the .95 version in and is out of step with the rest of kde sc
[16:00] <jbicha> that's fine and today's was fine; I just don't need an auto-build tomorrow :)
[16:00] <infinity> Riddell: Go nuts.
[16:01] <Riddell> infinity: that's a dangerous thing to say to me!
[16:01] <infinity> Riddell: It's your Alpha, unblock what you want. :)
[16:01] <xnox> infinity: when kernel lands, will you also respin ubuntu images? as i was trying to do some ubiquity work, but the cd no worky in qemu.
[16:02] <infinity> xnox: Do you expect -5 to work in qemu?
[16:03] <infinity> xnox: Is this the kvm_intel=1-not-passed-correctly bug (which is fixed in -5), or the "cirrus video in kvm blows up the host" bug, which isn't?
[16:04] <infinity> xnox: Anyhow, sure, I can respin ubuntu.  It's not uncronned, mind you, so it'll do itself.
[16:04] <xnox> infinity: i think both, but i guess the latter one will kill me anyway. *sigh*
[16:05]  * xnox only was aware of the former one.
[16:05] <xnox> I guess I need cloud images respun as well.
[16:05]  * xnox goes to use debian d-i
[16:05] <utlemming> xnox: ?
[16:07] <xnox> utlemming: auto-package-testing uses cloud images, to run the tests. And that's what I was working on, qemu-ubiquity-autopilot-auto-package-test
[16:07] <utlemming> xnox: ack, let me know when you need a new cloud image and I'll kick the build for you
[16:08] <utlemming> xnox: I can have an image ~20 minutes but full publication can take about 3 hours
[16:10] <xnox> utlemming: next daily should be fine. or respin after -5 is published, but that's not urgent, as I am a niche case. nothing alpha/release blocking.
[16:55] <phillw> I've requested a full respin of lubuntu on the qa-tracker; can you check that the request has gone through. Many thanks.
[16:56] <stgraber> phillw: it's running
[16:57] <stgraber> phillw: if the tracker says "(re-building)" instead of "(disabled)", that means it's been queued properly and is building somewhere
[16:58] <elfy> stgraber: anyway to find out when the Xubuntu spin will get added?
[16:59] <stgraber> elfy: when you request it? it's self-service nowadays
[16:59] <elfy> someone asked about 8 hours ago I thought
[16:59] <stgraber> elfy: so you need to go on the daily milestone on the tracker, tick the images you want to build and select re-build at the bottom of the page
[17:00] <stgraber> elfy: there's no xubuntu build request in the DB, so no
[17:00] <elfy> mmmm - this is all new to me
[17:00] <stgraber> yeah, sorry, this was introduced in alpha-1 but you didn't participate so weren't contacted back then
[17:00] <elfy> yea
[17:01] <elfy> stgraber: sorry - not quite what I meant - ALL of this release stuff is new to me :)
[17:01] <stgraber> ok ;)
[17:02] <elfy> stgraber: so - how do we get xubuntu build request in the DB
[17:03] <elfy> I can see a mail to the release list from knome about 6 hours ago
[17:03] <elfy> I'll talk to knome later this evening - but we do want to participate
[17:04] <stgraber> elfy: go to http://iso.qa.ubuntu.com/qatracker/milestones/299/builds
[17:04] <elfy> yep
[17:04] <stgraber> elfy: tick your products, go at the bottom of the page and click "Update rebuild status"
[17:04] <rsalveti> xnox: one thing, the name android there can be a bit confusing, as we're not building directly from aosp, for example
[17:04] <stgraber> elfy: ah, wrong page, I meant the Daily page, sorry
[17:04] <elfy> stgraber: done
[17:04] <elfy> oops
[17:04] <rsalveti> xnox: we're using a custom cm-10.1 based source tree, with our changes on top
[17:04] <infinity> phillw: Your full respin was premature, I'm going to be pushing a new kernel into the release pocket shortly, and I'm pretty sure you'll want that.
[17:05] <stgraber> elfy: I meant http://iso.qa.ubuntu.com/qatracker/milestones/270/builds
[17:05] <stgraber> elfy: right
[17:05] <elfy> re-building
[17:05] <rsalveti> xnox: we could as well have one image based on aosp directly in there later on, once we're able to share some of the code
[17:05] <elfy> stgraber: and that will create alpha2?
[17:05] <phillw> stgraber: I'll go cancel, then!
[17:06] <stgraber>  54 | Xubuntu Desktop amd64                    | 2013-07-23 13:05:15 |                     | elfy        |      0
[17:06] <stgraber>  55 | Xubuntu Desktop i386                     | 2013-07-23 13:05:15 |                     | elfy        |      0
[17:06] <stgraber> elfy: yeah, those are on the manifest so they'll show up as alpha-2
[17:06] <cjwatson> phillw: you can't, once it's building
[17:06] <elfy> stgraber: excellent - that was painless - I like that :)
[17:06] <xnox> rsalveti: sure. we have a mixture of: aosp, cynogenmod, clockwork mod, our patches, our upstream projects, and external gnu and non-gnu fsf stuff, oh and 3rd party vendor bits.
[17:07] <stgraber> elfy: any product on this list http://iso.qa.ubuntu.com/qatracker/series/37/manifest will automatically be copied from Daily to the current milestone
[17:07] <xnox> rsalveti: if and when we have another "flavour" of android, we can start namespacing them somewhat more sensible.
[17:07] <phillw> cjwatson: indeed not :/
[17:07] <xnox> rsalveti: but android-asop-cynogenmod-gnu-fsf-et-al would be too long of a name =)
[17:07] <rsalveti> xnox: right, actually this is just cm-10 + our patches :-)
[17:07] <rsalveti> in the android sense
[17:07] <elfy> stgraber: k - think I understand that - don't click the wrong buttons :)
[17:07] <rsalveti> we could have android-cm-10.1 and android-aosp
[17:08] <rsalveti> for example
[17:08] <infinity> phillw: Also, your PPC images are going to probably be non-functional for A2.  You might just want to skip it entirely for this Alpha (we'll fix after).
[17:08] <rsalveti> we don't need to care much about the rest
[17:08] <xnox> rsalveti: i guess we will need to use better names, once we have a second branch, based on top of next aosp or next cm.
[17:09] <phillw> I'll delay sending the email and add in that it has a new kernel. infinity they un functioning in a1 as well. But I'll the PPC testers know not to bash their brains in. Thanks for the heads up.
[17:09] <rsalveti> xnox: but yeah, not for now, just a heads up, as I know we might have some requests to get this built on top of aosp soon as well
[17:09] <rsalveti> xnox: right
[17:10] <xnox> rsalveti: ok. at that point, we can do a rename as well. cause there will be a few things that will need to change to accomodate android flavours.
[17:10] <rsalveti> xnox: how are you creating the source package?
[17:10] <infinity> phillw: My point was that respinning PPC images is probably a horrible waste of time too.
[17:10] <rsalveti> xnox: using http://phablet.ubuntu.com/export/?
[17:10] <xnox> (flavours? forks? brands? release branches?)
[17:10] <xnox> rsalveti: no. I use $ repo sync, with my manifest, which is reduced manifest of the phablet-10.1 branch.
[17:11] <rsalveti> right, and why can't we reduce the original manifest?
[17:11] <xnox> rsalveti: and the debian/rules get-orig-source target generates the proper upstream tarball for me.
[17:11] <rsalveti> specially now with the phablet-saucy branch
[17:11] <rsalveti> sure, it's just that we already have a dump of the repositories there
[17:11] <xnox> rsalveti: we can, it's just it's a few changes, and e.g. jenkins build will fail unless modified accordingly to install additional dependencies.
[17:12] <xnox> rsalveti: and the porting guide needs update, as more things need to be installed, and only available in saucy at the moment.
[17:12] <rsalveti> xnox: right, and we don't want that actually
[17:12] <xnox> rsalveti: awesome.
[17:12] <rsalveti> xnox: so are are you using your branch as base there? or just your custom manifest?
[17:13] <rsalveti> xnox: I'm planning to move our stuff to use the phablet-saucy branch today
[17:13] <xnox> rsalveti: I'll draft an email with patch series and everything that needs changing.
[17:13] <xnox> rsalveti: oh, I see.
[17:13] <phillw> infinity: stgraber they can be removed from the A2 manifest. I've just emailed the PPC lubuntu team to let them know.
[17:13] <rsalveti> right, so that's why I want to get the most changes you had there in that branch
[17:13] <rsalveti> so we can start using that branch as base for your source package
[17:14] <rsalveti> and remove whatever repo we want during build time, so we don't need to maintain 2 different manifests
[17:14] <xnox> rsalveti: http://paste.ubuntu.com/5904749/
[17:14] <stgraber> phillw: just don't request a build for it and it won't show up again
[17:14] <xnox> rsalveti: that's the changes to my manifest, wait that's not all.
[17:15] <xnox> rsalveti: http://paste.ubuntu.com/5904752/
[17:15] <infinity> phillw: Cool, thanks.  Ben and I will get the kernel issue fixed post-Alpha.
[17:15] <phillw> stgraber: okies :)
[17:16] <rsalveti> xnox: cool, guess we can remove most but the prebuilts
[17:16] <rsalveti> as we're replacing that with local tools and such
[17:16] <xnox> rsalveti: all prebuilts are gone =)
[17:17] <xnox> rsalveti: i pushed my manifest as people/xnox branch in the manifest repo, but well it needs rebasing/merging with phablet-saucy branch.
[17:17] <rsalveti> sure, no worries
[17:17] <rsalveti> will get some of your stuff merged and see if I can still produce a valid build
[17:18] <rsalveti> then we just need to sync to update your package, but probably tomorrow
[17:18] <xnox> rsalveti: android packaging the top level "debian/" dir is: https://github.com/xnox/android
[17:18] <xnox> rsalveti: and in there you will see 6 patches
[17:18] <rsalveti> xnox: right
[17:18] <rsalveti> xnox: why not a bzr branch?
[17:19] <rsalveti> somewhere where core-devs could also push stuff
[17:19] <xnox> rsalveti: they are fairly self-explanatory. The tricky ones are that, prevent arbitrary network access. E.g. in debian/rules I sue chdist to access ubuntu mirror to pull things instead of using pull-lp-bin / pull-lp-source
[17:20] <rsalveti> xnox: right
[17:20] <rsalveti> that might need a bit of rework, but should be fine
[17:20] <xnox> rsalveti: i want it in git, to be able to do $ repo sync, but I guess this can be made into a bzr branch. Afterall we are fetching a bunch of stuff inline anyway from all over the place.
[17:20] <xnox> rsalveti: i can look into reworking it, right after I am back from the gym.
[17:20] <phillw> infinity: can you please give me a ping / send an email to ubuntu-release when the new the kernel is read for triggering a rebuild. Thanks :)
[17:21] <xnox> rsalveti: it's EOD here. And i guess I should help with rebasing those patches on to the saucy branch =)
[17:21] <xnox> rsalveti: i'm off on holiday till monday as well.
[17:21] <infinity> phillw: It'll probably be after A2, so it'll be in a cronned daily, no need to force any rebuilds.
[17:22] <xnox> rsalveti: are there phablet-saucy branches for most projects? i can rebase and push those patches one by one.
[17:22] <xnox> rsalveti: or do you prefer me to email them, for peer review from sergiusens & yourself?
[17:22] <rsalveti> xnox: I'll review all the patches there, and get those applied (the ones that are not package specific)
[17:23] <rsalveti> xnox: seems you're manually doing repo init and sync, right?
[17:23] <rsalveti> that's not part of get-orig-source
[17:24] <xnox> rsalveti: some of them change behaviour drastically, for example instead of prebuilt sdk/ndk, I ask all modules to link against the just-compiled-bionic and some such. Which might not be abi stable. But we are not at the moment providing bionic in a way for other packages to compile for androideabi.
[17:24] <xnox> rsalveti: right, yes, just $ repo init; repo sync. Clone in the debian (can't remember if i added it to the manifest or not).
[17:24] <rsalveti> right
[17:25] <xnox> rsalveti: get-orig-source target only generates the tarball as appropriate for upload into the archive.
[17:25] <xnox> rsalveti: so it's very packaging specific.
[17:25] <rsalveti> xnox: right, but it'd be nice to automate the repo sync part as well
[17:25] <rsalveti> so I can just fire up a command and get a tarball in the end
[17:25] <stgraber> elfy: there you go ^ note that those are broken and you'll need to respin once we get the new kernel+d-i in the release pocket (or infinity will just respin everyone)
[17:25] <rsalveti> that's why I was thinking if we could already use the exported tarball from phablet.u.c
[17:26] <rsalveti> we can strip that one if needed
[17:26] <rsalveti> like, you're not pointing out your custom manifest in the package itself
[17:26] <xnox> rsalveti: i would be nice to publish daily tarball, without all the extra bits. I didn't find where/how the export tarball is generated at the moment.
[17:26] <rsalveti> so it's hard to reproduce and create the same orig tarball unless you really know what is happening there :-)
[17:27] <xnox> rsalveti: if you look at the debian/rules, it's using my manifest, ignores a few extra files / partially selects what to include and tars everything up under a $name.
[17:27] <rsalveti> xnox: there's a cron job that takes care of that in phablet.u.c, we can change that to create the tarball we need for this package
[17:27] <xnox> rsalveti: that would be nice. cause then we can do $ uscan && uupdate && debuild -S && dput ubuntu ../*.changes
[17:28] <rsalveti> exactly
[17:28] <rsalveti> xnox: alright, I'll put some time into this, we can sync once you're back
[17:28] <xnox> rsalveti: and fully automatically do the uploads, and only get repo tool involved in the android development.
[17:28] <rsalveti> right, that would be nice indeed
[17:28] <elfy> stgraber: thanks
[17:28] <xnox> rsalveti: right, i'm off to the gym, but ping me if there is anything else. will be back later to read scrollback =)
[17:29] <rsalveti> xnox: sure, thanks, enjoy
[17:30] <infinity> slangasek: Kernel's promoted sorry about the delay.  bad_timing++
[17:32] <slangasek> infinity: thanks for following through :)
[17:32] <phillw> infinity: ack
[18:24] <infinity> Rebuilding all the A2 images for the new kernel.  Enjoy.
[18:29] <phillw> infinity: I'll send a new email :)
[18:32] <phillw> infinity: I take it that this will *not*  solve the PPC issue and this is still going to be post alpha 2?
[18:33] <infinity> phillw: Right.
[18:35] <phillw> infinity: thanks! (I've got a meeting in 1.5 hours and I do like to have the most up to date information for all the testers :) )
[19:23] <jbicha> the amd64 manifest is outdated on http://cdimage.ubuntu.com/ubuntu-gnome/daily-live/current/
[19:31] <xnox> rsalveti: sent email with first rebase of patches and a small todo list of remaining things i should rebase and send your way =)
[19:33] <rsalveti> xnox: great, thanks
[19:34] <rsalveti> xnox: nothing here yet
[19:35] <xnox> rsalveti: https://lists.launchpad.net/ubuntu-phone/msg03304.html
[19:35] <rsalveti> xnox: thanks
[19:35] <xnox> rsalveti: i wonder if you seen my previous patches i have been sending the same way...... or simply lag =)
[19:35] <rsalveti> xnox: we just had 2 crazy weeks, so might still be in the backlog
[19:36] <rsalveti> but will check, things are getting back to normal
[22:15] <darkxst> infinity, hi, can you turn of the ubuntu gnome cron jobs?
[22:16] <Laney> darkxst: they are off
[22:17] <darkxst> ok cool
[23:15] <rsalveti> can someone look at maliit-frameworks? new release, and a new lib package
[23:16] <rsalveti> slangasek: in case you're around ^ this will remove another package from our ppa
[23:16] <rsalveti> sergiusens: ^^