[00:22] <nacc> rbasak: i think i got ubuntu/devel working :)
[00:26] <rbasak> \o/
[00:48] <nacc> rbasak: will talk w/ you in the am on it, i think i got barry's bug fixed too, as well as the isc-dhcp import
[00:54] <rbasak> Great!
[05:00] <pitti> Good morning
[05:13] <infinity> pitti: Morning.
[05:13] <infinity> pitti: Kernel attempt number 2 in progress.  Turns out that changing CC in the top level Makefile blows up dksm. :/
[05:13] <infinity> dkms, too.
[05:18] <infinity> Qt will migrate today if I have to jam it in with a fork.
[05:19]  * pitti hands infinity some lube too
[05:22] <sarnold> don't force it, get a bigger hammer
[05:22] <infinity> pitti: Witness the horror: http://paste.ubuntu.com/23066399/
[05:23] <infinity> export SHELL=env PATH=$(PWD)/debian/compiler:$(PATH) /bin/bash -e
[05:23]  * infinity shudders.
[05:23] <pitti> that's a curious ABI bump
[05:23] <pitti> 9034 → 9134?
[05:23] <infinity> pitti: 34.53 matches the xenial source.
[05:23] <pitti> using gcc 6 instead of 5 changes ABI?
[05:23] <infinity> pitti: 90/91 was me making the ABI not clash with xenial.
[05:24] <pitti> ln -s /usr/bin/gcc-5 debian/compiler/gcc
[05:24] <pitti> elegant! *cough*
[05:24] <infinity> pitti: No, not actually an ABI change, but ABI == package name, they have to be unique these days for other reasons (signed modules, for one)
[05:25] <infinity> The days of ABI tracking are dead.  Unless we move to using a central signing key for modules.
[05:25] <infinity> But for now, because of the baked in ephemeral key, every kernel needs to be a unique "abi".
[05:25] <infinity> pitti: And yes, "elegant". :P
[05:26] <infinity> pitti: Though, I might clean it up and propose something similar but more robust for compiler switching.  Specifying CC breaks some of upstream's Makefiles (a joyous bug I won't bother hunting down), and changing CC in the top level Makefile breaks installed kbuild (ie: dkms), so...
[06:46] <pitti> sergiusens: FYI, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapcraft test fails
[06:48] <Unit193> pitti: BTW, with upstart user sessions, dbus-launh would launch an application in a new session or something such that the new application was unaware of other applications.  With the new systemd/dbus-user-session, that and unsetting DBUS_SESSION_BUS_ADDRESS no longer work.  Do you know how I can do this?
[06:50] <pitti> Unit193: that's not the same -- dbus-launch starts a new (local) bus and sets D_S_B_A to *that* address; that should continue to work as before
[06:50] <pitti> Unit193: *unsetting* D_S_B_A will just make applications use the builtin $XDG_RUNTIME_DIR/bus default
[06:51] <Unit193> Hrm, neither are working now as a workaround.
[06:51] <pitti> neither of this is a function of how you start the session -- most probably this changed with installing dbus-user-session
[06:51] <Unit193> I figured it was from dbus-user-session, aye.  But clearly I don't know dbus magic. :)
[06:51] <pitti> what are you tryign to do?
[06:53] <Unit193> There's a workaround to get dropbox to show up correctly, but it's to force it out of indicator-application and use its trayicon, otherwise you get an IMAGENOTFOUND icon and a non-functioning menu.
[06:55] <pitti> Unit193: and "DBUS_SESSION_BUS_ADDRESS=invalid dropbox" doesn't work? I tried "dbus-launch --exit-with-session d-feet" and that runs in its own private session bus world as expected
[06:56] <Unit193> pitti: Correct.
[06:58] <pitti> I figure actually launching a new bus is moot as dropbox then can't communicate with anything else anyway -- so just using an invalid address is simpler
[07:02] <Unit193> pitti: Eh, I'll just nuke XDG_RUNTIME_DIR for now instead I guess.
[07:02] <pitti> Unit193: that's much worse, but if you know what you are doing, sure :)
[07:04] <Unit193> pitti: Dropbox is entirely weird, it has /usr/bin/dropbox, which launches ~/.dropbox-dist/dropboxd, which launches another script, which finally launches the actual process.  If I set the env in the uppermost script, I should still get a functional dropbox without breaking too much, I'd think.
[07:04] <pitti> cjwatson: FYI, I just committed http://bazaar.launchpad.net/~ubuntu-archive/ddeb-retriever/trunk/revision/171 to ignore wily as a supported release; this should hopefully stop the cron spam
[07:05] <pitti> (not sure why it can't be marked as obsolete yet, but I suppose there are reasons)
[07:11] <infinity> pitti: There's a reason, it's just my TODO list being too long, and some things I need to clean up before I disable it.
[07:11] <infinity> pitti: Sorry it was causing backscatter.
[07:13] <pitti> infinity: no problem, it's an easy enough workaround
[07:37] <pitti> cjwatson, infinity: is there some way to find out what pulls p3-lp into standard now? http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt
[07:37] <pitti> this will affect containers as well, and might not be intended
[07:41] <pitti> oh, I think update-manager-core (in standard seed) → python3-update-manager → python3-launchpadlib
[07:41] <pitti> but python-launchpadlib has been optional forever, even in xenial
[07:42] <pitti> ok, that came from http://launchpadlibrarian.net/275354292/update-manager_1%3A16.10.2_1%3A16.10.3.diff.gz
[07:43] <pitti> "Attempt to retrieve Changelogs from PPA sources"
[08:01] <tsdgeos> is libreoffice-writer crashing in yakkety for anyone else?
[08:15] <jibel> doko, hey, could you help with bug 1613602 to understand where the problem is, if it's libc or something else?
[08:15] <ubottu> bug 1613602 in Canonical System Image "repowerd crashes on xenial/arm64" [Critical,New] https://launchpad.net/bugs/1613602
[08:15] <jibel> doko, alf and vicamo can provide more info if needed
[08:22] <mwhudson> how do i see the default gcc flags? (i.e. the place where pie got turned on for s390x in 16.04)
[08:24] <juliank> I feel like the arm64 build is going weird, it's printing "INFO: pkgstripfiles: waiting for lock (apt-transport-https) ..."  since a minute or so https://launchpad.net/ubuntu/+source/apt/1.3~rc2ubuntu1/+build/10631459
[08:24] <brendand> has anyone been using the nose-subunit plugin successfully recently? my attempts to install it have been underwhelming
[08:25] <juliank> I guess I'll restart the build and hope for more luck this time
[08:30] <juliank> Hmm, now it's cancelling stuff since a minute or so
[08:32] <juliank> well, seems to have been cancelled. retrying now. let's hope it works better this time ...
[08:57] <doko> jibel: glibc should be infinity's expertise. but I can have a look tomorrow
[08:58] <doko> mwhudson, compile and link a helloworld.c with -v and look for the flags
[09:03] <xnox> mwhudson, PIE is on by default in the toolchain for s390x in 16.04, in 16.10 it's also on for amd64 and ppc64el.
[09:03] <doko> ahh, yes, we even have a wiki page documenting these ...
[09:09] <mwhudson> xnox, doko: context is https://github.com/golang/go/issues/16780
[09:10] <mwhudson> which i think roughly speaking means "-fdebug-prefix-map doesn't work"
[09:10] <mwhudson> but only on s390x!
[09:10] <mwhudson> which makes no sense
[10:07] <jibel> infinity, any insight on bug 1613602?
[10:07] <ubottu> bug 1613602 in Canonical System Image "repowerd crashes on xenial/arm64" [Critical,New] https://launchpad.net/bugs/1613602
[10:08] <infinity> jibel: Nothing immediately leaps to mind.
[10:08] <infinity> jibel: I can look more $later, but not sure precisely when $later will be.
[10:10] <infinity> Laney: The default gedit colour scheme has a transparent background.  That can't be right. :P
[10:10] <jibel> infinity, that's fine as long as later != infinity
[10:10] <infinity> jibel: infinity would be an awful result indeed.  The last thing I want to do is examine the same bug at every point in time.
[10:11] <infinity> Maybe that's what hell is.
[10:15] <Laney> infinity: Not seen that, will check on an iso or something later
[10:16] <infinity> Laney: I thought it might be a bad local mapping of old setting or something, but if you go to preferences, colours, and click the schemes/themes (which I would expect would reset any bad settings I have?), they all seem to work fine, but the top one has a transparent window.
[10:16] <infinity> And the top is, I assume, also the default.  It is here anyway.
[10:18] <infinity> Laney: Also an entertaining menu re-rendering bug (which I'm guessing is the theme's fault?) where hilighting a menu item makes the menu grow in size slightly...
[10:18] <Laney> It looks right on a live session :(
[10:18] <Laney> Yes, that one is known
[10:19] <infinity> Laney: Hrm.  The gedit thing is fine in live?  Great.  I'll try a fresh profile at some point, but if it's an upgrade bug, that's icky.
[10:19] <Laney> https://trello.com/c/EXpA6lKW/8-look-into-gtk-3-20
[10:19] <Laney> Those are my known issues
[10:20] <infinity> Laney: Handy.  I'll keep that card open and only bug you when something is either not there or listed fixed and clearly not. :)
[10:20] <Laney> Try gedit in a guest session
[10:20] <Laney> Maybe something's held back pre-3.20 or whatever
[10:29] <infinity> Laney: Guest session is fine.
[10:29] <infinity> Laney: Which implies an upgrade bug.  But I haven't exactly customized gedit or anything.  I only use it for quick throwaway notes.
[10:35] <Laney> infinity: Meh, keep the bug around and let me see it when we're next in the same place
[10:36] <xnox> Mirv, i'm getting QT_QT_INCLUDE_DIR set to NOTFOUND building against Qt4 in calligra
[10:37] <xnox> never mind, i have qt5 installed as well.
[10:38] <Mirv> ok
[10:38] <Mirv> calligra is removed from Debian it seems
[10:39] <xnox> it's not.
[10:39] <xnox> it's in unstable.
[10:40] <xnox> but yeah, it is not in a nice state at the moment.
[10:40] <Mirv> correct, just looking regarding release. it seems there's some 2.9 packaging in there but not finished or touched since 2015.
[10:40] <Mirv> (I was mostly curious there is still some software using Qt 4 which should be on its way out)
[10:40] <xnox> ubuntu is on 2.9 series
[10:41] <xnox> i wonder what happened. I guess libreoffice got better kde/qt integration and people gave up on calligra?
[10:41] <xnox> it is ex-KOffice, right?
[10:42] <Mirv> I think Calligra was funded by Nokia until... not anymore, maybe it's been searching for itself a bit and with less resources
[10:42] <xnox> ah, did not know about nokia funding
[10:42] <Mirv> so calligra was also more mobile oriented and was running on Nokia N9 as the document viewer
[10:42] <Mirv> but indeed LO is starting to cover all those corners now
[10:43] <xnox> anyway, i have an umbigious reference between "half" and "Eigen::half_impl::half" to fix. Silly OpenEXR not using a namespace.
=== hikiko is now known as hikiko|ln
=== hikiko|ln is now known as hikiko
[11:53] <mdeslaur> slangasek: I'm going to need some help from someone to figure out why libgcrypt20 isn't building on armhf anymore in xenial: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/10628823
[11:53] <mdeslaur> slangasek: unfortunately, it's an urgent update
[11:54] <mdeslaur> slangasek: could you please tell me who I can ask?
[11:59] <ogra_> does anyone else see apparmor hangs in 16.04 upgrades today ?
[11:59] <ogra_> i see a kernel oops during the apparmor package postinst on two 16.04 machines i upgraded today
[11:59] <ogra_> involving an uncloseable update-manager too
[12:00] <ogra_> bug 1614459
[12:00] <ubottu> bug 1614459 in apparmor (Ubuntu) "daily upgrade on 16.04 hangs" [Undecided,New] https://launchpad.net/bugs/1614459
[12:02] <infinity> cjwatson: What conclusion did we draw the last time we talked about alignment on armhf on arm64 kernels?
[12:03] <infinity> cjwatson: Looks like mdeslaur is seeing SIGBUSes in libgcrypt that (presumably) were being fixed up or ignored before. :/
[12:04] <mdeslaur> infinity: fixed up by what?
[12:04] <infinity> mdeslaur: Anyhow, short story, gcrypt has alignment bugs.  Long story, it seems our armv7 kernels were fixing those up instead of throwing bus errors, and our arm64 kernels aren't (or can't).
[12:04] <mdeslaur> oh, huh
[12:04] <ogra_> SRU team ... see above bug please (havent heard of anyone else who can reproduce it yet, but i have seen it on two machines now)
[12:05] <jibel> tyhicks, hey, can you have a look at the bug ogra pasted earlier? 1614459 it's a regression in xenial
[12:05] <infinity> mdeslaur: I'll note that yakkety doesn't seem to have said problem, so finding the commit(s) that fixed the alignment bug(s) might not be too hard.
[12:06] <mdeslaur> yeah, possibly http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=a6158a01a4d81a5d862e1e0a60bfd6063443311d and http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=commit;h=1111d311fd6452abd4080d1072c75ddb1b5a3dd1
[12:06] <mdeslaur> I'll try backporting those
[12:06] <Mirv> Laney: both http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-ui-toolkit and the -gles would be there now for the --all-proposed run of unity8
[12:07] <Laney> huh, I thought I did it
[12:07] <Laney> lemme see
[12:07] <infinity> mdeslaur: It was probably a mistake for us to ever have kernels that fixed up alignment errors on ARM in the first place, but now here we are.
[12:08] <infinity> Those traps are super expensive, we were just hurting ourselves by not catching the bugs.
[12:09] <Laney> Mirv: there we go
[12:10] <mdeslaur> infinity: thanks for the hint
[12:11] <Mirv> thanks
[12:13] <Laney> huh
[12:13] <Laney> it's disappeared
[12:14] <Laney> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/u/unity8/20160818_121007@/log.gz
[12:16] <cjwatson> infinity: https://bugs.launchpad.net/launchpad-buildd/+bug/1516331
[12:16] <ubottu> Launchpad bug 1516331 in launchpad-buildd "please set /proc/cpu/alignment=4 on Launchpad ARM buildd kernels" [Undecided,New]
[12:16] <Mirv> Laney: indeed I still don't see them at http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8
[12:16] <cjwatson> infinity: Steve explicitly wanted us there to do more raising of SIGBUS, which at the time seemed to be not a thing on arm64 kernels, but maybe that is in fact a thing now, in which case "yay" as far as that bug is concerned
[12:17] <Laney> Mirv: Some kernel uninstallability, looks like things are publishing out
[12:31] <infinity> cjwatson: Well, mdeslaur was sigbusing all over the place, so it definitely seems to be a thing.
[12:31] <infinity> cjwatson: I think what's not a thing is the config that does alignment fixups.  I think.
[12:33] <infinity> cjwatson: Although, that indeed contradicts the bug comments.  Hrm.
[12:34] <infinity> cjwatson: Oh!  But your test was an armv8 binary.  mdeslaur's sigbussery was armv7 on arm64.
[12:35] <infinity> cjwatson: From this, I would conclude that armv8 allows and fixes unaligned access, but v7-on-64 raises a sigbus.  Maybe.
[12:35] <infinity> Ish.
[12:35] <cjwatson> Ah, could be.  Either way it's apparently what we wanted for more reliable behaviour with phones.
[12:37] <infinity> cjwatson: If you can prove the truth of my conclusion, I think you can close Steve's bug as Fix Released By Accident.
[13:04] <xnox> Mirv, is qml working correctly on powerpc - a harmless test fails to work https://launchpad.net/ubuntu/+source/biometryd/0.0.1+16.10.20160628-0ubuntu3
=== _salem is now known as salem_
[13:37] <caribou> infinity: mdeslaur: I'm working on building statically linked pam-winbind & libnss-winbind as suggested for LP: #1584485
[13:37] <ubottu> Launchpad bug 1584485 in samba (Ubuntu) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
[13:38] <caribou> infinity: building them statically brings a bunch of crtbeginT.o: relocation R_X86_64_32 against `__TMC_END__' that seems to be fixed by using -static-libgcc
[13:38] <caribou> infinity: should I just iteratively identify each one that fails & add the flag or there is a more direct approach ?
[13:39] <Mirv> xnox: no, 32-bit powerpc has problems that are tagged with powerpc https://is.gd/9FnqIR
[13:41] <infinity> caribou: I'm not sure I have much advice, I don't tend to do much static linking.
[13:42] <caribou> infinity: well, I'll keep on the iterative approach if the number of modification is small (not many so far)
[13:43] <infinity> caribou: If you've got the time, I'd recommend trying to do it in a suitably upstreamable way, so the build can just be done with --static-winbind or some such.  We may be the first to notice the problem, but it really should bite anyone.
[13:43] <infinity> (In fact, I'd suggest that --static-winbind be the default, for that reason)
[13:44] <caribou> infinity: ok, will keep that in mind once I get something building
[13:44] <infinity> caribou: Not critical for the SRU or anything, but would be nice to push something upstream so we don't have to maintain a delta, that's all.
[13:45] <caribou> infinity: should be feasible with some waf hacking
[13:52] <infinity> caribou: It might be enough to extend the NONSHARED bit in buildtools/wafsamba/samba_deps.py to allow type BINARY and type LIBRARY, and then tweak it a bit, then one can do --nonshared-binary=nss_winbind or some such.
[13:53] <infinity> caribou: But that's my naive poke ater 5 minutes of grepping. :)
[13:53] <caribou> infinity: ok will look at that too
[13:56] <infinity> caribou: How did this end up in your lap? :P
[13:56] <caribou> infinity: took it over from a colleague
[13:57] <mdeslaur> caribou: did he quit? I'd consider quitting too if that was on my lap :)
[13:57] <caribou> mdeslaur: :D
[13:58] <caribou> mdeslaur: that's how one builds experience in build weirdiness I suppose
[13:59] <xnox> Mirv, ack. Do you want a bug open about it + upload that skips that one test on powerpc?
[13:59] <xnox> (fro biometryd)
[14:00] <infinity> xnox: Looks like they're tacking "skip tests on ppc" bugs on to that master bug as tasks.
[14:00]  * xnox looks again
[14:00] <infinity> A one-stop shop to reopen them all after the Qt bug is fixed, I guess.
[14:13] <tyhicks> ogra_, jibel: the apparmor oops was a known bug that only affected a handlful of people
[14:13] <tyhicks> ogra_, jibel: unfortunately, the apparmor package SRU is causing it to happen to a lot more people now because the update process triggers a profile reload :/
[14:14] <tyhicks> ogra_, jibel: I've duped your bug to bug #1579135 - jjohansen has a proposed fix and any testing of the kernel mentioned in comment #27 would be appreciated
[14:14] <jibel> tyhicks, so what is the plan of action?
[14:14] <ubottu> bug 1579135 in apparmor (Ubuntu) "AppArmor profile reloading causes an intermittent kernel BUG" [Critical,Incomplete] https://launchpad.net/bugs/1579135
[14:15] <jibel> tyhicks, okay, thanks
[15:11] <coreycb> arges, mind rejecting cinder and aodh from the xenial queue? I forgot the bug #.
[15:12] <arges> coreycb: rejected! *slams basketball*
[15:12] <coreycb> arges, lol, thanks
[15:20] <pitti> arges: he'll get the rebound, I'm sure :)
[16:01] <seb128> happyaron, cyphermox, looks like the network-manager-applet (1.2.0-0ubuntu2) and ubuntu3 uploads didn't get commited to git which made the 1.2.2-0ubuntu1 update revert them/drop them, we really need to sort out the nm vcses and standardize on using them...
[16:02] <cyphermox> word
[16:02] <cyphermox> just use git; that's what we agreed on
[16:02] <cyphermox> for the record, I haven't done an upload of NM in weeks
[16:02] <seb128> cyphermox, yeah, those you did in may
[16:02] <seb128> still there are missing from the vcs
[16:03] <seb128> which makes happyaron's update he handed me for sponsoring today buggy
[16:03] <seb128> happyaron, can you please fix the vcs tomorrow then I can have another look at uploading it for you
[16:05] <cyphermox> seb128: the git tree was up to date, I'm not sure what happened for stuff to be missing
[16:05] <seb128> k
[16:05] <seb128> let's see with Aron tomorrow
[16:05] <seb128> cyphermox, thanks
[16:05] <seb128> I'm sure what happened is "git"
[16:05] <seb128> :p
[16:05] <seb128> the best tool to get things screwed up it seems :-/
[16:06] <cyphermox> no
[16:06] <cyphermox> tbh it has happened a couple of times that people forget to commit or whatever
[16:06] <seb128> yeah, but you said that it was uptodate
[16:06] <seb128> so it means somebody rewrote the commit history or something
[16:07] <cyphermox> I think it's counter-productive to try to figure out who did what and where
[16:07] <cyphermox> aron will fix the git tree, things will be good
[16:08] <seb128> yeah, that was mostly joking
[16:08] <seb128> I just wanted to make sure everybody was syncing up on using the same vcs
[16:08] <cyphermox> yes
[16:08] <seb128> seems you guys are
[16:08] <seb128> so it's good
[16:08] <seb128> cyphermox, thanks
[16:08] <cyphermox> np
[16:32] <Mirv> Laney: rerunning autopkgtests with --all-proposed still broken?
[16:34] <Laney> Mirv: nope
[16:34] <Laney> i386 done, amd64 nearly
[16:34]  * Mirv finds the correct entry on the running page
[16:36] <Mirv> i386 was a pass, and seems amd64 too (qmluitests pass just visible on the running page)
[16:38] <Laney> Mirv: can you find out why the disabling didn't work and fix it please?
[16:40] <Mirv> Laney: yes, robru should be online now
[16:40] <Laney> ♥
=== JanC is now known as Guest7844
=== JanC_ is now known as JanC
[18:12] <juliank> How can I check what translation stuff was exported during the apt build? A tarball is generated, but it's not accessible; and the translation import queue does not have it either.
[18:12]  * juliank is wondering if launchpad exporting/importing of apt translation domains now works
=== beisner is now known as beisner-biab
=== beisner-biab is now known as beisner
=== salem_ is now known as _salem
=== Insight is now known as Guest18492
[22:20] <nacc> powersj: nice find on LP: #1613982, I just reviewed and rejected it :)
[22:20] <ubottu> Launchpad bug 1613982 in php-defaults (Ubuntu) "Date parsing has been fixed in 14.04, but broken in 16.04 again" [Undecided,Invalid] https://launchpad.net/bugs/1613982
[22:21] <powersj> nacc, thanks :)
[22:26] <Unit193> nacc: BTW, I think it's very cool that you're an active developer that keeps an eye out in #ubuntu too.  Thanks.
[22:28] <nacc> Unit193: thanks! i try to be -- always hard with time constraints, though :)
[22:28] <nacc> luckily i'm mostly working on release stuff, so people's complaints tend to be relevant :)