| === henrix_ is now known as henrix | ||
| === pleia2_ is now known as pleia2 | ||
| === henrix_ is now known as henrix | ||
| === Mirv_ is now known as Mirv | ||
| === jbicha is now known as Guest14309 | ||
| === Ursinha is now known as Guest36665 | ||
| === popey_ is now known as popey | ||
| === forestpi1kie is now known as forestpiskie | ||
| === lan3y is now known as Laney | ||
| cjwatson | Image builds failed today due to a complex interaction between software-center and a python-configparser package pulled in by a new dependency from python-configglue. I'm mailing Barry for advice | 08:49 |
|---|---|---|
| Laney | seems to be bug #1038429 fwiw | 08:51 |
| ubot2` | Launchpad bug 1038429 in software-center (Ubuntu) "update-software-center crashed with order (MRO) for bases SafeConfigParser, object in __new__()" [Medium,Confirmed] https://launchpad.net/bugs/1038429 | 08:51 |
| Laney | there's some analysis in there | 08:51 |
| cjwatson | Oh, I didn't expect it to be that far back in history | 08:52 |
| Laney | It just happens now for everyone because python-configglue gets pulled in by something but I guess the bug was always present | 08:53 |
| Laney | was going to ask dobey to take a look | 08:53 |
| cjwatson | Be my guest :) | 08:54 |
| === jibel_ is now known as jibel | ||
| === doko_ is now known as doko | ||
| === elmo_ is now known as elmo | ||
| cjwatson | i386 builders down briefly while I rebootstrap lua-ldoc/lua-penlight | 12:25 |
| cjwatson | back on auto (bah, still fails) | 12:30 |
| xnox | Thank you for accepting gcc-arm-linux-androideabi, whoever that was =) | 14:44 |
| stgraber | xnox: oh, does that mean we'll soon be building our android bits in the archive? | 14:49 |
| xnox | stgraber: yeah, as soon as we work out a sensible way to ship binary blobs. I'm thinking to have: android-src package, which ships android-src. Then per-device binary blob packages for each of the 4 devices. And then a package which builds images for all four using: cross-toolchain above, android-src, binary-blob package. | 14:57 |
| xnox | stgraber: once cross-toolchain is ported to use cynogenmod sources instead of linaro sources, it will to start to build-depend on android-src. | 14:57 |
| xnox | that way keeping up android copyright would be easier, by having only one place to do so. | 14:58 |
| xnox | stgraber: but it does mean, that arch:all gnupg-android package can be added to gnupg package right now ;-) | 14:58 |
| xnox | and parted. | 14:58 |
| stgraber | cool | 14:59 |
| sergiusens | xnox: the blobs don't necesarily need to be in the build tree as long as they are installed later | 14:59 |
| xnox | sergiusens: that's nice! i had the plan that ready-to-flash .zips / .img are build in the package. If binary blobs are needed to be added later, what should the .deb ship? just the tree of build: system/ recovery/ boot/ ? | 15:01 |
| xnox | from out/product/.... | 15:01 |
| sergiusens | xnox: that's my plan for community builds... $OUT/system + boot (which ogra today mangles in cdimage to make it an ubuntu one) are the device.zip, then we need recovery.img | 15:04 |
| xnox | sergiusens: is recovery.img generic or also has blobs? | 15:05 |
| ogra_ | sergiusens, yeah, we need to find a way to replace the initrd before zipping | 15:05 |
| sergiusens | xnox: I don't recall what was in boot/, will need to check | 15:05 |
| cjwatson | sergiusens: boot isn't mangled, although system.zip is | 15:06 |
| cjwatson | well, *-touch-armhf.zip | 15:06 |
| cjwatson | and *-system-armel+*.zip | 15:06 |
| sergiusens | cjwatson: I though ogra grabbed boot.img which is in thesystem-armel-*. zip | 15:07 |
| * sergiusens hasn't checked the code yet | 15:07 | |
| ogra_ | i replace boot.img with a zip -u | 15:07 |
| ogra_ | (-u for update) | 15:07 |
| cjwatson | sergiusens: It's all in cdimage code now, not in ogra's home dir any more ... and the boot.img is wgetted from foo.bootimg-* on the livefs builder, no cdimage-side mangling of that part | 15:08 |
| cjwatson | *-system-armel+*.zip is mangled to insert the right boot.img | 15:08 |
| cjwatson | https://bazaar.launchpad.net/+branch/ubuntu-cdimage/view/head:/lib/cdimage/build.py#L418 add_android_support and build_livecd_base functions | 15:09 |
| ogra_ | right | 15:12 |
| ogra_ | and the mangling should move into the android build | 15:13 |
| ogra_ | so cdimage doesnt need to do it | 15:13 |
| ogra_ | (we just need some feedback from prters first before we can do that) | 15:14 |
| ogra_ | *porters | 15:14 |
| xnox | ogra_: so is the plan to have: android-src package, with common sources. Plus 4-per-device packages with binary blobs for each, build-dep on android-src & android-cross-toolchain, building final zips/images an ok plan? | 15:14 |
| ogra_ | (flipping the ports is way harder than nexus ... since we have no HW usually) | 15:14 |
| xnox | .... since the binary-blob packages will need to be in restricted/multiverse | 15:15 |
| ogra_ | xnox, i'm not sure we can actually rely on common sources ... i'm not so sure how much build option mangling per device we have for the android core | 15:15 |
| ogra_ | so we would probably still have one package per arch | 15:15 |
| ogra_ | and yeah one additional package for the blobs | 15:15 |
| ogra_ | (per subarch again) | 15:16 |
| xnox | ogra_: android-src - just ships the equivalent of the repo-checkout under /usr/src/. We do need to build it fully for each device. | 15:16 |
| ogra_ | ah, so you were talking about source, i was referring to binary | 15:17 |
| xnox | ogra_: well, something like the gcc-4.7-source and binutils-source packages. They are binary packages, but they ship pure source code. | 15:18 |
| xnox | ogra_: specifically to decouple per-device builds. | 15:18 |
| ogra_ | ok | 15:18 |
| xnox | (per-arch / cross-arch etc) | 15:18 |
| ogra_ | well i would like to end up with something like android-rootfs-$subarch_$version.deb which pulls in android-blobs-$subarch_$version.deb | 15:19 |
| ogra_ | no matter how we get there :) | 15:19 |
| ogra_ | the livefs-builder can then merge their contents into a zip | 15:19 |
| xnox | ogra_: not sure that would be possible..... what do you expect in the android-rootfs*.deb? | 15:19 |
| ogra_ | everything that isnt a blob ? | 15:20 |
| xnox | ah, no zips. | 15:20 |
| ogra_ | well or tar.xz or whatever stephane needs :) | 15:20 |
| xnox | ogra_: ok, i need to poke at unflipped images =) | 15:21 |
| ogra_ | xnox, essentiually i need to produce something like the current device specific zip in the end | 15:21 |
| xnox | ogra_: i thought i'd be generating: android-rootfs-with-bloby-$subarch_$version.deb which has like ramdisk.img, recovery.img, userdata.img, system.img | 15:21 |
| xnox | ack. | 15:22 |
| ogra_ | but licensing might force us to have that split into two | 15:22 |
| ogra_ | i would prefer if you could do it like that ... but i doubt that works licensing wise | 15:22 |
| xnox | well, that deb would be in multiverse =) | 15:23 |
| ogra_ | unless we push the whole stuff into restricted ... but that would kind of violate what restricted is for | 15:23 |
| ogra_ | thats why i thought "rootfs -> universe", "blobs -> restricted" ... and easily installable alongside so that they form the content of a zip | 15:24 |
| cjwatson | restricted is proprietary hardware support; Android objects don't seem particularly against its spirit? | 15:25 |
| ogra_ | i wouldnt like to bring multiverse into play at all | 15:25 |
| ogra_ | cjwatson, well, the whole android rootfs ? | 15:25 |
| cjwatson | Oh, right, no, that would be a bit much | 15:25 |
| ogra_ | yeah | 15:25 |
| ogra_ | thus the split | 15:26 |
| ogra_ | xnox, there is a per device "proprietary.txt" (or similar, cant rememebr the exact name) that actually defines whats a blob ... based on that we should be able to have a restricted package | 15:27 |
| ogra_ | everything thats not in there should go into an android-rootfs-$subarch package into universe | 15:27 |
| ogra_ | (or ven main if we actually want to support it) | 15:28 |
| xnox | ogra_: I'm not sure how zips are assembled / .img files created. Cause then we would want a wrapper available to generate normal .zip / .img files. | 15:29 |
| xnox | after both .debs are installed. | 15:29 |
| ogra_ | xnox, dont worry about the zips get me a package with the content of /system in it (including /system/boot/ramdisk.img) and separate the blobs into an extra package, i'll care for the rest | 15:30 |
| ogra_ | the generation of the zips or tarxz or whatever we will use in the end can happen on the livefs builder as part of the image build | 15:31 |
| sergiusens | xnox: ogra_ I guess what you want from the vendor branches is the specific makefiles without the PRODUCT_COPY files | 15:31 |
| ogra_ | what i would like is something that contains /usr/lib/android-rootfs-$subarch/system ... | 15:31 |
| ogra_ | in a deb | 15:31 |
| ogra_ | sergiusens, right | 15:31 |
| sergiusens | xnox: where is all your stuff to check out? is it in your xnox branch in phablet.ubuntu.com? | 15:32 |
| ogra_ | hmm, we would probably also want /usr/lib/android-rootfs-$subarch/recovery (containing the recovery subdir from the out dir of the build tree) | 15:33 |
| xnox | sergiusens: what do you mean? =)))) so far I only have two .git repos for the cross-toolchain on github, not yet moved to phablet.u.c. And yet to start doing above beast of a "lets-package-android" | 15:34 |
| sergiusens | xnox: I mean in other words that I want your setup to see what's going on :-) | 15:34 |
| ogra_ | xnox, wow, it only took you half a day to assemble the copyright file ? how did you manage that ? | 15:35 |
| xnox | sergiusens: ah, sure. I can give you my manifest, that's pushed to phablet.ubuntu.com | 15:35 |
| ogra_ | even a licensecheck over only one subarch generates a 4MB mess for me here (not to mention the 100s of completely unlicensed files in the tree) | 15:36 |
| xnox | sergiusens: so far, i'ts people/xnox branch of the manifest repo with only changes to use system-wide toolchain, instead of prebuilt one. | 15:36 |
| xnox | sergiusens: next up, I need to start using native host toolchain. next up debian/ folder will be added. | 15:36 |
| rsalveti | hopefully the boot and recovery doesn't bring any binary in place | 15:36 |
| rsalveti | otherwise we might need to create them differently | 15:36 |
| xnox | sergiusens: where / how is the export tarball generated? | 15:37 |
| ogra_ | well they are sourc eat some point :) | 15:37 |
| ogra_ | *at | 15:37 |
| rsalveti | I mean the binary blobs (hal, etc) | 15:37 |
| ogra_ | boot.img shouldnt | 15:37 |
| ogra_ | not sure about recovery though | 15:37 |
| ogra_ | is there networking support in recovery usually ? | 15:38 |
| * ogra_ didnt think there was | 15:38 | |
| ogra_ | thats the only thing i could imagine needing blobs | 15:38 |
| ogra_ | hmm, unless ... how does recovery access the framebuffer | 15:39 |
| rsalveti | I'm worried about fb and input | 15:39 |
| ogra_ | well, fb usues pixelflinger usually, i dont thing that needs any EGL | 15:40 |
| ogra_ | but i might be wrong, clearly an assumption :) | 15:40 |
| sergiusens | let me check | 15:42 |
| xnox | ogra_: on a more imminent point, can we move current builds to the toolchain now in the archive? I have patches for android-build to check/use system-wide toolchain, I can test them a bit and push. But then the toolchain needs to be installer wherever the build is run. | 15:57 |
| rsalveti | xnox: can you send us the needed patch so we can review and test? | 16:00 |
| ogra_ | xnox, i think rsalveti and serguiens have scripts that pull the kernels into the build, should work similar for the toolchain | 16:00 |
| rsalveti | yes, we just need changes to make the android build system to use them during build time | 16:00 |
| ogra_ | right | 16:01 |
| sergiusens | ogra_: xnox: I just checked manta and there is no prop bits in recovery, going to build latest maguro et.al. and just check to be sure | 16:35 |
| sergiusens | xnox: regarding $OUT/boot, was that supposed to be $OUT/root ? | 16:35 |
| sergiusens | $OUT/root is the android-ramdisk in the boot.img btw (for original android) | 16:36 |
| xnox | sergiusens: probably. I'm fuzzy with names =) | 16:37 |
| xnox | whichever they are, excluding userdata | 16:37 |
| === Guest14861 is now known as maxb | ||
| ScottK | wireshark is currently blocked from migrating to -release due to netexpect. That will FTBFS with the current wireshark (I filed #714535 in Debian with no response from the maintainer). Would the reasonable thing to do for now be to remove the netexpect binaries to wireshark can migrate? Note: there are security issues fixed in the wireshark upload. | 18:07 |
| infinity | ScottK: Posting it to the new API would be the sanest thing to do. | 18:24 |
| * ScottK <-- not a C programmer. | 18:25 | |
| * ScottK would prefer to not leave the open vulnerabilities in saucy in the mean time. | 18:25 | |
| infinity | Most of the changes look reasonably straightforward. | 18:29 |
| infinity | Let me wake up a bit, and I'll see if it's not too much effort to fix. | 18:29 |
| === NCommand` is now known as NCommander | ||
| === NCommander is now known as Guest96374 | ||
| ScottK | Thanks. | 18:36 |
| ScottK | You could even upload an NMU and let it sync ... | 18:36 |
| infinity | ScottK: If the security issues are hugely urgent enough to not let it sit in proposed, we could also backport the patches to 1.8.7 in the security PPA and copy directly to the release pocket. | 18:38 |
| ScottK | I didn't investigate the details. | 18:39 |
| ScottK | Every wireshark release has something. | 18:39 |
| infinity | "The NetworkExpect source code is maintained in a Subversion repository. This repository is currently not available to the community, but this may change depending on the interest from the community." | 18:42 |
| infinity | Grr. | 18:43 |
| infinity | So, it *could* be fixed upstream, but I can't tell. Fun. | 18:43 |
| infinity | ScottK: Uploaded and patch submitted to the Debian maintainer. It builds. No idea how well it works. | 19:17 |
| ScottK | infinity: Thanks. | 19:17 |
| * ScottK doesn't really care much for netexpect, so as long as it builds and unblocks wireshark, I'm happy. | 19:18 | |
| infinity | Well, my assumption is that upstream has already fixed this anyway, but due to having a closed VCS, I have no way of telling. | 19:19 |
| infinity | (Their history seems to show they track wireshark API changes fairly actively) | 19:19 |
| infinity | Put one small tick in the "Open > Free" column. | 19:20 |
| micahg | infinity: any chance I can get you to unblock abiword by doing some removals? | 19:52 |
| infinity | micahg: I looked at that briefly. It's not removed from Debian, only from testing. | 19:57 |
| micahg | infinity: and? | 19:58 |
| infinity | cjwatson: Did you ever get anywhere with magic demotion scripts, or should I just do a manual copy of a few things down to proposed? | 19:58 |
| micahg | I didn't say blacklist :), if it gets fixed, we can resync | 19:58 |
| infinity | micahg: And, I'd rather demote than delete. | 19:58 |
| === james_ is now known as Guest8292 | ||
| micahg | hrm? demote?? | 19:58 |
| jbicha | infinity: I believe pyabiword is very broken | 19:58 |
| infinity | Oh, I suppose demotion won't work if it wouldn't cause uninstallables and get re-promoted immediately. I think what's holding it out of testing is RC bugs. | 19:59 |
| micahg | ys | 19:59 |
| jbicha | it needs to be rebuilt against abiword (which isn't too difficult) but I'd rather see it removed | 20:00 |
| micahg | well, it's not a simple rebuild as the upstream source needs to be patched for the 3.0 ABI, but pyabiword upstream seems very dead as you mentioned in the removal bug | 20:00 |
| infinity | jbicha: Well, it also knocks out all those sugar-* packages. | 20:01 |
| jbicha | infinity: the ones that don't work anyway? | 20:01 |
| micahg | it's just 4 and if someone cares enough to fix them, we can add them back | 20:02 |
| infinity | Meh. | 20:04 |
| * infinity removes. | 20:04 | |
| micahg | thanks | 20:04 |
| micahg | and if someone really cares if it gets fixed later, we can always backport | 20:04 |
| infinity | Done. | 20:07 |
| ScottK | Is +1 maint still a thing? I don't recall it mentioned recently. | 20:12 |
| infinity | It is, but we don't seem to have formal staffing/rotations this cycle. | 20:13 |
| slangasek | we were meant to; if that didn't happen, it's been an oversight | 20:13 |
| slangasek | https://wiki.ubuntu.com/PlusOneMaintenanceTeam suggests we're a bit understaffed on it this cycle. | 20:14 |
| infinity | I got a whopping 1 volunteer this cycle. | 20:14 |
| slangasek | then we need people to be voluntold | 20:14 |
| infinity | Yeah, quite possibly. | 20:14 |
| infinity | I don't think we need the 3-per-month of the past cycles, but more than just me wouldn't hurt my feelings. :P | 20:15 |
| xnox | infinity: python3 -c "import minions from Despicable.Me.2; plus_one.add(minions)" | 20:33 |
| infinity | xnox: Has someone been to the movies recently? :P | 20:33 |
| * xnox =)))))))))))))))))))))) | 20:33 | |
| infinity | I dated a girl who had a stuffed Minion plushie in her bed. I should have married her. | 20:34 |
| xnox | http://youtu.be/ioKl3d1e_ug | 20:34 |
| * xnox has a stuffed stich | 20:34 | |
| === pgraner` is now known as pgraner | ||
| === Guest96374 is now known as NCommander | ||
| === Guest17995 is now known as charles | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!