[00:01] <pavlix> xnox: So what are your main interests?
[00:02] <xnox> pavlix, volleyball and skiing =)
[00:02]  * xnox giggles
[00:04] <xnox> pavlix, been around since about 2012. DD, Ubuntu Core Developer, ex SPI director. Mostly code in C and Python. Did a bit of upstart, a bit of systemd, currently doing a bit of s390x.
[00:06] <pavlix> xnox: That sounds nice. I joined Red Hat in May 2012 as a core NetworkManager developer at that time but later worked with the packagers of various network services and recently left to go back freelance.
[00:07] <xnox> pavlix, fun!
[09:31] <sunweaver> LocutusOfBorg: what do you need to know about Ayatana Indicators?
[09:35] <JackFrost> sunweaver: Problem for remmina was that remmina is in main and ayatana indicators aren't.
[09:42] <sunweaver> ouch.
[09:42] <sunweaver> why is remmina main?
[09:42] <sunweaver> it would require a ubuntu series file then I guess that reverts the upstream patch in remmina.
[09:43] <ginggs> flexiondotorg: would you add Conflicts: telegram-desktop to your telegram PPA packages please?  It would prevent future bugs like LP: #1740708
[09:44] <JackFrost> sunweaver: https://ubuntudiff.debian.net/q/package/remmina just have to flip deps really.
[10:03] <sunweaver> we could do a libappindicator3-dev (>= <ubuntu-version) | libayatana-appindicator3-dev in the Debian package, so that patch would be unnecessary.
[10:03] <sunweaver> I am in touch with remmina upstream, so I could ask to get the translations.patch upstreamed, too.
[10:07] <sunweaver> JackFrost: I just pinged mfv from Debian on this who maintains remmina in Debian and lives "next door" to upstream of remmina.
[10:08] <JackFrost> Ooooh, fancy.
[10:08] <JackFrost> Thanks, sunweaver.
[10:08] <sunweaver> we hang out on #debian-remote (OFTC)
[10:08]  * sunweaver loves shrinking the ubuntudiff website...
[10:11] <JackFrost> sunweaver: Indeed, though in the past I didn't want to push any indicator stuff on to Debian.
[10:13] <sunweaver> that's why I started a fork....
[10:14] <sunweaver> because Inidicators from Launchpad do not work on non-Ubuntu systems.
[10:14] <JackFrost> sunweaver: I'm Unit193, btw..
[10:15] <sunweaver> this man(?) is confusing me...
[11:47] <bdrung_work> mvo, hi. can you merge initramfs-tools from Debian unstable to bionic (you are the last uploader) or should i do it?
[11:49] <bdrung_work> apw, ^
[11:50] <mvo> bdrung_work: you are welcome to merge it, my contribution was mostly a drive-by fix
[12:00]  * apw is happy for anyone to merge it indeed
[12:26] <rbasak> slangasek: ahasenack pointed out to me that the Breaks in Xenial seems to be holding back distro-info-data. I had noticed that but ignored it previously.
[12:26] <rbasak> slangasek: I think it's because the Breaks in distro-info-data for Xenial is wrong.
[12:26] <rbasak> Because on Xenial, juju-core is a 1.x series transitional package.
[12:27] <rbasak> So those of us who upgraded into Xenial with juju 1.x previously installed have a blocked distro-info-data package.
[12:29] <ahasenack> https://pastebin.ubuntu.com/26325364/ ^
[14:27] <bdrung_work> apw, done
[14:27] <bdrung_work> ubuntu carries a huge amount of change. many of them should be upstreamed.
[14:35] <apw> bdrung_work, yes, yes it should
[16:51] <slangasek> rbasak: it certainly appears that distro-info-data's Breaks don't have a version of juju-core in xenial that satisfies them, so something needs fixed...
[16:53] <slangasek> rbasak: so distro-info-data probably needs to Breaks: juju-2.0 (<< 2.2.6) instead?
[16:53] <rbasak> slangasek: that sounds about right. But only in Xenial.
[16:54] <rbasak> Unless future series have the same arrangement in Juju?
[16:54] <rbasak> Otherwise that'll be painful for future distro-info-data imports :-(
[16:54] <slangasek> rbasak: it only matters for xenial
[16:55] <slangasek> rbasak: well, it mattered also for zesty, but EOL
[16:56] <rbasak> slangasek: OK. I'm not really familiar with the details. Just passing on the report :)
[17:10] <slangasek> rbasak: distro-info-data reuploaded, if you want to review
[17:31] <rbasak> slangasek: diff looks empty apart from changelog?
[17:32] <slangasek> rbasak: but is it a good changelog? ;)
[17:32] <slangasek> looking
[17:36] <slangasek> rbasak: rejected/reuploaded, thanks
[17:47] <rbasak> slangasek: looks good, but do you know any reason for distro-info-data 0.28ubuntu0.3 to be in the security pocket?
[17:48] <slangasek> rbasak: not offhand
[17:49] <rbasak> Seems like some distro-info-data updates were deliberately being put in there.
[17:49] <rbasak> So now I don't know whether it's correct for this fix to go in there, or all fixes to distro-info-data should go into the security pocket :-(
[17:58] <mdeslaur> rbasak: if you're sruing it, just get someone to pocket-copy it to -security after
[17:58] <rbasak> mdeslaur: ah, OK. I was under the impression that a pocket copy in that direction wasn't always safe.
[17:58] <rbasak> (though seems unlikely to be an issue for distro-info-data)
[17:58] <mdeslaur> it isn't, but this package only has data in it
[17:59] <rbasak> I'm happy with your ack then. Thanks :)
[18:02] <mdeslaur> rbasak: oh, was that a regression only in post 0.3?
[18:02] <mdeslaur> sorry, I lack a bit of context
[18:03] <rbasak> I'll need to check the versions.
[18:03] <mdeslaur> you need to make sure you don't break juju-core users that don't have -updates enabled
[18:03] <rbasak> A distro-info-data update caused a regression in Juju which was parsing the data wrong.
[18:03] <rbasak> We have a Breaks: for it now.
[18:04] <mdeslaur> is the breaks on a version that is in -security?
[18:04] <rbasak> And juju is fixed now.
[18:04] <rbasak> Looking
[18:05] <rbasak> The version of distro-info-data in xenial-security won't break any version of Juju.
[18:05] <mdeslaur> right, so if you push the new distro-info-data to -security, environments that have -updates disabled will break, no?
[18:05] <mdeslaur> because the new juju won't be available
[18:05] <rbasak> But if we did pocket copy the version of distro-info-data I just accepted into xenial-proposed to xenial-security, then the version of src:juju-core in xenial-security won't work with it.
[18:06] <rbasak> Right
[18:06] <rbasak> So better not do that.
[18:06] <mdeslaur> right
[20:48] <tsimonq2> doko: Looking at GCC 8 failures, fixing Debian bug 885128 should fix a few failing Qt packages, and qtlocation is interesting because it could (not sure) be a GCC segfault. Otherwise the rest of the Qt failures should be fixed upstream...
[20:48] <tsimonq2> All I have for now :)