[04:47] hi [06:09] Good morning === dgadomski_ is now known as dgadomski [07:59] pip pip [08:01] Tally ho! [08:03] COME ON BARBIE LET'S GO PARTY [08:04] :D [08:14] hey willcooke Laney RAOF === alan_g is now known as alan_g|AFK [08:15] morning seb128 [08:19] hey Laney! [08:19] bonjour seb128 [08:19] hello willcooke [08:19] salut pitti, ça va ? [08:20] seb128: ça va bien, merci ! et toi ? [08:20] pitti, ça va bien aussi merci ! [08:20] hi seb128 pitti & willcooke [08:20] how are you all? [08:21] good! you? [08:21] it's september [08:21] back to school [08:21] seems so [08:21] haha [08:21] do they have that in france? [08:21] 6 week summer holiday [08:26] I think it's more than that [08:26] :-o [08:27] it starts like on july 8th [08:27] and resume on septembre 1st [08:27] we should have that [08:27] * Laney emails some people to get it arranged [08:28] :-) [08:28] k, need to reboot [08:28] why is intel becoming so crappy :-/ [08:29] :( [08:30] better [08:31] that laptop used to work perfectly fine in trusty times :-/ [08:31] now on xenial I can't switch to a vt [08:31] they are missing to start with (systemd issue?) [08:31] then when I switch back to my session I get corruption and missing textures [08:31] like launchpad icons are empty [08:31] icons are missing in random gtk uis etc [08:31] ups [08:31] launchpad->unity launcher [08:33] is there an upstream bug? [08:33] if not maybe tjaalt_on could help you file one [08:35] there is https://bugs.freedesktop.org/show_bug.cgi?id=88584 open since 2015-01 with a stack of users from different distro commenting [08:35] Freedesktop bug 88584 in Driver/intel "[ilk] Font and screen corruption in GTK+ applications" [Major,New] [08:35] but no upstream traction :-/ [08:37] the missing vt prompts is newer though [08:38] so likely another issue but I don't even know where to start to determine if that's systemd or something else [08:38] I guess I could try to switch back to upstart to compare [08:40] that upstream bug has a patch attached since april but that's not getting reviewed ... [08:40] tjaalton, ^ do you know anything you could nudge about getting it reviewed maybe? [08:47] seb128: distros are moving away from -intel [08:47] shrug [08:47] that feels like standard answer nowadays [08:48] "the code you are using is being replaced, get the new stuff when you can, meanwhile sucks to be you" [08:48] there hasn't been even a snapshot release in almost two years [08:49] :-( [08:49] everyone running a random git snapshot instead [08:49] is there still a company who cares about their users? [08:49] until recently [08:49] they do, just not on -intel [08:50] which is a one-man show [08:50] that's ridiculous [08:50] not really [08:50] they're testing everything on modesetting now [08:50] Hello [08:51] right, still reality is most of their linux users are on -intel [08:51] for a while [08:51] it's like Apple saying that they stop supporting iphone < 7 next weeks [08:51] see how it would fly with people who just bought a 6 [08:51] anyway [08:52] bottom line is that I'm going to be stucked with non working video driver if I understand correctly? [08:52] with iphone there are no options [08:53] I wonder if I should buy ati or nvidia for my next laptop [08:53] are you on xenial? [08:53] yes [08:53] so try modesetting [08:53] uninstall intel [08:53] I'm not "trying" anything [08:53] easiest way [08:53] then don't [08:53] I'm using whatever we ship to our users [08:53] 16.04.2 users will get modesetting [08:54] it's not a solution to ship a non working driver by default and tell technical enough users to go install something else and let normal user stucked on buggy software [08:54] and newer [08:54] k [08:54] so I'm waiting for that ;-) [08:54] sounds like it's not a critical issue then :) [08:55] well it's really annoying [08:55] but it's too easy to do hacks and forget about our users [08:55] I'm not doing that, I'm not hacking my box and claiming it's fixed/not an issue [08:55] so is there a lp bug? [08:56] sure [08:57] bug #1573959 for example [08:57] bug 1573959 in xserver-xorg-video-intel (Ubuntu) "On-screen text disappears after suspend" [High,Confirmed] https://launchpad.net/bugs/1573959 [08:57] how is that related? [08:57] I know there are bugs [08:58] related to what? [08:58] to ilk screen corruption [08:58] I don't know === Saviq_ is now known as Saviq [08:58] there is a bug but my awesome bar doesn't seem to have it [09:01] tjaalton, https://bugs.launchpad.net/bugs/bugtrackers/freedesktop-bugs/88584 [09:02] Error: Could not gather data from Launchpad for bug #88584 (https://launchpad.net/bugs/88584). The error has been logged [09:02] some of those are probably different issues [09:02] but there is a class of similar user visible problems [09:04] it's been like that in every release [09:04] just for different set of users [09:05] :-/ [09:05] well when I try to vt switch I get those [09:05] Sep 1 11:04:24 localhost kernel: [ 2112.025344] dell_wmi: Unknown WMI event type 0x11: 0xffd1 [09:05] Sep 1 11:04:29 localhost kernel: [ 2117.261620] [drm] stuck on render ring [09:05] Sep 1 11:04:29 localhost kernel: [ 2117.268160] [drm] GPU HANG: ecode 5:0:0x87e6fff8, in Xorg [2190], reason: Ring hung, action: reset [09:05] that's kernel or mera [09:06] mesa [09:06] k, so modesettings is not going to help? [09:06] no [09:06] :-/ [09:07] seems similar to https://bugs.freedesktop.org/show_bug.cgi?id=94002 [09:07] Freedesktop bug 94002 in DRM/Intel "[drm] GPU HANG: ecode 9:0:0x85dfbfff, in firefox [881], reason: Ring hung, action: reset" [Major,New] [09:08] you have skylake? [09:09] "Intel® Ironlake Mobile x86/MMX/SSE2" [09:09] not that then [09:10] https://bugs.freedesktop.org/show_bug.cgi?id=93311 then [09:10] Freedesktop bug 93311 in DRM/Intel "[drm] GPU HANG: ecode 5:1:0x01000000, reason: Ring hung, action: reset after resume from hibernate" [Normal,New] [09:11] dunno [09:12] try latest kernel, and if it goes away start bisecting ;) [09:12] haha [09:12] or ignore it [09:12] well, I would like to get some vt back [09:12] and being able to switch session without having to reboot after [09:13] you're asking too much ;) [09:13] I'm going to end up being one of those people buying a mac [09:13] or installing win10 and using the ubuntu command line there [09:13] :-( [09:13] that's a solid plan [09:13] wtf intel really [09:14] I wonder if nvidia or ati is any better [09:14] none of my friends run linux anymore [09:14] :-( [09:14] just the way it is [09:14] it's sad [09:14] not that the desktop is much better [09:14] sorry :) [09:15] no your fault [09:15] tjaalton, thanks and sorry for the ranting [09:16] * larsu cheers seb128 up [09:16] it's getting better even on the intel side [09:16] anyway let's reboot and try that i915.enable_rc6=0 in case that makes a difference [09:16] hey larsu ;-) [09:16] brb [09:17] Laney: hey.... So, i was wondering: is there a way to figure if systemd is running in the session or not? [09:18] cause we've some upstart stuff running which I'd like to disable [09:18] in that case [09:18] yeeeessssssssss [09:18] let me try to remember what the way we used elsewhere is [09:18] as upstart has an env var... I don't see much in systemd [09:18] I think it's [ -d "${XDG_RUNTIME_DIR}/systemd" ] [09:18] pitti: ^? [09:19] m [09:19] define "in the session' [09:19] what's easy is "running for current user" [09:19] pitti: user session [09:19] yeah [09:19] which is by and large a constant "yes" [09:20] [ /bin/true ] [09:20] better [09:20] what Laney said (${XDG_RUNTIME_DIR}/systemd) [09:20] of course there would be also a systemd dbus proxy.... which... we use, but [09:20] hi everyone! [09:20] I've vts back [09:20] ok thanks [09:20] hi larsu [09:20] and no gpu hang on vt switch [09:20] or if you care about whether you are running, then ask systemd over dbus [09:20] hey larsu! [09:20] Trevinho: but "is it being used to bring up the session", we are currently in the middle of that -- it brings up half of the session [09:20] seb128: but... that't not the linux experience™ [09:20] tjaalton, i915.enable_rc6=0 ftw :p [09:20] Trevinho: what's the actual concrete question that you want to answer? [09:21] seb128: you hacked your laptop! [09:21] seb128: works? [09:21] larsu, you are wrong, it's exactly the linux experience [09:21] haha, indeed [09:21] cool [09:21] larsu, get non working crap, need to ressort to command line hacks to get something working [09:21] pitti: i want to understand who has run unity... and so behave consequently [09:21] seb128: I only saw what you did after I wrote that ;) [09:21] Laney, yeah :-( [09:21] might as well try that other driver if you're going to do that [09:21] Trevinho: "systemctl --user is-active unity7.service", I'd say (or the equivalent D-Bus call) [09:22] since for the lockscreen we're running a different version of the panel service... And I'd love to decide what method to use to start it... [09:22] Laney, except that tjaalton said the driver wouldn't help with gpu hangs that it's kernel [09:22] larsu: how's it going? [09:22] O RLY [09:23] Laney: great! Visiting Faina in Dubai right now :) [09:23] how are you? [09:23] Dubai, fancy! [09:23] feelin' fine [09:23] I can see a lot of chemtrails [09:23] uh oh [09:23] so probably won't be feeling fine for long [09:23] watch out [09:24] reading the documentation for meson too [09:24] * Laney misses jussi [09:24] what's dubai like? [09:24] it was quite popular at GUADEC [09:25] ya, seems to be getting some attention [09:25] Laney: I just got here last night and am sitting in a hotel room working [09:25] want to find out how to build a git submodule and then link that into the outer project [09:25] Laney: but then, my laptop and phone both still knew the wifi... yeah, it's ok. Hot. Tall buildings. A tad boring [09:26] might leave this task up to ximion ... [09:26] did he talk to jussi at guadec? [09:26] dunno [09:26] there's a meson file in this project though [09:26] I saw both of them [09:26] but I don't know if together [09:27] you know [09:27] i've never seen them in the same room at the same time [09:27] oh! I've never thought about that [09:27] I've also never seen them type into irc at the same time [09:27] oh man [09:28] jbicha, hey, I fixed versions, it was stucked on an error about diverging branch, did you uncommit/push --overwrite a different version of your most recent commit? [09:28] https://github.com/mesonbuild/meson/wiki/Wrap%20dependency%20system%20manual [09:28] jbicha, I forced it back to the current trunk [09:28] I guess that I should write a meson build file for the other project to make this easy then ... [09:28] jbicha, should work on the next cron [09:28] * Laney is being forced to learn too much stuff! [09:29] Laney: by the chemtrails? [09:30] they do look like they spell out "Satoris" [09:30] haha === alan_g|AFK is now known as alan_g [09:55] pitti: there could be still a case where an user disabled systemd in session, and then we want things to work as it used to be in upstart? [09:57] like... disabling the xdg_data dirs not to include the systemd upstart or... [09:57] I don't know... [09:58] Trevinho: yes, it should work with upstart or just plain gnome-session too, if possible [09:58] mhmh... [09:58] Trevinho: oh, is that for deciding whether you send an initctl emit or systemctl start for triggering screensaver or similar? [09:58] pitti: ok since I've the situation where I would like to manage things with the proper runnner [09:58] pitti: yes, for example.. [09:58] pitti: or... the unity script [09:59] which right now allows to restar unity manually or with upstart... [09:59] Trevinho: if you want a cheaper way, you can check /proc/self/cgroup [09:59] in teh case someone started unity manually and wanted to restart it with systemd, the script support starting it... but what should I pick? Upstart or systemd? [10:00] if "unity7.service" appears in the name=systemd line (or really, anywhere in the file), it's managed inside a unit [10:01] Trevinho: in that caes, why would that someone not just run systemctl --user start unity7 ? [10:01] mh, not bad... if it's in upstart instead... there's not much other way [10:01] pitti: since there are so many people which use the "unity" script to restart... So, in that case I want to use the proper runner [10:01] pitti: however I think that parsing the XDG dirs for the systemd is enough at script level, isn't it? [10:01] or... that would change eventuall? [10:01] y* [10:02] Trevinho: if that's just for the script, then performance doesn't matter, and you can certainly use systemctl --is-active? [10:02] Trevinho: you mean testing for XDG_RUNTIME_DIR/systemd? that's pretty much a constant yes, so that won't tell you much [10:02] (since vivid) [10:03] pitti: mh ok... So if that is there, then we're sure that the user has enabled systemd in session... and thus we consider it the primary choice... right? [10:03] Trevinho: so I'd say, start it with systemd if "systemctl --user is-enabled unity7.service", otherwise the old way [10:03] (since unity has support for it) [10:03] err, wait, we might not explicitly enable it but pull it in via ubuntu-session.service [10:03] yeah, that's the thing :-) [10:03] Trevinho: can you even stop unity7? I thought you wanted to make it a Requires=, not just a Wants= [10:03] but, well having the xdg dir is enough [10:03] then, if you stop unity, your entire session will stop [10:04] (so maybe a Wants= is better after all, if you want to support restarting; and I think it's usually sufficient too) [10:04] pitti: that's not happening on crash, right? [10:04] pitti: yeah, right now it's a requires btw [10:04] Trevinho: what is "right now"? [10:04] restarting has to be suported, yeah... [10:04] it's not unit-ified in yakkety, and in our staging git it's a wants [10:04] right now.. means what's I'm landing :) [10:04] a [10:04] "ah" [10:05] Trevinho: so yes, I'd say make it a wants, then you can stop and restart it [10:05] gnome-session, terminals etc. will continue to run [10:05] and Restart=on-failure will make it auto-restart on a crash [10:05] I mean, it's fine if it would crash the session on manual crash, but I want it to restart too [10:05] (while still allowing you to stop it cleanly) [10:06] yeah, I think that's better... people uses to restart unity sometimes... So I'd prefer not to kill the session in that case [10:06] agreed [10:07] although... it would be nice to crash in case this happens during lockscreen :-) [10:07] but... not sure I can achieve that [10:07] Trevinho: pretty much the only thing that should be "required" IMHO is gnome-session.service === hikiko is now known as hikiko|ln [10:08] I mean when unity-screen-locked.target is active, it would be nice that if unity gets killed, the whole session crashes [10:08] Trevinho: I'm not entirely sure what you mean, but if you mean "kill the session if unity crashes while being locked" -> units can have an OnFailure= action which could check the state and do stuff [10:08] Trevinho: ah, that can be done [10:08] maybe that needs some more units [10:09] Trevinho: unity-screen-locked.target Requires=unity7.service, and make graphical-session.target go down if unity-screen-locked.target stops (need to think about how this looks like) [10:10] pitti: ah, good.... I'm understanding how to do the first two parts, less in how to make graphical session go down [10:11] yeah, the latter is a bit tricky [10:12] Trevinho: I think what we can do is to make unity-screen-locked.target Requires=Requires=unity7.service and OnFailure=unity-crash.service which Conflicts=graphical-session.target [10:12] Trevinho: but this needs some experimentatino first, maybe let's land this in a separate step [10:13] pitti: yeah, sure [10:13] unity-screen-locked.target Requires=Requires=unity7.service can still be done now thoug, right? There's no problem with this [10:13] except the obvious duplicate Requires= :) [10:13] sure [10:14] Trevinho: yes, I think that's semantically correct by itself [10:14] if the screen lock is implemented in unity7 [10:14] also wondering if the panel-service in locked mode is a requirements or a wants [10:14] pitti: yeah, it is.. [10:15] or.......... well, sometimes it fallback to gnome screensaver, but this won't affect this side of things [10:56] hmmm, I wonder "libreoffice-core" has "Breaks: libreoffice-gnome (<< ${binary:Version})" (but no Conflicts: ) and libreoffice-gnome has "Depends: libreoffice-core (= ${binary-Version)". the upgrade failed with "errors encountered while processing libreoffice-gnome", however a follow-up "apt-get upgrade" complains about the relations mentions above, however "apt-get upgrade -f" is fine and upgrades libreoffice-gnome just fine. [10:59] Sweet5hark1, there are some things missing on libreoffice-gnome === hikiko|ln is now known as hikiko [11:04] term.log just has "will deconfig libreoffice-gnome, would be broken by libreoffice-core", which isnt a problem per se. Id assume adding a "Conflicts: libreoffice-core (<= 1:5.2.0-0ubuntu2)" would help (as would having a C/R: libreoffice-gtk (<= 1:5.2.0-0ubuntu2) instead of << -- but Im still not entirely clear what goes wrong here. [11:13] * Sweet5hark1 grumbles something about libreoffice-core just doing a "break" instead of a C/R with earlier versions of any binary falling out of the libreoffice is just a maintainer circlejerk. there is absolutely no point in ever allowing binaries from different builds on the same system. [11:57] Sweet5hark1, mumbling around is not asking [11:59] Sweet5hark1, in case you want to ignore more suggestions https://paste.debian.net/plain/800852 [12:06] ricotz: im not aware I ignored that, but maybe sending patches by mail is preferable as things get lost on IRC anyway? [12:07] ricotz: also that patch it pretty useless without context (no line count for patching a 3000? line control file) ... [12:08] Sweet5hark1, haven't sent your this, but I guess I was pretty clear regarding the packagekit stuff [12:08] in control.in at libreoffice-gnome [12:09] I can't provide you a properly authored patch with a packaging repo [12:14] ricotz: yeah so is the nature of merge conflicts. [12:15] seb128: yes, I had a typo in a commit so I rewrote history (for versions) :( [12:15] jbicha, k, well that's what make it stop working ... to know for next time, the auto-updater doesn't use --force so it was hitting an error [12:15] Sweet5hark1, I didn't argued about the merge conflict [12:16] what made it* [12:16] it's fixed now === JanC is now known as Guest23252 === JanC_ is now known as JanC [12:54] good morning, team! [13:03] hey desrt! [14:01] Ugh. Updating w->y yesterday was a mistake. [14:04] lol. [14:04] at least you're not travelling :) [14:07] that's not a supported upgrade path [14:07] you should go through xenial [14:08] what error did you get? [14:08] happyaron, hey, is there any news from those nm/nma updates? [14:08] that's the nice thing about debian: there are never any upgrades :D [14:08] lol [14:13] seb128, report from happyaron this morning was that sponsorship should be up today [14:14] I meant x->y. Sorry. tetex-doc and tetex-math-extra, apt and apt-utils file collisions. libboost-dev depending on nonexistant virtual pkg. libaccount and ubuntu-system-settings-online-accounts some problems. some libmedia conflict. [14:14] Others that scrolled off top of buffer. [14:15] urg [14:15] did you report those bugs? [14:15] willcooke, k, thanks [14:15] qengho, willcooke, and what's the status of the new api keys? [14:15] At the apt failure, I didn't trust state. [14:16] seb128: I'll see what I can reproduce from /var/log/apt/ [14:16] k [14:16] bah, intel bug is back, can't see any text, brb [14:18] tjaalton, where do I find that new intel driver replacement? [14:19] seb128: what do you mean? it's built with the server [14:19] should I just uninstall intel then? [14:19] to try it [14:19] just uninstall intel and it'll get used [14:19] k [14:19] thanks [14:20] in yakkety the server is patched to not load intel except very old gpus [14:20] +on [14:21] I'm on xenial [14:21] right, just saying [14:32] willcooke: I just added you to the call, but we're meeting with Saviq and kgunn on https://hangouts.google.com/hangouts/_/canonical.com/michael-hall? [14:32] mhall119, erm. k. One moment, I'm in the middle of some stuff [15:39] seb128: please have a look at xenial branch of nma for SRU when you have time, :) [15:40] happyaron, k, yakkety as well? (that needs to be updated first before a SRU) [15:40] yakkety is already uploaded [15:41] gotta merge 1.2.4 very soon, though [15:44] hum [15:44] let me look to git [15:44] I though we would go directly for 1.2.4 [15:45] ok, then would be next morning [15:46] do you think we should not go for the new version directly for some reason? [15:46] it's only some more segfault fixes [15:46] no other changes [15:47] no, just meant 1.2.4 can be done quicker for xenial [15:49] I'm asking because you updated git to SRU the previous version [15:49] so maybe you prefer that to going to the current one for some reason? [15:52] just because it's tested, but I agree 1.2.4 is safe [15:52] so updating to it now (looks easy enough [16:08] seb128: mind to check again? both x- and y- this time, :) [16:11] happyaron, looks good, going to review a bit more before uploading ... can you update the bug tomorrow to link to some of the segfaults in should fix? like a few e.u.c urls maybe as testcase, also need to update the version referenced in the description [16:11] no need to do that today, it's already late for you [16:11] the SRU team is probably not going to review that today anyway [16:11] ok [16:12] thanks [16:17] happyaron, would be nice to reference some of the bugs in the changelog as well [16:58] is the ubiquity slideshow broken in the 16.10 images? [16:59] I'm installing in a virtualmachine and it's not showing anything [17:09] indeed [17:09] it looks like it broke with the new webkit2gtk [17:09] which jbicha synced, so hopefully he can look [17:10] hmm? I lost power from tropical storm hermine [17:10] slideshow in ubiquity is broken with new webkit [17:11] you can test it by installing ubiquity and moving the start_slideshow() Gtk.main() block up below self.live_installer_show() in gtk_ui.py and then running 'ubiquity gtk_ui' [17:11] got to go, see you later [17:15] happyaron, uploaded to yakkety after tweaking the changelog to include some bugs references [17:30] thanks seb128 happyaron [17:30] off now, night all [17:49] seb128, sil2100, robru - any idea why ubuntu-touch depends on particular python-gnupg? [17:50] known gnupg 2.1 breaks? [17:50] i have no idea [18:13] xnox: not sure, possibly anyway it's no longer valid === sabdfl_ is now known as sabdfl [19:20] ricotz, any idea what's going on with https://launchpadlibrarian.net/281964460/buildlog_ubuntu-yakkety-amd64.firefox_50.0~a2~hg20160831r332986-0ubuntu1~umd1_BUILDING.txt.gz ? [19:29] chrisccoulson, I would assume the "he" translation contains an invalid string? [19:32] chrisccoulson, I would assume the "he" translation contains an invalid string? [20:34] desrt: GTK 3.22 is the start of the last stable 3.x series? [20:34] I wish we had known that a few weeks ago, might have done GTK 3.22 for yakkety [20:51] I doubt it? [21:07] desrt, was the proposed numbering scheme approved? [21:10] sil2100, i don't think python-gnupg is at all at fault here. At the moment in yakkety chroot "apt install ubuntu-touch" fails on amd64 [22:30] xnox: I have a fix for that already [22:31] xnox: no worries [22:31] Let me give you the silo number [22:31] ah [22:31] xnox: don't worry about touch images, I keep looking at the failures when I have a moment [22:31] xnox: https://requests.ci-train.ubuntu.com/#/ticket/1895 <- the address-book-app change here [22:32] xnox: I already told slangasek I'm working on it so that no one duplicates work [22:32] sil2100, not concerned about touch, or touch images per-se. [22:32]