[01:25] <tsimonq2> tjaalton: About the XDG implementation bug we talked about last week, https://salsa.debian.org/xorg-team/debian/xorg/merge_requests/2
[02:07] <krytarik> tsimonq2, tjaalton: As opposed to what that MR says it does though, it actually "only" makes sure that '/etc/xdg' is included in the variable if it is already set.
[02:09] <tsimonq2> krytarik: I wouldn't consider that "only"
[02:11] <tsimonq2> krytarik: Before this PR, it indiscriminately set it to /etc/xdg/xdg-$DESKTOP_SESSION and /etc/xdg
[02:11] <tsimonq2> krytarik: Now, if it's empty, sure it still does that, but if it isn't empty, it does that and retains the original content
[09:53] <doko> Preparing to unpack .../40-python3-sha3_1.0.2-2ubuntu1_amd64.deb ...
[09:53] <doko> Unpacking python3-sha3 (1.0.2-2ubuntu1) ...
[09:53] <doko> dpkg: error processing archive /tmp/apt-dpkg-install-SsTVVg/40-python3-sha3_1.0.2-2ubuntu1_amd64.deb (--unpack):
[09:53] <doko>  trying to overwrite '/usr/lib/python3/dist-packages/sha3.py', which is also in package python3-pysha3 1.0.0-0ubuntu3
[09:53] <doko> xnox: ^^^
[10:46] <xnox> doko, i guess i am missing breaks/replaces; had this now as well.
[13:43] <mvo> another question about autopkgtests - I have a snapd test that is failing on amd64 right now. the failure looks like it is fixed with the latest systemd in bionic-proposed. is it possible that the autopkgtest vm still has an older systemd installed? and if so, how/when is that refreshed?
[13:49] <seb128> mvo, you can retrigger the test with the systemd proposed version if you want
[13:50] <seb128> mvo, I think by default it doesn't use all proposed
[13:50] <seb128> mvo, "The Ubuntu CI system runs packages with only selected packages from -proposed available (the package which caused the test to be run);" is what is written on http://packaging.ubuntu.com/html/auto-pkg-test.html
[13:51] <seb128> mvo, if you try manually you can -apt-pocket=proposed=src:foo
[13:51] <seb128> mvo, or you can add &trigger=package/version to the web retry url
[13:57] <mvo> seb128: let me try that, thank you!
[14:06] <ddstreet> sil2100 re: lp #1644662, the build for gnome pkgs automatically updates the Uploaders:, how did you build a src pkg without the Uploaders: getting changed?
[14:06] <ddstreet> for my future reference, if i have to sponsor a gnome pkg again
[14:12] <sil2100> ddstreet: I just did a regular rebuild with debuild -S just without touching the debian/control, as it was reverting its contents from what was already in the archive
[14:13] <ddstreet> sil2100 ok interesting, that's all i did and it did update the Uploaders:
[14:13] <sil2100> Sometimes it makes sense, but here it got brought back to a very early uploader list which seemed not that nice
[14:13] <sil2100> hmm
[14:13] <ddstreet> it does a 'smart' update of Uploaders: using locally-installed gnome files
[14:14] <ddstreet> yeah, i didn't want to change the field, but if you check the control.in the field is @GNOME_TEAM@ so it has to be auto-populated at pkg build time
[14:14] <ddstreet> anyway, glad it didn't change it on your system :)
[14:15] <ddstreet> sil2100 btw, it uses the locally-installed /usr/share/gnome-pkg-tools/1/rules/uploaders.mk file to figure out what the Uploaders: list should be.
[14:35] <jbicha> the Uploaders field is really irrelevant on Ubuntu so I wouldn't worry about it :)
[15:23] <mvo> seb128: so &trigger=systemd/latest-in-proposed gave me systemd latest but not the latest snapd, can I can triggers? who is the expert in this these days? sil2100 maybe? (context is autopkgtest and how to ensure that my -proposed snapd runs against the -proposed systemd)
[15:25] <jbicha> mvo: you can multiple &trigger= to your URL
[15:25] <seb128> mvo, you need to &trigger= all the packages you want from proposed
[15:26] <seb128> &trigger=systemd/proposed&trigger=snapd/proposed
[15:28] <mvo> seb128, jbicha: thank you!
[15:28] <mvo> \o/
[15:29] <seb128> mvo, yw!
[15:40] <caribou> Hello, I'm working on rebuilding gcc7.3 using sbuild which complains that it cannot resolve dependencies to gnat-7 & g++-7 which are native packages of gcc7.3. A=
[15:40] <caribou> Any reason why this happens and why ?
[15:40] <caribou> s/why/how to fix it ?
[15:41] <caribou> hello to everyone btw, long time no see
[16:05] <nacc> caribou: hi!
[16:06] <nacc> caribou: can you paste the exact error (presumably from apt)?
[16:09] <nacc> tjaalton: is it expected for intel-gpu-tools to no longer ship intel-gpu-overlay in bionic?
[16:14] <nacc> tjaalton: LP: #1750605 (from #ubuntu+1)
[16:18] <caribou> nacc: the error is from sbuild : https://pastebin.ubuntu.com/p/yY5gnjqQd4/
[16:19] <caribou> nacc: the gnat-7 & g++-7 dependencies come from the gcc-7 package being built & they're identified as :native in the d/control file
[16:20] <caribou> nacc: I'm trying to build gcc-7 on Xenial btw
[16:23] <nacc> caribou: looking if i can see
[16:35] <nacc> caribou: possibly gcc needs to be bootstrap built?
[16:35] <nacc> i'd almost assume it does
[16:37] <caribou> nacc: well, that's something I don't know. But following your question sbeattie answered my query in #ubuntu-hardened so looks like I won't need to rebuild gcc-7 as gcc-5 in xenial-proposed has the retpoline patches
[16:37] <caribou> which is what I was after
[16:37] <caribou> I'm still curious to know what a "bootstrap build" is though :)
[16:39] <tjaalton> nacc: looking
[16:39] <xevious> Is anyone working on kernel 4.16 for Bionic?
[16:39] <xevious> Or, are there any plans for it?
[16:39] <xevious> There are some big improvements for vGPUs coming from Intel.
[16:39] <tjaalton> no
[16:40] <tjaalton> bionic will ship with 4.15
[16:43] <tjaalton> nacc: looks like it needs a new build-dep
[16:46] <nacc> caribou: i've done it for other tooling, you build a minimal part, and then use that to rebuild itself
[16:46] <nacc> caribou: if that makes sense
[16:55] <xevious> xnox: Oops. I forgot to run the php-zeta-base package through adt with proposed enabled.
[16:59] <xnox> xevious, all i hope is that the messages makes some sense to you, because php is all greek to me.
[17:02] <xevious> It makes perfect sense: 'object' is now a keyword in PHP 7.2
[17:11] <tjaalton> nacc: pushed new i-g-t to sid
[17:11] <nacc> tjaalton: thanks!
[17:11] <nacc> xevious: you have a fix for that? i can help usher it through
[17:11] <nacc> xnox: thanks for your help!
[17:12] <xevious> nacc: Working on it now.
[17:12] <nacc> xevious: thanks
[17:15] <xevious> nacc: After I fix this, it's just Horde packages.
[17:16] <xevious> I'll this php-zeta-base sorted out, then I'm taking the rest of the day off (it's my birthday).
[17:16] <xevious> s/this/get/
[17:16] <xevious> Brains.
[17:16] <nacc> xevious: happy birthday! and thanks for your contribution to Ubuntu!
[17:17] <nacc> xevious: yeah, i think i can get horde fixed today
[17:20] <xnox> nacc, i see a bunch of horde uploads.... yet it is still a seas of red. Do we need, like an all-proposed=1 maas-retry of everything?
[17:20] <xnox> nacc, or do you know what is still outstanding?
[17:20] <xevious> A bunch of packages need to be updated for PHPUnit 6's namespaced classes.
[17:20] <nacc> xnox: yeah, it will be that once i'm done uploading
[17:20] <nacc> i made it up to php-horde-k on friday
[17:21] <xevious> xnox: In most cases, it's just a search and replace. There are some places where it requires some manual updates, though. (Exception handling completely changed, for instance.)
[17:22] <xevious> Is it possible to rename a file with quilt?
[17:22] <nacc> yeah it's a bit slower than normal, since i have to build, test and then possibly test other entanged packages locally before uploading :)
[17:24] <xnox> xevious, quilt add old new
[17:24] <xnox> xevious, mv old new
[17:25] <xnox> xevious, quilt refresh
[17:25] <xevious> xnox: Thanks
[17:59] <xevious> nacc: I attached a new patch for php-zeta-base.
[18:00] <nacc> xevious: thanks
[18:00] <nacc> xevious: i have a feeling php-horde-sessionhandler is relatively broken
[18:00] <nacc> https://github.com/horde/SessionHandler/blob/master/lib/Horde/SessionHandler.php#L95
[18:00] <nacc> emits a warning now
[18:00] <nacc> https://bugs.php.net/bug.php?id=71038
[18:01] <ddstreet> nacc are you able to review/sponsor lp #1718568 to bionic for me?
[18:02] <ddstreet> i can upload to sru releases once it's in bionic
[18:03] <nacc> ddstreet: yeah, i'm in the middle of some php stuff, but i can do it this afternoon worst case?
[18:04] <ddstreet> nacc awesome thnx, no big hurry
[18:04] <ddstreet> whenever you have time
[18:04] <nacc> ddstreet: ack
[18:05] <xevious> nacc: I uploaded a fixed patch for php-zeta-base... https://bugs.launchpad.net/ubuntu/+source/php-sabredav/+bug/1750041/comments/11
[18:07] <nacc> xevious: sponsoring now
[18:08] <ddstreet> smoser fyi the patch for lp #1718568 is on top of your dhclient.linux script ipv6 dad change, you may want to reivew also
[18:20] <nacc> xevious: sponsored
[18:23] <xevious> Nice.
[18:23] <nacc> xevious: if you could look at the above php-horde-sessionhandler thing (i also don't use php much) ... imo, i might just need to disable the dep8 tests for now
[18:25] <xevious> Where does adt store its containers? I'd like to move it onto this VM's enormous ramdisk.
[18:26] <nacc> xevious: it's just using lxd's config
[18:26] <nacc> xevious: if i had to guess
[18:34] <xevious> nacc: "Headers already sent" probably means there was some unintended output before an explicit call to `header()`.
[18:36] <xevious> (Or, any other method that sends a header...)
[18:37] <nacc> xevious: sure, but, aiui, this is an intentional upstream change
[18:37] <nacc> xevious: and it's not clear the php-horde-sessionhandler code is supposed to work
[18:37] <xevious> They don't officially support PHP7+, though, right?
[18:39] <xevious> nacc: If they're developing for PHP 5.x, they may be calling something that was valid code on that version of the interpreter, but on PHP7 it generates a warning that produces some output.
[18:40] <xevious> If that happens before any methods that affect headers, it'll cause a "Headers already sent" error.
[18:41] <nacc> xevious: not sure, tbh
[18:41] <nacc> xevious: but, presumably, this passed with 7.0 and 7.1
[18:42] <xevious> Is this blocking other packages, or could I look at it tomorrow?
[18:43] <nacc> xevious: go enjoy!
[18:43] <nacc> xevious: i can keep digging :)
[18:45] <xevious> nacc: You're going to want to look for unintended output occurring somewhere before any of these lines are executed during that failing test: https://pastebin.com/wsRbzaHV
[18:46] <nacc> xevious: yeah, i'll nee to run it by hand
[18:46] <nacc> thanks!
[18:47] <xevious> If you get frustrated with it, you can leave it for me to look at tomorrow.
[18:48] <nacc> xevious: thanks, i'll let you know
[18:48] <xevious> Is something holding up that php-zeta-base?
[18:48] <nacc> i'm deep in some mock + reflection stuff now (different package)
[18:51] <xevious> I see it listed as the latest upload, but it's not showing up in proposed. I'm just not sure where I go to monitor the process...
[18:51] <nacc> xevious: it needs to build, then publish, then it needs to be seen by the dep8 runners
[18:51] <nacc> xevious: i'll check on it this afternoon
[18:51] <nacc> xevious: it passed locally for me
[18:53] <xevious> Yeah, I totally goofed and forgot to test that one with proposed enabled when I first submitted a patch.
[22:26] <nacc> xevious: fyi, it would appear php-horde-sessionhandler, which in turn affects php-horde-kolab-storage, and php-horde-kronolith all may be entanged due to the php7.2 session handling changes
[23:28] <nacc> xevious: hey and look at htat php-horde-core is passing iwth all-proposed=1
[23:49] <nacc> xevious: i think most of horde, but what i mentioned earlier is now passing. i'm uploading one last one and then i'm going to let the publisher settle before retrying php-horde-l* and on