[06:59] <Logan> doko: if you're around, I've pinged you in Bug 1536093 - just needs a quick fix. it's affecting a lot of people, unfortunately
[07:06]  * alkisg had to purge a lot of apt related packages and to reinstall them later in order to get past this...
[07:58] <ricotz> alkisg, "dpkg -i --force-overwrite libxapian-1.3-4_*.deb"
[08:00] <alkisg> Ah, I tried dpkg-divert but I didn't take time to try other things, and I worked around it with purge + reinstall, thanks :)
[08:02] <sarnold> how'd this package make out of -proposed?
[08:05] <pitti> Good morning
[08:05] <pitti> sarnold: we don't do upgrade testing as part of -proposed tests
[08:05] <pitti> sarnold: we implicitly do for packages which are in a minimal install, but xapian is far from that
[08:06] <sarnold> morning pitti :) I'm surprised to see you already, I though tyou just quit a few hours ago...
[08:06] <pitti> sarnold: right, I did a nightshift for the proposed-migration sprint
[08:06] <sarnold> pitti: did this pass then because there's no autopkgtests that rely upon it?
[08:07] <sarnold> pitti: eep :) I had assmed maybe you'd be over on this continent..
[08:07] <pitti> sarnold: no, but fresh installs of the debs are fine -- this is an upgrade prolbem
[08:07] <sarnold> pitti: ahhhhhhh
[08:07] <pitti> sarnold: only in spirit :) day time in Europe, night shift for the US guys
[08:07] <spineau> mitya57: hello, I've updated pyotherside packaging in debian to unblock the MIR (https://bugs.launchpad.net/ubuntu/+source/pyotherside/+bug/1534067). If you could review/sponsor it I would be extremely grateful.
[08:08] <sarnold> pitti: thanks for the explanation
[08:09] <pitti> sarnold: so, we actually have (or at least had) daily upgrade tests which should pick this up
[08:09] <sarnold> pitti: piuparts thing?
[08:09] <pitti> but https://platform-qa-jenkins.ubuntu.com/job/upgrade_ubuntu-trusty-xenial-desktop-amd64_qemu/ has failed for a while
[08:10] <pitti> sarnold: no, I don't think this uses piuparts; just a standard desktop/server/etc. base image, and do-release-upgrade, and some post-upgrade checks ("does thist still boot", etc."0
[08:10] <sarnold> that's a lot of red dots :)
[08:10] <pitti> https://platform-qa-jenkins.ubuntu.com/ has green ones, too
[08:11] <pitti> https://platform-qa-jenkins.ubuntu.com/job/upgrade_ubuntu-trusty-xenial-desktop-i386_qemu/59/console
[08:11] <pitti> lol
[08:11] <cyphermox> Good morning!
[08:11] <pitti> I don't think that actually even started the upgrade
[08:11] <pitti> which might be an actual problem given that the  other tests work, or some desktop specific upgrade test problem
[08:12] <pitti> hey cyphermox!
[08:13] <pitti> $ sudo dpkg -i --force-overwrite /var/cache/apt/archives/libxapian-1.3-5_1.3.4-0ubuntu4_amd64.deb
[08:13] <pitti> FTR, to fix this locally
[08:21] <Unit193> pitti: Err, I liked `sudo dpkg --purge libxapian-1.3-4` better, less --force.
[08:27] <LocutusOfBorg> wonderful, virtualbox doesn't build, and I don't know how to fix
[08:27] <LocutusOfBorg>  sbuild-build-depends-virtualbox-dummy : Depends: texlive-fonts-extra but it is not going to be installed
[08:28] <LocutusOfBorg> texlive-fonts-extra/amd64 unsatisfiable Depends: fonts-roboto-hinted
[08:29] <LocutusOfBorg> I did a syncpackage fonts-roboto
[08:29] <LocutusOfBorg> not sure why it has been kicked out
[08:30] <sarnold> looks like there's a fonts-roboto but not the -hinted variant https://launchpad.net/ubuntu/+source/fonts-android
[08:30] <LocutusOfBorg> I think I'm talking about src:fonts-roboto
[08:30] <LocutusOfBorg> not the one provided by fonts-android
[08:31] <sarnold> ahhhh
[08:32] <sarnold> hmm, did that also drop the fonts-roboto-hinted? check the changelog https://launchpad.net/debian/+source/fonts-roboto
[08:32] <LocutusOfBorg> fonts-android needs a merge I think :)
[08:33] <LocutusOfBorg> I checked the PTS https://packages.debian.org/unstable/fonts-roboto-hinted
[09:41] <LocutusOfBorg> any pretty please sponsor for this?
[09:41] <LocutusOfBorg> "syncpackage -s costamagnagianfranco -V 1:6.0.1r3-2 -f -b 1536547 fonts-android"
[09:41] <LocutusOfBorg> after double checking
[10:05] <rbasak> LocutusOfBorg: I would but I'm hesitant to touch that package because it looks like the phone is a heavy consumer. Maybe get one of that team to check and sync it?
[10:10] <LocutusOfBorg> well, somebody will hopefully take the job :)
[10:10] <LocutusOfBorg> seems it won't block the virtualbox migration hopefully
[10:10] <LocutusOfBorg> even if fonts-droid took over a binary package from it
[10:16] <LocutusOfBorg> doko, can you please sync python-greenlet? or fakesync, since the orig tarballs seems to differ
[10:20] <pitti> xnox: any luck with the ppc64el instance?
[10:21] <xnox> pitti, yes. You can kill it by the way. I have reproduced the bug with more logs. and then loggedout. I have uploaded new btrfs-tools into debian, it synced into ubuntu. However, need to resolve ftbfs on arm64 for it to migrate and build updated iso image.
[10:21] <xnox> due to compiler ice.
[10:22] <pitti> xnox: ah, great! so d-i in nested QEMU worked?
[10:22]  * pitti kills it to reclaim some quota back
[10:22] <xnox> pitti, somewhat slow =)
[10:22] <xnox> pitti, yeah do kill it.
[10:23] <pitti> crw-rw---- 1 root kvm 10, 232 Jan 19 17:08 /dev/kvm
[10:23] <pitti> xnox: ^ this didn't help? (I didn't put ubuntu into the kvm group)
[10:33] <LocutusOfBorg> pitti, is openvpn on your radar? if not, can I do a merge and ping you with a debdiff?
[10:38] <xnox> pitti, can't remember if i checked that or not. I think i was rebel, and run it as root anyway.
[10:39] <xnox> pitti, it was good enough. so meh =)
[10:40] <LocutusOfBorg> well, I did it and opened LP: #1536568
[11:10] <pitti> LocutusOfBorg: thanks
[11:11] <pitti> LocutusOfBorg: ah, I see Debian accepted our startup ordering patch
[11:16] <pitti> LocutusOfBorg: LGTM! Just one nitpick:
[11:16] <pitti> Remaining Ubuntu changes:
[11:16] <pitti> [...]
[11:16] <pitti>   - drop openvpn@.service change, included in Debian
[11:17] <pitti> this looks strange, as that's not a "remaining change", it's the opposite
[11:17] <pitti> I'll just drop that changelog line
[11:17] <pitti> LocutusOfBorg: test-building and running with my VPN, then I'll upload
[11:23] <pitti> LocutusOfBorg: uploaded, thanks!
[11:25] <LocutusOfBorg> thanks :)
[11:26] <LocutusOfBorg> I wasn't sure about not mentioning, or mentioning the not-a-delta-anymore line
[11:26] <LocutusOfBorg> :)
[11:26] <pitti> LocutusOfBorg: it's fine to mention it as a second entry, like " * Drop..." (but not under " * Remaining changes:")
[11:26] <pitti> LocutusOfBorg: but really, it's just a tiny detail
[11:27] <pitti> LocutusOfBorg: but as the Debian changelog gets included, I usually leave it out
[11:28] <LocutusOfBorg> thanks, I was thinking the same, the change was mentioned a few lines below, but with a different phrasing
[11:32] <pitti> apw: hm, all linux* stuff and d-i are valid candidates, but there's some uninstallability; did you already check this, or shoudl we look into this?
[11:32] <apw> pitti, oh i know what it is, it is ppp being in the pile
[11:33] <apw> isdnutils has a tight ppp linkage
[11:33] <apw> i am looking at the merge right now
[11:33] <pitti> apw: that's not on the uninstallabilitly list on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt though
[11:33] <pitti> apw: not for "trying: linux" I mean (it's separately uninstallable, but due to NM)
[11:34] <apw> Trying easy from autohinter: debian-installer/20101020ubuntu412 linux-signed/4.3.0-7.18 linux/4.3.0-7.18 ppp/2.4.7-1+1ubuntu1 pptpd/1.4.0-7 network-manager-pptp/1.0.8-2ubuntu1 linux-meta/4.3.0.7.8
[11:34] <pitti> ah, so linux blocks on d-i blocks on ppp
[11:34] <apw> right and that is blocked on isdnutils which has
[11:34] <pitti> apw: thans
[11:35] <pitti> (OMG, it's 2016, we still ship isdnutils?)
[11:35] <apw> Depends: ppp (>= 2.4.6), ppp (<< 2.4.7),
[11:35] <apw> which is preventing pppd from migrating
[11:35] <apw> there is an update in debian which i have just merged, just need to review if it makes _any_ sense
[11:35]  * Laney knows of people still using ISDN
[11:37] <yofel> Laney: could you please add extra-cmake-modules back to the kubuntu packageset?
[11:37] <yofel> and is there a better procedure for such requests than pinging some dmb member on IRC? ^^
[11:37] <Laney> emailing the list
[11:37] <yofel> the private one?
[11:37] <Laney> no
[11:37] <Laney> devel-permissions
[11:37] <yofel> ok, thanks.
[11:38] <Laney> why isn't it in your set?
[11:38] <Laney> because something else uses it I suppsoe
[11:39] <yofel> probably, but I haven't found out what
[11:41] <apw> pitti, ok the merge is small enough to be eyeballable i recon, so i think i'll build test it and throw it over the wall
[11:41] <Laney> fcitx at least
[11:41] <pitti> apw: it's not like anybody could really test it :)
[11:42] <Laney> anyway it seems ok
[11:43] <pitti> apw: ISDN had been a big thing in Germany (and not much in other states) until ~ 2000 or so; these days companies still use it for internal phone networks, but *nobody* hooks a linux server up to an ISDN box
[11:43] <pitti> (any more)
[11:46] <apw> i hope not :)  though as you say .de loves it
[11:46] <apw> i reemeber our uni converting the 30line isdn thing into an IP line and gaining a bunch of performance, 20 years ago
[11:47] <maswan> roughly 20 years ago the old phone monopoly was starting to think about introducing isdn in .se, using convoluted pay-per-traffic schemes, around the same time ethernet to the apartment started to get common. It never got anywhere here.
[11:48] <apw> isdn seemed to last about a year as a network thing here
[11:49] <mitya57> zyga, spineau: ok to sponsor pyotherside (in Debian) now?
[11:49] <Laney> mitya57: doooo it
[11:49] <spineau> mitya57: +1000
[11:49]  * Laney is anxious about iso build breakage
[11:49]  * mitya57 does
[11:49] <Laney> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu
[11:50] <mitya57> spineau, unstable or experimental then? The previous upload was to experimental.
[11:51] <spineau> mitya57: I don't know it was experimental the first time
[11:52] <spineau> mitya57: if ubuntu can be sync'ed from experimental I wouldn't probably change it now
[11:52] <mitya57> It can be synced, yes. Though I can't find any reason why the previous upload was in experimental.
[11:53] <mitya57> Are 1.2.0 and 1.4.0 releases compatible?
[11:54]  * spineau is looking at http://pyotherside.readthedocs.org/en/latest/#version-1-4-0-2015-02-19
[11:56] <mitya57> Ok, let's keep it in experimental for now. It's easy to do another upload pushing it to unstable if needed.
[11:57] <mitya57> Uploaded!
[11:57] <mitya57> (Please tag it yourself)
[11:58] <spineau> mitya57: I was asking in a separate channel (#checkbox) but for us (and our usage) 1.4.0 brings more features and we didn't have to change out code to be compliant but we are not using all pyotherside new methods
[11:59] <mitya57> For Ubuntu there's no difference. If you want to upload checkbox to Debian too and need pyotherside in unstable, ping me and I'll do another upload.
[12:00] <mitya57> In any case I heard zyga wanted to make some other changes to the packaging like moving it to pkg-kde team.
[12:00] <spineau> mitya57: ok, checkbox (-converged) is ubuntu specific so I think we're good now
[12:01] <mitya57> Ok
[12:01] <spineau> mitya57: about tag, you meant git-dpm tag?
[12:01] <mitya57> Yes
[12:01] <spineau> mitya57: ok, doing it right now
[12:01] <spineau> mitya57: again thanks a lot for your help and time
[12:02] <mitya57> You are welcome! I'll try to sync it into Ubuntu when LP picks it up (that'll be tomorrow).
[12:10] <mitya57> spineau, oops, I forgot it has a new binary. I'll reupload it now, but that also means it'll take a bit longer until it is accepted.
[12:10] <spineau> mitya57: like going into the NEW queue
[12:10] <mitya57> Yes
[12:12] <spineau> mitya57: ok, I think I have to convince cyphermox to accept the MIR with the package as it is today
[12:12] <mitya57> :)
[12:12] <spineau> mitya57: as the best we can do now is waiting for ftp masters
[12:12] <mitya57> They are usually quick on processing new binaries (but not for new sources)
[12:13] <mitya57> Where quick means less than week
[12:14] <Laney> you could fakesync it
[12:15] <spineau> Laney: what would it mean in practice (sorry it's the first time I'm facing such issue)
[12:16] <mitya57> That means a normal upload to Ubuntu rather than sync.
[12:17] <mitya57> I have no problem with waiting, but I can do that too if you want.
[12:18] <spineau> mitya57: the mir bug is critical as it blocks the xenial daily builds, if you can fakesync to ubuntu, I'm sure the MIR team will accept pyotherside
[12:19] <mitya57> Ok, will do that now
[12:19] <spineau> mitya57: thanks
[12:19] <Laney> thanks mitya57
[12:19] <Laney> we could also unseed checkbox for a bit until this is fixed
[12:20] <mitya57> Done!
[12:21]  * mitya57 afk
[12:24] <apw> pitti, bah overlapped with someone else, theirs hit the queue 5m before mine
[12:24] <pitti> yay coordination :/
[12:24] <apw> anyhow its been uploaded, so i assume it will unplug shortly
[12:24] <apw> yeah i cna't have tlaked about it more here, so, whatever
[12:26] <spineau> Laney: it depends if it's easy to restore. The last time I filed a MIR bug, it took less than a day from fix-committed to fix-released. So if someone from the MIR team could review https://bugs.launchpad.net/ubuntu/+source/pyotherside/+bug/1534067 today we could have successful builds tomorrow morning
[12:27] <pitti> spineau: that's not the issue -- once a MIR is approved, any archive admin can promote it and that's fast
[12:27] <pitti> but this MIR hasn't been reviewed/approved yet
[12:27] <Laney> maybe we can ping a friendly MIR teamer
[12:31] <spineau> ok, if I can help/answer questions about pytherside in ubuntu, just ping me
[12:59] <zyga> mitya57: hey
[12:59] <zyga> mitya57: thanks for helping us out :)
[13:36] <cyphermox> mitya57: spineau: looking at pyotherside now
[13:37] <jamespage> anyone know if there is a nice way to make AC_CHECK_HEADERS multi-arch aware?
[13:38] <spineau> cyphermox: thank you
[13:38] <jamespage> i.e. /usr/include/<tuple>
[13:38] <jamespage> for checking like
[13:53] <flexiondotorg> If anyone is able, I'd really appreciate some sponsoring for Ubuntu MATE :-)
[13:58] <maswan> doko: RH seems to think that CVE-2015-7575 (rejecting md5 for tls) applies to java as well, does this apply to ubuntu (or debian) versions of openjdk too? There has been quite a bit of discussion in $work regarding this today.
[14:00] <mdeslaur> maswan: probably, yes. We follow new openjdk releases, I believe we're going to publish one soon.
[14:05] <cjwatson> jamespage: you shouldn't need to do anything; /usr/include/<current triplet> is on the include path by default
[14:05] <cyphermox> spineau: who will deal with fixing things in Ubuntu if bugs happen? neither you nor zyga seem to have the requisite upload rights?
[14:06] <jamespage> cjwatson, yeah - I think I see my problem - something else (I thought it was this)
[14:07] <spineau> cyphermox: we can fix bugs indeed but someone else will have to upload them
[14:07] <spineau> cyphermox: is that an issue?
[14:07] <cyphermox> well it will certainly make your life harder
[14:08] <cyphermox> what is pyotherside used for in checkbox?
[14:09] <spineau> cyphermox: the new checkbox-converged is still using QML but we get rig of the dbus service to use python from QML thanks to pyotherside
[14:09] <spineau> s/rig/rid
[14:10] <spineau> cyphermox: it's the bridge between the python3 plainbox lib and QML
[14:29] <maswan> mdeslaur: thank you
[14:35] <spineau> cyphermox: I'll soon apply for checkbox upload rights. Do you think I should also apply for pyotherside?
[14:35] <spineau> I mean with the same application
[14:43] <cyphermox> spineau: it's up to you, if you can show work you've done on the packages
[14:45] <spineau> cyphermox: I'll do my best for pyotherside. But you'right, w/o such upload permissions bug fixes may be delayed in ubuntu
[15:10] <cpaelzer> I seem to miss something when creating my dsc & .changes with dpkg-buildpackage
[15:11] <cpaelzer> the background is that I pulled the source from another ppa, made a few changes and want to dput it to my ppa
[15:11] <cpaelzer> for one of the related archives dpkg-buildpackage decides to go "dpkg-source: info: building openvswitch-dpdk using existing ..."
[15:11] <cpaelzer> now when I puload the .changes file launchpad (correctly) complains about that archive being missing
[15:12] <cpaelzer> I guess there is a way to include (or not exclude) that file, but the manpage isn't obvious enough for now
[15:12] <cpaelzer> rbasak: in case you know ^^
[15:12] <cjwatson> cpaelzer: dpkg-buildpackage -sa
[15:13] <cjwatson> cpaelzer: that's autodetected in some cases but not all
[15:13] <cjwatson> (to be clear, I mean add -sa to the other options you're already passing)
[15:13] <cpaelzer> cjwatson: "-sa    Forces the inclusion of the original source." on dpkg-genchanges bassed by buildpackage - thanks
[15:41] <spineau> cyphermox: thanks for the pyotherside MIR review.
[15:41] <spineau> cyphermox: should we change the status of the bug now?
[15:42] <cyphermox> spineau: nah it's good
[15:42] <spineau> cyphermox: ok
[15:44] <LocutusOfBorg> pitti, a regression in openvpn :( did you read it?
[15:44] <LocutusOfBorg> lp: #153568
[15:45] <LocutusOfBorg> lp: #1536568
[16:10] <pitti> LocutusOfBorg: no, not yet; sorry, busy
[16:11] <LocutusOfBorg> seems an user error
[16:12] <LocutusOfBorg> np
[16:43] <tkamppeter> pitti, hi
[16:45] <tkamppeter> I have a question: The liblouis source package and most of its binary packages are in Main, but liblouis-bin is in Universe, how do I get liblouis-bin into Main?
[16:48] <cjwatson> tkamppeter: make something in main (build-)depend on it or recommend it
[16:54] <tkamppeter> cjwatson, thank you very much. I will do so.
[18:01] <mitya57> zyga, you're welcome!
[18:17] <doko> stgraber, https://bugs.launchpad.net/bugs/1536727
[18:24] <tedg> slangasek: It seems that (though we haven't traced it down entirely) the upstart session can't set the cgroup of a job on xenial.
[18:24] <tedg> Does that ring a bell? Or are we likely barking up the wrong tree.
[18:26] <tedg> Hmm, I think we might have started it after the session. Will check that.
[18:29] <slangasek> tedg: I saw a blog from hallyn talking about changes to cgroups handling in xenial, not sure if that could be related?
[18:36] <hallyn> the cgroup handling changes is only for logins - so could affect upstart user jobs if they are making assumptions about cgroup paths, and could affect unprivileged trusty containers o nxenial
[19:04] <tedg> Reading the blog post, and I *think* we're okay because we're using freezer... but the path thing doesn't seem to be there.
[19:04] <tedg> Doesn't the path end up relative?
[19:26] <hallyn> tedg: it's created relative to the cgroup path of upstart, yes
[19:36] <SpamapS> marcoceppi: aw, I've missed Jorging. ;)
[19:36] <marcoceppi> SpamapS: are you in the audience?
[19:36] <SpamapS> marcoceppi: hi from 3 rows behind you to the right btw. ;)
[20:23] <tedg> slangasek: hallyn: I added a bug task for bug 1535058 to Upstart
[20:23] <tedg> Basically it seems that if my Upstart job has "cgroup freezer" it won't start
[20:24] <tedg> So it's not even back to my code talking to cgmanager, it is an issue with Upstart itself talking to cgmanager.
[20:28] <hallyn> tedg: thx
[21:13] <spineau> mitya57: I've made a mistake in pyotherside packaging (forgot to update the path to the test suite for adt-run). I've just fixed it in 1.4.0-3
[21:15] <spineau> mitya57: I'll need your sponsorship once again to update the version in debian/new and fakesync it to ubuntu
[21:16] <spineau> mitya57: I tested to be sure the fix works using adt-run on vivid img (http://pastebin.ubuntu.com/14592729/)
[21:40] <smoser> hey. is this known...
[21:41] <smoser> http://paste.ubuntu.com/14592856/
[21:41] <smoser> the key l ines there being:
[21:41] <smoser> update-initramfs: deferring update (hook will be called later)
[21:41] <smoser> /bin/cp: cannot stat ‘/boot/initrd.img-4.3.0-7-generic’: No such file or directory
[21:41] <smoser> Failed to copy /boot/initrd.img-4.3.0-7-generic to /boot/initrd.img at /var/lib/dpkg/info/linux-image-4.3.0-7-generic.postinst line 745.
[21:45] <smoser> anyone else seen that ? i'm seeing it in a chroot with qemu-static, but it seems from those lines fairly straight forward error.
[21:45] <smoser> update-initramfs got delayed, but the postinst was trying to copy it
[22:07] <mwhudson> when i run adt-run -U ... --- qemu adt-xenial-amd64-cloud.img the apt-get update fails
[22:18] <smoser> well, filed that at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536810
[22:18] <smoser> mwhudson, yah, i saw apt-get update errors earlier today too.
[22:18] <smoser> xenial moving target is guaranteed to happen at points.
[22:19] <smoser> until https://bugs.launchpad.net/launchpad/+bug/1430011 is fixed.
[22:19] <mwhudson> smoser: nah, this is more fundamental (sorry got distracted)
[22:19] <mwhudson> W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/restricted/source/Sources  Cannot initiate the connection to 10.0.2.2:3142 (10.0.2.2). - connect (101: Network is unreachable)
[22:19] <smoser> hm.. yeah.
[22:19] <mwhudson> i am ... familiar ... with the hash sum mismatch problem
[23:53] <bdrung> Mirv, reported the requested bug: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1536843