[05:37] <stgraber> xnox: FYI bug 1788314
[09:02] <seb128> tsimonq2, hey, did you notice that your apport upload to cosmic is screwed? you removed some systemd units from the debian dir and the diff includes .bzrignore .bzr-builddeb  and .git noise
[10:04] <sunweaver> ricotz: could you take a look at Debian bugs #836288 and #897694 and give some direction for a solution? (it is about plank upstream)
[10:05] <sunweaver> my sense is that dbus-x11 is not the correct approach these days, but going the dbus-run-session route.
[10:05] <sunweaver> could you work on a patch?
[10:05] <sunweaver> oh well, maybe dbus-x11 is needed to solve #897694...
[10:05] <sunweaver> thanks for any feedback given...
[10:12] <ricotz> sunweaver, hi, yes, switching to dbus-run-session is reasonable, as the bug reports describes this should be pretty straightforward to do
[10:12] <sunweaver> ricotz: what is the state of plank btw. any new upstream release coming before the end of the year? (Debian freeze)
[10:13] <ricotz> sunweaver, yes, I should do one soon
[10:14] <sunweaver> ok. Can you add the dbus-run-session support then with it?
[10:14] <ricotz> yes
[10:14] <sunweaver> ok, thanks. Removing that item from my list then.
[10:14] <sunweaver> Thanks!
[10:15] <xnox> stgraber, ouch!
[10:15]  * sunweaver is currently doing bulk uploads to get the Vcs-*: fields correct for all my packages.
[10:15] <ricotz> sunweaver, this might be interesting too https://launchpad.net/%7Ericotz/+archive/ubuntu/cosmic-vala-42/+packages?start=0&memo=0&batch=200
[10:16] <ricotz> sunweaver, if it contains a package which you are working on
[10:18] <sunweaver> ricotz: arctica-greeter -> ouch.
[10:19] <ricotz> those failures are mostly easy to fix
[10:19] <sunweaver> ricotz: libdbusmenu -> ouch
[10:19] <sunweaver> why is libdbusmenu related to vala 0.42?
[10:19] <sunweaver> it is C lib
[10:19] <sunweaver> (with a vapi file, possibly)
[10:19] <ricotz> it at least build-deps on valac
[10:20] <sunweaver> slick-greeter fails, too.
[10:20] <sunweaver> but unity-greeter not.
[10:20] <sunweaver> interesting...
[10:20] <ricotz> a lot of vala-unrelated failure too
[10:21] <ricotz> if it is vala-related then they fail because of "error: Property `Background.current_background' with custom `get' accessor and/or `set' mutator cannot have `default' value"
[10:21] <sunweaver> ah, arctica-greeter has been fixed upstream already.
[10:21] <sunweaver> I have some more changes in mind before I do a release.
[10:22]  * sunweaver should hurry with that then.
[10:22] <ricotz> 0.41.92-1 is still in NEW/exp
[10:22] <sunweaver> background.vala:447.5-447.37: error: Property `Background.current_background' with custom `get' accessor and/or `set' mutator cannot have `default' value
[10:22] <sunweaver> yeah, that one is new.
[10:23] <sunweaver> let me see...
[10:25] <ricotz> those default values can be dropped without further action if they e.g. null / 0 / 0.0
[10:26] <ricotz> otherwise they should be moved into the constructor or made a field-initializer
[10:26] <sunweaver> let me see...
[10:26] <sunweaver> ricotz: how is this? http://paste.debian.net/1038857/
[10:27] <ricotz> diff -U20 ?
[10:28] <sunweaver> http://paste.debian.net/1038860/
[10:29] <sunweaver> what about declarations/assignments like these...
[10:29] <sunweaver> "public double alpha { get; private set; default = 1.0; }" ?
[10:30] <ricotz> only custom properties are affected
[10:30] <sunweaver> ack.
[10:31] <ricotz> the patch seems fine if you are familiar with the code base since this is a behaviour change
[10:31] <eoli4n> Hi
[10:32] <ricotz> sunweaver, setting the default intends to have it set once at object creation
[10:33] <sunweaver> I guess my change is actual the wanted behaviour...
[10:33] <ricotz> which doesn't work as one expect for custom properties therefore the new error
[10:34] <ricotz> yeah, seems that way
[13:30] <GunnarHj> rbasak, sil2100: What's the next step as regards the SRUs of bug #1778041? I have added to the bug report a link to an IRC conversion rbasak and I had last week, where the possibility to ship empty packages was mentioned. But the uploads also miss binary packages of certain archs, and such a measure wouldn't address that aspect. So is the latter considered a problem? Or put in another way: Considering that we don't seem to be
[13:30] <GunnarHj> able to consistently help certain users to keep their systems clean of dropped packages, is it motivated to do it for those libpdf and nacl packages which are said to be not functioning anyway?
[13:40] <rbasak> GunnarHj: thank you for driving this bug. I won't be around for the next few weeks now, so I'm trying to avoid making any decisions that I won't be around to stand behind. I wanted to make sure we didn't go wrong on this point, but I'm happy for sil2100 to make the final decision.
[13:40] <rbasak> s/but//
[13:41] <rbasak> (or, if it had to be my decision, I'd ask infinity probably)
[14:06] <GunnarHj> rbasak: Ok, thanks for letting me know. Will talk with sil2100 about it, then.
[14:39] <ahasenack> tjaalton: heh, I was just about to ask you about sssd 1.16.3 :)
[14:39] <ahasenack> releasing package sssd version 1.16.3-1
[14:39] <ahasenack> Timo Aaltonen authored 1 hour ago
[14:44] <roaksoax> doko: howdy! is twisted broken on cosmic ? will the new update to 18.7 fix it ?
[14:45] <roaksoax> doko: i got a build failure with https://pastebin.ubuntu.com/p/P4pGG8RyFJ/
[15:00] <jbicha> acheronuk: so you have 2 copies of all the KDE autopkgtests running, 1 for the archive & 1 for a bileto ppa? 😢
[15:00] <jbicha> can we kill those bileto tests?
[15:01] <acheronuk> jbicha: umm what? that wasn't intended!
[15:01] <jbicha> I'm looking at https://autopkgtest.ubuntu.com/running 😟
[15:03] <acheronuk> jbicha: damn. usually I avoid that by lander sign off followed by publish immediately. I got called away from PC this morning at that time, so I guess was too slow
[15:03] <seb128> cyphermox, hey. modemmanager 1.8 is available, do you think you could update our package (and maybe Debian's)?
[15:03] <acheronuk> jbicha: if they can be killed, please do!
[15:05] <jbicha> juliank: sil2100: slangasek: it would be appreciated if one of you could kill the #3374 ppa autopkgtests. Not sure if that's easy to do or not
[15:06] <juliank> jbicha: huh hmm
[15:07] <juliank> I can kill a running process, but I don't know how to remove it from the queue
[15:07] <juliank> so it would just go back in front of it
[15:08] <slangasek> jbicha: do I understand these packages are already published and the test results won't be used for the ppa?
[15:08] <jbicha> yes
[15:08] <slangasek> ok
[15:08] <jbicha> https://bileto.ubuntu.com/#/ticket/3374
[15:09] <slangasek> juliank: from the cloud-worker, you can use autopkgtest-cloud/tools/filter-amqp to nuke things from the queue
[15:09] <juliank> slangasek: oh cool
[15:11] <slangasek> juliank: example: for arch in amd64 armhf i386 pp864el s390x; do autopkgtest-cloud/tools/filter-amqp <amqp creds go here> debci-ppa-cosmic-${arch} -v ci-train-ppa-service/3375; done
[15:14] <jbicha> slangasek: 3374 please 😉
[15:14] <slangasek> did I do the wrong one? shoot
[15:15] <slangasek> cpaelzer: ^^ sorry, I accidentally shot your autopkgtests out of the queue for https://bileto.ubuntu.com/#/ticket/3375
[15:16] <slangasek> also apparently I can't spell 'ppc64el' so let me fix that :P
[15:22] <tjaalton> ahasenack: ah, right. there's also 2.0.0
[15:23] <ahasenack> tjaalton: yeah, but I was looking at the security fixes in 1.16.3 compared to 1.16.2, and ubuntu feature-freezes tomorrow
[15:25] <cpaelzer> slangasek: all of them or just one?
[15:25] <slangasek> cpaelzer: all of them that were in the queue... except I didn't kill them on ppc64el due to a typo
[15:25] <cpaelzer> hehe
[15:25] <cpaelzer> and I have one result on ppc being good :-)
[15:25] <cpaelzer> thanks for the notice
[15:25] <cpaelzer> what I have is barely enough to go on
[15:26] <cpaelzer> good that I don't wait for completion
[15:45] <cjwatson> roaksoax: There's a fix for that in cosmic-proposed which hasn't made it to cosmic yet
[15:48] <cjwatson> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=906215 is part of it but apparently twisted's own autopkgtests are failing too
[15:52] <roaksoax> cjwatson: yes, I saw. thanks.
[15:53] <roaksoax> cjwatson: i'm guessing this is a dependency that broke things? Becuase I built packages yesterday that depend on twisted and it didn't fail. Where as today it does with the same dependencies
[15:53] <psusi> ok, what the heck?  I apt-get source qemu, dpkg-buildpackage, and qemu-system-* have extra deps that the one in the archive does not, including libcapstone3
[15:54] <cjwatson> roaksoax: Python 3.6 -> 3.7, presumably
[15:54] <rbasak> psusi: are you using a clean chroot for the build? If not, configure scripts inside package builds can pick up extra dependencies and decide to build against them.
[15:55] <cjwatson> roaksoax: Though I thought cosmic's default was still 3.6
[15:55] <psusi> ahh, I had previously tried building from the debian git repo and it had a few more deps it seems
[15:56] <psusi> that I guess are optional and we had them off
[15:57] <psusi> hrm.. guess I should set up pbuilder again
[16:11] <nacc> psusi: i'd recommend build over pbuilder, fwiw
[16:15] <psusi> there's a new one?  I remember there being schroot and pbuilder
[16:16] <nacc> psusi: sorry, typo! sbuild :)
[16:28] <psusi> ahh, forgot about that one
[16:34] <tsimonq2> seb128: I didn't O_O sorry.
[16:34] <tsimonq2> seb128: Want me to just revert it or is it handled already?
[17:13] <ahasenack> what does this do in debian/control, when there is no debian/tests? Testsuite: autopkgtest-pkg-python
[17:15] <Unit193> ahasenack: Basically, tries to import it.  See autodep8(1)
[17:19] <seb128> tsimonq2, it's not handled that I know of but I didn't follow up during the day, maybe best if you fix it
[18:16] <xnox> psusi, on both debian & ubuntu -> $ mk-sbuild cosmic
[18:16] <xnox> $ sbuild -A -d cosmic *.dsc
[18:47] <psusi> jbicha: say, what difference does it make whether gparted is in /usr/sbin or /usr/bin?
[19:07] <jbicha> psusi: ha, you're asking me about testing I did last year. I don't remember the details except that I guess it didn't run
[19:09] <psusi> odd... wonder why... I've merged your changes with a new upstream release I'm preparing for debian... was just wondering why it mattered either way
[19:14] <jbicha> it should be pretty easy to check. You can drop the change if it works fine without it
[19:16] <xnox> psusi, policykit things hardcoding a path or something?
[19:16] <psusi> AFAIK, it should work fine either way
[19:16] <xnox> is my best guess
[19:16] <xnox> indeed
[19:16] <psusi> so I merged it and as long as it works in debian... it's fine I guess
[20:00] <ahasenack> tjaalton: hi, you seem to have included a patch file in the root directory of sssd 1.16.3
[20:00] <ahasenack> --- sssd-1.16.3.orig/0001-common.dirs-common.postinst-Add-dir-for-secrets-with.patch
[20:00] <ahasenack> +++ sssd-1.16.3/0001-common.dirs-common.postinst-Add-dir-for-secrets-with.patch
[20:00] <ahasenack> in the debian .diff.gz file (source package)
[20:01] <tjaalton> bah
[20:04] <ahasenack> 1.16.2-1 is clean, doesn't have it
[20:05] <tjaalton> doesn't matter
[20:05] <ahasenack> was just checking if I hadn't overlooked it before
[20:05] <tjaalton> .2 was uploaded from another machine
[20:06] <ahasenack> this 1.16.3 can be a sync with ubuntu
[20:06] <ahasenack> our delta was adopted upstream
[20:07] <ahasenack> er, sync with debian
[20:07] <tjaalton> need me to sync it?
[20:07] <ahasenack> no, I'll just make a formal mp to have a record
[20:07] <tjaalton> k
[20:07] <ahasenack> should be synced tomorrow my morning
[21:08] <ahasenack> tjaalton: fyi, the freeipa dep8 tests are failing but exiting 0, giving a false green status: http://autopkgtest.ubuntu.com/packages/freeipa/cosmic/amd64
[21:08] <ahasenack> scroll to the end
[21:08] <ahasenack> they "all" end with a backtrace, but "PASS"
[21:08] <ahasenack> debian is a few versions behind I think
[21:09] <ahasenack> I'll file a bug, and take a look when I cna
[21:09] <ahasenack> I'll add dep8 tests to sssd this cycle still
[21:13] <tjaalton> it's in limbo atm
[21:13] <tjaalton> new dogtag is WIP, freeipa 4.7 too
[21:14] <tjaalton> and I'm on paternity leave
[21:14] <tjaalton> so most of it has to wait until next month
[21:16] <ahasenack> it's the only test than an sssd upload triggers, more reason for me to add a set of sssd specific tests
[21:16] <ahasenack> which I'll MP to debian, of course :)
[21:16] <ahasenack> tjaalton: congrats on the parenthood :)
[21:18] <tjaalton> thx
[21:52] <tjaalton> ahasenack: btw, any plans to merge latest tomcat8? it finally adds a systemd unit
[21:59] <tumbleweed> with the next tomcat8 upload, we should be able to sync again, going from the conversation in bugs.debian.org/895866
[22:00] <tjaalton> tumbleweed: check the ubuntu changelog..
[22:01] <tjaalton> apparently what debian did wasn't enough
[22:12] <tumbleweed> tjaalton: I wrote that changelog entry
[22:14] <nacc> heh
[22:14] <tjaalton> tumbleweed: so you're saying it's not needed?
[22:14] <tjaalton> the patch
[22:17] <tumbleweed> they're taken another shot at the problem, upstream, and .33 hopefully won't need it any more
[22:18] <tjaalton> ah, .33
[22:18] <tjaalton> cool
[22:18] <tjaalton> I thought you meant .32-2 :P