[00:45] <ahoneybun> LocutusOfBorg: could we get a LP request on this: https://launchpadlibrarian.net/276000721/trojita_0.7.0+git20160728-0ubuntu1~ubuntu16.04~ppa1.dsc
[00:46] <ahoneybun> tsimonq2 of Lubuntu might want it as well
[01:58] <jbicha> ahoneybun: I think it would be best if you filed a needs-packaging bug for that since it's not in Debian or Ubuntu
[01:58] <ahoneybun> it's packaged
[01:58] <ahoneybun> it's in that ppa
[01:58] <jbicha> right, but it needs to go through the new queue
[02:01] <jbicha> and it's often faster to get it in Ubuntu if you can find someone (like the Debian Qt team) to sponsor it into Debian first
[02:11] <ahoneybun> this sponsor thing is hold hundreds of uploads we have
[02:12] <ahoneybun> *holding
[02:21] <jbicha> if your packages were in sync with Debian, then a lot of the work would get done through autosync
[02:21] <jbicha> I've considered syncing qt/kde stuff but then I see that you're trying to maintain the packages in git which I don't have write access to
[02:22] <jbicha> but many times there aren't any real differences in the Kubuntu packages
[02:22] <ahoneybun> jbicha: we have to get sponsored to upload new versions to the archive
[02:22] <ahoneybun> for this there are
[02:23] <ahoneybun> we need to upload them to get Plasma 5.7.2 out
[02:23] <ahoneybun> Qt 5.6.1 is needed for 5.7
[02:23] <ahoneybun> Plasma
[02:23] <ahoneybun> we need a MOTU to come into #kubuntu-devel
[02:23] <ahoneybun> we have no one to upload atm
[03:17] <tsimonq2> ahoneybun: how so?
[03:17] <ahoneybun> the trojita email client
[03:17]  * tsimonq2 checks if it's in the LXQt metapackage
[03:21] <tsimonq2> ahoneybun: that's our plan in the blueprints but the blueprint is marked as blocked and it's not in the metapackage, I'll ask Julien, but otherwise \o/
[03:22] <ahoneybun> tsimonq2: clive has it built for xenial and yakkety in his ppa
[03:37] <tsimonq2> ahoneybun: great :)
[03:37] <tsimonq2> ahoneybun: is it not in the Ubuntu archive? :O
[03:37] <ahoneybun> nope guess not
[05:17] <Mirv> pitti: morning. could I get all-proposed for https://requests.ci-train.ubuntu.com/static/britney/ticket-1712/landing-070-yakkety/excuses.html and https://requests.ci-train.ubuntu.com/static/britney/ticket-1715/landing-080-yakkety/excuses.html , and restart of seemingly stuck "Test in progress" tests at https://requests.ci-train.ubuntu.com/static/britney/ticket-1715/landing-080-xenial/excuses.html ?
[05:30] <cpaelzer> good morning
[05:35] <Mirv> @pilot in
[05:50] <pitti> Good morning
[05:50] <tsimonq2> o/ pitti, how are you? :)
[05:50] <pitti> I'm great, thanks! last two days before summer vacation :)
[05:52] <tsimonq2> pitti: less than a month until the end of summer vacation and my first day of high school
[05:52] <tsimonq2> :D
[05:54] <pitti> that's still lots of of time to do stuff!
[05:54] <tsimonq2> it is! :)
[05:57] <pitti> Mirv: done
[05:59] <pitti> Mirv: btw, when that happens while I'm away, please ask L_aney, i_nfinity, s_eb128, d_idrocks, or s_langasek to run something like "retry-autopkgtest-regressions -s yakkety --ci-train-silo 080 --ci-train-ticket 1715 --all-proposed" on snakefruit
[05:59] <pitti> or --state RUNNING
[06:02] <tsimonq2> pitti: you acutally pinged Steve, he gets pinged on his last name too I think :P
[06:03] <pitti> well, I tried to be quiet :)
[06:03] <tsimonq2> :)
[06:15] <Mirv> pitti: noted and much appreciated!
[06:35] <Mirv> tedg: hi! could you take care of the click upload asked for in bug #1496292 so that we could unblock many things in yakkety? tsimonq2 / LXQt folks would appreciate among else :)
[06:37] <tsimonq2> yeah, lubutnu-qt-desktop can't be installed without it
[06:42] <acheronuk> nor can plasma-discover
[06:42] <tsimonq2> so the Kubuntu folks might appreciate it too :)
[08:07] <cpaelzer> ntp has issues exporting their code history https://github.com/ntp-project/ntp/issues/15
[08:07] <cpaelzer> via its archive I can only get full releases, where patches are obviously mangled together
[08:07] <cpaelzer> the next "best" (not) option is to check their bitkeeper
[08:08] <cpaelzer> but for obvious reasons I have none, and I even fail to get one setup for my personal account if I would
[08:08] <cpaelzer> so if one still has a dusty but working bk setup please ping me as I'm trying to get a fix referred from a ntp bug for an SUR
[08:20] <Unit193> Can't just look http://bk1.ntp.org/ntp-stable/?DATE=-6M..&PAGE=changes ?
[08:23] <cpaelzer> That will do, thanks Unit193
[08:24] <cpaelzer> I was looking for alternatives already - that is one that works - Thanks!
[09:15] <LocutusOfBorg> do anybody have any update about qt5 migration?
[09:21] <cpaelzer> mdeslaur: I come by ntp for a functional SRU anyway atm - there are quite a few CVEs reported - I wanted to discuss if I should include some in your opinion
[09:22] <cpaelzer> mdeslaur: sorry to bother you but according to the changelog you were the last to add CVE fixes to the package
[09:25] <cpaelzer> mdeslaur: looking at http://support.ntp.org/bin/view/Main/SecurityNotice#Recent_Vulnerabilities CVE-2016-4957 is high, CVE-2015-5300 is only medium but seems very easy to backport
[09:25] <cpaelzer> mdeslaur: there are several more at medium, but well that is why I ask you or other security Team members to let me know
[09:28] <LocutusOfBorg> I think #ubuntu-hardened is the best place to discuss ntp CVEs :)
[09:29] <cpaelzer> will do so on top, thanks LocutusOfBorg
[09:29] <LocutusOfBorg> probably all security Ubuntu folks follow here too, but hardened is better because of low messages numbers
[09:32] <cpaelzer> yeah I agree, I can leave the message "out there" as long as I test my SRU
[10:03] <cpaelzer> pitti: filed the nplan bugs and notified a few IBMers that I really want to pass that spec (it is more their than my job after all) :-)
[10:03] <cpaelzer> pitti: thanks for the feedback
[10:57] <andyrock> seb128: https://code.launchpad.net/~azzar1/nautilus/higidpi-desktop-view-margins/+merge/301621
[10:57] <andyrock> i also proposed a fix upstream
[11:13] <LocutusOfBorg> pitti, hi, do you have two seconds to look at runit package?
[11:13] <LocutusOfBorg> should we drop the upstart integration?
[11:14] <LocutusOfBorg> to merge the current debian package I should have to create a new runit-upstart package, and maybe it is time to stop that?
[11:14] <Laney> andyrock: I can push those upstream if you want
[11:18] <Son_Goku> what problem does netplan solve that wicked doesn't already solve?
[11:19] <Son_Goku> https://github.com/openSUSE/wicked
[11:25] <Odd_Bloke> Son_Goku: My understand of netplan is that it's declarative config that's used to configure existing networking things; I wouldn't expect there to be a daemon running.
[11:25] <Odd_Bloke> Son_Goku: But I don't know a great deal about netplan. :)
[11:26] <Son_Goku> wicked works pretty similarly to netplan in that it essentially obsoletes old style configuration
[11:26] <Son_Goku> but wicked's configuration can be validated, since it's XML
[11:27] <Son_Goku> but critically, because configuration is offered via D-Bus, you can have an arbitrary input mechanism for it
[11:28] <Son_Goku> the daemon is completely optional
[11:30] <Son_Goku> alternatively, NetworkManager itself is an alternative mechanism to old-style networking
[11:31] <Son_Goku> though I wonder if the reason this is such a problem is because Debian-based distributions' /etc/network/interfaces isn't well-supported in NM
[11:32] <Son_Goku> NetworkManager can read /etc/sysconfig/network-scripts/ifcfg-* files (which are INI style declarative files) or its own keyfile format
[11:32] <Son_Goku> in Fedora, for example, NetworkManager is preconfigured through ifcfg scripts
[11:33] <Son_Goku> err, ifcfg-* files
[11:34] <Son_Goku> I guess my question is, what problem is netplan trying to solve?
[11:34] <Son_Goku> that no other solution hasn't already done
[11:38] <xnox> pitti, see Son_Goku ^ above to discuss netplan vs wicked
[11:40] <Son_Goku> maybe I'm just used to how things work in Fedora and Mageia, but it seems weird that centralized configuration is a problem
[11:41] <Son_Goku> admittedly, in Fedora, we use NetworkManager everywhere (even on Server) since recent versions of NetworkManager have become quite lightweight
[11:42] <Son_Goku> and it supports a large variety of use cases
[11:43] <Son_Goku> the SUSE guys opted to create wicked to solve their problems, and I think that partially has to do with YaST
[11:44] <xnox> i think many years ago we did try wicked and connman for the netbook remix project, but that was literarly years ago.
[11:44] <xnox> on ubuntu side we have our own legacies to deal with =) there is ifupdown, there is networkd, there is networkmanager, and debian is trying for ifupdown2 (non starter for us, as it's in python), and then there is a lot of cloud/container configs.
[11:46] <Son_Goku> xnox, I think you're thinking of wicd
[11:46] <Son_Goku> which I do recall you using for Ubuntu Netbook
[11:46] <xnox> Son_Goku, probably.
[11:46] <xnox> never mind then =)
[11:46] <xnox> in general i think we want to go with networkd in most cases, but it's config is crap. And whenever one wants WiFi or 3G/LTE or even hotplug usb one is better off with networkmanager.
[11:46] <Son_Goku> I'm surprised no one wrote a networkd config backend for NM yet
[11:46] <Son_Goku> that would allow you to seamlessly use both
[11:47] <xnox> and then there is a bunch of mid-higher level things to expose too, w.r.t. system containers networking (e.g. lxd / openvz size) and nested networking (juju namespaces)
[11:47] <Son_Goku> right
[11:47] <Son_Goku> the latest NetworkManager releases have been focused on dealing with those problems specifically
[11:48] <Son_Goku> hell, with NM 1.2, I was able to migrate to using NetworkManager to maintain my container networking
[11:48] <xnox> but networkmanager is well, crap =) -> not official stance, but just my personal opinion. But it is the best we have for Wifi & 3G/LTE.
[11:48] <Son_Goku> what's wrong with NM?
[11:50] <Son_Goku> I know people have bitched about NetworkManager in the past, but the latest releases have been pretty solid
[11:56] <xnox> dhcp / dns, i've been on weird networks where it did not do the right thing, and one ends up shooting oneself in the foot. I'm sure if i used nmcli and/or dbus api to the spawned dhcp daemon I would know what to do. Also it is quite a bit heavy, I had partially booting systems where nm wouldn't start leaving me without network.
[11:56] <xnox> these days I find iproute2 an excellent network configuration manager =)))))
[11:57] <xnox> with iproute2 i could finally start to comprehend a little bit as to what is going on =)
[11:57] <xnox> but i am just a basic user. not a sysadmin at all.
[11:58] <infinity> Son_Goku: Personally, any time anyone tells me that a config file in XML is a *good* thing, I run away.  And that's coming from someone who finds ISC config files readable.
[11:58] <Son_Goku> I didn't say it's good for humans
[11:58] <Son_Goku> and even I don't manipulate the XML by hand myself
[11:59] <infinity> Then you'd immediately stop the conversation for most old Debian hacks.
[11:59] <infinity> "run a thing to spit out a config" isn't our style. :P
[11:59] <infinity> (Same reason people like me also hate virt-manager)
[11:59] <xnox> i have seen libxml segfault in a stable release =)
[11:59] <seb128> Laney, if you want to handle nautilus please do
[12:00] <infinity> Son_Goku: Anyhow, the real answer to your question is that nplan probably doesn't solve a problem that hasn't been solved, it just solves it differently.  Yay, diversity.
[12:00] <infinity> And my experiences with networking on Fedora/RH have never been pleasant on complex setups...
[12:01] <Son_Goku> oddly enough, I've had the opposite experience
[12:01] <infinity> That's how anecdotes go. ;)
[12:01] <Son_Goku> complex networking using the ifcfg* files has been considerably easier than network/interfaces :)
[12:01] <infinity> ifcfg looks easier on the surface, but it seems amazingly racey or something, cause I have machines that seem to want to only have a network on 2/3 boots, etc.
[12:02] <infinity> But that's backend implentation, of course, not the syntax's fault.
[12:02] <infinity> As for syntax, meh.  We happen to have a man at the helm who loves yaml.
[12:03] <infinity> Which I'm sure you noticed at the snappy sprint. :P
[12:03] <Son_Goku> yeah, I did :)
[12:06] <infinity> Son_Goku: I'm somewhat biased, because I happened to be part of the hallway conversation that became the spec for nplan, but I do like the concept of "this only handles config, and hands off to backends", since placing all your eggs in a networkd or networkmanager basket is just asking for more work down the road to make $daemon support your use-case.
[12:07] <Son_Goku> yeah
[12:07] <Son_Goku> well, that's part of the reason why I like the ifcfg-* scripts
[12:07] <Son_Goku> err files
[12:07] <Son_Goku> because they are supported by multiple network management tools
[12:08] <infinity> Yup, but the odds of them ever showing up in a Debian derivative are slim.
[12:08] <infinity> If pitti can sell Debian on nplan, then we're back to a "half the world does it this way, and the other half another way" thing, and that's not awful.
[12:08] <Son_Goku> doesn't take much for them to show up
[12:08] <infinity> (Oddly, that's one of the reasons I wished Debian would have gone with upstart, just to keep competition alive and upstreams on their toes :P)
[12:09] <infinity> But Debian developers seems blissfully unaware that they (or their derivatives) run on more than half the Linux machines in the world and they have a lot more power than they think.
[12:09] <infinity> Son_Goku: By "show up", I meant in the default install, of course.  Debian ships all sorts of options, because that's the sort of place they are.
[12:10] <Son_Goku> well, at least in NetworkManager, it's a configure argument away to support the ifcfg-* files
[12:10] <infinity> I guess I have to amend that "more than half the Linux machines" with "(not counting Android)" these days.
[12:10] <Son_Goku> as NM itself supports multiple config backends
[12:11] <Son_Goku> I don't really see a reason why configuration needs to be done differently everywhere :/
[12:11] <infinity> Oddly, Android may have finally given us all a reason to call classic distros "GNU/Linux" and RMS wins.
[12:11] <Son_Goku> especially for something as critical as networking
[12:11] <infinity> If we assume the "GNU" means glibc. :P
[12:12] <infinity> Son_Goku: I never saw why it needed to be different everywhere either, but I could never talk RedHat into the beauty of interfaces(5).
[12:13] <infinity> Son_Goku: And, at the end of the day, that's the attitude we have to contend with that leads to NIH in distros (and it's sometimes a good thing, sometimes not).  Broadly, the RHish and Debianish camps have their own ways to do lots of things, and when someone says "we should all do it the same way", they're really saying "we should all do it the way I prefer".
[12:13] <infinity> Son_Goku: Which doesn't sell well.
[12:13] <infinity> Son_Goku: It's the duck army and the bunny army.
[12:13]  * Son_Goku shrugs
[12:14] <infinity> http://i.imgur.com/GBxqls0.png
[12:20] <Son_Goku> infinity, I gave up quite a long time ago on persuading people on things like this
[12:21] <Son_Goku> nowadays, I just ask about it, present technical counterpoints, and hope for the best
[12:21]  * infinity nods.
[12:23] <infinity> Mostly, I just sit here and grumble about having to learn a new thing after 15+ years, but hopefully I'll survive the turmoil.
[12:24] <Son_Goku> haha
[12:33] <xnox> infinity, https://lh5.googleusercontent.com/-MV7R08WGNZY/UTIAf39b-3I/AAAAAAAANJo/uLxr73--TRA/w497-h373/gb.gif -> duck/bunny armies playing ingress
[12:34] <xnox> Son_Goku, infinity: it does sound like we are still in this situation https://xkcd.com/927/
[12:34] <xnox> caption needs updating with usb-C and thunderbolt
[12:48] <xnox> infinity, sbuild regular resolver fails to resolve libicu-dev (> 57) when building with experimental enabled (as created with $ mk-sbuild experimental) --build-dep-resolver=aptitude "fixes" this and correctly pulls in libicu from experimental. I recall you have previously said that one doesn't really need aptitude resolver, is there a way to selectively pull build-deps from experimental, when needed, with sbuild using apt resolver? or do i need to
[12:48] <xnox> fiddle with pinning?
[12:50]  * xnox believes mk-sbuild should have done the right thing for experimental distro to work with apt resolver
[12:51] <infinity> xnox: You'd need to pin experimental to 500, but then it won't be selective.
[12:52] <xnox> In http://aerostitch.github.io/linux_and_unix/debian/sbuild_with_experimental_distribution.html
[12:52] <infinity> xnox: ie: this is what our buildds do for backports:
[12:52] <infinity> $ cat etc/apt/preferences.d/backports
[12:52] <infinity> Package: *
[12:52] <infinity> Pin: release a=*-backports
[12:52] <infinity> Pin-Priority: 500
[12:52] <xnox> it is pinned: 900 -> unstable; 800 -> experimental. I wonder if it makes the build-deps selective or not.
[12:52]  * xnox ponders if i want selective experimental, or all-in-one / all-you-can eat deal
[12:53] <xnox> right.
[12:53] <Mirv> pitti: is it that if I rerun https://requests.ci-train.ubuntu.com/static/britney/ticket-1712/landing-070-yakkety/excuses.html it's again without proposed? could you rerun them all again with proposed? earlier today there was some gtk related breakage in proposed.
[12:53] <pitti> Mirv: oh, is that gtk3 uninstallability fixed now?
[12:54] <Mirv> pitti: yes it'd look like that to me, Laney's upload fixed it. among else my https://launchpad.net/ubuntu/+source/uim/1:1.8.6+gh20160630.0.c408e95-1build1 now built.
[12:54] <pitti> Mirv: yes, the retry links don't use all-proposed
[12:55] <pitti> Mirv: retried
[12:55] <Mirv> ok thank you again
[12:55] <pitti> no problem; /me retries the apport build as well
[12:56] <LocutusOfBorg> something is broken in yakkety, but I can't figure out what
[12:56] <LocutusOfBorg> dh: error: 'hardening' flag found but 'hardening-wrapper' not installed: No such file or directory
[12:56] <LocutusOfBorg> isn't picked up by debhelper?
[13:02] <infinity> LocutusOfBorg: That's from dpkg, actually.  And not exactly new.
[13:03] <infinity> Potentially code we should rip out at some point, though.
[13:03] <LocutusOfBorg> but is a bug in dpkg or not?
[13:03] <infinity> LocutusOfBorg: It might be a bug, it's not new in yakkety.
[13:04] <infinity> It comes from when we supported hardening options and Debian didn't.  I should tear that all out, I think.
[13:04] <infinity> Right after 14.04.5 flies.
[13:04] <infinity> Or maybe while.
[13:06] <LocutusOfBorg> BTW anybody will merge dpkg?
[13:06] <LocutusOfBorg> I can provide a debdiff if I have somebody looking at it :)
[13:07] <infinity> LocutusOfBorg: I merge it.
[13:08] <LocutusOfBorg> <3
[13:08] <Mirv> I hope mterry won't mind me ending his 5-day patch pilot
[13:08] <infinity> LocutusOfBorg: I prefer to let it cook in Debian, unless there's a killer feature we need.
[13:45] <Mirv> @pilot out
[13:53]  * dholbach hugs Mirv 
[13:56] <mhall119> Mirv: ping
[13:56] <Mirv> mhall119: eodish pong
[13:57]  * Mirv hugs the pilot hugger
[13:57] <mhall119> Mirv: tomorrow then, or when you have time, can you provide some help to #kubuntu-devel in getting packages udpated/added to the archives for 16.10?
[13:57] <mhall119> they've been really struggling since the Ubuntu Developers on that team left
[13:58] <Mirv> mhall119: I've uploaded around 120 packages from them, I think they're mostly happy and I'm waiting mostly for them to assess the autopkgtest situation so that they can advice release team..
[13:58] <Mirv> mhall119: the whole KDE Frameworks 5.24 and Plasma 5.7 is in yakkety-proposed now
[13:58] <mhall119> Mirv: ah, thank you so much, I hasn't skimmed the scrollback
[14:00] <Mirv> no problem
[15:01] <rbasak> !dmb-ping
[15:01] <sil2100> o/
[15:13]  * Snow-Man wonders where he can buy CDs of those Dave Matthews Band cover band from.
[15:13] <Snow-Man> s/those/this/
[15:21] <otto> When will the dmb meeting begin?
[15:22] <rbasak> otto: it's in #ubuntu-meeting. It's already going. We went past you in the agenda, but we can go round again for you if you can join now please?
[15:41] <Saviq> pitti, hey, can you please restart all of unity8 tests in https://requests.ci-train.ubuntu.com/static/britney/ticket-1575/landing-073-yakkety/excuses.html with all-proposed, Qt's not migrated still
[16:07] <pitti> Saviq: done
[16:11] <Saviq> pitti, thank you
[17:47] <seb128> cjwatson, hey, unsure if you are still around but I tried to build a snap on launchpad (https://code.launchpad.net/~ubuntu-desktop/+snap/ghex-udt/+build/2261) and the build is failing on "git.gnome.org: Name or service not known", am I doing something wrong?
[17:54] <dobey> is building snaps allowed to access the internet?
[18:02] <dannf> jgrimm: i can test that it doesn't crash on arm64, but not sure if that's sufficient to call it "verified". i'll test & leave a comment though.
[18:18] <kyrofa> dobey, indeed, but only on snapcraft's pull step
[18:18] <kyrofa> seb128, could that be the issue?
[18:19] <seb128> kyrofa, dunno, my snapcraft.yaml is normal I think?
[18:19] <seb128> http://bazaar.launchpad.net/~ubuntu-desktop/+junk/ghexudt/view/head:/snapcraft.yaml
[18:19] <seb128> kyrofa,
[18:19] <seb128>   ghex:
[18:19] <seb128>     plugin: autotools
[18:19] <seb128>     source: git://git.gnome.org/ghex
[18:20] <kyrofa> seb128, ah, I wonder if the proxy isn't letting git:// through
[18:21] <kyrofa> seb128, indeed, the yaml looks fine. But that doesn't mean the build system isn't doing something like that (e.g. mysql will download boost when building)
[18:21] <kyrofa> seb128, but no, the log looks good
[18:22] <kyrofa> seb128, does git.gnome.org support cloning over http, perhaps? Might try that
[19:24] <seb128> kyrofa, yeah, I'm going to try that, thanks for the suggestion
[19:24] <kyrofa> Sure thing
[21:50] <jgrimm> thanks dannf