[05:07] <pitti> Good morning
[05:08] <pitti> dobey: hey, how are you?
[05:09] <pitti> dobey: autopkgtest issues> you mean overriding regressions? which package(s)?
[08:02] <dholbach> good morning
[08:13] <zequence> cjwatson: Ah, of course. Thanks.
[08:55] <caribou> Is it possible to request a build in a PPA for another arch than i386 or amd64 ?
[08:56] <seb128> caribou, you need a special ppa for that
[08:56] <seb128> the standard virtualized ones only have the restricted set
[08:56] <caribou> seb128: special in what sense ?
[08:56] <Unit193> seb128: Not anymore, check the settings page of the PPA.
[08:57] <caribou> Unit193: great, thanks!
[08:58] <Unit193> Sure.
[08:58] <seb128> Unit193, I was unsure, thanks for correcting what I said ;-)
[08:58] <caribou> Unit193: well, ppc64-el is available but powerpc is not, I suppose that I need some specific access for that
[09:03] <Unit193> seb128: Heh, it's pretty new, but I don't remember from when exactly.  Still have yet to try it personally, don't have a technical need so no point wasting resources.
[09:07] <cjwatson> caribou: https://answers.launchpad.net/launchpad if you need anything other than amd64/i386/ppc64el
[09:08] <caribou> cjwatson: thanks!
[09:12] <happyaron> what's the mapping relationship from contrib (debian) to Ubuntu? is it universe or multiverse?
[09:14] <sladen> happyaron: it depends!
[09:15] <happyaron> well well
[09:15] <sladen> happyaron: https://help.ubuntu.com/community/Repositories/Ubuntu#What_are_Repositories.3F
[09:16] <sladen> happyaron: it's a 2x2 matrix.  Supported vs. Unsupported.  Libre vs. non-Libre
[09:16] <happyaron> I know that description, and my package is not going to be supported (at least as of now)
[09:16] <happyaron> it's in Debian contrib
[09:16] <sladen> happyaron: what is the package?
[09:17] <happyaron> sladen: zfs-linux
[09:17] <happyaron> :)
[09:18] <sladen> happyaron: sabdfl has been saying happy ZFS things in connection to Juju, so it might well become supported
[09:19] <happyaron> sladen: well I'm the maintainer
[09:20] <cjwatson> happyaron: multiverse by default
[09:20] <cjwatson> but overridable
[09:20] <happyaron> cjwatson: thanks, :)
[09:52] <doko> cjwatson, I saw you building a qemu. did you address the libseccomp issue already?
[09:53] <cjwatson> doko: in the PPA I built it in; not in the archive
[09:54] <cjwatson> doko: http://paste.ubuntu.com/13596021/ (the libtool bit was just for the backport)
[12:48] <seb128> pitti, do you know why we didn't get a xenial langpack yesterday? are those supposed to be weekly or bi-weekly?
[13:18] <pitti> seb128: because I'm getting old and forgot to enable the cronjob; done now, and running manually
[13:18] <seb128> pitti, danke (and you are not that old yet!)
[13:19] <pitti> seb128: so what do I blame it on then?
[13:19] <seb128> pitti, too much to do!
[13:19] <seb128> or maybe not enough stollen :-)
[13:19] <pitti> +1!
[13:28] <seb128> doko, do you plan to merge gettext? seems like something that would be nice to get early in the cycle rather than late, in case it creates build issues and such
[13:29] <doko> seb128, please take it, won't be this week
[13:29] <seb128> doko, ok
[13:54] <Mirv> ok Qt 5.5.1 is being published, hold on tight and if you see anything to be fixed to get it migrated in the upcoming 12 hours, feel free to fix
[13:55] <Mirv> it will take several hours before the autopkgtests are in shape for studying if something needs to be done
[14:00] <mterry> barry, btw, I uploaded a version of deja-dup that drops duplicity to a Suggests over the weekend
[14:01] <mterry> barry, so that should be one package off the image (though we really should port it at some future point)
[14:12] <pitti> mterry: does it have some session-installer integration? i. e. it installs duplicity when you want to use it?
[14:13] <mterry> pitti, yeah using packagekit before you can set up the first backup or restore
[14:13] <mterry> pitti, not ideal, but I didn't have time to port duplicity to py3 this cycle
[14:32] <seb128> barry, mterry, pitti: I'm unsure how those changes help though, we are doing tricks to pull python2 on the system for users after install rather than in front, it's sort of cheating and doesn't make us use less python2, just be less honest about it
[14:33] <kdub> how can I make a xenial schroot with mk-sbuild from wily?
[14:33] <mterry> seb128, but it does make us use less python2 -- not every Ubuntu install is a deja-dup desktop
[14:33] <pitti> yeah; the main difference is that people who don't use deja-dup won't have it installed, but it's still as supported as before
[14:33] <seb128> we could also have unseeded deja-dup
[14:33] <seb128> and tell users who want it to get it from software-center
[14:33] <seb128> that would have the same result, just less weird
[14:34] <mterry> seb128, that's another solution -- I'm fine with that -- less bugs :)  But I had assumed this was better
[14:34] <mterry> seb128, it's not exactly the same result
[14:34] <seb128> one advertize the feature a bit more
[14:34] <mterry> seb128, this way we are giving users more of a nudge to make backups
[14:34] <seb128> but it advertize a feature that is incomplete and prompt you to install things when you try to use it
[14:34] <seb128> which is somewhat not a great user experience
[14:34] <mterry> seb128, tell that to landscape :)
[14:34] <mterry> seb128, which isn't a good excuse to do it on deja-dup granted
[14:34] <seb128> mterry, we removed that icon in xenial ;-)
[14:35] <mterry> seb128, oh hah!  I didn't know
[14:35] <seb128> the landscape one
[14:35] <seb128> is that to keep a balance in the force?
[14:35] <seb128> remove one, add one :p
[14:36] <mterry> seb128, I personally don't see what's wrong with a feature that needs to hit the network to be fully ready.  But if you folks don't like it, I'm 100% on board with dropping deja-dup from the default image
[14:36] <seb128> mterry, I don't think it's wrong
[14:36] <seb128> I just think the "no more python2" is a lie
[14:36] <seb128> it's just "python2 on demand"
[14:36] <seb128> but, oh well
[14:36] <mterry> seb128, for some of our users  :)
[14:36] <mterry> seb128, I agree I'd rather port it to python3
[14:37] <mterry> seb128, but I don't really get work time for deja-dup anymore
[14:37] <seb128> right
[14:37] <seb128> it was not against you
[14:37] <mterry> seb128, at worst, what we are buying is image space -- which didrocks has great language plans for :)
[14:37] <seb128> oh well, I said what I hd to say on the topic
[14:37] <seb128> haha
[14:37] <seb128> right
[14:38] <seb128> let's see if we actually manage to drop python2 from the iso
[14:38] <mterry> seb128, if we don't..  we can always seed duplicity back in
[14:38] <seb128> :-)
[14:38] <didrocks> mterry: :p I'm still puzzled about the solution though, you will notice ;)
[14:38] <didrocks> mterry: but I hope you will be as indulgent as I were reviewing your branch for this proposal :)
[14:39] <mterry> didrocks, the language solution?
[14:39] <didrocks> mterry: the duplicity dropped to suggests
[14:39] <didrocks> mterry: what we discussed last week
[14:39] <didrocks> (basically, I share seb128's point of view, but understand the constraints of course)
[14:40] <mterry> didrocks, right -- again I'm sorta on your side, just not bothered as much.  The other two ways are porting duplicity or dropping deja-dup, both of which I'm happy to see happen, but can't do either
[14:40] <didrocks> mterry: yeah, no ideal solution (apart from the port… which… we already discussed and without upstream traction, will be really hard)
[14:41] <mterry> didrocks, or...  4th way: get a python2-compatibility mode added to upstream python3.  ;)  brilliant!
[14:42] <dobey> pitti: hey. how are you? i was confused about the excuses output, and my issue isn't with autopkgtests. so no need to do anything :)
[14:44] <didrocks> mterry: ahah, of course, we can do it, make a version free for FLOSS software only, and make billions!
[14:44] <didrocks> and then, using that money to port duplicity to py3
[14:45] <pitti> dobey: heh, good :)
[15:08] <rbasak> cpaelzer: looks like pitti beat you to the nis merge.
[15:08] <rbasak> I thought we checked with pitti first?
[15:08] <pitti> cpaelzer: oh, did you want to do it?
[15:08] <rbasak> pitti: we discovered an upgrade path issue, BTW.
[15:08] <pitti> MoM had it pinned on me
[15:08] <pitti> but please feel free to grab it -- I have zero attachment to nis
[15:08] <rbasak> pitti: previously the Ubuntu delta was accidentally shipping /etc/default/nis but not as a conffile.
[15:09] <rbasak> pitti: that causes it to get clobbered.
[15:09] <pitti> argh
[15:09] <pitti> the nis packaging is hilariously bad
[15:09] <pitti> every time I have to touch it I want to bite into my table
[15:09] <pitti> it's outright evil
[15:09] <rbasak> cpaelzer has a merge for me to review, but it's based on pre-Xenial.
, sorry
[15:10] <rbasak> pitti: and we drop the Upstart delta (which revealed the upgrade path issue)
[15:10] <rbasak> pitti: so I might ignore your uploads and review and upload cpaelzer's over it, if that's OK with you?
[15:10] <pitti> ah, you want to drop it because we don't care on the phone about nis, and other flavors are systemd?
[15:10] <pitti> rbasak: sure, go ahead
[15:10] <rbasak> Right. Thanks.
[15:10] <pitti> I'm glad I stop being TIL :)
[15:11] <rbasak> With this plan, IIRC, we need to fix the upgrade path in a delta in Xenial, but can drop the delta entirely in Xenial+1.
[15:11] <rbasak> Then we can all stop caring about it.
[15:11] <pitti> oh, good
[15:21] <cpaelzer> rbasak: just coming here - yes we checked with pitte before starting
[15:21] <barry> mterry: yes, thanks for that!  seb128 it does help because at least it will make our images smaller when we don't have to place two python stacks on them.  but yes, we should still be porting everything we can to python3
[15:22] <rbasak> cpaelzer: we'll ignore pitti's merge, since we went further to drop the delta saving ourselves from future work.
[15:22] <cpaelzer> pitti: it is totally satisfying that your table seems to look like mine due to nis packaging
[15:22]  * pitti spits out some splinters
[15:23] <rbasak> cpaelzer: "git diff logical/3.17-32ubuntu7 reconstruct/3.17-32ubuntu7" shows up a difference in ypbind-mt-1.20.1/src/Makefile.in that I'm not expecting. I'm looking into it.
[15:23] <cpaelzer> rbasak: IIRC that file was the FTBFS from dannf
[15:28] <rbasak> cpaelzer: dannf's change did make the Makefile.in delta unnecessary, but he didn't remove it.
[15:28] <rbasak> cpaelzer: so I'd expect logical/3.17-32ubuntu7 to still include it
[15:29] <rbasak> cpaelzer: because otherwise my check of "reconstruct should match logical except changelog and update-maintainer" fails.
[15:29] <cpaelzer> rbasak: that is still the stuff we made wrong together - but you are right that needs to be corrected to match the way we want to handle it
[15:30] <cpaelzer> I'm in hangout now - do you want me to upload a tree with that fixed somewhen the next few days?
[15:30] <rbasak> cpaelzer: yeah fair enough. I thought this might have come from our week together.
[15:30] <rbasak> cpaelzer: no, don't worry about it. It's not important for this merge. As long as we understand the process so we can avoid confusion next time, which I think we do.
[16:00] <bdmurray> mvo: Do you still plan on backporting the fix for bug 1267059? Could it be an SRU?
[16:01] <caribou> what's the best way to merge packages : bzr merge, grab-merge, other ?
[16:01] <caribou> rbasak: I know you use git, got your blog post
[16:02] <rbasak> caribou: I happily use grab-merge for very trivial merges that it doesn't break on.
[16:02] <seb128> bdmurray, hey, could you get the glib wily SRU out of the queue? it fixes an important nautilus segfault and has been stucked in the queue since earlier novembre
[16:02] <rbasak> The moment they get complex I fall back to git though.
[16:04] <bdmurray> seb128: there are 2 in the queue - should I look at the latest one?
[16:04] <caribou> rbasak: thanks
[16:04] <seb128> bdmurray, I guess so, apparently the previous one had a changelog issue or something that you pointed out to Laney?
[16:05] <bdmurray> seb128: oh right, no LaunchpadBugsFixed
[16:05] <bdmurray> seb128: okay, I'll look at it shortly
[16:05] <seb128> bdmurray, thanks
[16:09] <Laney> I did ping when I reuploaded it
[16:17] <seb128> Laney, yeah, but it's still waiting so I pinged again, there are some unhappy users with the nautilus segfaults
[16:17] <Laney> I know, thanks for doing that
[16:17] <Laney> just saying that I tried at the time :P
[16:19]  * didrocks just looked at plymouth last merge and cries
[16:24] <seb128> didrocks, :-(
[16:24] <didrocks> yeah, wasn't merge in 3 years despite multiple upstream releases in both ubuntu and debian :p
[16:35] <caribou> in the previous rsyslog pkg, we distributed the default rules in /etc/rsyslog.d/50-default.conf
[16:36] <caribou> in the newest debian package, most of these are now in /etc/rsyslog.conf : should we keep the delta as it is or adapt upstream's rsyslog to our use ?
[16:42] <seb128> bdmurray, thanks!
[16:44] <bdmurray> seb128: no problem
[16:46] <infinity> cjwatson: Did you do the last subversion merge because you actually wanted TIL, or was it a frustration thing blocking some other transition you were doing? :P
[17:58] <TJ-> With Apache2 are there plans to add libapache2-mod-http2 (HTTP/2) for 16.04 (./configure needs "--enable-http2" )?
[17:59] <jrwren> TJ-: I don't know, but I do know it is in upstream debian and its available via PPA
[17:59] <jrwren> 2.4.17
[17:59] <jrwren> TJ-: that wasn't added until 2.4.17 and wily shipped with a version less than 2.4.17
[17:59] <TJ-> I'm on about for 16.04 XX, currently has the Debian 2.4.17 but HTTP/2 isn't built
[18:00] <jrwren> TJ-: oh really? that is a bummer.
[18:00] <TJ-> yeah, I'm concerned it doesn't slip through the net for the LTS release
[18:01] <TJ-> But there could be a reason why it isn't enabled at this point, but there may be plans to enable it later in the cycle
[18:03] <mdeslaur> TJ-, jrwren: AFAIK, it's still considered "experimental", not something we want to support for an LTS release
[18:03]  * juliank thought the others above talked about an old kernel 2.4.17
[18:05] <TJ-> mdeslaur: I'd have thought with the extended period over which 16.04 is going to be available, with sites moving to use HTTP/2, it's one of the things we would want
[18:05] <mdeslaur> TJ-: yes, once it works properly
[18:08] <mdeslaur> feel free to bug the server team about it
[18:08] <TJ-> what's the definition of "works properly" for this?
[18:09] <mdeslaur> once the module isn't marked as experimental and the options get formalized to that upgrades won't break users?
[18:10] <mdeslaur> and once libhttp2 goes through the MIR process
[18:10] <TJ-> so in all likelyhood HTTP/2 for apache2 will only get into 16.04 via backports then, assuming upstream take their time on the module?
[18:11] <mdeslaur> no, I'd say it's something that would be appropriate to update and turn back on in an SRU once upstream declares it production ready
[18:13] <mdeslaur> but, ultimately it's the server team's decision if they want to turn it on and support it as-is
[18:15] <mdeslaur> TJ-: file a bug and ask about it in #ubuntu-server perhaps?
[18:17] <TJ-> will do. I'm not particularly worried about it but was just developing an upgrade plan and realised it wasn't available in the archive, and as we already have the nginx HTTP/2 support it seeme strange it wasn't in XX
[18:30] <cjwatson> infinity: It was one of the relatively easy ones on my list that didn't take too long; I originally ended up with TIL due to a Perl transition.  I have no problem with you stealing it though.
[18:55] <infinity> cjwatson: I don't *want* to steal it, but it's currently FTBFS until a merge, so someone has to.  I suppose it'll be me. :P
[21:37] <ben___> What is the proper way to handle dh_auto_clean on an unconfigured repo? http://paste.debian.net/340388/
[23:22] <fshp> Hi. I will fix bug in unity-settings-daemon. But I'm confused. Associated with the media keys. Can anyone help with advice?
[23:28] <Logan> cyphermox: are you planning on merging pytsk?
[23:33] <Logan> ben___: maybe do something like http://paste.ubuntu.com/13608786/