=== desrt_ is now known as desrt
=== rickytaylor26 is now known as ricky26
=== ericm|ubuntu is now known as ericm-afk
[08:11] <Xase>  lilstevie, any thoughts?
=== ericm-afk is now known as ericm
=== highvolt1ge is now known as highvoltage
[09:30] <jamespage> good morning: should we be enabling neon support for libraries that support it for ARM on Ubuntu?
[09:31] <infinity> jamespage: If they do runtime detection yes, if not, no.
[09:31] <infinity> jamespage: (Not all our targets support neon, so we can't use it by default)
[09:31] <jamespage> infinity, great - thats what I thought but wanted to check first - thanks!
[09:32] <infinity> (We have lots of code in the archive that does runtime neon detection, and it's a huge win when you can)
[09:32] <infinity> libjpeg-turbo being an obvious one.  Pretty sure there's handcrafted neon in libssl.  Etc, etc.
[09:32] <infinity> Well, it's a huge win if it's well-written neon. :P
[09:42] <ppisati> infinity: do you know if any babbage builder is using the kernel with the "large mmap() support"?
[09:42] <ppisati> bug 861296
[09:42] <ubot2> Launchpad bug 861296 in linux "mmap fails to allocate 2030Mb heap on ARM" [High,Confirmed] https://launchpad.net/bugs/861296
[09:50] <ppisati> infinity: or do you know to whom shall i talk for the arm builders?
[09:51] <ogra_> lamont
[09:51] <ogra_> but i think he switched tham already
[09:51] <ogra_> or at least he tested that kernel on one
[09:59] <ppisati> OlivierN: mail sent
[09:59] <ppisati> ops
[09:59] <ppisati> ogra_: ^
[10:01] <ogra_> :)
[10:20] <lool> Hey
[10:20] <lool> would someone know why "step" isn't built on ARM?
[10:20] <lool> it seems to be purposedly disabled on Ubuntu only
[10:20] <lool> (and this means kdeedu is uninstallable on armel)
[10:36] <ogra_> lool, i dont think anyone fo ubuntu-arm touched it ... probably the kde people did
[10:36] <ogra_> *of
[11:16] <infinity> lool: Arch is specified in the source, no idea why.  If it builds and runs, by all means, change that.
[11:26] <lool> infinity: It seems to be an intentional change from Riddell, see latest changelog entry, that's why I was digging a bit
[11:27] <lool> it's built in experimental (on armel)
[11:42] <infinity> lool: Looks like it's been like that since it was first uploaded to oneiric.  No clue why.
[13:08] <lool> since I couldn't commit to its Vcs-Bzr which doens't exist, I've pinged the kubuntu team
[13:34] <infinity> jcrigby: Are you going to have time to do some judicious s/armel/armel armhf/ (and other required tweaks) mojo on uboot-linaro and assorted kernels soon?
[13:37] <ogra_> oh, surprise, banshee failed on armhf
[13:39] <ogra_> infinity, do we still need the linux-libc-dev entry in the topic ? looks like it built
=== infinity changed the topic of #ubuntu-arm to: Ubuntu ARMv7 Discussion & Development | https://wiki.ubuntu.com/ARM | Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Get oneiric while it's hot ! http://cdimage.ubuntu.com/releases/11.10/release/ | Logs at http://irclogs.ubuntu.com/ | armhf builds are running
[13:41] <infinity> Nope.
[13:41] <infinity> adconrad@cocoplum:~$ suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/precise/main/binary-arm*/Packages.gz gt | wc -l
[13:41] <infinity> 238
[13:41] <infinity> Only 238 binary packages in main different (or missing) compared to armel.
[13:41] <ogra_> yay
[13:48] <ogra_> and only 4800 jobs in the queue
[13:48] <ogra_> not bad
=== cmagina_ is now known as cmagina
[14:31] <doko_> infinity, is this suite-diff command complete?
[14:32] <infinity> doko_: The copy in ~adconrad/bin is.
[14:32] <infinity> Well, FSVO "complete".  It's a hackish fix of a hackish branch of Colin's.
[14:35] <doko_> good enough
[14:38] <doko_> infinity, why is apr rescored to -1?
[14:39] <infinity> doko_: Testsuite that hangs on the buildds, if I recall.  Was saving it for "later".
[14:39] <infinity> (Or until I had a chance to look at it)
[14:40] <doko_> ok, starting a local build
=== ericm is now known as ericm-Zzz
[15:03] <jcrigby> infinity, tell me about armhf and u-boot, u-boot does no floating point
[15:04] <jcrigby> infinity, I think I just answered my own question.  U-boot should be built for both and go into both archives?
[15:06] <infinity> jcrigby: Yup.
[15:06] <infinity> jcrigby: Same story with kernel packages.
[15:06] <infinity> jcrigby: But u-boot's our current blocker.
[15:07] <doko_> infinity, apr tests run fine here
[15:08] <infinity> doko_: Whacky.  Which kernel and hardware?
[15:08] <infinity> doko_: But I'm happy to potentially eat a buildd to find out.
[15:10] <doko_> infinity, oneiric panda
[15:10] <infinity> Kay.  The buildds are natty panda, but we can try.  I'm game.
[15:10] <infinity> Score it up.
[15:16] <kenws> Hi there, I noticed that the Packages.gz for armel on Oneiric has gcc-avr 4.3.5 while on x86 it's 4.5.3. The funny thing is that 1) avr-libc depends on gcc-avr 4.5.3 and 2) the gcc-avr 4.5.3 deb is actually available.
[15:16] <kenws> http://paste.ubuntu.com/760527/
[15:17] <infinity>    gcc-avr |  1:4.3.5-1 | oneiric/universe | armel
[15:17] <infinity>    gcc-avr |  1:4.5.3-2 | oneiric/universe | source, amd64, i386, powerpc
[15:17] <ogra_> looks like NBS
[15:18] <kenws> infinity: yeah, but the avr-libc for armel depends on gcc-avr 4.5.3
[15:18] <infinity> kenws: The reason the deb is there is because it was built in precise.
[15:18] <kenws> infinity: ok, I see.
[15:18] <infinity> avr-libc is arch:all, hence the weird dep.
[15:19] <kenws> aah, ok - interesting
[15:20] <kenws> I haven't tried it but it looks like there is no easy way (without apt pinning) to get avr-libc installed on armel oneiric.
[15:20] <infinity> That should have been tidied and removed before release. :/
[15:20] <infinity> Would be just as broken, but less confusing.
[15:20] <ogra_> yep
[15:20] <infinity> You could always try running precise. ;)
[15:20] <kenws> : )
[15:20] <ogra_> armhf indeed :)
[15:21] <kenws> dOh, wdo we have armhf packages for precise already?
[15:21] <ogra_> sure
[15:21] <kenws> s/dOh/Oh/
[15:21] <kenws> cool
[15:21] <infinity> No installers yet, and missing some desktop bits (and lots of universe), but we're getting there.
[15:21] <ogra_> send flowers to infinity
[15:21] <ogra_> looks good for FF if we dont hit a bad disaster now
[15:23] <infinity> Yeah, I think we're going to be fine.
[15:23] <infinity> It might actually be in better shape than armel soon. :P
[15:23] <ogra_> well, lets see how the build system behaves
[15:23] <infinity> (Which won't hurt my feelings at all)
[15:23] <ogra_> i expect a bunch of changes to the subarch bits
[15:23] <infinity> Which build system?
[15:23] <ogra_> (image builds i mean(
[15:23] <kenws> so, the way for armhf is to deboostrap a rootfs or are there better ways?
[15:23] <infinity> d-i's done, livecd-rootfs is done, live-build is done.
[15:24] <infinity> All we need is uboot and kernels.
[15:24] <ogra_> kenws, use ubuntu-core
[15:24] <ogra_> infinity, cdimage and debian-cd
[15:24] <infinity> I did cdimage.
[15:24] <infinity> debain-cd is cake.
[15:24] <infinity> I'll do it tomorrow.
[15:24] <ogra_> there are plenty areas weher we check for armel
[15:24] <ogra_> *where
[15:24] <infinity> Like i said, cdimage is all done. :P
[15:24] <kenws> ogra_: ok, thanks
[15:24] <infinity> debian-cd won't take long.
[15:24] <ogra_> k
[15:25] <xranby> infinity: debootstrap of armhf are ticking on nicely... thanks!
[15:31] <kenws> will there be a precise release for the softfp abi as well?
[15:31] <infinity> kenws: Yes.
[15:31] <ogra_> might be an unsupported one though
[15:31] <infinity> kenws: But only one of them (probably armhf) will get official LTS support.
[15:32] <ogra_> which will get really funny wrt binary drivers
[15:32] <infinity> Binary drivers are going to be fun.
[15:32] <kenws> ok, so lets that the proprietaryGL libs will be available for hf as well ; )
[15:32] <kenws> yep
[15:32]  * kenws is looking for the ubuntu-core root fs
[15:32] <infinity> We have some good relationships with some vendors who will (hopefully) DTRT there.
[15:32] <infinity> But not all vendors.
[15:32] <ogra_> well, i think TI might be with us here if we can actually provide them a build and test env early enough
[15:33] <ogra_> but for others ...
[15:33] <kenws> which abi a the binaries in the precise-core-armel.tar.gz? (http://cdimage.ubuntu.com/ubuntu-core/releases/precise/alpha-1/)
[15:33] <ogra_> dont take A1
[15:33] <ogra_> take the last daily that built
[15:33] <ogra_> (and that should have the most recent abi)
[15:33] <kenws> ok, so http://cdimage.ubuntu.com/ubuntu-core/daily/current/
[15:34] <ogra_> right
[15:34] <kenws> thanks
[15:34] <infinity> ubuntu-core will actually be producing dailies again shortly.  Just fixing the buildd right now. :P
[15:35] <infinity> kenws: As for "which abi", armel is always softfp, armhf is always hard.  That's the point of having two. ;)
[15:39] <kenws> infinity: I agree : ). when I looked a the alpha-1 there was only one tarball and I didn't know how the binaries were built
[15:39] <infinity> kenws: Yeah, I landed all this post-A1. ;)
[15:39] <lilstevie> also, nvidia do have hf binary drivers for tegra
[15:39] <infinity> lilstevie: \o/
[15:39] <ogra_> yay, where ?
[15:40] <lilstevie> trimslice developer forums
[15:40] <infinity> lilstevie: Of course, if they also have executables with those, they won't run, I bet.
[15:40] <infinity> lilstevie: But the libraries and drivers will work.
[15:40] <lilstevie> they were built post a12r1
[15:40] <lilstevie> but they do have those daemon bits that aren't strictly needed anymore
[15:40] <ogra_> nice !
[15:41] <ogra_> bah, sigh
[15:41] <ogra_> so not like the linux4tegra drop then
[15:41] <infinity> Yeah, the daemon bits won't work.
[15:41] <lilstevie> not quite
[15:41] <infinity> We really need to push our linker changes upstream and get every toolchain on the same page.
[15:41] <infinity> Like, yesterday.
[15:42] <lilstevie> the daemons weren't running on Mer
[15:42] <lilstevie> but using the drivers
[15:42] <lilstevie> but in any case
[15:43] <lilstevie> they use them for the trimslice on Mer, and Archlinux
[15:43] <lilstevie> hf drivers that is
[15:47] <Xase> lilstevie: any abstract thoughts on my problem?
[15:47] <lilstevie> Xase: not yet, been a little busy
[15:48] <Xase> No sweat, any knowledge anyone could provide is a great help.
[15:51] <infinity> And we have Unity on armhf.  Welcome to a (probably partially broken) desktop.
[15:52] <lilstevie> infinity: heh
[15:52] <lilstevie> nice
[15:56] <lilstevie> I love comments on forums like "-it might be a good idea to test the binaries before running the script to make sure they don't segfault, since this seems to be a relatively common problem"
[15:56] <lilstevie> :/
[15:57] <lilstevie> 1) I have had 0 reports of this, and have no idea where this 'common problem' is. 2) I give an email address for people to report bugs to; nobody has
[15:57] <lilstevie> oh, and my favorite... 3) I use the stuff I do myself
[16:02] <doko_> ppisati, could you build linux-ti-omap4 for armhf please?
[16:03] <ppisati> doko_: is the next item in my todo list
[16:03] <infinity> \o/
[16:10] <doko_> ppisati, thanks, including the mmap patch?
[16:12] <ppisati> yep
=== Guest76640 is now known as NCommander
[16:35] <ndec> ogra_: hi. do you think i could get another PPA on tiomap-dev? something for 'experimental' stuff that we want ubuntu users to get access to easily?
=== NCommander is now known as Guest67564
[16:36] <ogra_> ndec, will have to talk to davidm about that, but he is traveling, how urgent is that ?
=== Guest67564 is now known as NCommander
[16:36] <ndec> not so many things in terms of build load, but i just need to make sure that we make a clear separation between what should work (release PPA) and our sandbox
[16:36] <ndec> not too much urgent.
[16:36] <ogra_> ok
[16:36] <ogra_> i'll get an answer before the friday meeting
[16:37] <ndec> good!
[16:59] <GrueMaster> ppisati: Does this round of SRU kernels have the mmap fix?
[17:11] <ppisati> GrueMaster: nope
[17:11] <ppisati> GrueMaster: it entered the trees today
[17:11] <GrueMaster> sigh.  Why so late?  It was tested a couple of weeks ago?
[17:12] <GrueMaster> Now we have to wait for another round of SRU updates.
[17:14] <infinity> Hey look, d-i succeeded.
[17:14] <ogra_> wohoo
[17:14] <ogra_> quick, lets build alternates :P
[17:15] <GrueMaster> For?  armhf???
[17:15] <infinity> I haven't done the debian-cd mangling yet. ;)
[17:15] <infinity> GrueMaster: Yeah.
[17:15] <ogra_> yep :P
[17:15] <GrueMaster> If only we had a kernel.
[17:15] <ogra_> well, netinst should work
[17:15] <ogra_> we do (if it finished yet)
[17:15] <ogra_> for omap at least
[17:16] <infinity> We have omap.
[17:16] <infinity> d-i wouldn't have built without it.
[17:16] <ogra_> ah, right
[17:16] <ogra_> u-boot is missing
[17:16] <infinity> Is not.
[17:16] <GrueMaster> omap?  Cool.  I can start testing it later today once my mirror has pulled it in.
[17:16] <infinity> Again, d-i won't build without it. :P
[17:16] <ogra_> you fixed it ?
[17:16] <ogra_> oookay
[17:16] <infinity> Just needed armhf added to the arch list.
[17:17]  * ogra_ wants ac100 :P
[17:17] <infinity> doko did uboot and x-loader.
[17:17] <ogra_> i saw x-loader
[17:17] <ogra_> missed u-boot somehow
[17:17] <infinity> I think he's just been looking at suite-diff.py output and adding armhf everywhere it wasn't. ;)
[17:17] <ogra_> heh
[17:18] <infinity> I've been focusing on getting the desktop built.
[17:18] <infinity> unity-2d done.
[17:18] <infinity> Some ubuntuone stuff still to go.
[17:18] <ogra_> yeah, and that lenses thing for 3d
[17:18] <infinity> Hey, we have a libinfinity.
[17:18] <infinity> The file lens needs actual fixing.
[17:18] <ogra_> well, a bunch hasnt built yet for -desktop
[17:18] <infinity> The desktop guys are on it.
[17:19] <ogra_> yep, saw that
[17:19] <infinity> I don't know about "a bunch".  We're only 153 packages short in main.
[17:19] <doko_> ogra_, all packages on armhf should be built, which also exist on armel (or are currently building ...)
[17:19] <infinity> Binary packages, that is.
[17:19] <ogra_> http://qa.ubuntuwire.org/ftbfs/primary-precise-armhf.html shows 10 (one ftbfs)
[17:19] <infinity> doko_: Redboot failed.  Calling the compiler by ABI name.  Not that it matters.
[17:20] <doko_> infinity, currently fixing
[17:20] <ogra_> for the ubuntu-desktop set
[17:20] <doko_> had to do libinfinity first ;)
[17:20] <ogra_> doko_, i wonder if we shouldnt just remove redboot
[17:20] <GrueMaster> redboot fails?  Oh no!  Panic time. :P
[17:20] <infinity> banshee's just waiting on ubuntuone stuff to sort out.
[17:20] <ogra_> nobody maintains it
[17:20] <infinity> ogra_: We don't boot any subarches with it anymore.
[17:20] <ogra_> and nothing uses it anymore
[17:20] <infinity> ogra_: Freescale moved entirely to u-boot.
[17:21] <ogra_> infinity, well, we probably kept it around for oem or something
[17:21] <infinity> I'm game for removal.
[17:21] <infinity> Or at least demotion.
[17:21] <ogra_> not sure
[17:21] <ogra_> huh
[17:21] <GrueMaster> Only redboot platform we have is Babbage3, which is stuck on Lucid.
[17:21] <ogra_> it was demoted ages ago
[17:21] <infinity> Or is it already in universe
[17:21] <infinity> ?
[17:21] <ogra_> if its in main again thats a bug
[17:21] <infinity> In that case, no idea why doko uploaded it. :P
[17:21] <ogra_> heh
[17:21] <ogra_> nostalgy :)
[17:22] <infinity> redboot-imx | 200952-0ubuntu2 |       precise | source
[17:22] <infinity> ^-- Looks main to me.
[17:22] <ogra_> GrueMaster, the vodafone netbook is babbage "like" so it might have helped having around a redboot package to patch it
[17:22] <infinity> Find where that's seeded and get rid of it.
[17:22] <ogra_> infinity, wow
[17:22] <infinity> Actually, I will.
[17:23] <ogra_> it shouldnt be seeded
[17:23] <ogra_> weird
[17:23] <infinity> ... wow.  I still don't have the precise seeds locally?  I fail at life.
[17:23] <GrueMaster> ogra_: So is the Efika, but iirc, it is u-boot.
[17:23] <infinity> platform.oneiric/installer: * redboot-tools-udeb [armel]
[17:23] <infinity> Yeah, it's seeded.
[17:23] <infinity> Now to fix it in precise.
[17:23] <ogra_> GrueMaster, right, i think the vodabook is actually very close to bbg
[17:23] <ogra_> so might use redboot
[17:24] <GrueMaster> ENOCLUE.
[17:24] <infinity> Freescale ditched redboot ages ago.
[17:24] <infinity> Any newer imx51 stuff should be u-boot, from what I understand.
[17:24] <ogra_> infinity, yes, thats what i say, the HW is based on a board where no u-boot existed
[17:24] <GrueMaster> I thought we were looking at switching bbg3 during Lucid also, but couldn't get it working.
[17:24] <ogra_> right
[17:24] <infinity> Well, I'll keep it seeded then.
[17:25] <ogra_> code was immature and incomplete
[17:25] <infinity> ogra_: Care to verify with our new PES overlords? :)
[17:25] <ogra_> infinity, no, drop it
[17:25] <ogra_> thats a 2009 source that nobody touched afterwards if people need the source package they should pull from lucid
[17:25] <ogra_> i dont think it changed since
[17:26] <GrueMaster> If needed, universe isn't too far to see for the eye of Sauron.
[17:26] <infinity> Yeah, I won't remove it, just demote it.
[17:28] <infinity> Committed.
[17:29]  * ogra_ just asked about the vidabook, if they dont use it i'll file a removal bug
[17:29] <ogra_> *voda
[17:29] <infinity> It does little harm being in universe.
[17:29] <infinity> If some keener wants to do a home-brew precise setup on their babbage.
[17:30] <ogra_> hm
[17:30] <ogra_> as long as nobody bothers me about it (it might have my name all over the changelog)
[17:30] <infinity> :P
[17:32] <ogra_> hmm, looks like the xubuntu seeds would like to know about armhf
[17:33] <micahg> ogra_: indeed, but I was waiting for universe to be more complety built before doing that
[17:33] <ogra_> ah
[17:35] <infinity> micahg: Hey, I spent some time unsnagging at least the core of xubuntu...
[17:35] <micahg> infinity: I wasn't blaming anyone :)
[17:35] <infinity> micahg: libxfcegui4 needs love, though.
[17:35] <infinity> micahg: (hint, hint)
[17:35] <micahg> infinity: doko fixed that I thought
[17:36] <infinity> Oh, so he did.
[17:36] <infinity> He's been rather nuts with the uploads today.
[17:36] <ogra_> argh
[17:37] <infinity> And banshee's off!
[17:37] <ogra_> root@horus:/# exit
[17:37] <ogra_> ogra@horus:~/chroot-hf$ ps ax
[17:37] <ogra_> Killed
[17:37] <infinity> ogra_: Reboot.
[17:37] <ogra_> no way to umount the /proc inside the chroot now i guess
[17:37] <ogra_> grr
[17:37] <infinity> ogra_: You upgraded your chroot without having a no-op policy-rc.d in place.
[17:37] <infinity> ogra_: And something broke your init.
[17:37] <micahg> infinity: I can update the xubuntu seeds tomorrow for armhf if you think everything's close enough for it to work
[17:38] <infinity> micahg: No huge rush.
[17:38] <micahg> ok
[17:38] <ogra_> infinity, well, i upgraded without /proc or /sys mounted ... and only mounted them for configuring procps ...
[17:38] <ogra_> afterwards
[17:38] <infinity> ogra_: And procps is what killed you, then.
[17:39] <infinity> I bet. :P
[17:39] <ogra_> likely
[17:39] <ogra_> not init though
[17:39]  * ogra_ crosses fingers and reboots
[17:41] <infinity> I should go do debian-cd now.
[17:41] <infinity> We're closer to desktop images than I thought we would be.
[18:00] <infinity> ogra_: debian-cd done.
[18:00] <infinity> ogra_: If you want to review the latest revision (but I already merged it into production...)
[18:00] <ogra_> well, if its already merged i'll look at the fallout :P
[18:01] <ogra_> livecd-rootfs (or rather BuildLiveCD) dont seem happy at,
[18:01] <ogra_> *atm
[18:01] <ogra_> the failure mail i got looks like a quoting issue in BuildLiveCD
[18:02] <ogra_> Subject: LiveFS --f-omap4/ubuntu/armel+omap4 failed to build on 20111205 ...
[18:02] <ogra_> -f is usually for the filesystem call
[18:02] <infinity> ogra_: But does the failure log itself look goofy?
[18:02] <ogra_> there is no content
[18:02] <infinity> ogra_: Or just the subject line?
[18:02] <infinity> Weird...
[18:03]  * GrueMaster has become numb to these emails.
[18:03] <ogra_> seems to have failed in buildLiveCd already
[18:03] <infinity> Cause I have a log...
[18:03] <infinity> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/precise/ubuntu-omap4/20111205/livecd-20111205-armel.out
[18:03] <ogra_> GrueMaster, i only glance over them if they roll in ... that way such inconsistencies jump in my face
[18:04] <infinity> ogra_: I've done literally nothing to BuildLiveCD that would lead to that.
[18:04] <ogra_> stramge
[18:05] <infinity> Which host mailed that to you?
[18:05] <ogra_> nusakan
[18:05] <ogra_> indeed
[18:06] <infinity> So, it's not from BuildLiveCD at all...
[18:06] <ogra_> if it starts with LiveFS it is from the buildlive run
[18:06] <ogra_> (the subject i mean)
[18:06] <infinity> Yes, but not BuildLiveCD.
[18:07] <ogra_> well, thatrs just a subsequent call indeed
[18:07] <ogra_> buildlive isnt doing much else but running BuildLiveCD remotely
[18:08] <ogra_> but yeah, i indeed meant the execution of BuildLiveCD
[18:08] <infinity> I blame Colin's revision.
[18:08] <infinity> -                       mail -s "LiveFS $PROJECT/$DIST/$arch failed to build on $datestamp" \
[18:08] <infinity> +                       mail -s "LiveFS $PROJECT${SUBPROJECT:+-$SUBPROJECT}${subarch:+-$subarch}${UBUNTU_DEFAULTS_LOCALE:+-$UBUNTU_DEFAULTS_LOCALE}/$DIST/$arch failed to build on $datestamp" \
[18:08] <ogra_> oh
[18:09] <infinity> Though, how we're getting OPTIONS in there, I don't know...
[18:10] <infinity> Oh, we're not.
[18:10] <ogra_> where does --f come from then ?
[18:10]  * ogra_ doesnt see it
[18:11] <ogra_> must come out of $PROJECT${SUBPROJECT:+-$SUBPROJECT}
[18:11] <infinity> Did you get that mail more than once?
[18:11] <ogra_> nope, not yet
[18:11] <infinity> I suspect it was a manual build with bad options on the CLI.
[18:11] <ogra_> ah
[18:11] <infinity> Leading to the empty mail and the whacky subject.
[18:12] <ogra_> it would really help if it would publish the euid of the executing user :)
[18:12] <ogra_> that way we should be able to distinguish between sudoed CLI calls and cron runs :)
[18:15] <ogra_> SUDO_USER sshould be unset if it runs from cron, right ?
[18:17] <ogra_> that way we should be able to tag it as manual build, i think that would help
[18:17] <infinity> cron runs as root, so yes.
=== doko_ is now known as doko
[21:04] <jhobbs> where is the most proper place to check for the status of an ubuntu package for arm?
[21:05] <micahg> jhobbs: in most cases it should be the same as any other architecture, you can use rmadison in devscripts to query what the latest version per arch is of a package
[21:06] <GrueMaster> jhobbs: You can also search launchpad.net for the package.
[21:06] <GrueMaster> Just select the version "in Ubuntu".
[21:07] <jhobbs> thanks
[21:12] <infinity> ppisati: So, on pressure, but if we had a ti-omap4 kernel on armhf, we could build desktop CDs in about an hour (without libreoffice, it's still building... But close enough!)
[21:12] <infinity> ppisati: s/on pressure/no pressure/ ;)
[21:15]  * GrueMaster increases the pressure.
[22:37] <infinity> ubuntu-core/armhf dailies re-enabled, tomorrow we build desktop images.
[22:37] <infinity> Or maybe tonight after I've napped. :P
[22:38] <GrueMaster> W00T!
[23:04] <doko> infinity, exo ftbfs on armhf, succeeds here locally ...