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 | 00:57 |
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:37 |
nacc | slangasek: given that, would i change the state to "invalid" (with an appropriate comment)? Or would you just leave it as "new"? | 01:42 |
sarnold | nacc: would this help the reporter? https://launchpad.net/~ondrej/+archive/ubuntu/php | 01:48 |
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:50 |
nacc | sarnold: hrm, perhaps i was wrong! Provides: php5.5-mongodb, php5.6-mongodb, php7.0-mongodb | 01:52 |
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:54 |
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:55 |
nacc | ah well, i think i've done my due diligence now :) | 01:56 |
sarnold | :) | 01:56 |
=== athairus is now known as afkthairus | ||
pitti | Good morning | 06:35 |
=== hikiko is now known as hikiko|bbl | ||
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:24 |
LocutusOfBorg | pitti, pping again about opencv autopkgtests (please run against proposed) | 08:56 |
pitti | LocutusOfBorg: triggered | 08:57 |
=== hikiko|bbl is now known as hikiko | ||
=== maxb_ is now known as maxb | ||
pitti | LocutusOfBorg: indeed, looks better now (still blocked by the freeze) | 10:51 |
LocutusOfBorg | thanks pitti | 10:54 |
=== stub` is now known as stub | ||
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 | 11:27 |
=== _salem is now known as salem_ | ||
=== dpm_ is now known as dpm | ||
pitti | GunnarHj: oh, so this isn't a regression from Monday's langpack builds, AFAIUI? | 12:49 |
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:50 |
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:51 |
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 | 12:52 |
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:01 |
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:03 |
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:12 |
rbasak | cyphermox: no I'm not affected, but it's a hot bug and I wasn't sure if you'd seen it. | 13:16 |
cyphermox | happyaron: ^ | 13:18 |
=== JanC is now known as Guest53913 | ||
=== JanC_ is now known as JanC | ||
pete-woods | pitti: question about packaging dbusmock templates | 14:47 |
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:48 |
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:49 |
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:50 |
pitti | ah | 14:51 |
pete-woods | which stays in lock-step with the API | 14:51 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
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:08 |
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:09 |
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:23 |
slangasek | nacc: 'wontfix' would be my preference there :) | 15:30 |
nacc | slangasek: ack, thanks! | 15:42 |
nacc | mdeslaur: fyi, ondrej picked up your patch, thanks again! | 15:45 |
mdeslaur | nacc: ah, cool, thanks for sending it to debian! | 15:46 |
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:00 |
semiosis | if you can't get to it, do you think anyone else might be able to? | 16:02 |
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:03 |
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:04 |
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. | 16:06 |
=== dpm is now known as dpm-afk | ||
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! | 17:41 |
mterry | @pilot in | 18:09 |
=== 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 | ||
coreycb | arges, hello there, any chance you could review some of our sru's in the wily queue? | 18:48 |
doko | slangasek, won't we trigger the "interpreter problem" by making setuptools M-A: foreign? | 18:57 |
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:01 |
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:02 |
highvoltage | /win 19 | 19:04 |
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:07 |
doko | wondering why, because setuptools depends on pkg-resources | 19:09 |
doko | but yes, making it M-A: foreign is less invasive than making it Arch: any | 19:10 |
mvo | arges: hey, if you have time, it would be great if you could do a sru review/approval for snapd 2.0.10 | 19:45 |
arges | ok | 20:07 |
arges | coreycb: sure | 20:11 |
coreycb | arges, thanks | 20:12 |
nacc | hallyn: ping | 20:30 |
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:31 |
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:32 |
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 | 20:33 |
=== 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: | ||
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:34 |
nacc | rbasak: i'll update my MR too | 20:35 |
hallyn | excellent | 20:35 |
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:39 |
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:40 |
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:41 |
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:42 | |
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:43 |
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:44 |
pitti | i. e. not worth keeping a delta over it, but worth filing fix to Debian | 20:45 |
nacc | pitti: yep, submitting now | 20:49 |
nacc | hallyn: pitti: thanks again for the guidance | 20:51 |
pitti | nacc: yw! | 20:51 |
hallyn | \o | 20:51 |
Odd_Bloke | How can I find if there's an Ubuntu bug corresponding to a Debian bug? | 21:00 |
Odd_Bloke | *find out | 21:00 |
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:02 |
Odd_Bloke | pitti: Thanks! | 21:05 |
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:19 |
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:20 |
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:21 |
Unit193 | Alright, thanks. | 21:22 |
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:30 |
slangasek | nacc: there's certainly no reason not to | 21:34 |
nacc | slangasek: can i just provide a reasonable (read: common) default? | 21:35 |
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:36 |
nacc | slangasek: ack, that's what i was planning on | 21:37 |
nacc | will send that to debian too :) | 21:37 |
=== salem_ is now known as _salem |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!