[04:38] <xnox> sarnold, thanks my vps with irc bouncer had a hickup
[07:09] <yellabs-r2> hello , good morning
[07:09] <yellabs-r2> this is just a quick flyby , i guess its known that zenity is broken on ubuntu 16.04 ?
[07:10] <yellabs-r2> it spits out an error message : Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[07:10] <sarnold> please file bugs, what's obvious to users may not be obvious to us
[07:10] <yellabs-r2> i think its an debian issue ( or zenity )
[07:11] <yellabs-r2> there are lots of file bugs ,  and i know your time is precious
[07:12] <yellabs-r2> you can test and see it yourself
[07:12] <yellabs-r2> open terminal and type zenity --info ( if you have a ubuntu desktop )
[07:12] <RAOF> yellabs-r2: That's not actually an error; what is the problem you're seeing?
[07:13] <sarnold> that's the thing, i, personally, have no idea what zenity -is- :) if you a file a bug, someone who knows what it is might see the bug :)
[07:13] <yellabs-r2> Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
[07:13] <yellabs-r2> try zenity --info from terminal ( on ubuntu desktop 16.04 or up )
[07:14] <yellabs-r2> sarnold , i understand ;)
[07:14] <RAOF> yellabs-r2: Again, that's not actually an error :)
[07:14] <Unit193> sarnold: IIRC, makes shiny GUI dialog boxes pretty easily.
[07:14] <RAOF> yellabs-r2: That's a warning, which is entirely harmless.
[07:15] <sarnold> Unit193: oh, like whiptail but .. with gtk dialogs :)
[07:15] <yellabs-r2> its not nice to see , when running a script , can we avoid such warning ?
[07:18] <RAOF> yellabs-r2: You could patch zenity to not use a GtkDialog.
[07:18] <yellabs-r2> okey i will do that, thanks for your time
[07:18] <yellabs-r2> keep up the good work !
[07:37] <tvoss> xnox, o/
[08:22] <jtaylor> hm does clang++ work for anyone in xenial?
[08:22] <jtaylor> it seems to search for stuff in the wrong folders
[08:34] <juliank> doko: Could APT or qapt (?) be having a tiny ABI break on ppc64el and s390x? I synced apt 1.3~pre4 yesterday, and now the libqapt tests fail with abi-compliance-checker exiting with 6. Ideas?
[08:37] <juliank> I do see some symbol changes in APT;  but with all the templates involved, that's not out of the ordinary
[08:41] <doko> juliank, see https://lists.debian.org/debian-release/2016/08/msg00038.html, you probably hit https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00314.html when using template member functions.
[08:41] <doko> if yes, then please do an abi bump
[08:44] <juliank> doko: AFAICT from dpkg-gensymbols, there are no missing cxx11 symbols. The only cxx11 mentioned in the negative string is part of __cxx11::basic_string
[08:45] <doko> juliank, it's not about missing symbols, it's about a missing __cxx11 in some symbols
[08:54] <Laney> juliank: do you know about https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/a/apport/20160805_024013@/log.gz ?
[08:55] <juliank> doko: Yes, I'm looking at it
[08:55] <juliank> ehm, Laney
[08:55] <Laney> <3
[08:55] <Laney> or ♥ if you prefer
[08:56] <juliank> Laney: It might be related to Dir::State::Status not being absolute /var/lib/dpkg/status anymore, but being automatically detected dependening on Dir::State
[08:56]  * juliank wonders how much ~pre4 will break
[08:58] <juliank> Laney: But on the other hand, the python-apt rootdir option already sets that itself...
[08:58] <juliank> So I'm a bit confused
[09:05] <juliank> Laney: Do you have a way to run the apport autopkgtest locally (I have not set up autopkgtest yet, and am basically doing blind test suite fixing ...) - It might be as simple as https://paste.ubuntu.com/22292870/
[09:06]  * juliank would have run the test directly, but they require root
[09:07] <juliank> Hmm, it seems I can easily build that test environ
[09:09] <tsdgeos> guys, i'm getting "GPG error: http://security.ubuntu.com/ubuntu yakkety-security InRelease: At least one invalid signature was encountered."
[09:09] <tsdgeos> is that known or something?
[09:09] <tsdgeos> or am i being hijacked in my dns/http traffic?
[09:12] <Laney> juliank: I usually use "adt-buildvm-ubuntu-cloud -r yakkety" to make a qemuable image you can pass to adt
[09:13] <Laney> probably pitti would tell me that's the 2014 way of doing it, but he's not here ...
[09:17] <juliank> Laney: I tried that and it severely hangs my machine :/
[09:17] <juliank> Let's try again without chrome running...
[09:20] <juliank> Laney: It seems autopkgtest qemu uses up a lot of space in /tmp, thus leading to memory pressure, as that's a tmpfs
[09:21] <Laney> does it respect TMPDIR?
[09:21] <LocutusOfBorg> jtaylor, for some particular projects it is not working
[09:21] <LocutusOfBorg> you are right
[09:21] <LocutusOfBorg> but in general, it works
[09:21] <LocutusOfBorg> and BTW you didn't say version and project
[09:22] <Laney> I actually used to do that the other way around, set TMPDIR to a tmpfs somewhere else as for me /tmp is not one but I've got enough ram
[09:22] <Laney> I never checked it didn't leak stuff into /tmp though
[09:24] <juliank> Laney: It creates some overlay in tmp, I hope I fixed that now
[09:24] <Laney> you can also use schroot, but not sure if that's good enough for apport
[09:29] <juliank> Laney: I'm setting up an lxc in parallel
[09:39] <Laney> mardy: hey... any idea what this "Web Authentication for Google" webview I started getting this morning is about? :)
[09:39] <Laney> unity7 yakkety
[09:47] <jtaylor> LocutusOfBorg: I mean a simple file containing only main and including cstdio
[09:47] <jtaylor> LocutusOfBorg: or finding libstdc++
[09:47] <jtaylor> though I'm on an upgraded system so the folders might be a bit messier than they should
[09:55] <LocutusOfBorg> bug clang version?
[09:55] <LocutusOfBorg> s/bug/but
[09:56] <LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1372062
[09:58] <Laney> juliank: I've got a VM where it fails if you want access
[10:00] <jtaylor> LocutusOfBorg: 3.8
[10:02] <LocutusOfBorg> oh :(
[10:02] <LocutusOfBorg> from updates?
[10:03] <jtaylor> yes
[10:05] <juliank> Laney: autopkgtest works now, setup is a bit annoying, though ...
[10:06] <Laney> I only did the vm thing, that's easy enough
[10:07] <mardy> Laney: could be that both the access token and refresh token have expired
[10:08] <mardy> Laney: if you log in, please pay attention to which app is requesting access in the google webview
[10:10] <Laney> mardy: I mean that it's just a dialog asking for my credentials, but it doesn't tell me why it wants them
[10:10] <Laney> you think I should log in?
[10:10] <mardy> Laney: no, wait
[10:10] <mardy> Laney: can you reproduce it at will?
[10:10] <Laney> well, it happened the two times I've logged in today
[10:11] <Laney> I think I set some environment variables for signon-ui debugging before
[10:11] <mardy> Laney: can you paste the syslog somewhere?
[10:12] <Laney> mardy: is 'grep signon' okay?
[10:14] <Laney> mardy: https://paste.debian.net/787027
[10:16] <mardy> Laney: should be ok, yes
[10:24] <mardy> Laney: unfortunately the signond log doesn't tell me much about who the requestor is... do you know of a way to set an environment variable which will be visible to processes auto-started by dbus?
[10:27] <Laney> mardy: sure, I can stuff something into systemd
[10:28] <juliank> Laney: I uninstalled libpam-tmpdir and can now run autopkgtests in schroot - much faster than qemu :D
[10:28] <mardy> Laney: this would help: SSOUI_LOGGING_LEVEL=2
[10:36] <Laney> mardy: https://paste.ubuntu.com/22298856/ is that more useful?
[10:41] <mardy> Laney: and you have the same dialog visible?
[10:43] <Laney> yep
[10:45] <mardy> Laney: and xkill tells you that's signon-ui? can you also check the pid please?
[10:45] <Laney> mardy: what process needs that env var
[10:45] <Laney> ?
[10:45] <Laney> signond didn't get killed when I logged out so it doesn't have it
[10:45] <mardy> Laney: signon-ui
[10:46] <Laney> it's definitely signon-ui
[10:46] <Laney> and the window's process has the environment variable set
[10:46] <mardy> Laney: pid 7936?
[10:46] <Laney> 17220
[10:46] <mardy> uh
[10:46] <Laney> not mentioned in syslog at all
[10:46] <Laney> but that's the pid of signon-ui
[10:47] <mardy> Laney: do you also have another signon-ui as pid 7936?
[10:47] <Laney> that's the dbus-daemon
[10:47] <mardy> ah right
[10:47] <Laney> aha
[10:48] <Laney> that makes sense
[10:49] <juliank> Laney: Fixed in -0ubuntu5
[10:50] <juliank> Now there's only the weird abi-compliance-checker issue in qapt to be fixed
[10:50] <juliank> Unfortunately, there is no output at all
[10:51] <juliank> which makes it hard to debug what exactly it is complaining about...
[10:51] <doko> juliank, maybe wait for xnox, there are similar issues, e,g, in gnupgpp autopkg tests
[10:52] <xnox> well acc is easy enough to run by hand.
[10:52] <juliank> doko: Mmh, OK. AFAICS, it errors out when dumping the ABI, not when comparing it...
[10:52] <xnox> i guess it should be more verbose.
[10:52] <juliank> That is, "abi-compliance-checker -q -l libqapt-dev -v1 3.0.2-0ubuntu3 -dump debian/libqapt-dev.acc -dump-path debian/libqapt-dev/usr/lib/s390x-linux-gnu/dh-acc/libqapt-dev_3.0.2-0ubuntu3.abi.tar.gz returned exit code 6"
[10:54] <Laney> juliank: why the host's status file?
[10:54] <mardy> Laney: it's very weird, the only request signon-ui gets (grep for queryDialog in the log) is for a web-based authentication, and that's handled opening an oxide webview, not a username/password dialog
[10:54] <juliank> Laney: Well, the chroot has no status file, and that was the previous default for Dir::State::Status, so it's the obvious fix to return it to old APT defaults where it worked ...
[10:55] <juliank> Laney: I don't know enough about apport to know why it uses the host status file there, but I guess it does not matter anyway.
[10:56] <juliank> Laney: Once pitti reappears he can rebuild it however he wants :D
[10:56] <xnox> tvoss, where are you hitting the issue? as far as i can tell we don't ship gmock in ubuntu archive....
[10:57] <xnox> and gtest package in ubuntu doessn't gmock
[10:57] <tvoss> xnox, sorry, it's google-mock and an upgrade this morning brought in a fixed google-mock to y
[10:57] <tvoss> xnox, sorry for looking into it, let me mark the bug as invalid
[10:57] <tvoss> the one against gtest that is
[10:57] <xnox> ah
[10:57] <xnox> well, it needs changing from gtest to google-mock
[10:58] <xnox> i'll fix that up
[10:58] <xnox> everything changed names upstream now
[10:59] <juliank> xnox: The problem with running acc manually is that it only fails on ppc64el and s390x
[10:59] <juliank> xnox: ...
[10:59] <xnox> lol =)
[10:59]  * xnox shall fix that
[11:00] <xnox> tvoss, can't fix gtest cause that fails with g++-6, even upstream.
[11:00]  * xnox should suggest to smr to package googletest as a new source package with new googletest and googlemock combined
[11:01] <xnox> tvoss, Laney fixed everything already?! =) so i should ignore this
[11:02] <xnox> tvoss, now i understand what you mean.
[11:08] <Laney> xnox: wat
[11:08] <Laney> mardy: it is a webview
[11:08] <Laney> sorry, I must have forgotten to say that
[11:09] <Laney> xnox: the maintainer of google-mock emailed me asking if I wanted to become the maintainer after I NMUed it
[11:09] <Laney> "erm, thanks but no thanks"
[11:09] <mardy> Laney: ah, ok, then it's called from pid 8346
[11:10] <Laney> mardy: e-d-s
[11:10] <mardy> Laney: and if you log in, google should tell you the name of the app authenticating
[11:10] <xnox> Laney, well google-mock and gtest got merged into googletest upstream, and gtest is maintainer by smr.
[11:10] <xnox> I'd happy to take the lot into pkg-boost team =)
[11:10] <Laney> xnox: lalala
[11:10] <Laney> you go do that
[11:10] <xnox> and give Fredrik access rights
[11:10]  * Laney doesn't want to maintain more weird things
[11:11]  * juliank is also in the process of porting APT from the archaic 1998 build system to cmake ...
[11:11] <Laney> mardy: so the problem is that e-d-s requesting authentication doesn't tell me that until after I authenticate
[11:11] <Laney> so I don't know why I'm giving my password
[11:11] <mardy> Laney: but did it appear out of nowhere? usually these requests get queued and an OSD notification is sent
[11:11] <Laney> the webview appears when I log in
[11:12] <Laney> there might be an OSD too, but those are transient
[11:12] <Laney> I didn't notice
[11:12] <Laney> and I definitely did see the notifications before, but never this dialog
[11:12] <Laney> so something changed
[11:13] <mardy> Laney: anyway it's wrong, this screen should not appear; you should see a notification, then once you open system-settings -> online-accounts, it would tell you that the google account needs authentication
[11:13] <mardy> Laney: so please file a bug
[11:13] <Laney> okay
[11:13] <mardy> Laney: maybe the OSD cannot be sent (maybe the D-Bus service is not up yet?)
[11:13] <Laney> who wins the bug?
[11:13] <mardy> Laney: signon-ui
[11:14] <Laney> signon-ui for now
[11:14] <Laney> thanks for the help!
[11:14] <mardy> Laney: the fact that it appears at login also hints that it might be because the OSD is not up yet
[11:14] <Laney> notify-osd is D-Bus activated
[11:15] <mardy> mmmm
[11:15] <Laney> could be that the API call fails or something
[11:16] <Laney> is the dialog a fallback in that casE?
[11:16] <mardy> Laney: can you just dismiss that dialog, and see if reappears some minutes later?
[11:16] <Laney> mardy: in fact it comes back straight away
[11:16] <Laney> !!!
[11:17] <mardy> Laney: it makes you feel loved, doesn't it?
[11:17] <mardy> ;-)
[11:18] <mardy> Laney: yes, it's a fallback: http://bazaar.launchpad.net/~online-accounts/signon-ui/trunk/view/head:/src/request.cpp#L133
[11:18] <mardy> Laney: in our case windowId() == 0, so skip those two ifs
[11:18] <Laney> fun
[11:19] <Laney> but I don't see "Error dispatching to indicator" in the log
[11:20] <mardy> Laney: maybe findAccount() fails, line 244
[11:21] <Laney> mmm
[11:21] <mardy> Laney: can you please paste the output of "account-console list" and then "account-console show <id of the google account>"?
[11:22] <mardy> Laney: if you have more than one google account, please show all
[11:22] <mardy> the value of parameters[SSOUI_KEY_IDENTITY] is 102, according to your logs
[11:24] <Laney> mardy: ok, I can see which one is 102
[11:24] <Laney> I should blanke out the ClientSecret right?
[11:24] <Laney> blank*
[11:27] <Laney> mardy: bug #1610206 has it all
[11:28] <mardy> Laney: thanks, looking...
[11:32] <mardy> Laney: weird, the account seems all right...
[11:34] <mardy> Laney: given that you can reproduce it easily, could you please keep a dbus-monitor running?
[11:34] <mardy> Laney: if you have the dialog open right now, please just cancel it and let it reappear
[11:38] <Laney> mardy: oh god it didn't come back
[11:38] <mardy> Laney: might be that e-d-s retries just once
[11:39] <Laney> I closed it like 5 times before
[11:39] <Laney> maybe they had stacked up
[11:39] <Laney> i'll leave it running and see if it appears
[11:39] <Laney> going to be a big dbus log
[11:39] <mardy> ok
[11:40] <doko> tvoss, is https://launchpad.net/ubuntu/+source/qtgrilo/0.0.20130610-0ubuntu4 still needed, or is this cruft?
[11:42] <xnox> juliank, doko, Mirv: http://paste.ubuntu.com/22303251/
[11:43] <juliank> eww
[11:43] <juliank> that looks nasty
[11:44] <xnox> hm, why is gcc used, instead of g++
[11:44] <tvoss> doko, I don't know, Mirv ^
[11:46] <xnox> gcc or g++ don't make a difference
[11:49] <xnox> juliank, Mirv - drop, reproducible with just "include <atomic>"
[11:52] <Mirv> doko: tvoss: I believe qtgrilo is cruft, at least it's not on images. CC: sil2100
[11:54] <Mirv> and qtgrilo is not surely the only package that should be removed. I have for example bug #1606531 which includes reminders-app, no longer published to archives.
[11:54] <Mirv> not familiar with xnox's problem
[11:55] <doko> Mirv,  sil2100: https://bugs.launchpad.net/ubuntu/+source/qtgrilo/+bug/1610219
[11:57] <doko> Mirv, hmm, I don't see any of these packages in nbs ...
[11:59] <xnox> doko, https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220
[11:59] <xnox> regression in gcc-6 since gcc 5.4
[12:09] <Mirv> doko: they are in yakkety-proposed at the moment, the sources like qtquickcontrols-opensource-src and qtdeclarative-opensource-src
[12:21] <sil2100> grilo grilo, hmm, yeah, need to look into that but I guess it's not a thing anymore
[12:21] <Laney> zap it
[12:43] <jbicha> http://reqorts.qa.ubuntu.com/reports/sponsoring/ is up-to-date but the subpages like motu.html are 2 weeks old
[14:41] <seb128> doko, thanks for sponsoring those totem/rhythmbox updates, do you plan to merge in the vcs as well?
[15:18] <seb128> slangasek, just a fyi I fixed the samba build on yakkety (and I'm going to backport a bugfix for a gvfs/cpu use issue)
[15:36] <slangasek> seb128: ok, IIRC I did that merge to un-break the gnutls delta, so do what you need to :)
[15:38] <seb128> slangasek, the issue was a buggy ldb merge, once that fixed samba builds
[15:39] <seb128> anyway sorted out
[15:39] <seb128> I was just letting you know in case you still had it on some todolist
[15:40] <slangasek> seb128: nope, I summarily deleted all of the lp emails telling me about the build failures caused by people hitting the retry button ;-)
[15:40] <seb128> hehe
[16:28] <nacc> bdmurray: as to the phasing of my virt-manager update; afaict, two of the errors are not new in my version (https://errors.ubuntu.com/problem/d742c4e2a061c34261f126539298c430d849d96d and https://errors.ubuntu.com/problem/28048ddac92361b73296c899966474adfef41982). One is new (https://errors.ubuntu.com/problem/00ae98e11d3c5f53ee5e58adb9811d3132176af4), but I'm not sure how my change could lead to that,
[16:28] <nacc> as functionally it only changes virtinst.
[16:34] <bdmurray> nacc: okay, looking
[16:35] <nacc> bdmurray: thanks, I'm reviewing the new one in more depth, but it seems unrelated to me.
[16:40] <cyphermox> juliank: is there a code branch in LP for the ubuntu diff for apt? or do you just upload directly?
[16:41] <juliank> cyphermox: There is no apt diff anymore (again), that was just some temporary direct uploads to try to get the autopkgtests working again.
[16:42] <juliank> cyphermox: I initially only planned one upload, but things got a bit out of control ...
[16:42]  * juliank hought: oh hey, I pull the tarball and just apply my diffs, and upload; and everything will start working
[16:43] <nacc> bdmurray: ah and the new report was a fresh install; so may be a false positive?
[16:43] <juliank> cyphermox: why do you ask?
[16:44] <bdmurray> nacc: Okay, I've overridden the increased rate so it should continue phasing.
[16:45] <nacc> bdmurray: thank you very much
[16:45] <cyphermox> juliank: I'd like to get code review for a change to the apport magic for failed package installs
[16:46] <cyphermox> juliank: somehow it doesn't feel like it applies to Debian so much
[16:46] <bdmurray> cyphermox: which magic?
[16:46] <juliank> cyphermox: I see. Well, we still keep it all in one place
[16:47] <juliank> cyphermox: Feel free to open a pull request for https://github.com/Debian/apt, https://github.com/julian-klode/apt ; or send a patch
[16:47] <cyphermox> bdmurray: making sure we can get the proper /var/log/apt/term.log when package installs fail in the uniquity environment
[16:48] <bdmurray> cyphermox: is that part of apt?
[16:48] <juliank> I can merge pull requests *really* fast
[16:48] <cyphermox> yeah, the code that writes the apport report is directly in apt
[16:49]  * bdmurray rereads package install fails in ubiquity
[16:49] <juliank> cyphermox: I plan for a new APT release next week (final 1.3 pre-release)
[16:50] <juliank> That will get a ton of crazy installation ordering changes...
[16:50] <juliank> Huge potential to reduce issues and improve speed
[16:51] <juliank> and socks5 proxy support
[16:51] <juliank> and tor support
[16:51] <juliank> (not that I did any of those)
[16:52] <cyphermox> bdmurray: basically, we noticed that some shim-signed failures to install in the live image would include the live session's /var/log/apt/term.log rather than the one in /target... at least that's how things look to me, given that there are important bits missing
[16:52] <cyphermox> juliank: essentially: http://paste.ubuntu.com/22330893/
[16:53] <cyphermox> it's very crude :)
[16:53] <juliank> Yes. very.
[16:53] <cyphermox> :)
[16:55] <juliank> cyphermox: But looks OK. Put it in a git commit and push it somewhere/open a pull request/send in an email
[16:55] <cyphermox> ack
[16:55] <cyphermox> I'm going to do a bit more testing on it and send you a pull request
[17:07] <nacc> slangasek: i've gotten some feedback that dep3changelog using 'Closes LP: #' is not correct (that it's intended for Debian bugs only). Given you wrote dep3changelog, do you have a strong opinion?
[17:10] <slangasek> nacc: feedback from whom?
[17:10] <nacc> slangasek: rbasak mostly :)
[17:10] <slangasek> and "intended for Debian bugs only" - what part?
[17:11] <nacc> slangasek: i think rbasak means that 'Closes' generally is for Debian bugs only? So 'Closes LP: #...' is confusing? Rather than just using 'LP: #...' or '(LP: #...)'
[17:12] <slangasek> ok
[17:13] <slangasek> so the only part I think is confusing is that we currently write 'Closes: LP: ####'
[17:13] <slangasek> the extra colon looks weird
[17:13] <slangasek> but 'Closes LP: ####' has always been in use, even if not by everyone
[17:13] <nacc> slangasek: and actually dep3changelog for only a lpbug doesn't insert the extra colon
[17:14] <slangasek> ah? then I think it all works as intended ;)
[17:14] <nacc> https://code.launchpad.net/~nacc/ubuntu/+source/qemu/+git/qemu/+merge/300114, the diff comments, is specifically what I mean
[17:14] <nacc> he's mentioned it a few times elsewhere as well
[17:14] <nacc> just trying to be correct and consistent
[17:28] <rbasak> Hmm. I've never seen "Closes: LP:" nor "Closes LP:" used before. But if slangasek says it's normal, then I suppose that's OK :)
[17:28] <nacc> rbasak: sorry, i should probably have directed that to you -- I was just reviewing what dep3changelog did internally and realized slangasek owned it
[17:28] <rbasak> I favour tight consistency though. Easier to ramp up newcomers then.
[17:28] <rbasak> nacc: np. I didn't realise that was coming from a tool.
[17:29] <nacc> rbasak: agreed. I just think using a tool is the most consistent (to me)
[17:29] <nacc> rbasak: because now, I don't handwrite my changelog entries from my patches, i just run `dep3changelog` on the patches
[17:29] <rbasak> Agreed - if it needs fixing, the tool should be fixed. Otherwise using its default output should always be OK. I just didn't know about the tool, and had never seen that style used anywhere else.
[17:30] <rbasak> I would prefer a single style to be agreed upon as the standard to teach newcomers, and then have every tool use it.
[17:31] <nacc> 100% agreed
[17:35] <jbicha> it's more common to omit the Closes for LP bugs
[17:49] <juliank> What's goingon in -fstack-protector-strong?
[17:49] <juliank> https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/1608744
[17:50] <juliank> stupid copy paste pasted wrong thing ...
[17:50] <juliank> Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
[17:50] <juliank> gcc: error: unrecognized command line option ‘-fstack-protector-strong’
[17:51] <juliank> Ah, I see. Somehow the system compiles the module for the kernel with gcc 4.8
[17:51] <juliank> but that's trusty, so it makes sense
[19:50] <Unit193> In the firefox changelog: remove ebian/patches/webapprt-support-for-langpacks.patch  I was amused. :)
[21:28] <nacc> rbasak: i wonder if at least part of the solution to LP: #1597414 is to just trust the publishing history unconditionally. If it says the version goes backward, let it, but warn?
[21:28] <nacc> or maybe we could add a flag?