[03:08] <armourz> Can anyone teach me a few things about ubuntu dev?
[03:15] <sarnold> irc works best with concrete questions :)
[03:17] <Unit193> sarnold: How are you doing today?
[03:17] <sarnold> Unit193: I'm great super, thanks for asking! :)
[03:17] <sarnold> Unit193: how're you tonight?
[03:17] <Unit193> Quite alive, though coffee gone now.
[03:17] <sarnold> oh no! I too am without coffee
[03:17] <sarnold> but tomorrow morning I shall get more
=== salem_ is now known as _salem
=== JanC_ is now known as JanC
=== Tm_K is now known as Tm_T
=== arvour is now known as armour
=== arvour is now known as armourz
=== madwizar1 is now known as madwizard
=== armourz is now known as arvour
=== CRogers__ is now known as CRogers
[09:31] <cpaelzer> rbasak: FYI - I found prior art to my packaging problem in several other packages, libhwloc seems to be the closest to my case
[09:31] <cpaelzer> rbasak: on that "template" I'll start to develop a solution for DPDK - except some feedback convinces me otherwise
[09:32] <cpaelzer> I might reply to my own ubuntu-devel post once I have tested it successfully
[09:32] <cpaelzer> it might be easier to ack/nack a proposed solution than to create a new one based on my description
[09:40] <rbasak> cpaelzer: sounds good
[10:28] <doko> nacc: so dropping everything from ldb is fine for now. I had a chat with jelmer at fosdem about python3 & samba, so we might re-introduce these packages again, but not yet for 17.04. about the s390x bits ... maybe drop those as well, and see what happens
[10:28] <xnox> s390x ldb was fixed upstream, so recent upstream should be fine without any s390x delta
[10:29] <xnox> nacc, ^
[10:29] <xnox> doko, i missed both you and jelmer at fosdem =(
[10:29] <doko> xnox: have you been there?
[10:30] <xnox> doko, yeah i was at fosdem.
=== _salem is now known as salem_
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[14:08] <cyphermox> wxl: looking
[14:37] <cjwatson> fossfreedom: nothing debian-cd related is on my to-do list, nor do I intend for it to be; while I gave some initial advice, somebody else will need to review
[14:43] <cyphermox> fossfreedom: fwiw that won't make the cd boot straight to maybe-ubiquity, it should just happen by default if you don't touch anything, unless what you want is a CD that behaves a bit like Kubuntu
[16:02] <nacc> doko: xnox: ack, I'll refresh my merge and verify
[16:06] <nacc> xnox: i'm guessing, though, debian has not picked up a recent enough upstream (1.1.27 is what is currently packaged, I see 1.1.29 at least on upstream tarball page). Looking for a changes/news to figure out which version included the fix
[16:07] <nacc> xnox: hrm, upstream (in the bug) said it was fixed in 1.1.26, but we are carrying it currently as delta...
[16:08] <xnox> debian is frozen, and will not take new point releases.
[16:08] <xnox> nacc, if you want to can request ship newer release in ubuntu.
[16:10] <Laney> experimental exists
[16:12] <nacc> xnox: ack, i'll see if it is needed or not
[16:15] <nacc> xnox: oh nm, we probably coudl have dropped it on last merge, it was added in 1.1.24, fixed upstream in 1.1.26, duly noted!
=== sergiusens_ is now known as sergiusens
[16:25] <nacc> doko: so the only two bits of delta that i'd like (double) verification on then are the "symbols for the extension" module and the encoding of the SOABI (which does have a hardcoded py3, so can probably also be dropped). So presuming neither of those are critical, would you suggest we sync ldb?
[16:29] <rbasak> mterry: is the MIR in bug 1619239 approved then? I think so as you set Fix Committed, but I want to make sure.
[16:29] <ubottu> bug 1619239 in tomsfastmath (Ubuntu) "[MIR] tomsfastmath (runtime dependency of clamav)" [High,Fix committed] https://launchpad.net/bugs/1619239
[16:34] <mterry> rbasak: yeah -- now it just needs an archive admin to push the button to promote it
[16:35] <rbasak> mterry: thanks. We need to sync clamav first to pull it in first I think.
[16:35] <rbasak> caribou: ^
[16:35] <mterry> rbasak: ah yeah
[16:36] <rbasak> I just wanted to check we were good first, because otherwise our delta can stay.
[16:43] <nacc> rbasak: do you have bugs filed for the two pkgs you looked at before that failed to import (and which were they?)
[16:43] <rbasak> Yes, one moment.
[16:43] <nacc> rbasak: thanks
[16:43] <rbasak> nacc: bug 1661212 is one.
[16:43] <ubottu> bug 1661212 in usd-importer "Importer crashes when ubuntu/<stable release>-devel branches do not fast forward" [High,Triaged] https://launchpad.net/bugs/1661212
[16:44] <rbasak> I didn't note the package name :-(
[16:44] <nacc> rbasak: yeah that's what i needed :)
[16:44] <rbasak> I can dig it out I think.
[16:44] <nacc> rbasak: can you update the headline with it onc eyou find it?
[16:44] <rbasak> ack
[16:45] <rbasak> nacc: the other was bug 1661092: snapd.
[16:45] <ubottu> bug 1661092 in usd-importer "Import fails when debian directory is a symlink" [High,Fix released] https://launchpad.net/bugs/1661092
[16:45] <nacc> rbasak: ok, just to check, was the other bind9?
[16:47] <rbasak> nacc: it was ntfs-3g
[16:47] <nacc> rbasak: ack
[16:47] <rbasak> nacc: we want one bug per importer bug. Perhaps the importer failures should be separate bugs?
[16:48] <nacc> rbasak: they are right now
[16:48] <nacc> well, i'm filing them one at a time as we get them :)
[16:51] <rbasak> nacc: trouble is, I'm turning the bug into "importer can't do X" where X is quite specific. Because that's what the importer bug actually is.
[16:51] <rbasak> But then we'd end up duping multiple failures. Really catching up on old imports is a separate dimension.
[16:52] <nacc> rbasak: yeah, i'm suggesting do that and eitehr also file a bug for a failed import
[16:52] <nacc> rbasak: or put the specific case in the subject line as well
[16:52] <nacc> rbasak: right now, i'm filing a bug per failed import, independent of bugs in the code
[16:52] <rbasak> nacc: I think we should have separate bugs. One for the root cause, one per failed import.
[16:52] <nacc> rbasak: agreed
[16:53] <rbasak> Because otherwise as soon as the importer bug is fixed, the failed import notes disappear.
[16:53] <nacc> rbasak: so you'll file two more? :)
[16:53] <rbasak> nacc: I should be able to just import snapd. But yeah, I can file one for ntfs-3g.
[16:56] <nacc> rbasak: sounds good
[16:56] <nacc> rbasak: oh right, you have the fix for snapd ready, i guess (that's the symlink one right ?)
[17:41] <rbasak> nacc: right
[17:44] <nacc> rbasak: thanks
[17:48] <rbasak> nacc: snapd imported and pushed
[17:48] <rbasak> (successfully)
[17:48] <nacc> rbasak: awesome, nice work
[17:49] <rbasak> nacc: and I filed an import bug for ntfs-3g bug 1662611
[17:49] <ubottu> bug 1662611 in usd-importer "ntfs-3g failed to import (2017-02-02)" [Undecided,New] https://launchpad.net/bugs/1662611
[17:51] <nacc> rbasak: appreciate it
[18:05] <nacc> slangasek: re: the cloud-image change for open-iscsi initiator name. Do you have any suggestion for how to test my change locally?
[18:07] <slangasek> nacc: to test that the image builds and boots the way you expect?
[18:07] <nacc> slangasek: yeah
[18:07] <nacc> slangasek: specifically generating a new initiator name
[18:07] <slangasek> nacc: you might want https://github.com/OddBloke/ubuntu-standalone-builder
[18:07] <slangasek> (not "local", it needs a cloud - but doesn't require special LP setup)
[18:08] <nacc> slangasek: ok, thanks!
[18:28] <rbasak> nacc: looks like phpunit-mock-object is a really minor merge left over from your work on the PHP transition. Would you like to take care of it?
[18:30] <rbasak> cpaelzer: how do you feel about looking at the nis merge? That's from when you first started - remember? :-)
[18:31] <nacc> rbasak: ack, i'll get the php one(s) done this week, ideally
[18:48] <rbasak> doko: are you planning on merging ldb?
[18:48] <nacc> rbasak: i'm doin git
[18:48] <nacc> *doing it
[18:48] <nacc> rbasak: in consultation with doko, as it's needed for samba
[18:49] <rbasak> Ah, OK. I'll give you the work item then :)
[18:49] <nacc> rbasak: ack
[19:03] <rbasak> tjaalton: so the latest sssd in Debian requires src:http-parser which is in universe. Looks like the new "secrets" support?
[19:03] <rbasak> For now, I can build without that it looks like, as there's a configuration flag for that. Or, do you want it MIR'd?
[19:03] <rbasak> "http parser" sounds security sensitive. Especially for the "secrets" feature.
[19:03] <rbasak> So maybe it'll have to be next cycle?
[19:30] <sbeattie> rbasak: there's a MIR request for http-parser already.
[19:30] <sbeattie> https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957
[19:30] <ubottu> Launchpad bug 1638957 in http-parser (Ubuntu) "[MIR] http-parser, dependency of sssd" [High,Incomplete]
[19:31] <tjaalton> yeah, the ball is on the security team now ;)
[19:32] <rbasak> Oh. Thanks!
[19:32] <rbasak> I just prepared an upload to disable the secrets service for now.
[19:33] <rbasak> Should I upload that pending the MIR, and then we can revert and sync when appropriate?
[19:33] <tjaalton> I'm fine either way
[19:33] <rbasak> Then at least we'd get testing on the newer sssd, even if without the secrets service.
[19:33] <tjaalton> it's in debian testing too
[19:34] <rbasak> OK I'll upload for now. Then if the MIR doesn't get done in time at least we have something automatically.
[19:34] <tjaalton> right
[19:51] <rbasak> So dogtag is holding up nss migrating, which presumably is due to tomcat 8.5 too?
[19:51] <rbasak> tjaalton: are we certain that tomcat 8.5 needs removing?
[19:52] <rbasak> It has made it to testing.
[19:52] <tjaalton> rbasak: yes
[19:53] <rbasak> Is there an ~ubuntu-archive bug on this?
[19:53] <tjaalton> no
[19:53] <rbasak> I'm not sure I follow the reasoning, so if not would you mind filing one with an explanation please?
[19:53] <tjaalton> didn't think of that
[19:53] <tjaalton> https://fedorahosted.org/pki/ticket/2560
[19:53] <tjaalton> I'll file one
[19:53] <rbasak> Thanks!
[19:53] <tjaalton> did send an email to ubuntu-release, but a bug makes more sense
[19:53] <rbasak> Then I can point people to the bug for current status and when explaining blockers :)
[19:54] <tjaalton> the reason why 8.5 was "rushed" for stretch was that 8.0 will be EOL before stretch is
[19:54] <tjaalton> but it's not an issue for 17.04
[19:54] <rbasak> That makes sense.
[19:55] <tjaalton> well, building reverse-depends would've shown that it was a bad decision.. though it makes my life easier not having to support freeipa on stretch :)
[19:58] <tjaalton> so, a bug against tomcat with ubuntu-archive assigned?
[19:59] <rbasak> Yes
[20:01]  * rbasak EODs
[20:02] <tjaalton> done, bug #1662654
[20:02] <ubottu> bug 1662654 in tomcat8 (Ubuntu) "Please remove tomcat 8.5 from zesty-proposed" [Undecided,New] https://launchpad.net/bugs/1662654
=== salem_ is now known as _salem
=== JanC_ is now known as JanC
[23:27] <jgrimm> nacc, one thing noticed while getting powersj going on merges.. ubuntu-git-tools isn't documented there, tho the tools are part of the process.. always good having someone new go through documentation
[23:27] <nacc> jgrimm: what's ubuntu-git-tools?
[23:28] <nacc> jgrimm: oh, rbasak's old repo? they are all in the importer repo now
[23:29] <jgrimm> nacc, oh, didn't realize they are in there too, i'm using from cloned repo
[23:29] <nacc> jgrimm: yeah, we migrated it a while back
[23:29] <nacc> the other repo is defunct at this point
[23:30] <jgrimm> nacc, i see them there now. i only had ./bin in my path too, so i'll switch
[23:30] <nacc> jgrimm: yeah, probably should move them now that we have a bin upstream
[23:30] <nacc> jgrimm: please file a bug on that, it's probably a worthwhile cleanup
[23:30] <jgrimm> nacc, cool cool. tx