=== 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
cjwatsonImage 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 advice08:49
Laneyseems to be bug #1038429 fwiw08: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/103842908:51
Laneythere's some analysis in there08:51
cjwatsonOh, I didn't expect it to be that far back in history08:52
LaneyIt just happens now for everyone because python-configglue gets pulled in by something but I guess the bug was always present08:53
Laneywas going to ask dobey to take a look08:53
cjwatsonBe my guest :)08:54
=== jibel_ is now known as jibel
=== doko_ is now known as doko
=== elmo_ is now known as elmo
cjwatsoni386 builders down briefly while I rebootstrap lua-ldoc/lua-penlight12:25
cjwatsonback on auto (bah, still fails)12:30
xnoxThank you for accepting gcc-arm-linux-androideabi, whoever that was =)14:44
stgraberxnox: oh, does that mean we'll soon be building our android bits in the archive?14:49
xnoxstgraber: 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
xnoxstgraber: 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
xnoxthat way keeping up android copyright would be easier, by having only one place to do so.14:58
xnoxstgraber: but it does mean, that arch:all gnupg-android package can be added to gnupg package right now ;-)14:58
xnoxand parted.14:58
sergiusensxnox: the blobs don't necesarily need to be in the build tree as long as they are installed later14:59
xnoxsergiusens: 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
xnoxfrom out/product/....15:01
sergiusensxnox: 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.img15:04
xnoxsergiusens: is recovery.img generic or also has blobs?15:05
ogra_sergiusens, yeah, we need to find a way to replace the initrd before zipping15:05
sergiusensxnox: I don't recall what was in boot/, will need to check15:05
cjwatsonsergiusens: boot isn't mangled, although system.zip is15:06
cjwatsonwell, *-touch-armhf.zip15:06
cjwatsonand *-system-armel+*.zip15:06
sergiusenscjwatson: I though ogra grabbed boot.img which is in thesystem-armel-*. zip15:07
* sergiusens hasn't checked the code yet15:07
ogra_i replace boot.img with a zip -u15:07
ogra_(-u for update)15:07
cjwatsonsergiusens: 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 part15:08
cjwatson*-system-armel+*.zip is mangled to insert the right boot.img15:08
cjwatsonhttps://bazaar.launchpad.net/+branch/ubuntu-cdimage/view/head:/lib/cdimage/build.py#L418  add_android_support and build_livecd_base functions15:09
ogra_and the mangling should move into the android build15:13
ogra_so cdimage doesnt need to do it15:13
ogra_(we just need some feedback from prters first before we can do that)15:14
xnoxogra_: 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/multiverse15: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 core15:15
ogra_so we would probably still have one package per arch15:15
ogra_and yeah one additional package for the blobs15:15
ogra_(per subarch again)15:16
xnoxogra_: 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 binary15:17
xnoxogra_: well, something like the gcc-4.7-source and binutils-source packages. They are binary packages, but they ship pure source code.15:18
xnoxogra_: specifically to decouple per-device builds.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.deb15:19
ogra_no matter how we get there :)15:19
ogra_the livefs-builder can then merge their contents into a zip15:19
xnoxogra_: 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
xnoxah, no zips.15:20
ogra_well or tar.xz or whatever stephane needs :)15:20
xnoxogra_: 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 end15:21
xnoxogra_: i thought i'd be generating: android-rootfs-with-bloby-$subarch_$version.deb which has like ramdisk.img, recovery.img, userdata.img, system.img15:21
ogra_but licensing might force us to have that split into two15:22
ogra_i would prefer if you could do it like that ... but i doubt that works licensing wise15:22
xnoxwell, 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 for15:23
ogra_thats why i thought "rootfs -> universe", "blobs -> restricted" ... and easily installable alongside so that they form the content of a zip15:24
cjwatsonrestricted 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 all15:25
ogra_cjwatson, well, the whole android rootfs ?15:25
cjwatsonOh, right, no, that would be a bit much15:25
ogra_thus the split15: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 package15:27
ogra_everything thats not in there should go into an android-rootfs-$subarch package into universe15:27
ogra_(or ven main if we actually want to support it)15:28
xnoxogra_: 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
xnoxafter 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 rest15: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 build15:31
sergiusensxnox: ogra_ I guess what you want from the vendor branches is the specific makefiles without the PRODUCT_COPY files15:31
ogra_what i would like is something that contains /usr/lib/android-rootfs-$subarch/system ...15:31
ogra_in a deb15:31
ogra_sergiusens, right15:31
sergiusensxnox: 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
xnoxsergiusens: 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
sergiusensxnox: 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
xnoxsergiusens: ah, sure. I can give you my manifest, that's pushed to phablet.ubuntu.com15: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
xnoxsergiusens: 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
xnoxsergiusens: next up, I need to start using native host toolchain. next up debian/ folder will be added.15:36
rsalvetihopefully the boot and recovery doesn't bring any binary in place15:36
rsalvetiotherwise we might need to create them differently15:36
xnoxsergiusens: where / how is the export tarball generated?15:37
ogra_well they are sourc eat some point :)15:37
rsalvetiI mean the binary blobs (hal, etc)15:37
ogra_boot.img shouldnt15:37
ogra_not sure about recovery though15:37
ogra_is there networking support in recovery usually ?15:38
* ogra_ didnt think there was15:38
ogra_thats the only thing i could imagine needing blobs15:38
ogra_hmm, unless ... how does recovery access the framebuffer15:39
rsalvetiI'm worried about fb and input15:39
ogra_well, fb usues pixelflinger usually, i dont thing that needs any EGL15:40
ogra_but i might be wrong, clearly an assumption :)15:40
sergiusenslet me check15:42
xnoxogra_: 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
rsalvetixnox: 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 toolchain16:00
rsalvetiyes, we just need changes to make the android build system to use them during build time16:00
sergiusensogra_: 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 sure16:35
sergiusensxnox: 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
xnoxsergiusens: probably. I'm fuzzy with names =)16:37
xnoxwhichever they are, excluding userdata16:37
=== Guest14861 is now known as maxb
ScottKwireshark 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
infinityScottK: 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
infinityMost of the changes look reasonably straightforward.18:29
infinityLet 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
ScottKYou could even upload an NMU and let it sync ...18:36
infinityScottK: 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
ScottKI didn't investigate the details.18:39
ScottKEvery 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
infinitySo, it *could* be fixed upstream, but I can't tell.  Fun.18:43
infinityScottK: Uploaded and patch submitted to the Debian maintainer.  It builds.  No idea how well it works.19:17
ScottKinfinity: 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
infinityWell, 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
infinityPut one small tick in the "Open > Free" column.19:20
micahginfinity: any chance I can get you to unblock abiword by doing some removals?19:52
infinitymicahg: I looked at that briefly.  It's not removed from Debian, only from testing.19:57
micahginfinity: and?19:58
infinitycjwatson: 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
micahgI didn't say blacklist :), if it gets fixed, we can resync19:58
infinitymicahg: And, I'd rather demote than delete.19:58
=== james_ is now known as Guest8292
micahghrm?  demote??19:58
jbichainfinity: I believe pyabiword is very broken19:58
infinityOh, 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
jbichait needs to be rebuilt against abiword (which isn't too difficult) but I'd rather see it removed20:00
micahgwell, 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 bug20:00
infinityjbicha: Well, it also knocks out all those sugar-* packages.20:01
jbichainfinity: the ones that don't work anyway?20:01
micahgit's just 4 and if someone cares enough to fix them, we can add them back20:02
* infinity removes.20:04
micahgand if someone really cares if it gets fixed later, we can always backport20:04
ScottKIs +1 maint still a thing?  I don't recall it mentioned recently.20:12
infinityIt is, but we don't seem to have formal staffing/rotations this cycle.20:13
slangasekwe were meant to; if that didn't happen, it's been an oversight20:13
slangasekhttps://wiki.ubuntu.com/PlusOneMaintenanceTeam suggests we're a bit understaffed on it this cycle.20:14
infinityI got a whopping 1 volunteer this cycle.20:14
slangasekthen we need people to be voluntold20:14
infinityYeah, quite possibly.20:14
infinityI don't think we need the 3-per-month of the past cycles, but more than just me wouldn't hurt my feelings. :P20:15
xnoxinfinity: python3 -c "import minions from Despicable.Me.2; plus_one.add(minions)"20:33
infinityxnox: Has someone been to the movies recently? :P20:33
* xnox =))))))))))))))))))))))20:33
infinityI dated a girl who had a stuffed Minion plushie in her bed.  I should have married her.20:34
* xnox has a stuffed stich20: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!