/srv/irclogs.ubuntu.com/2016/06/29/#ubuntu-devel.txt

naccslangasek: 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 package00:57
ubottuLaunchpad bug 1579815 in php-mongodb (Ubuntu) "Please "duplicate" as php5-mongodb to trusty-universe" [Wishlist,New] https://launchpad.net/bugs/157981500:57
slangaseknacc: that would normally be a no-go for SRU01:37
naccslangasek: that's what i thought as well, just wasn't sure, thanks!01:37
naccslangasek: given that, would i change the state to "invalid" (with an appropriate comment)? Or would you just leave it as "new"?01:42
sarnoldnacc: would this help the reporter? https://launchpad.net/~ondrej/+archive/ubuntu/php01:48
naccsarnold: 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 trusty01:50
naccsarnold: hrm, perhaps i was wrong! Provides: php5.5-mongodb, php5.6-mongodb, php7.0-mongodb01:52
sarnoldnacc: 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
naccsarnold: yeah, i think that's because of the build-deps01:55
naccsarnold: not entirely sure01:55
naccsarnold: a lot of people use his ppa, i know that01:55
sarnoldyeah01:55
naccah well, i think i've done my due diligence now :)01:56
sarnold:)01:56
=== athairus is now known as afkthairus
pittiGood morning06:35
=== hikiko is now known as hikiko|bbl
Odd_Blokeslangasek: 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
LocutusOfBorgpitti, pping again about opencv autopkgtests (please run against proposed)08:56
pittiLocutusOfBorg: triggered08:57
=== hikiko|bbl is now known as hikiko
=== maxb_ is now known as maxb
pittiLocutusOfBorg: indeed, looks better now (still blocked by the freeze)10:51
LocutusOfBorgthanks pitti10:54
=== stub` is now known as stub
GunnarHjpitti: Thoughts on bug #1591503? Would it be a good idea to rebuild fcitx-mozc for now and somehow override pkgstriptranslations?11:27
ubottubug 1591503 in language-pack-zh-hant-base (Ubuntu) "missing fcitx-mozc.mo" [Medium,Confirmed] https://launchpad.net/bugs/159150311:27
=== _salem is now known as salem_
=== dpm_ is now known as dpm
pittiGunnarHj: oh, so this isn't a regression from Monday's langpack builds, AFAIUI?12:49
rbasakpitti: 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
ubottubug 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/159605612:50
rbasakWe can wait for it to settle and have some testing first of course.12:50
pittirbasak: yeah, seems fairly harmless12:50
rbasakGreat, thanks!12:50
pittirbasak: added a task12:51
rbasakI just went to do that and Xenial wasn't in the list of options. Most confusing :-)12:51
pittirbasak: probably just mid-air collision12:52
rbasakYeah. Webapps and concurrency don't mix.12:52
pittiI mean, I probably already added it when you tried to12:52
pittiGunnarHj: 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 now13:01
rbasakcyphermox: bug 1211110 looks like it could use some attention. There are a few bugs I've seen with poor NM/OpenVPN interactions.13:03
ubottubug 1211110 in openvpn (Ubuntu) "network manager openvpn dns push data not updating system DNS addresses" [High,Confirmed] https://launchpad.net/bugs/121111013:03
cyphermoxrbasak: are you pointing it out because you're affected?13:12
cyphermoxunfortunately, it's quite hard to get things to play nice when they all expect to be authoritative and they all go muck in resolv.conf13:12
rbasakcyphermox: no I'm not affected, but it's a hot bug and I wasn't sure if you'd seen it.13:16
cyphermoxhappyaron: ^13:18
=== JanC is now known as Guest53913
=== JanC_ is now known as JanC
pete-woodspitti: question about packaging dbusmock templates14:47
pete-woodsif a package stuffs a new template in /usr/lib/python3/dist-packages/dbusmock/templates/14:48
pete-woodsare you okay with that?14:48
pete-woods(I think it's already happening, btw)14:48
pittipete-woods: fine for me, as long as there are no conflicts14:48
pete-woodspitti: awesome, that makes my life easier then14:49
pittipete-woods: however, you can specify a full path for the template14:49
pete-woodsas we can put new templates in a package we manage, without having to bug you14:49
pittiso it shouldn't usually be necessary14:49
pete-woodsyeah, there's that option too14:49
pete-woodsI'd really like to have an official directory for it14:49
pete-woodsso I can know where to look14:49
pittitemplates should not really be shipped in debs14:49
pittithey should only be necessary during package build ("make check") or autopkgtests, in both cases it can be taken from the source14:50
pittiunless there's some foo-test-tools package14:50
pete-woodsactually thinking of -dev packages14:50
pete-woodsso I can include e.g. a mock template for connectivity-api in connectivity-api-dev14:50
pittiah14:51
pete-woodswhich stays in lock-step with the API14:51
pete-woodspitti: 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-woodsif we could agree on that, and get a patch to python-dbusmock to search it, that would be great15:01
pete-woodsas 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 responsible15:01
pete-woodsfor15:01
pittipete-woods: ah, and you don't like the above because it's Debian specific? (specific to python3-defaults, that is)15:02
pete-woodspitti: it just feels a bit naughty for us to stuff things in the upstream package's path15:02
pete-woodsas opposed to e.g. a /usr/share/dbusmock/templates dir15:03
pittipete-woods: I don't mind moving the templates to /usr/share/python-dbusmock/templates/ and search/put them there15:03
pete-woodsor something along those lines15:03
pete-woodspitti: that would be great15:03
pete-woodswe want to put some documentation together for how we'd like teams to support testing by providing their own mocks15:03
pete-woodsmocks for their own daemons I mean15:04
pete-woodsand being able to release them into a standard place alongside their headers, etc would be great15:04
pete-woodsespecially being able to point to a readme.md on your github site saying "this is where templates go"15:08
pete-woodsso we don't just look like some lone nuts15:08
pittipete-woods: well, if we change that, then dbusmock's own templates would go there too15:08
pete-woodspitti: well it could search both paths15:09
pete-woodspitti: but I'm happy with either option there15:09
pittithat sounds a bit complicated to me15:09
pittiand makes it less obvious which one wins on conflicts15:09
pete-woodsthat's a fair point15:09
pete-woodspitti: 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
slangaseknacc: 'wontfix' would be my preference there :)15:30
naccslangasek: ack, thanks!15:42
naccmdeslaur: fyi, ondrej picked up your patch, thanks again!15:45
mdeslaurnacc: ah, cool, thanks for sending it to debian!15:46
semiosisOdd_Bloke: hi.  just checking in.  i'll be around most of the day if you have any questions about the merge.16:00
Odd_Blokesemiosis: Oh, shoot, that completely fell off my plate. :(16:00
semiosisif you can't get to it, do you think anyone else might be able to?16:02
Odd_Blokesemiosis: It'll need to be someone on my team, and we're all equivalently busy ATM, I'm afraid.16:03
Odd_Blokesemiosis: But I've milestoned it in a way that it'll show up on my list of things to do.16:03
Odd_Blokesemiosis: 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
semiosiswell 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_Blokesemiosis: Apologies for dropping it.16:04
Odd_Blokesemiosis: Understood, thank you again for taking the time to submit the MP.16:06
semiosisit'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
sil2100infinity, 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
sil2100infinity, slangasek: thanks!17:41
mterry@pilot in18: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
coreycbarges, hello there, any chance you could review some of our sru's in the wily queue?18:48
dokoslangasek, won't we trigger the "interpreter problem" by making setuptools M-A: foreign?18:57
slangasekdoko: 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 this19:01
slangasekcurrently, and not annotating it blocks cross-building, so IMHO it's the lesser evil19:01
dokoslangasek, agreed about python-setuptools, but python-pkg-resources is much more used19:02
dokothe alternative is to make these packages Arch: any19:02
highvoltage/win 1919:04
slangasekdoko: I get what I need (unblocking unity8 cross-build) with just python-setuptools, python-pkg-resources doesn't matter to me19:07
slangasekdoko: so I guess I should've filed a separate bug report, sorry19:07
dokowondering why, because setuptools depends on pkg-resources19:09
dokobut yes, making it M-A: foreign is less invasive than making it Arch: any19:10
mvoarges: hey, if you have time, it would be great if you could do a sru review/approval for snapd 2.0.1019:45
argesok20:07
argescoreycb: sure20:11
coreycbarges, thanks20:12
nacchallyn: ping20:30
hallynnacc: .20:31
nacchallyn: 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
nacchallyn: i'm thinking we can drop that delta20:32
hallynnacc: <shrug> i don't have /var/lock/subsys20:32
hallynxenial system running upstart20:32
nacchallyn: ah, might be an upstart vs. systemd thing?20:32
hallynbut will openmpi create the dir if its needed?20:32
nacca 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
hallyni 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 exist20:33
nacchallyn: 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 that20:33
hallynmaybe update /etc/init/mounted-var.conf20:33
mterry@pilot out20: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:
hallynnacc: cool - o \o20:34
hallynhm20:34
hallynthat's me with broken glasses20:34
hallyn\o20:34
naccheh20:34
nacchallyn: i think we can send the rest of the delta straight to debian, as it's bugfixes, etc. and then we can sync finally20:34
naccrbasak: --^ fyi20:34
naccrbasak: i'll update my MR too20:35
hallynexcellent20:35
pittinacc, hallyn: /run/lock/subsys is created in /usr/lib/tmpfiles.d/legacy.conf; happy to drop this if we don't need it20:39
hallynpitti: i think its the other way around - openmpi wants it and upstart doesn't create it20:40
naccpitti: ah interesting ...20:40
hallynalthough maybe openmpi should then be updated20:40
nacchallyn: well, we could change openipmi to use /var/lock then20:40
hallynif it need something out of 'legacy.conf' :)20:40
hallynright20:40
pittiyeah, we should not rely on those old paths any more20:40
naccpitti: and that would drop one more legacy user20:40
naccok, is that true in debian too, pitti ?20:40
hallyngood justification for a push to debian.20:40
hallynthx pitti20:41
pittialso, not /var/lock/, using this is brittle for early-boot stuff20:41
argescoreycb: why did you split the openstack SRU bugs up20:41
pittinacc: yes20:41
naccpitti: where would you suggest?20:41
pittinacc: /run/lock20:41
pittinacc: /var/lock is a symlink, but that doesn't help you if /var itself is remote20:41
naccpitti: ah intersetsing20:41
nacc*interesting20:41
pittithat was the whole reason for introducing /run :)20:41
naccpitti: got it, i'll update the patch and fix that then20:42
pitti(well, that and that it's guaranteed to be a tmpfs)20:42
pittinacc: cheers20:42
pittiFWIW, I don't think that we had /var/lock/subsys under sysvinit either20:42
* pitti boots a debian sid with sysv to check20:42
coreycbarges, I think originally glance-store wasn't ready so we didn't want to hold up the neutron*/nova sru20:43
pittinacc: FTR, openmpi is not early-boot stuff, so /var/lock is not technically broken; but it's better style to use /run directly IMHO20:43
naccpitti: yep, make ssense20:44
pittinacc: yep, no /run/lock/subsys (and therefore not /var/lock/subsys) under sysvinit-core in Debian20:44
pittinacc: so, doesn't affect us, but does affect Debian20:44
pittii. e. not worth keeping a delta over it, but worth filing fix to Debian20:45
naccpitti: yep, submitting now20:49
nacchallyn: pitti: thanks again for the guidance20:51
pittinacc: yw!20:51
hallyn\o20:51
Odd_BlokeHow can I find if there's an Ubuntu bug corresponding to a Debian bug?21:00
Odd_Bloke*find out21:00
pittiOdd_Bloke: https://bugs.launchpad.net/bugs/bugtrackers/debbugs/1234521:02
ubottuLaunchpad bug 12345 in isdnutils (Ubuntu) "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]21:02
pittiOdd_Bloke: of course that only works if the ubuntu bug actually got linked to that 12345 debian bug21:02
Odd_Blokepitti: Thanks!21:05
robert_ancellslangasek, 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
slangasekrobert_ancell: I mean that the Packages file can annotate what the support period is for a given binary package21:19
robert_ancellah21:19
slangasekblacklisting a package from building should be done by changing the package itself to not build for that arch21:19
robert_ancelloh right, that's easy to do. duh.21:20
Unit193robert_ancell: LP 1494491 got a chance this cycle, btw?21:20
ubottuLaunchpad bug 1494491 in Light Display Manager "Use accountsservice extensions for background, keyboard layouts, has-messages" [Medium,Triaged] https://launchpad.net/bugs/149449121:20
robert_ancellUnit193, if someone does the work I'm happy to review / land it21:21
robert_ancellIt seems unlikely I'll have time at present21:21
Unit193Alright, thanks.21:22
naccpitti: 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: #159647421:30
ubottuLaunchpad bug 1596474 in openipmi (Ubuntu) "openipmi adding to autoload fail" [High,New] https://launchpad.net/bugs/159647421:30
slangaseknacc: there's certainly no reason not to21:34
naccslangasek: can i just provide a reasonable (read: common) default?21:35
slangaseknacc: reasonable defaults are 'Default-Start: 2 3 4 5' 'Default-Stop: 0 1 6'21:36
slangasekand you should certainly use those values :)21:36
naccslangasek: ack, that's what i was planning on21:37
naccwill 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!