=== salem_ is now known as _salem === juliank_ is now known as juliank === _salem is now known as salem_ === salem_ is now known as _salem [04:38] sarnold, thanks my vps with irc bouncer had a hickup [07:09] hello , good morning [07:09] this is just a quick flyby , i guess its known that zenity is broken on ubuntu 16.04 ? [07:10] it spits out an error message : Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. [07:10] please file bugs, what's obvious to users may not be obvious to us [07:10] i think its an debian issue ( or zenity ) [07:11] there are lots of file bugs , and i know your time is precious [07:12] you can test and see it yourself [07:12] open terminal and type zenity --info ( if you have a ubuntu desktop ) [07:12] yellabs-r2: That's not actually an error; what is the problem you're seeing? [07:13] 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] Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged. [07:13] try zenity --info from terminal ( on ubuntu desktop 16.04 or up ) [07:14] sarnold , i understand ;) [07:14] yellabs-r2: Again, that's not actually an error :) [07:14] sarnold: IIRC, makes shiny GUI dialog boxes pretty easily. [07:14] yellabs-r2: That's a warning, which is entirely harmless. [07:15] Unit193: oh, like whiptail but .. with gtk dialogs :) [07:15] its not nice to see , when running a script , can we avoid such warning ? [07:18] yellabs-r2: You could patch zenity to not use a GtkDialog. [07:18] okey i will do that, thanks for your time [07:18] keep up the good work ! [07:37] xnox, o/ [08:22] hm does clang++ work for anyone in xenial? [08:22] it seems to search for stuff in the wrong folders [08:34] 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] I do see some symbol changes in APT; but with all the templates involved, that's not out of the ordinary [08:41] 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] gcc.gnu.org bug 2016 in rtl-optimization "-O _AND_ -funroll_all_loops causes segfaults on PPC" [Normal,Resolved: fixed] [08:41] if yes, then please do an abi bump [08:44] 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] juliank, it's not about missing symbols, it's about a missing __cxx11 in some symbols [08:54] 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] doko: Yes, I'm looking at it [08:55] ehm, Laney [08:55] <3 [08:55] or ♥ if you prefer [08:56] 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] Laney: But on the other hand, the python-apt rootdir option already sets that itself... [08:58] So I'm a bit confused [09:05] 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] Hmm, it seems I can easily build that test environ [09:09] guys, i'm getting "GPG error: http://security.ubuntu.com/ubuntu yakkety-security InRelease: At least one invalid signature was encountered." [09:09] is that known or something? [09:09] or am i being hijacked in my dns/http traffic? [09:12] juliank: I usually use "adt-buildvm-ubuntu-cloud -r yakkety" to make a qemuable image you can pass to adt [09:13] probably pitti would tell me that's the 2014 way of doing it, but he's not here ... [09:17] Laney: I tried that and it severely hangs my machine :/ [09:17] Let's try again without chrome running... [09:20] 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] does it respect TMPDIR? [09:21] jtaylor, for some particular projects it is not working [09:21] you are right [09:21] but in general, it works [09:21] and BTW you didn't say version and project [09:22] 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] I never checked it didn't leak stuff into /tmp though [09:24] Laney: It creates some overlay in tmp, I hope I fixed that now [09:24] you can also use schroot, but not sure if that's good enough for apport [09:29] Laney: I'm setting up an lxc in parallel [09:39] mardy: hey... any idea what this "Web Authentication for Google" webview I started getting this morning is about? :) [09:39] unity7 yakkety [09:47] LocutusOfBorg: I mean a simple file containing only main and including cstdio [09:47] LocutusOfBorg: or finding libstdc++ [09:47] though I'm on an upgraded system so the folders might be a bit messier than they should [09:55] bug clang version? [09:55] s/bug/but [09:56] https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1372062 [09:56] Launchpad bug 1372062 in llvm-toolchain-3.5 (Ubuntu) "Some LLVM 3.5 headers are in wrong paths and different from llvm-3.5 installed from sources." [Undecided,Confirmed] [09:58] juliank: I've got a VM where it fails if you want access [10:00] LocutusOfBorg: 3.8 [10:02] oh :( [10:02] from updates? [10:03] yes [10:05] Laney: autopkgtest works now, setup is a bit annoying, though ... === hikiko is now known as hikiko|ln [10:06] I only did the vm thing, that's easy enough [10:07] Laney: could be that both the access token and refresh token have expired [10:08] Laney: if you log in, please pay attention to which app is requesting access in the google webview [10:10] 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] you think I should log in? [10:10] Laney: no, wait [10:10] Laney: can you reproduce it at will? [10:10] well, it happened the two times I've logged in today [10:11] I think I set some environment variables for signon-ui debugging before [10:11] Laney: can you paste the syslog somewhere? [10:12] mardy: is 'grep signon' okay? [10:14] mardy: https://paste.debian.net/787027 [10:16] Laney: should be ok, yes [10:24] 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] mardy: sure, I can stuff something into systemd [10:28] Laney: I uninstalled libpam-tmpdir and can now run autopkgtests in schroot - much faster than qemu :D [10:28] Laney: this would help: SSOUI_LOGGING_LEVEL=2 [10:36] mardy: https://paste.ubuntu.com/22298856/ is that more useful? [10:41] Laney: and you have the same dialog visible? [10:43] yep [10:45] Laney: and xkill tells you that's signon-ui? can you also check the pid please? [10:45] mardy: what process needs that env var [10:45] ? [10:45] signond didn't get killed when I logged out so it doesn't have it [10:45] Laney: signon-ui [10:46] it's definitely signon-ui [10:46] and the window's process has the environment variable set [10:46] Laney: pid 7936? [10:46] 17220 [10:46] uh [10:46] not mentioned in syslog at all [10:46] but that's the pid of signon-ui [10:47] Laney: do you also have another signon-ui as pid 7936? [10:47] that's the dbus-daemon [10:47] ah right [10:47] aha [10:48] that makes sense [10:49] Laney: Fixed in -0ubuntu5 [10:50] Now there's only the weird abi-compliance-checker issue in qapt to be fixed [10:50] Unfortunately, there is no output at all [10:51] which makes it hard to debug what exactly it is complaining about... [10:51] juliank, maybe wait for xnox, there are similar issues, e,g, in gnupgpp autopkg tests [10:52] well acc is easy enough to run by hand. [10:52] doko: Mmh, OK. AFAICS, it errors out when dumping the ABI, not when comparing it... [10:52] i guess it should be more verbose. [10:52] 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] juliank: why the host's status file? [10:54] 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] 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] 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] Laney: Once pitti reappears he can rebuild it however he wants :D [10:56] tvoss, where are you hitting the issue? as far as i can tell we don't ship gmock in ubuntu archive.... [10:57] and gtest package in ubuntu doessn't gmock [10:57] xnox, sorry, it's google-mock and an upgrade this morning brought in a fixed google-mock to y [10:57] xnox, sorry for looking into it, let me mark the bug as invalid [10:57] the one against gtest that is [10:57] ah [10:57] well, it needs changing from gtest to google-mock [10:58] i'll fix that up [10:58] everything changed names upstream now [10:59] xnox: The problem with running acc manually is that it only fails on ppc64el and s390x [10:59] xnox: ... [10:59] lol =) [10:59] * xnox shall fix that [11:00] 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 === hikiko|ln is now known as hikiko [11:01] tvoss, Laney fixed everything already?! =) so i should ignore this [11:02] tvoss, now i understand what you mean. === vrruiz_ is now known as rvr [11:08] xnox: wat [11:08] mardy: it is a webview [11:08] sorry, I must have forgotten to say that [11:09] xnox: the maintainer of google-mock emailed me asking if I wanted to become the maintainer after I NMUed it [11:09] "erm, thanks but no thanks" [11:09] Laney: ah, ok, then it's called from pid 8346 [11:10] mardy: e-d-s [11:10] Laney: and if you log in, google should tell you the name of the app authenticating [11:10] Laney, well google-mock and gtest got merged into googletest upstream, and gtest is maintainer by smr. [11:10] I'd happy to take the lot into pkg-boost team =) [11:10] xnox: lalala [11:10] you go do that [11:10] 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] mardy: so the problem is that e-d-s requesting authentication doesn't tell me that until after I authenticate [11:11] so I don't know why I'm giving my password [11:11] Laney: but did it appear out of nowhere? usually these requests get queued and an OSD notification is sent [11:11] the webview appears when I log in [11:12] there might be an OSD too, but those are transient [11:12] I didn't notice [11:12] and I definitely did see the notifications before, but never this dialog [11:12] so something changed [11:13] 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] Laney: so please file a bug [11:13] okay [11:13] Laney: maybe the OSD cannot be sent (maybe the D-Bus service is not up yet?) [11:13] who wins the bug? [11:13] Laney: signon-ui [11:14] signon-ui for now [11:14] thanks for the help! [11:14] Laney: the fact that it appears at login also hints that it might be because the OSD is not up yet [11:14] notify-osd is D-Bus activated [11:15] mmmm [11:15] could be that the API call fails or something [11:16] is the dialog a fallback in that casE? [11:16] Laney: can you just dismiss that dialog, and see if reappears some minutes later? [11:16] mardy: in fact it comes back straight away [11:16] !!! [11:17] Laney: it makes you feel loved, doesn't it? [11:17] ;-) [11:18] Laney: yes, it's a fallback: http://bazaar.launchpad.net/~online-accounts/signon-ui/trunk/view/head:/src/request.cpp#L133 [11:18] Laney: in our case windowId() == 0, so skip those two ifs [11:18] fun [11:19] but I don't see "Error dispatching to indicator" in the log [11:20] Laney: maybe findAccount() fails, line 244 [11:21] mmm [11:21] Laney: can you please paste the output of "account-console list" and then "account-console show "? [11:22] Laney: if you have more than one google account, please show all [11:22] the value of parameters[SSOUI_KEY_IDENTITY] is 102, according to your logs [11:24] mardy: ok, I can see which one is 102 [11:24] I should blanke out the ClientSecret right? [11:24] blank* [11:27] mardy: bug #1610206 has it all [11:27] bug 1610206 in signon-ui (Ubuntu) ""Web authentication for Google" WebView appears on login" [Undecided,New] https://launchpad.net/bugs/1610206 [11:28] Laney: thanks, looking... [11:32] Laney: weird, the account seems all right... [11:34] Laney: given that you can reproduce it easily, could you please keep a dbus-monitor running? [11:34] Laney: if you have the dialog open right now, please just cancel it and let it reappear [11:38] mardy: oh god it didn't come back [11:38] Laney: might be that e-d-s retries just once [11:39] I closed it like 5 times before [11:39] maybe they had stacked up [11:39] i'll leave it running and see if it appears [11:39] going to be a big dbus log [11:39] ok [11:40] tvoss, is https://launchpad.net/ubuntu/+source/qtgrilo/0.0.20130610-0ubuntu4 still needed, or is this cruft? [11:42] juliank, doko, Mirv: http://paste.ubuntu.com/22303251/ [11:43] eww [11:43] that looks nasty [11:44] hm, why is gcc used, instead of g++ [11:44] doko, I don't know, Mirv ^ [11:46] gcc or g++ don't make a difference [11:49] juliank, Mirv - drop, reproducible with just "include " [11:52] doko: tvoss: I believe qtgrilo is cruft, at least it's not on images. CC: sil2100 [11:54] 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] bug 1606531 in reminders-app (Ubuntu) "RM: transitional QML module packages" [Undecided,New] https://launchpad.net/bugs/1606531 [11:54] not familiar with xnox's problem [11:55] Mirv, sil2100: https://bugs.launchpad.net/ubuntu/+source/qtgrilo/+bug/1610219 [11:56] Launchpad bug 1610219 in qtgrilo (Ubuntu) "demote qtgrilo, not compatible with grilo-0.3" [Undecided,New] [11:57] Mirv, hmm, I don't see any of these packages in nbs ... [11:59] doko, https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1610220 [11:59] Launchpad bug 1610220 in gcc-6 (Ubuntu) "atomic header cannot be compiled into translation unit with -fkeep-inline-functions" [Undecided,New] [11:59] regression in gcc-6 since gcc 5.4 [12:09] doko: they are in yakkety-proposed at the moment, the sources like qtquickcontrols-opensource-src and qtdeclarative-opensource-src === JanC is now known as Guest20161 === JanC_ is now known as JanC [12:21] grilo grilo, hmm, yeah, need to look into that but I guess it's not a thing anymore [12:21] zap it [12:43] http://reqorts.qa.ubuntu.com/reports/sponsoring/ is up-to-date but the subpages like motu.html are 2 weeks old === _salem is now known as salem_ [14:41] doko, thanks for sponsoring those totem/rhythmbox updates, do you plan to merge in the vcs as well? [15:18] 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) === mnepton is now known as mneptok [15:36] seb128: ok, IIRC I did that merge to un-break the gnutls delta, so do what you need to :) [15:38] slangasek, the issue was a buggy ldb merge, once that fixed samba builds [15:39] anyway sorted out [15:39] I was just letting you know in case you still had it on some todolist [15:40] 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] hehe === davidcalle is now known as davidcalle|afk [16:28] 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] as functionally it only changes virtinst. [16:34] nacc: okay, looking [16:35] bdmurray: thanks, I'm reviewing the new one in more depth, but it seems unrelated to me. [16:40] juliank: is there a code branch in LP for the ubuntu diff for apt? or do you just upload directly? [16:41] 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] 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] bdmurray: ah and the new report was a fresh install; so may be a false positive? [16:43] cyphermox: why do you ask? [16:44] nacc: Okay, I've overridden the increased rate so it should continue phasing. [16:45] bdmurray: thank you very much [16:45] juliank: I'd like to get code review for a change to the apport magic for failed package installs [16:46] juliank: somehow it doesn't feel like it applies to Debian so much [16:46] cyphermox: which magic? [16:46] cyphermox: I see. Well, we still keep it all in one place [16:47] 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] bdmurray: making sure we can get the proper /var/log/apt/term.log when package installs fail in the uniquity environment [16:48] cyphermox: is that part of apt? [16:48] I can merge pull requests *really* fast [16:48] yeah, the code that writes the apport report is directly in apt [16:49] * bdmurray rereads package install fails in ubiquity [16:49] cyphermox: I plan for a new APT release next week (final 1.3 pre-release) [16:50] That will get a ton of crazy installation ordering changes... [16:50] Huge potential to reduce issues and improve speed [16:51] and socks5 proxy support [16:51] and tor support [16:51] (not that I did any of those) [16:52] 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] juliank: essentially: http://paste.ubuntu.com/22330893/ [16:53] it's very crude :) [16:53] Yes. very. [16:53] :) [16:55] cyphermox: But looks OK. Put it in a git commit and push it somewhere/open a pull request/send in an email [16:55] ack [16:55] I'm going to do a bit more testing on it and send you a pull request [17:07] 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] nacc: feedback from whom? [17:10] slangasek: rbasak mostly :) [17:10] and "intended for Debian bugs only" - what part? [17:11] 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] ok [17:13] so the only part I think is confusing is that we currently write 'Closes: LP: ####' [17:13] the extra colon looks weird [17:13] but 'Closes LP: ####' has always been in use, even if not by everyone [17:13] slangasek: and actually dep3changelog for only a lpbug doesn't insert the extra colon [17:14] ah? then I think it all works as intended ;) [17:14] https://code.launchpad.net/~nacc/ubuntu/+source/qemu/+git/qemu/+merge/300114, the diff comments, is specifically what I mean [17:14] he's mentioned it a few times elsewhere as well [17:14] just trying to be correct and consistent [17:28] 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] 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] I favour tight consistency though. Easier to ramp up newcomers then. [17:28] nacc: np. I didn't realise that was coming from a tool. [17:29] rbasak: agreed. I just think using a tool is the most consistent (to me) [17:29] rbasak: because now, I don't handwrite my changelog entries from my patches, i just run `dep3changelog` on the patches [17:29] 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] 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] 100% agreed [17:35] it's more common to omit the Closes for LP bugs [17:49] What's goingon in -fstack-protector-strong? [17:49] https://bugs.launchpad.net/ubuntu/+source/ndiswrapper/+bug/1608744 [17:50] Launchpad bug 1608744 in ndiswrapper (Ubuntu) "ndiswrapper-dkms 1.59-2: ndiswrapper kernel module failed to build" [Undecided,New] [17:50] stupid copy paste pasted wrong thing ... [17:50] Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler [17:50] gcc: error: unrecognized command line option ‘-fstack-protector-strong’ [17:51] Ah, I see. Somehow the system compiles the module for the kernel with gcc 4.8 [17:51] but that's trusty, so it makes sense [19:50] In the firefox changelog: remove ebian/patches/webapprt-support-for-langpacks.patch I was amused. :) [21:28] 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] Launchpad bug 1597414 in usd-importer "isc-dhcp cannot be imported" [Undecided,New] https://launchpad.net/bugs/1597414 [21:28] or maybe we could add a flag?