[00:31] <Logan_> Does a package that previously FTBFSed in Ubuntu require an FFE, if the package wasn't previously published in Raring due to the FTBFS? The new Debian version builds properly, and there is a sync request for it.
[00:33] <micahg> Logan_: If it's got new features, yes
[00:33] <Logan_> Well, I mean, the binary wasn't published in Raring previously due to the FTBFS.
[00:33] <micahg> Logan_: which package?
[00:33] <Logan_> And the only fix in Debian is for the FTBFS, so now the binary would be published.
[00:34] <Logan_> https://bugs.launchpad.net/ubuntu/+source/libio-async-loop-glib-perl/+bug/1154211
[00:34] <ubottu> Launchpad bug 1154211 in libio-async-loop-glib-perl (Ubuntu) "Sync libio-async-loop-glib-perl 0.20-3 (universe) from Debian unstable (main)" [Undecided,New]
[00:34] <Logan_> I tested the Debian version in my amd64 pbuilder, and it didn't FTBFS.
[00:35] <micahg> ah, it's grandfathered into the release pocket, please sync to raring + SRU to quantal if it works
[00:36] <Logan_> So no FFE is required?
[00:36] <micahg> no, it's just fixing something broke ATM
[00:36] <Logan_> kk
[00:36] <micahg> generally binary new requires FFe, but that's when you're adding/restructuring
[00:37]  * micahg is trying in a 32 bit chroot for kicks
[00:37] <micahg> Logan_: do you have 32 bit chroots?
[00:38] <Logan_> Just amd64 pbuilder.
[00:38] <Logan_> Tends to be a good indicator, though.
[00:38] <micahg> yeah, catches most things
[00:38] <Logan_> If it's a complex package, I usually push it to my PPA to see if it works on i386, etc.
[00:38] <micahg> was fine in 32 bit raring FWIW
[00:38] <Logan_> synced
[00:39] <micahg> so, if you feel like SRUing, that would be great
[00:40] <micahg> hrm, seems like the build  chroots are stale, it's taking over a minute on i386 just to update the chroot
[00:42] <Logan_> I don't think I should SRU, as I don't have a quantal pbuilder
[00:43] <micahg> seems to build fine there (I don't have -updates enabled in my chroot though)
[00:44] <micahg> Logan_: I'd be happy to upload if you'll do the paperwork :)
[00:44] <Logan_> oh lord :P
[00:47] <Logan_> I actually have to be AFK for a bit, so I'll probably deal with it later or tomorrow, unless you want to handle the paperwork ;)
[00:50] <micahg> Logan_: nah, I'm about to run off myself
[00:56] <xnox> Logan_: there will be about 150 more uploads of no code change, just email change from the same maintainer. Watch out, we generally don't merge if there are no code changes.
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
[07:19] <dholbach> good morning
[07:20] <ESphynx> 'morning :)
=== almaisan-away is now known as al-maisan
=== ]reed[ is now known as [reed]
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
=== al-maisan is now known as almaisan-away
=== tiagoscd is now known as Guest97368
=== tiagohillebrandt is now known as tiagoscd
=== Pici` is now known as Pici
[13:31] <mdeslaur> ScottK: think you could pull the trigger on LP: #1154581 please?
[13:32] <ubottu> Launchpad bug 1154581 in Lucid Backports "Please backport puppet 2.7.1-1ubuntu3.8 (main) from oneiric-updates" [Undecided,New] https://launchpad.net/bugs/1154581
[13:32]  * ScottK looks
[13:35] <ScottK> mdeslaur: Uploaded.
[13:35] <mdeslaur> ScottK: awesome, thanks!
[13:39] <ScottK> mdeslaur: It got rejected.  Sent you mail.
[13:41] <mdeslaur> ScottK: oh, how odd...ok, let me upload, one sec
[13:41] <ScottK> Thanks.  Just give me a ping when it's done.
[13:47] <mdeslaur> ScottK: uploaded
[13:48]  * ScottK looks.
[13:48] <ScottK> mdeslaur: Accepted.
[13:48] <mdeslaur> ScottK: thanks
[13:49] <ScottK> You're welcome.
=== highvolt1ge is now known as highvoltage
=== highvolt1ge is now known as highvoltage
[20:19] <ESphynx> good morning ;)
[21:37] <evck> Hi, I'm interested in packaging something, and I don't believe it's in Universe. It's the gcc-arm-none-eabi toolchain (https://answers.launchpad.net/gcc-arm-embedded). I'm not sure if it should be part of the gcc-defaults-armel-cross package, which includes the toolchain for Linux (gcc-arm-linux-gnueabi) targets, or a new package. Any advice?
[21:41] <ScottK> infinity: ^^^ You might know ...
[21:41] <Laney> or hrw
[21:43] <infinity> evck: It could potentially be built from the current cross packages, yes.  Patches welcome.
[21:45] <evck> infinity: So this would be a patch to the gcc-defaults-armel-cross package that builds gcc-arm-none-eabi in addition to gcc-arm-linux-gnueabi?
[21:46] <infinity> evck: That would seem like a sane way to go, if gcc-arm-none can be built from our current GCC sources.
[21:47] <infinity> evck: Alternately, you could do another source package that just builds gcc-arm-none (again, pulling in gcc-4.7-source, ideally), but if it needs a bootstrap to get there, you may end up duplicating a lot of what the other cross source does.
[21:48]  * infinity isn't particularly familiar with how to build the -none- targets, as he doesn't do any bare-metal/embedded work.
[21:48] <evck> infinity: Ok, I have a bit to learn about the packaging process, but I'll take a look into it.
[21:49] <infinity> evck: Well, a good first step isn't packaging-related at all, but confirming that you can actually build gcc-arm-none-eabi from the gcc-4.7-source sources.
[21:50] <infinity> evck: ie: if this requires an patching from a source other than upstream GCC or the Linaro branch, we'd need to sort that out.
[21:50] <infinity> s/an/any/
[21:50] <infinity> evck: If it's just a matter of passing some configure flags and bundling up the results, it's likely fairly trivial to bolt than on to the current cross builds as another pass.
[21:50]  * infinity hand waves enough to appear to be flailing.