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:31 |
---|---|---|
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:33 |
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:34 |
micahg | ah, it's grandfathered into the release pocket, please sync to raring + SRU to quantal if it works | 00:35 |
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:36 |
* micahg is trying in a 32 bit chroot for kicks | 00:37 | |
micahg | Logan_: do you have 32 bit chroots? | 00:37 |
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:38 |
micahg | so, if you feel like SRUing, that would be great | 00:39 |
micahg | hrm, seems like the build chroots are stale, it's taking over a minute on i386 just to update the chroot | 00:40 |
Logan_ | I don't think I should SRU, as I don't have a quantal pbuilder | 00:42 |
micahg | seems to build fine there (I don't have -updates enabled in my chroot though) | 00:43 |
micahg | Logan_: I'd be happy to upload if you'll do the paperwork :) | 00:44 |
Logan_ | oh lord :P | 00:44 |
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:47 |
micahg | Logan_: nah, I'm about to run off myself | 00:50 |
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. | 00:56 |
=== almaisan-away is now known as al-maisan | ||
=== al-maisan is now known as almaisan-away | ||
dholbach | good morning | 07:19 |
ESphynx | 'morning :) | 07:20 |
=== 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 | ||
mdeslaur | ScottK: think you could pull the trigger on LP: #1154581 please? | 13:31 |
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:32 | |
ScottK | mdeslaur: Uploaded. | 13:35 |
mdeslaur | ScottK: awesome, thanks! | 13:35 |
ScottK | mdeslaur: It got rejected. Sent you mail. | 13:39 |
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:41 |
mdeslaur | ScottK: uploaded | 13:47 |
* ScottK looks. | 13:48 | |
ScottK | mdeslaur: Accepted. | 13:48 |
mdeslaur | ScottK: thanks | 13:48 |
ScottK | You're welcome. | 13:49 |
=== highvolt1ge is now known as highvoltage | ||
=== highvolt1ge is now known as highvoltage | ||
ESphynx | good morning ;) | 20:19 |
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:37 |
ScottK | infinity: ^^^ You might know ... | 21:41 |
Laney | or hrw | 21:41 |
infinity | evck: It could potentially be built from the current cross packages, yes. Patches welcome. | 21:43 |
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:45 |
infinity | evck: That would seem like a sane way to go, if gcc-arm-none can be built from our current GCC sources. | 21:46 |
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:47 |
* 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:48 |
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:49 |
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. | 21:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!