[00:57] <nacc> slangasek: would you have an opinion on LP: #1579815? Not sure if there is a precedence for that, although the regression chance is low, since it'd be a new package
[00:57] <ubottu> Launchpad bug 1579815 in php-mongodb (Ubuntu) "Please "duplicate" as php5-mongodb to trusty-universe" [Wishlist,New] https://launchpad.net/bugs/1579815
[01:37] <slangasek> nacc: that would normally be a no-go for SRU
[01:37] <nacc> slangasek: that's what i thought as well, just wasn't sure, thanks!
[01:42] <nacc> slangasek: given that, would i change the state to "invalid" (with an appropriate comment)? Or would you just leave it as "new"?
[01:48] <sarnold> nacc: would this help the reporter? https://launchpad.net/~ondrej/+archive/ubuntu/php
[01:50] <nacc> sarnold: checking; if i had to guess, that'll just be the backport of the php7-supporting php-mongodb to go with the php7 backport in the same ppa to trusty
[01:52] <nacc> sarnold: hrm, perhaps i was wrong! Provides: php5.5-mongodb, php5.6-mongodb, php7.0-mongodb
[01:54] <sarnold> nacc: it's a little terrifying that there's openssl and pcre3 and so on in there, it feels like a lot for one person to support.
[01:55] <nacc> sarnold: yeah, i think that's because of the build-deps
[01:55] <nacc> sarnold: not entirely sure
[01:55] <nacc> sarnold: a lot of people use his ppa, i know that
[01:55] <sarnold> yeah
[01:56] <nacc> ah well, i think i've done my due diligence now :)
[01:56] <sarnold> :)
=== athairus is now known as afkthairus
[06:35] <pitti> Good morning
=== hikiko is now known as hikiko|bbl
[08:24] <Odd_Bloke> slangasek: We've already been using this code to build yakkety images, so we did break (e.g.) lxd, but we've fixed it up now.
[08:56] <LocutusOfBorg> pitti, pping again about opencv autopkgtests (please run against proposed)
[08:57] <pitti> LocutusOfBorg: triggered
=== hikiko|bbl is now known as hikiko
=== maxb_ is now known as maxb
[10:51] <pitti> LocutusOfBorg: indeed, looks better now (still blocked by the freeze)
[10:54] <LocutusOfBorg> thanks pitti
=== stub` is now known as stub
[11:27] <GunnarHj> pitti: Thoughts on bug #1591503? Would it be a good idea to rebuild fcitx-mozc for now and somehow override pkgstriptranslations?
[11:27] <ubottu> bug 1591503 in language-pack-zh-hant-base (Ubuntu) "missing fcitx-mozc.mo" [Medium,Confirmed] https://launchpad.net/bugs/1591503
=== _salem is now known as salem_
=== dpm_ is now known as dpm
[12:49] <pitti> GunnarHj: oh, so this isn't a regression from Monday's langpack builds, AFAIUI?
[12:50] <rbasak> pitti: would you consider bug 1596056 for an SRU to Xenial? It'd be really helpful for all the postinst failure bugs we get.
[12:50] <ubottu> bug 1596056 in init-system-helpers (Ubuntu) "output of invoke-rc.d for systemd units un-debuggable on failure" [Wishlist,Fix committed] https://launchpad.net/bugs/1596056
[12:50] <rbasak> We can wait for it to settle and have some testing first of course.
[12:50] <pitti> rbasak: yeah, seems fairly harmless
[12:50] <rbasak> Great, thanks!
[12:51] <pitti> rbasak: added a task
[12:51] <rbasak> I just went to do that and Xenial wasn't in the list of options. Most confusing :-)
[12:52] <pitti> rbasak: probably just mid-air collision
[12:52] <rbasak> Yeah. Webapps and concurrency don't mix.
[12:52] <pitti> I mean, I probably already added it when you tried to
[13:01] <pitti> GunnarHj: yeah, rebuilding mozc with NO_PKG_MANGLE=1 seems fine as a workaround for now; I can't see what's wrong with it right now
[13:03] <rbasak> cyphermox: bug 1211110 looks like it could use some attention. There are a few bugs I've seen with poor NM/OpenVPN interactions.
[13:03] <ubottu> bug 1211110 in openvpn (Ubuntu) "network manager openvpn dns push data not updating system DNS addresses" [High,Confirmed] https://launchpad.net/bugs/1211110
[13:12] <cyphermox> rbasak: are you pointing it out because you're affected?
[13:12] <cyphermox> unfortunately, it's quite hard to get things to play nice when they all expect to be authoritative and they all go muck in resolv.conf
[13:16] <rbasak> cyphermox: no I'm not affected, but it's a hot bug and I wasn't sure if you'd seen it.
[13:18] <cyphermox> happyaron: ^
=== JanC is now known as Guest53913
=== JanC_ is now known as JanC
[14:47] <pete-woods> pitti: question about packaging dbusmock templates
[14:48] <pete-woods> if a package stuffs a new template in /usr/lib/python3/dist-packages/dbusmock/templates/
[14:48] <pete-woods> are you okay with that?
[14:48] <pete-woods> (I think it's already happening, btw)
[14:48] <pitti> pete-woods: fine for me, as long as there are no conflicts
[14:49] <pete-woods> pitti: awesome, that makes my life easier then
[14:49] <pitti> pete-woods: however, you can specify a full path for the template
[14:49] <pete-woods> as we can put new templates in a package we manage, without having to bug you
[14:49] <pitti> so it shouldn't usually be necessary
[14:49] <pete-woods> yeah, there's that option too
[14:49] <pete-woods> I'd really like to have an official directory for it
[14:49] <pete-woods> so I can know where to look
[14:49] <pitti> templates should not really be shipped in debs
[14:50] <pitti> they should only be necessary during package build ("make check") or autopkgtests, in both cases it can be taken from the source
[14:50] <pitti> unless there's some foo-test-tools package
[14:50] <pete-woods> actually thinking of -dev packages
[14:50] <pete-woods> so I can include e.g. a mock template for connectivity-api in connectivity-api-dev
[14:51] <pitti> ah
[14:51] <pete-woods> which stays in lock-step with the API
[15:00] <pete-woods> pitti: the main thing I was hoping for was a canonical path for 3rd party packages to contribute new mocks to (in their -dev packages)
[15:01] <pete-woods> if we could agree on that, and get a patch to python-dbusmock to search it, that would be great
[15:01] <pete-woods> as we'd like to start putting our money where our mouth is, and provide reusable mocks for each of the daemons that our team is responsible
[15:01] <pete-woods> for
[15:02] <pitti> pete-woods: ah, and you don't like the above because it's Debian specific? (specific to python3-defaults, that is)
[15:02] <pete-woods> pitti: it just feels a bit naughty for us to stuff things in the upstream package's path
[15:03] <pete-woods> as opposed to e.g. a /usr/share/dbusmock/templates dir
[15:03] <pitti> pete-woods: I don't mind moving the templates to /usr/share/python-dbusmock/templates/ and search/put them there
[15:03] <pete-woods> or something along those lines
[15:03] <pete-woods> pitti: that would be great
[15:03] <pete-woods> we want to put some documentation together for how we'd like teams to support testing by providing their own mocks
[15:04] <pete-woods> mocks for their own daemons I mean
[15:04] <pete-woods> and being able to release them into a standard place alongside their headers, etc would be great
[15:08] <pete-woods> especially being able to point to a readme.md on your github site saying "this is where templates go"
[15:08] <pete-woods> so we don't just look like some lone nuts
[15:08] <pitti> pete-woods: well, if we change that, then dbusmock's own templates would go there too
[15:09] <pete-woods> pitti: well it could search both paths
[15:09] <pete-woods> pitti: but I'm happy with either option there
[15:09] <pitti> that sounds a bit complicated to me
[15:09] <pitti> and makes it less obvious which one wins on conflicts
[15:09] <pete-woods> that's a fair point
[15:23] <pete-woods> pitti: at any rate, anything along those lines would be great. I can try hacking on it myself if you don't have time to do it?
[15:30] <slangasek> nacc: 'wontfix' would be my preference there :)
[15:42] <nacc> slangasek: ack, thanks!
[15:45] <nacc> mdeslaur: fyi, ondrej picked up your patch, thanks again!
[15:46] <mdeslaur> nacc: ah, cool, thanks for sending it to debian!
[16:00] <semiosis> Odd_Bloke: hi.  just checking in.  i'll be around most of the day if you have any questions about the merge.
[16:00] <Odd_Bloke> semiosis: Oh, shoot, that completely fell off my plate. :(
[16:02] <semiosis> if you can't get to it, do you think anyone else might be able to?
[16:03] <Odd_Bloke> semiosis: It'll need to be someone on my team, and we're all equivalently busy ATM, I'm afraid.
[16:03] <Odd_Bloke> semiosis: But I've milestoned it in a way that it'll show up on my list of things to do.
[16:03] <Odd_Bloke> semiosis: So unless there's some catastrophe that I need to deal with, I should get to it by the end of the week.
[16:04] <semiosis> well then i guess that's all I can do.  just want to mention that this bug affects a lot of people, who are going elsewhere for ubuntu vagrant images (https://github.com/mitchellh/vagrant/issues/7463#issuecomment-228363552)
[16:04] <Odd_Bloke> semiosis: Apologies for dropping it.
[16:06] <Odd_Bloke> semiosis: Understood, thank you again for taking the time to submit the MP.
[16:06] <semiosis> it's my pleasure.  please let me know if there's anything else I can do to help move things along.
=== dpm is now known as dpm-afk
[17:41] <sil2100> infinity, slangasek: hey! Could one of you, if you find some time, review https://code.launchpad.net/~sil2100/ubuntu-cdimage/ubuntu-touch-custom/+merge/298640 ?
[17:41] <sil2100> infinity, slangasek: thanks!
[18:09] <mterry> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mterry
[18:48] <coreycb> arges, hello there, any chance you could review some of our sru's in the wily queue?
[18:57] <doko> slangasek, won't we trigger the "interpreter problem" by making setuptools M-A: foreign?
[19:01] <slangasek> doko: yes and no.  python3-setuptools is pure python, with nothing in its dependency chain besides python3; there is one Arch: any package in the archive that depends on python3-setuptools, nml, and it includes a python .so, so it *could* be affected by the "interpreter problem".  And third-party packages could also be affected.  But in practice, we don't have a better way to express this
[19:01] <slangasek> currently, and not annotating it blocks cross-building, so IMHO it's the lesser evil
[19:02] <doko> slangasek, agreed about python-setuptools, but python-pkg-resources is much more used
[19:02] <doko> the alternative is to make these packages Arch: any
[19:04] <highvoltage> /win 19
[19:07] <slangasek> doko: I get what I need (unblocking unity8 cross-build) with just python-setuptools, python-pkg-resources doesn't matter to me
[19:07] <slangasek> doko: so I guess I should've filed a separate bug report, sorry
[19:09] <doko> wondering why, because setuptools depends on pkg-resources
[19:10] <doko> but yes, making it M-A: foreign is less invasive than making it Arch: any
[19:45] <mvo> arges: hey, if you have time, it would be great if you could do a sru review/approval for snapd 2.0.10
[20:07] <arges> ok
[20:11] <arges> coreycb: sure
[20:12] <coreycb> arges, thanks
[20:30] <nacc> hallyn: ping
[20:31] <hallyn> nacc: .
[20:31] <nacc> hallyn: heya -- refreshing myself on the openipmi merge/delta and seeing what to send to Debian. We have a delta to not use /var/lock/subsys (typo'd in the changelog i realize now) because it doesn't exist (or didn't). But I think it exists in both Debian and Ubuntu now.
[20:32] <nacc> hallyn: i'm thinking we can drop that delta
[20:32] <hallyn> nacc: <shrug> i don't have /var/lock/subsys
[20:32] <hallyn> xenial system running upstart
[20:32] <nacc> hallyn: ah, might be an upstart vs. systemd thing?
[20:32] <hallyn> but will openmpi create the dir if its needed?
[20:32] <nacc> a sid container had it (was my first test)
[20:33] <hallyn> "officially" upstart is no longer supported so you can probably drop it.  is it needed in cloud archives?
[20:33] <hallyn> i think it'd be better if we use /var/lock/subsys and just make sure that upstart or openmpi creates it if it doesn't exist
[20:33] <nacc> hallyn: right, and that'd be something i think debian would need to ensure too, so let me see and i'll double/triple-check on that
[20:33] <hallyn> maybe update /etc/init/mounted-var.conf
[20:33] <mterry> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: Xenial (16.04) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-xenial | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[20:34] <hallyn> nacc: cool - o \o
[20:34] <hallyn> hm
[20:34] <hallyn> that's me with broken glasses
[20:34] <hallyn> \o
[20:34] <nacc> heh
[20:34] <nacc> hallyn: i think we can send the rest of the delta straight to debian, as it's bugfixes, etc. and then we can sync finally
[20:34] <nacc> rbasak: --^ fyi
[20:35] <nacc> rbasak: i'll update my MR too
[20:35] <hallyn> excellent
[20:39] <pitti> nacc, hallyn: /run/lock/subsys is created in /usr/lib/tmpfiles.d/legacy.conf; happy to drop this if we don't need it
[20:40] <hallyn> pitti: i think its the other way around - openmpi wants it and upstart doesn't create it
[20:40] <nacc> pitti: ah interesting ...
[20:40] <hallyn> although maybe openmpi should then be updated
[20:40] <nacc> hallyn: well, we could change openipmi to use /var/lock then
[20:40] <hallyn> if it need something out of 'legacy.conf' :)
[20:40] <hallyn> right
[20:40] <pitti> yeah, we should not rely on those old paths any more
[20:40] <nacc> pitti: and that would drop one more legacy user
[20:40] <nacc> ok, is that true in debian too, pitti ?
[20:40] <hallyn> good justification for a push to debian.
[20:41] <hallyn> thx pitti
[20:41] <pitti> also, not /var/lock/, using this is brittle for early-boot stuff
[20:41] <arges> coreycb: why did you split the openstack SRU bugs up
[20:41] <pitti> nacc: yes
[20:41] <nacc> pitti: where would you suggest?
[20:41] <pitti> nacc: /run/lock
[20:41] <pitti> nacc: /var/lock is a symlink, but that doesn't help you if /var itself is remote
[20:41] <nacc> pitti: ah intersetsing
[20:41] <nacc> *interesting
[20:41] <pitti> that was the whole reason for introducing /run :)
[20:42] <nacc> pitti: got it, i'll update the patch and fix that then
[20:42] <pitti> (well, that and that it's guaranteed to be a tmpfs)
[20:42] <pitti> nacc: cheers
[20:42] <pitti> FWIW, I don't think that we had /var/lock/subsys under sysvinit either
[20:42]  * pitti boots a debian sid with sysv  to check
[20:43] <coreycb> arges, I think originally glance-store wasn't ready so we didn't want to hold up the neutron*/nova sru
[20:43] <pitti> nacc: FTR, openmpi is not early-boot stuff, so /var/lock is not technically broken; but it's better style to use /run directly IMHO
[20:44] <nacc> pitti: yep, make ssense
[20:44] <pitti> nacc: yep, no /run/lock/subsys (and therefore not /var/lock/subsys) under sysvinit-core in Debian
[20:44] <pitti> nacc: so, doesn't affect us, but does affect Debian
[20:45] <pitti> i. e. not worth keeping a delta over it, but worth filing fix to Debian
[20:49] <nacc> pitti: yep, submitting now
[20:51] <nacc> hallyn: pitti: thanks again for the guidance
[20:51] <pitti> nacc: yw!
[20:51] <hallyn> \o
[21:00] <Odd_Bloke> How can I find if there's an Ubuntu bug corresponding to a Debian bug?
[21:00] <Odd_Bloke> *find out
[21:02] <pitti> Odd_Bloke: https://bugs.launchpad.net/bugs/bugtrackers/debbugs/12345
[21:02] <ubottu> Launchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]
[21:02] <pitti> Odd_Bloke: of course that only works if the ubuntu bug actually got linked to that 12345 debian bug
[21:05] <Odd_Bloke> pitti: Thanks!
[21:19] <robert_ancell> slangasek, when you say "We have the capability to mark different support periods in the archive by package×architecture" does that mean we can blacklist a bunch of packages to not build i386?
[21:19] <slangasek> robert_ancell: I mean that the Packages file can annotate what the support period is for a given binary package
[21:19] <robert_ancell> ah
[21:19] <slangasek> blacklisting a package from building should be done by changing the package itself to not build for that arch
[21:20] <robert_ancell> oh right, that's easy to do. duh.
[21:20] <Unit193> robert_ancell: LP 1494491 got a chance this cycle, btw?
[21:20] <ubottu> Launchpad bug 1494491 in Light Display Manager "Use accountsservice extensions for background, keyboard layouts, has-messages" [Medium,Triaged] https://launchpad.net/bugs/1494491
[21:21] <robert_ancell> Unit193, if someone does the work I'm happy to review / land it
[21:21] <robert_ancell> It seems unlikely I'll have time at present
[21:22] <Unit193> Alright, thanks.
[21:30] <nacc> pitti: hallyn: while it seems like long-term we'd want to convert /etc/init.d/openipmi to a proper systemd unit file (?), is there any reason for there not to be a 'Default-Start' and 'Default-Stop' entry in that script? It apparently leads to errors: LP: #1596474
[21:30] <ubottu> Launchpad bug 1596474 in openipmi (Ubuntu) "openipmi adding to autoload fail" [High,New] https://launchpad.net/bugs/1596474
[21:34] <slangasek> nacc: there's certainly no reason not to
[21:35] <nacc> slangasek: can i just provide a reasonable (read: common) default?
[21:36] <slangasek> nacc: reasonable defaults are 'Default-Start: 2 3 4 5' 'Default-Stop: 0 1 6'
[21:36] <slangasek> and you should certainly use those values :)
[21:37] <nacc> slangasek: ack, that's what i was planning on
[21:37] <nacc> will send that to debian too :)
=== salem_ is now known as _salem