[13:54] <piggz> hi, does anyone here know about the biometryd code in ubports for reading android FP? im trying to port it to SailfishOS and have some issues running it
[15:05] <piggz> when I ask to enroll, logcat says https://paste.mozilla.org/QEcDJG2v
[15:06] <piggz> and biometryd says
[15:06] <piggz> [root@Pro1 nemo]# biometryd enroll --device=android
[15:06] <piggz> setActiveGroup failed: SYS_EINVAL
[15:06] <piggz> Starting template enrollment for User[0] to Android HAL Bridge
[15:06] <piggz> on_started
[15:06] <piggz> on_failed:
[15:06] <piggz>   ERROR_UNABLE_TO_PROCESS


[11:47] <xnox> do i have network connectivity to ports archive, when building arch:all packages on distro builders or ppas?
[11:48] <cjwatson> Not guaranteed, but the archive in sources.list will be a non-split one so you should use whatever it says
[11:49] <cjwatson> I remember writing code somewhere to parse sources.list for that ...
[11:49] <cjwatson> Ah yes
[11:49] <cjwatson> xnox: see e.g. grub2-signed
[11:52] <xnox> cjwatson: nice. let me see, if I can extend that for my needs.
[12:12] <chrisccoulson> could somebody please approve that? ^^
[13:23] <infinity> chrisccoulson: Do we have new versions for P and Q too?
[13:24] <chrisccoulson> infinity, yeah, 1 second
[13:24] <chrisccoulson> infinity, ok, those are uploaded as well now
[13:59] <rsalveti> cjwatson: is there an easy way to check why a package takes so long in proposed sometimes? just wondering if we have any sort of logs or pending tests and such so I can better track how much time it'd take still to be fully published in the archive
[13:59] <infinity> rsalveti: If it's still in proposed, it's easy to tell why.
[13:59] <ogra_> rsthat should be solved since beginning of this week
[13:59] <rsalveti> just remember that I had to wait quite a few hours for upstart and network-manager over the past few days
[13:59] <infinity> rsalveti: NM was caught in a mini-transition of some sort, I believe.
[13:59] <ogra_> i havent had any package that took more than 50min turnaround time since monday
[13:59] <infinity> Not sure what your upstart issue was.
[13:59] <ogra_> the same package took between 4 and 6 h last week
[13:59] <rsalveti> cool then, nm might be some other issue it seems
[14:00] <rsalveti> will let you guys know if I get such behavior again
[14:00] <ogra_> yeah
[14:00] <ogra_> it should be gone
[14:00] <ogra_> infinity, i thought there was supposed to be an annoucement mail ?
[14:00]  * ogra_ hasnt seen one
[14:01] <infinity> ogra_: There was, I suppose I should write that this afternoon.  Though, I didn't want to write it while there were other kinks being worked out.  Things seem smooth now.
[14:01] <infinity> Ish.
[14:01] <ogra_> :)
[14:02] <rsalveti> awesome
[14:02]  * rsalveti hugs the release team
[14:07] <cjwatson> rsalveti: We have loads of logs under http://people.canonical.com/~ubuntu-archive/proposed-migration/
[14:07] <cjwatson> rsalveti: network-manager got stuck on a bug in our autopkgtest handling, now fixed
[14:07] <rsalveti> cjwatson: awesome, thanks
[14:10] <cjwatson> rsalveti: upstart was bitten by a bug in auto-package-testing relating to virtual package handling and had to be manually forced; the underlying bug there has been fixed since Friday
[14:11] <cjwatson> (Or so I believe, judging from lp:auto-package-testing r212)
[14:14] <rsalveti> cjwatson: got it, so it's just be being unlucky, but seems it should all be better now
[14:14] <rsalveti> *me
[14:15] <cjwatson> rsalveti: The last couple of weeks have had some fairly big (though quiet) archive-infrastructure changes, but the worst of it has settled down
[14:16] <cjwatson> So yes, I think it should mostly be better, though I'd still appreciate being told about any oddities while they're happening so that I can investigate
[14:16] <rsalveti> great, sure, will let you know if I get stuck again with any package
[14:16] <ogra_> i doubt you will see more than 1h turnaround time with anything now (unless it actually takes hours to build indeed)
[14:17] <cjwatson> Or unless it's genuinely stuck in a library transition, or with build or test failures
[14:19] <ogra_> yeah
[14:20] <stgraber> can another AA look at iproute2 in binNEW? I've got a couple of packages that are stuck on the iproute => iproute2 transition so it'd be nice to have iproute2 in the archive
[14:31] <infinity> stgraber: Ew, can we not fix the failure to check return values instead?  The security team is usually anal about those in MIR audits. :P
[14:31] <infinity> Also, whoever NEWed that source to universe shouldn't have...
[14:33] <infinity> stgraber: Also a bit suspicious that we had to disable -Werror and Debian didn't?  Same glibc version...
[14:35] <stgraber> infinity: well, those warnings also appear in our current iproute but are ignored there, so I thought we wouldn't be any worse
[14:35] <infinity> stgraber: Anyhow.  Accepted, but it would be nice to dig deeper into that.
[14:36] <infinity> (And promoted to main, where it should have been)
[14:39] <cjwatson> infinity: No human NEWed it into universe - it was auto-synced in bulk
[14:42] <infinity> cjwatson: Ahh.  That makes more sense.
[14:43] <stgraber> infinity: I'm not seeing those warnings in the Debian sbuild log at all (and it's clearly building with -Wall -Werror there too) ...
[14:47] <infinity> stgraber: So, this could be because it's not been built with gcc-4.8 in Debian.  Maybe.
[14:48] <infinity> Oh, hrm.  No.  The armhf buildd, at least, was 4.8
[14:48] <stgraber> infinity: yeah and 4.7 also had the warning, our old iproute from raring has the warnings in its buildlog
[14:48] <ScottK> Is Debian gcc on armhf Linaro or FSF?
[14:49] <infinity> ScottK: I think doko just went Linaro across the board for Debian to save his sanity.
[14:49] <ScottK> OK.
[14:49] <ogra_> yeah
[14:50] <infinity> stgraber: Weird.
[14:51] <infinity> stgraber: Maybe those functions only grow a __wur when built with FORTIFY_SOURCE or some such.
[14:51]  * infinity is too lazy to look right now.
[14:53] <infinity> Oh, or maybe __wur itself only triggers when building with FORTIFY_SOURCE. :P
[14:53] <infinity> It's amazing the things one forgets.
[14:54] <cjwatson> The latter, I think.
[14:54] <infinity> And how quickly one forgets them at my advanced age.
[14:54] <cjwatson> Using dpkg-buildflags in Debian would probably show it up.
[14:54] <infinity> cjwatson: Yeah, that "or maybe" was more of a "in fact, it's like this".
[19:05] <ogra_> infinity, do you know if livefs builders can see jenkins ?
[19:05] <ogra_> or cjwatson ^^^
[19:05] <sergiusens> better said lillypilly or nusakan
[19:06] <ogra_> sergiusens needs to get the click packages into the build somehow ... preferably without having to post-process them on nusakan indeed
[19:06] <sergiusens> it's for adding click packages to the touch builds, I'm creating them on jenkins and can copy them over to nusakan scriptiseally
[19:10] <infinity> They almost certainly can't see jenkins.
[19:11] <infinity> They *can* see archive-team.internal (which is ~ubuntu-archive/public_html on lillypilly), but we could poke a hole for something more appropriate, perhaps.
[19:11] <infinity> I assume these click packages will have some slightly more public and sane archive than jenkins at some point? :P
[19:12] <sergiusens> infinity: they certainly should (I'm not on the hook for that one though)
[19:20] <sergiusens> when you say poke a hole, it means all the way to jenkins or some other location?
[19:25] <stgraber> or I suppose we could have something pulling from Jenkins and pushing to ~ubuntu-archive/public_html on lillypilly (seems vaguely cleaner than direct access from the buildds to jenkins, though adds an extra delay)
[19:25] <stgraber> it'd also be slightly better for non-Canonical people as they'd actually be able to see what's being pulled in
[19:31] <infinity> Yeah, that would be preferable as an interim solution.  But I think we probably need to discuss how these packages are being built and published.
[19:31] <infinity> I'm not a huge fan of all of this happening outside the usual developer playground.
[19:49] <sergiusens> infinity: cjwatson would have the long term plan for that I think
[19:49] <sergiusens> click is just too new to have a nice workflow
[20:29] <knome> apparently, none of the flavors still show up at status.ubuntu.com
[22:56] <jbicha> gnome-online-accounts seems stuck in saucy-proposed, the libgdata and e-d-s tests seem to have passed
[23:00] <ScottK> update-excuses says libgadata is still running.
[23:00] <ScottK> See what happens after the next publisher run, I'd say.
[23:04] <cjwatson> It's been allegedly RUNNING for a good ten runs now ...
[23:08] <cjwatson> ./data/adt/saucy-proposed/amd64/archive/2013/07/10/saucy_amd64_libgdata_20130710-205401.result:saucy amd64 libgdata 0.13.3-2 PASS gobject-introspection 1.36.0-2 liboauth 1.0.1-1 libgdata 0.13.3-2 libxml2 2.9.0+dfsg1-4ubuntu5 libsoup2.4 2.42.2-6 glib2.0 2.37.3-1ubuntu2 eglibc 2.17-0ubuntu5 gcr 3.8.2-4 gnome-online-accounts 3.8.2-1ubuntu1
[23:08] <cjwatson> so, huh, what's it doing
[23:08] <cjwatson> Oh, it thinks it's still running on i386
[23:10] <cjwatson> I've forced it and will check with jibel in the morning
[23:36] <jbicha> thanks