[00:00] <jbicha> hi, cogl failed to build on arm & I don't know enough to fix it
[00:39] <jbicha> so, how does the new queue work for new binary packages?
[00:40] <jbicha> can we reject cogl until we figure out how to get it to build on ARM? as the new cogl will break gnome-shell
[00:41] <infinity> jbicha: I can reject the binaries, sure.
[00:42] <slangasek> rejecting new binaries should really only be done for wrongly named packages that have to be done anyway, or very grave bugs
[00:43] <slangasek> is there a bug open for this gnome-shell issue?
[00:43] <infinity> slangasek: In this case, the request to reject until he fixes the FTBFS, so he doesn't have to deal with skew in one direction or the other doesn't hurt my feelings. :)
[00:43] <infinity> slangasek: The issue is, I assume just that gnome-shell needs to be updated for the new cogl.
[00:43] <infinity> jbicha: That said, you could just make sure gnome-shell has versioned build-deps, and it would be dep-wait on arm*
[00:43] <slangasek> jbicha: is it the skew you were worried about?  that wasn't clear to me
[00:44] <jbicha> and I think continuing the gnome-shell/clutter transition wouldn't be a good idea
[00:44] <infinity> slangasek: Ahh, I had a bit more context from the ARM channel.
[00:44] <infinity> slangasek: cogl->clutter->gnome-shell is the dependency chain, and if cogl's broken, there's not much point in carrying forward until it's fixed.
[00:44] <slangasek> ah
[00:49] <jbicha> slangasek: the cogl/clutter transition bug is bug 941617 by the way
[00:49] <ubot2`> Launchpad bug 941617 in clutter-1.0 "FFe: Update clutter/cogl to 1.9" [Wishlist,Confirmed] https://launchpad.net/bugs/941617
[00:49] <slangasek> ack
[00:52] <infinity> jbicha: Anyhow, bug me about help with cogl tomorrow afternoon if janimo hasn't magically fixed it overnight for you. ;)
[00:53] <jbicha> infinity: thanks
[12:52] <knome> stgraber, ?
[12:53] <knome> stgraber, if the non-pae kernel is doable for xubuntu, we're all in!
[12:59] <cjwatson> please file a bug on the ubuntu-cdimage project asking for it, and assign it to me
[13:00] <knome> okay, thanks :)
[13:05] <greyback> skaet: Hi, as agreed, Unity2D are working on releasing a mini-release today. We're in final testing mode now, but can you please look at https://bugs.launchpad.net/unity-2d/+bug/954175
[13:05] <ubot2`> Launchpad bug 954175 in unity-2d "[FFe] [UIFe]: Multimonitor support for Unity-2d" [Undecided,New]
[13:05] <greyback> skaet: I'm off for luch now, will be back in 45 mins or so
[13:32] <knome> cjwatson, https://bugs.launchpad.net/ubuntu-cdimage/+bug/955009
[13:32] <ubot2`> Launchpad bug 955009 in ubuntu-cdimage "Use non-pae kernel on i386 for Xubuntu 12.04" [Undecided,New]
[13:36] <cjwatson> saw it in mail, thanks
[13:54]  * ogra_ really likes to see the "highlighting-kate" package on -changes every now and then ... its the "get release manager attaention" tool, right ? :)
[13:57]  * Laney is an attention seeker
[13:58] <Laney> that transition is more than half done now… should go below 200 today…
[14:20] <greyback> skaet: ping
[14:22] <skaet> greyback,  have gone in and approved.   Thanks.
[14:22] <greyback> skaet: many thanks to you
[15:40] <skaet> Riddell,   MIR - fontskanjistrokeorders,  is there someone working on resolving the issues flagged in the bug?    I'm not sure it meets the definition of critical priority though, am adjusting to high.
[15:52] <Riddell> skaet: what's the bug number?
[15:52] <skaet> https://bugs.launchpad.net/ubuntu/precise/+source/fonts-kanjistrokeorders/+bug/918289
[15:52] <ubot2`> Launchpad bug 918289 in fonts-kanjistrokeorders "[MIR] fonts-kanjistrokeorders" [High,Incomplete]
[15:53] <Riddell> mm right, I guess he marked as critical because it's illegal to ship it like that
[15:54] <Riddell> I'll take a look when I can
[15:54] <skaet> thanks
[15:58] <skaet> Daviey,   looking at the MIRs for server,  there seem to be some server ones without priority (netcf, python-keystoneclient, python-cherrpy, vblade-persist, ceph)  could you take a pass and prioritize?
[15:59] <Daviey> skaet: Oh aye.. Expect them to double within the next two days. :(
[16:00] <skaet> Daviey, *sigh* not what I wanted to hear....  :P   please prioritize the ones there now,  so our precious MIR resources focus on the most important ones then.
[16:10] <infinity> skaet: But Daviey loves all his children equally.
[16:12]  * ogra_ wasnt aware Daviey had reproduced already
[16:43] <skaet> didrocks,  whats' the current ETA for compiz 0.9.7.2 (was expecting it on monday?)
[16:43] <didrocks> skaet: compiz? no
[16:43] <didrocks> skaet: we landed a trunk snapshot in monday
[16:43] <didrocks> which is 0.9.7.0+bzr…
[16:44] <didrocks> but never planned to announce it as 0.9.7.2
[16:44] <didrocks> who told that?
[16:44] <skaet> Compiz 0.9.7.2 planned for Monday  was in last week's status...
[16:44] <skaet> https://wiki.ubuntu.com/DesktopExperienceTeam/ReleaseStatus
[16:44] <didrocks> well, I'm not the one filing this… I told dbarth that wasn't accurate
[16:45] <didrocks> so you get a new compiz
[16:45] <didrocks> which is basically "trunk"
[16:45] <didrocks> on Monday
[16:45] <didrocks> not sure how it was officially mixed with a 0.9.7.2 release, which is just a tag at the end :)
[16:46] <skaet> thanks for clarifying.
[16:46] <skaet> am trying to figure out what's left to land.
[16:47] <skaet> unity 5.8,  unity-2d 5.8 (both bug fix releases) is on my radar for next week.
[16:47] <didrocks> right
[16:47] <skaet> will there be a compiz or nux drop?
[16:47] <didrocks> and unity-2d with multimonitor, as we discussed, this week
[16:47] <skaet> yes
[16:47] <didrocks> (testing ending)
[16:47] <didrocks> yeah, when we talk about unity, it's in fact:
[16:48] <didrocks> dee, libunity, nux, unity-lens-files, unity-lens-applications, unity-lens-music, unity, (and some compiz pieces)
[16:48] <didrocks> ah, and bamf
[16:48] <skaet> are some bits landing before, or is it all going to hit simultaneously?
[16:49] <didrocks> skaet: no, all components are intermixed unfortunately
[16:49] <didrocks> but when we do community testing
[16:49] <didrocks> it's on all the bits as well
[16:50] <didrocks> so we are quite clear about the "stack" statuts
[16:50] <didrocks> status*
[16:50] <skaet> where should I be looking for the plans?
[16:50] <didrocks> what do you mean by "the plans"?
[16:51] <skaet> which bits of the stack are dependent on each other and tested together.
[16:51] <didrocks> skaet: basically all of this are tested together
[16:52] <didrocks> skaet: if you want to see what the packages are updataed:
[16:52] <didrocks> https://launchpad.net/~unity-team/+archive/staging
[16:52] <didrocks> when we launch the test:
[16:52] <didrocks> https://launchpad.net/~unity-team/+archive/ppa
[16:52] <didrocks> so basically, every components that are not "grey" (meaning, there is a higher version in the ppa than in precise) is planned to be released, for now
[16:53] <didrocks> like you can see, there has been no new bamf commit for now (the line is grey)
[16:53] <skaet> didrocks,  yes, understand they're tested together - trying to get forecast though of what's being assembled together.   Where bug fixes emerging, etc.
[16:53] <didrocks> skaet: ah bug fixes, that's different
[16:53] <didrocks> skaet: so, I have a distro priority list:
[16:53] <didrocks> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuMtju1x8UoEdDNCT1U5MlVodjIwNGJPdnU5YVltVmc#gid=1
[16:54] <didrocks> those are all the bugs that are due/important for precise ^
[16:54] <didrocks> for what is planned, you have the milestoned:
[16:54] <didrocks> https://launchpad.net/unity/+milestone/5.8.0
[16:54] <didrocks> but unfortunatly, there are too many bugs that they can close in the milestone
[16:55] <didrocks> so keep an eye on the "fix committed" ones (when upstream updates the status, which is, unfortunatly, not everytime the case)
[16:57] <skaet> didrocks, I'll go do some cross checking and get back to you,  am a bit worried about some of the bugs that are indicated as critical from a release perspective and have been lingering.
[16:58] <didrocks> skaet: what do you mean, the bugs that you have on your list?
[16:59] <didrocks> skaet: if you have concerns about the rate of fixing (that I do have as well), please see with thumper
[16:59] <didrocks> so that I'm not the lonely voice :)
[16:59] <skaet> didrocks,  :)   bugs that have been indicated as blockers for the release (ie. milestoned/critical/release targetted)...   checking on them now.
[17:00] <didrocks> skaet: ah ok ;)
[17:00] <didrocks> skaet: normally, they should be on the priority list as well (but it's better if you ping me with the list)
[17:01] <skaet> didrocks,  will do.
[19:37] <skaet> knome,  re: the logo question yesterday,   as long as you let the docs folk know about it,  it should be fine as long as it lands this week. (so time to catch the oop's next week ;) )
[19:37] <skaet> knome,  please let me know the bug number to sign off on.
[19:38] <knome> thanks skaet, will file a bug right after the xubuntu community meeting and get back to you with it :)
[19:43] <knome> skaet, https://bugs.launchpad.net/ubuntu/+source/xubuntu-artwork/+bug/955396
[19:43] <ubot2`> Launchpad bug 955396 in xubuntu-artwork "New Xubuntu logo" [Undecided,Confirmed]
[20:37] <skaet> slangasek,  netboot images,  just noticed the ones on the daily image tracker are pretty old/stale,  and paths aren't matching where the current ones are being posted.    Was there a decision made not to keep them on cdimage at some point?
[20:38] <skaet> current images: http://archive.ubuntu.com/ubuntu/dists/precise/main/installer-amd64/current/images/netboot/
[20:38] <skaet> is linked to from: http://cdimage.ubuntu.com/netboot/precise/
[20:38] <slangasek> skaet: the netboot images have never been stored on cdimage; not sure I understand the question
[20:39] <slangasek> where are they linked on the daily image tracker? http://iso.qa.ubuntu.com/qatracker/milestones/204/builds only shows omap4
[20:39] <skaet> am trying to cut/paste but its not cooperating... :P   just a sec
[20:40] <skaet> http://cdimage.ubuntu.com/netboot/daily/VERSION/precise-netboot-amd64.iso
[20:40] <skaet> showing up as a download link for amd64..
[20:41] <slangasek> really?
[20:41] <slangasek> because that doesn't exist on the server
[20:41] <slangasek> (nusakan)
[20:41] <slangasek> where do you see that link?
[20:42] <slangasek> it's never been correct AFAIK
[20:42] <skaet> looking in the iso tracker.
[20:42] <slangasek> ok, where in the ISO tracker :)
[20:42] <skaet> http://iso.qa.ubuntu.com/admin/config/services/qatracker/products
[20:42]  * slangasek looks
[20:42] <skaet> under Netboot amd64 - download link, from admin page
[20:42] <slangasek> aha
[20:42] <skaet> am also noticing others are missing completely,  so
[20:42] <slangasek> yes, that's incorrect
[20:43] <skaet> cleanup time I think.
[20:44] <slangasek> yes, looks like cut'n'paste error at some point; cleaning up
[20:44] <skaet> awesome.  thanks!
[20:45] <skaet> you going to handle them all,  or do you want me to take some.
[20:45] <skaet> ?
[20:45] <slangasek> I'll get 'em all
[20:45] <skaet> coolio
[20:45] <skaet> :)
[20:46] <slangasek> http://iso.qa.ubuntu.com/admin/config/services/qatracker/products/47/downloads should be more meaningful now
[20:52] <slangasek> ogra_, infinity: ^^ I'm trying to work out which bits from http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/20101020ubuntu118/images/omap/netboot/ (et al) should be linked from the ISO tracker... do these files really have to all be downloaded individually?
[20:54] <slangasek> ogra_, infinity: or is the boot.img-* an all-in-one netbootable image?
[20:59] <slangasek> skaet: so the one thing missing from my perspective is that the "daily testing" page (http://iso.qa.ubuntu.com/qatracker/milestones/204/builds) links to version 20120113... that's not a version number for the netboot images, which only get rebuilt when the installer is uploaded
[20:59] <slangasek> so the real version number is 20101020ubuntu118
[20:59] <slangasek> is that getting auto-populated somewher?
[20:59] <slangasek> stgraber: ^^
[21:01] <stgraber> slangasek: they are currently manually added, so whoever last added them (might well have been me) did it with the current date
[21:02] <stgraber> slangasek: so you're saying we should use whatever's the latest version of debian-installer for that? if so, I'll add it to a cron here so it's checked once an hour and bumped if needed
[21:06] <slangasek> stgraber: yeah, I think that's the only value that makes sense there for a version
[21:06] <slangasek> since if we're testing the netboot image, that's the granularity that matters
[21:07] <stgraber> slangasek: ok, writting the script now. Please keep the broken version for now, I'll test the script on it to make sure it works
[21:10] <slangasek> ok
[21:20] <stgraber> slangasek: done
[21:22] <slangasek> yay, thanks
[21:39] <Laney> please could somebody process bug #955204 :-)
[21:39] <ubot2`> Launchpad bug 955204 in haskell-binary "Remove from Precise -- included in GHC" [Undecided,Confirmed] https://launchpad.net/bugs/955204
[21:41] <slangasek> looking
[21:41] <Laney> having it in makes some builds break
[21:42] <slangasek> removed
[21:42] <Laney> i'm filing some others, but they aren't urgent
[21:42] <Laney> cheers
[21:42] <skaet> slangasek, stgraber,  re: netboot.  Thanks.
[21:43]  * skaet just catching up on IRC after phone calls....
[22:07] <ogra_> slangasek, boot.img should be an SD card image, youu wont boot a beagle XM without SD (or a directly attached USB OTG server)
[22:08] <ogra_> that we have the contents separately available too helps with qemu-system
[22:09] <slangasek> ogra_: SD card image? I don't understand; these are labelled 'netboot'
[22:09] <ogra_> well, they are netinstall images, the beagle XM cant actually do a real netboot since you need MLO and u-boot locally
[22:10] <slangasek> so they're being packaged in the wrong directory in d-i?
[22:10] <ogra_> and there is no NADA
[22:10] <ogra_> err
[22:10] <ogra_> NAND
[22:10] <slangasek> if there's no support for actually booting kernel+initrd over the network here, it shouldn't be in a directory called "netboot", that's just confusing
[22:11] <ogra_> well, kernel and initrd can be used over the network and run a netinst d-i session
[22:11] <slangasek> used over the network how?
[22:11] <ogra_> to do that you would create an SD where you put MLO, u-boot and boot.scr in place, in boot.scr you define that it should PXE boot
[22:12] <ogra_> u-boot then pulls kernel and initrd via tftp
[22:13] <slangasek> and the uImage and uInitrd that are shown in that directory can be booted via tftp that way?
[22:13] <ogra_> using the boot.img you can avoid the SD creation if you want
[22:13] <ogra_> right
[22:13] <slangasek> how does boot.img let you avoid it?
[22:13] <slangasek> (is any of this documented somewhere?)
[22:13] <ogra_> its just for convenience (though i think NCommander includes kernel and initrd in the boot.img, which actually makes it a "netinst iso")
[22:14] <slangasek> ok, so the boot.img is a dd'able image containing the MLO, u-boot and boot.scr
[22:14] <slangasek> plus, maybe, the uImage and uInitrd
[22:14] <ogra_> i dont think its largely documented, i worte documentation for the very first implementation i did for lucid
[22:15] <ogra_> but that very likely was removed during a wiki cleanup
[22:15] <slangasek> heh
[22:16] <slangasek> http://testcases.qa.ubuntu.com/Install/ARM/NetBoot
[22:16] <ogra_> yeah, right, you can (or better should be able to, i havent tested that in ages, GrueMaster uses it though) use it for a real netboot with SD "jumpstart"
[22:16] <slangasek> ogra_: ^^ that's what's linked from the iso tracker - could you review it please and see if anything needs improving?
[22:16] <ogra_> will do
[22:17] <slangasek> ta
[22:17] <GrueMaster> slangasek: It looks right for omap4.  I'll need to edit it when we add armadaxp to the tracker though.
[22:17] <ogra_> yeah, looks fine
[22:17] <GrueMaster> Considering I wrote it last cycle.  :)
[22:18] <ogra_> the variant where you create your own SD from the separate parts should be documented somewhere though
[22:18] <slangasek> the NAND limitation is beagle-only, isn't it?  IIRC panda has NAND
[22:18] <ogra_> nope
[22:18] <ogra_> nothing has nand nowadays
[22:18] <slangasek> ogra_: right, but "assemble your own" doesn't need to be documented in the test case... that can go elsewhere
[22:18] <ogra_> you have either eMMC (if you are lucky) which is a lot cheaper than NAND ... or nothing and an SD slot
[22:18] <slangasek> GrueMaster: ah, ok :)
[22:18] <GrueMaster> the nand limitation only affects BeagleBoard.  Not XM or newer.
[22:19] <GrueMaster> The only change to the test case is for armhf.
[22:19] <ogra_> i dont think even linaro has any boards that have NAND atm
[22:19] <slangasek> ogra_: well, I'm less interested in the specific flash technology built in than I am in whether it's present and loaded with a netboot-capable u-boot :)
[22:20] <slangasek> so eMMC vs. NAND shouldn't matter?
[22:20] <ogra_> indeed
[22:20] <ogra_> as in: both are persistent storage it wont matter indeed
[22:20] <GrueMaster> afaik, the only officially supported netboots going forward are omap4 and server platforms as they come online.
[22:20] <ogra_> nontheless, we dont support any such devices atm
[22:21] <slangasek> GrueMaster: sure
[22:21] <ogra_> right, we shouldnt drop omap3 (huge community behind it) but we dont need to officially support it
[22:21] <slangasek> anyway, it sounds like I'm already pointing to the right files now on the ISO tracker as a happy coincidence
[22:21] <ogra_> (we also get it for free from the mainline kernel)
[22:21] <slangasek> GrueMaster, ogra_: thanks for confirming
[22:21] <ogra_> :)
[22:22]  * ogra_ vanishes again for some late dinner
[22:23] <GrueMaster> Ah, I see you added armadaxp and omap to the tracker.  Not sure if we will continue testing omap.  omap4 for sure and armadaxp (I was actually going to ask for it to be added as soon as the 3.2 kernel hits the pool).
[22:24] <GrueMaster> At any rate, I have to leave for the day.