[04:55] Hi [05:44] Good morning [05:45] seb128, Laney: I simply ran out of time on Friday when I reviewed the SRU queue :) [05:45] good morning pitti! [05:45] Good morning [05:45] & desktopers [05:45] how are you? [05:45] quite fine, thanks! had a swap day yesterday, and met StevenK [05:46] we did a tour through Augsburg, and went to Munich in the afternoon to pick up my wife from work, see the English Garden, and have Bavarian dinner [05:48] schnitzel? pig knuckles? thuriginer klosse? :) [05:48] ah, nice! [05:48] welcome back pitti :) I hope travel was alright? [05:48] what is StevenK doing around there? holidays? [05:49] sarnold: yes, uneventful and on time indeed, thanks! and I mostly figured out now how to deal with jetlag [05:49] pitti: nice all around :) [05:49] seb128: yeah, his mother, sister, and him do some kind of Europe tour right now [05:49] nice [05:49] seb128: and they stay in Munich for a week [05:49] sarnold: absolutely; it was a nice sprint too [05:49] you still have summer there btw? [05:52] seb128: not really, it has been grey and a bit rainy since yesterday :/ [05:53] same here :-/ [05:53] I hope it gets better for the weekend, we want to do a rafting tour on Sunday [06:27] good morning desktop! [06:31] heeey desrt! [06:33] hello pitti [06:33] another beautiful day here :) [06:42] hey desrt! how are you? [06:42] good... doing some morning cleaning :) [06:42] * desrt is switching from debfoster to apt-mark [06:42] flexiondotorg, bug #1580382 seems like one for you ("topmenu-gtk" issue) [06:42] bug 1580382 in topmenu-gtk (Ubuntu) "/usr/bin/yelp:11:_gdk_window_has_impl:gdk_x11_window_get_xid:topmenu_monitor_set_cur_server:handle_cur_server_event:gdk_event_apply_filters" [High,New] https://launchpad.net/bugs/1580382 [06:43] flexiondotorg, I'm just pointing it out in case, unsure if that watch that source but all the reports seem to come from your flavor [06:48] desrt@humber:~$ apt-mark showmanual | wc -l [06:48] 46 [06:49] shiny [06:51] happyaron, hey, could you get a SRU/update ready for bug #1574347 (on top of the current one so we can upload once the first one goes to -updates) [06:51] bug 1574347 in network-manager (Ubuntu) "WiFi network list disappears from network manager applet" [High,Confirmed] https://launchpad.net/bugs/1574347 [07:03] seb128: work on that today [07:03] happyaron, thanks! [07:29] seb128: have time to sponsor -openconnect? https://launchpad.net/~happyaron/+archive/ubuntu/ppa/+sourcepub/6404038/+listing-archive-extra [08:03] morning! [08:05] morning Laney [08:06] what ho [08:06] 'tis misty today, almost foggy [08:08] pretty gruesome here [08:09] Rained all day yesterday, but still warm. Good for the plants thogh [08:09] though [08:09] The allotment will need some weeding I expect :) [08:10] hoe hoe hoe [08:10] \o/ [08:11] the other day I made a contraption to water underneath the cloches [08:11] wonder if that's working [08:11] happyaron, yes, on my list for this morning [08:11] hey Laney willcooke [08:11] yo seb128 [08:11] what up gangsta [08:12] I started fresh and early today, was there for pitti's "good morning"! [08:12] that's exciting [08:12] and just back from getting some coffee [08:12] hey Laney, good morning! [08:12] which was welcome after email catchups [08:12] what about you? [08:18] hi pitti! === Drac0 is now known as Guest7296 [08:19] I'm good thanks [08:19] managed to dodge the rain yesterday while on the bike [08:20] :-) [08:52] pitti, remember that usd/upower segfault? [08:52] seb128: I do, yes; on lid closing? [08:52] yes [08:52] that's a simple code reproducer [08:52] UpClient *client = NULL; [08:52] client = up_client_new (); [08:52] printf("lid is closed? %d\n", up_client_get_lid_is_closed (client)); [08:52] do that with upower down [08:52] -> segfault [08:52] I moved the upowerd binary here for testing [08:52] but some of the reports have upower taking up to a minute to start [08:53] which I guess is some lower stack issues [08:54] seb128: ah, so this crash comes even before the point when it would crash on a nonexisting lid object? or does it somehow handle that without crashing then? [08:54] so I guess calling up_client_something() lazily does the dbus connection, it's not up_client_new()? or does that return NULL? [08:54] (as client != NULL in the stack trace that I saw) [08:54] the stacktrace might be a different issue [08:55] I get a segfault with the code I just copied [08:55] up_client_new() hang for a while [08:55] then give a dbus timeout warning [08:55] and code goes on [08:55] and up_client_get_lid_is_closed() segfaults [08:55] seb128: what's the value of client? some object or NULL? [08:55] let me check the value, I think it was not null [08:56] that'd be sad indeed [08:56] if up_client_new() does block and shows a timeout, then it already does the connection and ought to return NULL [08:56] if not, we surely need to fix that [08:56] but I have a feeling that's not the whole story with the lid close crash yet [08:57] no, it's not [08:57] #0 0xb7f797ed in up_exported_daemon_get_lid_is_closed (object=0x0) [08:57] at up-daemon-generated.c:747 [08:57] #1 0xb7f7417d in up_client_get_lid_is_closed (client=0x8053f08 [UpClient]) [08:57] at up-client.c:208 [08:57] #2 0x080485f6 in main (argc=1, argv=0xbfffef34) at upower.c:8 [08:57] so client != NULL [08:57] eww [08:57] so up_client_new() returns a non null value [08:58] seb128: do you mind filing a bug about that on fd.o? will look at it ASAP [08:58] doing [08:58] thanks [08:58] so with that, the lid was either a red herring, and those reporters have a slow-starting upower [08:58] right [08:58] which makes more sense [08:58] or upower does start, and the lib later crashes on the nonexisting lid object [08:58] because u-s-d code didn't change since trusty [08:59] there were a few comments on the bug from people who say that upower is slow to start [08:59] as it doesn't check if a lid is present [08:59] seb128: interesting; so ideally it's just that then :) [08:59] yeah [08:59] let's see what they say once we have a -proposed package [09:07] pitti, https://bugs.freedesktop.org/show_bug.cgi?id=95350 [09:07] Freedesktop bug 95350 in general "up_client_new returns an invalid object when upowerd isn't started" [Normal,New] [09:08] seb128: merci ! [09:08] pitti, let me know if you need more debug info, I'm locally testing with a systemctl stop upower/moving the binary away to avoid dbus activation, then using the test code [09:08] de rien ! [09:12] pitti, some of the comments state e.G [09:12] "You'll know if the system is hit with this as it'll be much slower to boot and the kernel will spew errors of the type: [09:12] kernel: usb 2-1.1: device descriptor read/64, error -110 [09:12] kernel: usb 2-1-port1: unable to enumerate USB device" [09:12] so I guess part of those are also kernel issues [09:12] those users say boot is slow [09:12] but I guess that should be reported separately as a kernel bug [09:12] ack === greyback is now known as greyback|away [10:08] pitti: seb128: do you want to reschedule that meeting about de-upstartification? [10:09] Laney: yeah, let's; I still don't have a good idea about how the user session is plumbed together these days, so let's at least exchange some braindump and see how to go on [10:10] Laney, seb128, tedg: would tomorrow afternoon (EU)/morning (US) work for you? [10:10] xnox: ^ [10:11] we have the foundations meeting at 1500 UTC, before that would be good [10:11] that. [10:11] pitti: I heard that systemd --user isn't really that ready yet though, so it sounds like this either means going back to gnome-session / xdg autostart /or/ taking on the systemd work [10:11] desrt: ^^^ [10:11] talking about dropping upstart in the user session? [10:11] yeah [10:12] Laney: it indeed doesn't replace upstart --session directly, it's aiming for services that apply to all running user sessions indeed [10:12] Laney, so, there are github repositories with user session units and systemd generators for xdg autostart things [10:12] systemd --user _is_ a reality [10:12] but it doesn't do all of the things that we might expect of it [10:12] there's no systemd user instance per session indeed [10:12] and it does work, however lenart didn't take any units like that upstream. [10:12] debian is running systemd --user already [10:12] * pitti has dbus-user-session installed for two weeks now, finding a few small issues but it by and large works [10:12] so do we. [10:12] well anyway, I don't know that much about it [10:12] but as a gnome-session replacement? not even close... [10:12] but it's per user instance, not per user-session. [10:12] such as https://bugzilla.gnome.org/show_bug.cgi?id=759115 [10:12] Gnome bug 759115 in general "Add systemd user .service file" [Normal,Resolved: fixed] [10:12] desrt: agreed [10:13] so if someone wants to exchange their information to me/us that would be helpful [10:13] i think we should do what debian is doing [10:13] desrt: AFAIK they just use gnome-session and dbus activation [10:13] but we moved from that to upstart --user [10:13] and I'd like to understand the advantages that we got from that, and whether they justify maintaining upstart further [10:14] as nobody is doing that ^ right now [10:14] is there some benefit to having processes started from upstart instead of dbus-daemon? [10:14] (and don't look at me, maintaining one init system / ubuntu boot is enough for one person :) ) [10:14] the answer to this is surely "yes, but they're pretty minimal." [10:14] I see no benefit for real services, as they just get auto-activated [10:14] it might be for things like indicators [10:14] as with upstart user you can set them to auto-restart after crashes [10:14] and this is where you were discussing xdg-autostart... [10:15] and IIRC xdg-autostart/gnome-session don't have an autorestart thingy [10:15] desrt: do you have time tomorrow around 14:00 UTC to join a hangout? [10:16] and then what of phone? [10:16] i will probably be on ICE [10:16] Laney: oh, no gnome-session there? [10:16] let me check [10:16] nope [10:16] Laney: although on a phone we could actually use systemd --user, as realistically there's only ever one session anyway? [10:17] I should have said unity8/mir [10:17] pitti: in fact, i'll be inside of a plane [10:18] is this afternoon any better? [10:18] yes. it would be fine. [10:19] seb128, xnox, Laney: ^ what about you this afternoon? [10:20] sure [10:20] you might want stgraber or slangasek for a discussion of the initial motivation [10:21] ok, I'll invite them [10:21] or jodh [10:21] heh [10:24] I sent invites, please feel free to move the thing around [10:25] pitti: 3pm? [10:26] it says 3pm here too [10:26] desrt: too earl? [10:26] maybe set a timezone and it'll fix it [10:26] wait [10:26] it was an initial approxmiation of "afternoon/East coast morning" [10:26] I think my calendar is still on prague time [10:26] * Laney looks [10:26] I meant it to be at 15:00 CEST/13:00 UCT [10:26] but later WFM too [10:27] ya [10:27] my bad [10:27] I did wonder when a meeting earlier this week happened an hour before I thought it would [10:27] should have been suspicious then :) [10:27] time zones FTW [10:30] somehow timezones always manage to be completely screwed for everything [10:30] email and the web should have a widget that allow displaying a unix-epoch-based timestamp in whatever timezone the rendering machine is currently in [10:31] (without allowing arbitrary javascript from email to run in my browser) [10:31] not sure how many people would be *less* confused by "let's meet at 1462962700" [10:32] you wouldn't actually see that.... [10:33] the tech ctte does this: [10:33] Subject: Next Debian CTTE Meeting is at date -d 'Tue May 31 17:00:00 UTC 2016' [10:33] hah, nice [10:33] ya.. i basically want a form of this that is capable of rendering itself [10:34] shell injection in email Subject: :) [11:43] Laney,seb128 "standing excemption for snappy etc" trello card is marked as done - is it really done? [11:44] ah, thanks for the reminder === greyback|away is now known as greyback [11:44] I commented about that yesterday but I think after Laney left [11:44] then I closed IRC so didn't see potential replies [11:45] desrt, pitti, Laney, systemd-session meeting wfm [11:45] isn't it about feature freeze? [11:45] Laney, it's about SRU exception [11:45] like being able to SRU new versions [11:45] ok then move it back [11:45] even if they include features and such [11:45] k, thanks [11:45] willcooke, ^ [11:45] I've not heard those things called standing exemptions before [11:45] that is a term used for feature freeze exceptions [11:46] tomato, tomato. What should it be called? [11:46] or maybe its not even a thing? [11:47] dunno if there is an official namez [11:47] well [11:47] https://wiki.ubuntu.com/StableReleaseUpdates#Documentation_for_Special_Cases [11:47] so "SRU special case" [11:47] ? [11:47] or just put a description in [11:47] it doesn't matter to me [11:48] oki [11:49] Laney, does snappy about a standing FFe btw? [11:49] just curious now, since you put it to done :-) [11:49] does snappy have* [11:49] I guess it's more a by-cycle situation though [11:50] no [11:50] there is no feature freeze [11:50] it's seeded in Ubuntu so for sure it's subject to that feature freeze? [11:50] everything is subject to feature freeze when there is one [11:50] except things that have a ffe :p [11:50] but a previous cycle's exception would no longer apply [11:50] like touch packages have(had?) [11:51] they ask for that every cycle [11:51] but haven't actually for the last two [11:51] k, makes sense I guess [11:51] well they asked but didn't get them [11:51] and it was in fact ok [11:51] yeah, they cheat by using their overlay :p [11:51] mostly by ignoring the development release [11:51] or violating feature freeze [11:52] * Laney doesn't read the changes list [11:52] best not to know [11:52] yeah :-/ === hikiko is now known as hikiko|ln === maclin1 is now known as maclin [12:20] tedg: seb128: pitti: xnox: desrt: mind if we make it 13:30 UTC? [12:20] * Laney would ideally be AFK at 13:00 [12:20] Laney: fine for me, just move it in the calendar? [12:21] Laney: so, in 70 minutes? [12:21] ack [12:22] 70 minutes indeed, thanks - moved [12:25] biab [12:25] telegram me if someone can't make the new time [12:28] Laney, wfm [12:50] Laney, i thought we are meeting at 14:00 british summer time, no? [12:50] oh 14:30 summer time now. [12:59] xnox: now you put this in my head https://www.youtube.com/watch?v=yG0oBPtyNb0 === hikiko|ln is now known as hikiko [13:01] davmor2, whoop whoop =) [13:01] * xnox swings his hips [13:27] morning all [13:28] hey andyrock! how are you? [13:28] seb128, Laney, xnox: ready for session in a minute? [13:29] pitti, yes [13:29] pitti: desrt@desrt.ca plz [13:30] pitti: coming [13:30] desrt: invite sent [13:31] shouldn't unity pick up newly installed apps automatically? [13:31] i mean the search thing [13:32] tjaalton, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1506744 [13:32] Ubuntu bug 1506744 in unity (Ubuntu) "Newly installed applications do not show in the dash" [High,Triaged] [13:32] ahah .) [13:32] :) [13:32] what willcooke said [13:32] pitti: not seeing it :( [13:32] :) [13:33] oh hangouts [13:34] "Trying to join the call..." [13:35] * desrt sighs [13:35] I think pitti has to approve it or something [13:35] * Laney switched to canonical account and got straight in [13:36] I /msged him hte URL [13:36] it looked like the hangout owner has to approve external people or something [14:01] hey seb128 fine just finished swedish class [14:03] andyrock, hey :-) [14:24] xnox: ideally we could make these services hang off session-c2.scope (the session specific logind "master unit"), then the lifecycle on logout would happen automatically [14:24] xnox: and I think we have to, as you can't guarantee that you run shutdown code in the session itself (kill -9/crash/etc.) [14:26] hm. [14:26] pitti, but session-c2.scope is system, not user one.... [14:26] or can user units be part of system scope? [14:26] i guess they must?! [14:27] look at systemd-cgls [14:27] xnox: not with the "classical" /user session ones [14:27] xnox: but the logind scope is the one that is supposed to group all the processes that actually run in your session, so the lifetime of that is exactly what we want [14:28] this is where it gets fuzzy and where I'd like to confer with the dbus and systemd upstream people [14:28] Laney, pitti - e.g. /lib/systemd/systemd --user is not in a session-c2.scope, it's user-wide. [14:28] how do you get systemd to put things in that scope? [14:28] indeed [14:28] there's another option, though [14:28] use system units, templates per-user?! [14:28] we can run the units as part of user@1000.service, and bind them to session*.scope [14:29] so that they go down with the session [14:29] * pitti needs to test that [14:29] will those have DISPLAY? [14:29] or does display need to be fetched from the session? [14:29] xnox: user units do, yes [14:29] I don't want to use system units for user session stuff, that'd be conceptually wrong and also dangerous [14:30] and you can't make them start as the correct user [14:44] hum, does somebody what part we were cleaning with snapcraft to avoid redownloading the debs? [14:45] popey, ^ [14:45] like to rebuild after the wrapper changes [14:47] ha [14:47] "build" [14:47] desrt / larsu / darkxst: do you recommend fastmail? [14:47] yes-ish [14:47] * Laney is de-neckbearding [14:48] it's not awesome, but i don't know of anything better [14:48] yes, it's pretty good [14:48] arg, no -:/ that cleaned the deb cache as well [14:49] greg was saying that they rate limit him sometimes [14:49] or not, it's only redownloading the index [14:49] but I assume you don't send that much email ;) [14:49] larsu, "him"? [14:49] larsu, oh, and hey :-) [14:49] seb128: greg [14:49] hi seb128! [14:49] * desrt guesses that greg uses fastmail as a smarthost for git patch mailings [14:50] ya [14:50] 500 at a time :) [14:50] * Laney wondered which greg but gets it now [14:50] few people have a legitimate need to send 500 emails in a go :) [14:50] lol, sorry I did skip over the "grep" at the stat of the line for some reason :p [14:50] oh, no [14:50] I read that as "grep" :p [14:50] though you were grepping logs [14:50] grep greg log.txt [14:50] :-) [14:51] i'm naming my kid grep [14:51] Hahhahahah [14:51] this is not going to cause any confusion or misspelling at all [14:52] alright, migrating off this shit is my weekend project [14:53] laney@cripps> wc -l .procmailrc ~ [14:53] 351 .procmailrc [14:53] and porting that to sieve is going to be fun [14:53] grep sure will marry lil bobby tables one day... [14:53] Laney: i bet there is a tool for that [14:54] Laney, just curious what's the motivation behind? [14:55] too much spam [14:55] and a few times I have ruined everything and made emails bounce [14:55] like the times the disk on the server got full [14:55] :-/ [14:55] or the times that dspam crashed [14:55] which makes mail get rejected [14:55] So Good [14:56] it's a really boring problem to have to solve [14:56] yeah :-/ [14:57] and if my server is no longer doing email then I might actually upgrade it off wheezy /o\ [14:59] seb128: i installed apt-cacher-ng in the end [14:59] but snapcraft clean [14:59] popey, right, I remembered, "pull" is the part I don't want to clean, so doing a "clean build" works fine [15:01] oooh [15:01] learned something today [15:01] thanks [15:19] popey, yw! [15:32] pitti, how does the systemd suspend delay inhibit thing works? is it up to the processes to say when they are done/let the system suspend? [15:33] seb128: yes, as otherwise you can't predict when they are done with whatever they need to do before suspend [15:34] https://www.freedesktop.org/wiki/Software/systemd/inhibit/ [15:34] pitti, k, I'm looking a bit a bug #1574120, my guess is that one of the process has to no give the lock back ... I wonder if a "sleep 10; systemd-inhibit" call would tell us which one, just asked on the bug [15:34] bug 1574120 in systemd (Ubuntu) "Notebook doesn't suspend when lid is closed after update to 16.04" [Medium,Incomplete] https://launchpad.net/bugs/1574120 [15:34] seb128: the process tells that it's done by closing an fd that you got from the Inhibit() call (so taht the inhibitor goes away when the process crashes) [15:34] k [15:35] so if one process is misbehaving it could make suspend not happen [15:35] though why it work when selecting directly the item then? [15:36] also InhibitDelayMaxSec defaults to 5s [15:36] that's probably not it :-/ [15:36] seb128: it might mis-detect that there is an external monitor? [15:37] suspend only happens with the internal monitor, if you have an external one or docked lid close doesnt' do anything [15:37] (on purpose) [15:37] pitti, is there any command that would tall that? there is no multimonitor suspend lock from u-s-d and xrandr doesn't list one [15:37] unsure how to poke the systemd state though [15:38] or how systemd check if there is one [15:38] seb128: this isn't done via delays, but via blocks [15:38] some of the submitters have a block, but not all of them AFAIR [15:38] pitti, right, but https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1574120/comments/38 [15:38] Ubuntu bug 1574120 in systemd (Ubuntu) "Notebook doesn't suspend when lid is closed after update to 16.04" [Medium,Incomplete] [15:38] that's the one I 'm looking at [15:38] there is no block [15:39] so it could be that logind itself detects an external monitor and doesn't suspend by default [15:39] right [15:39] how would one tell if that's the case? [15:39] do you know where systemd would look to tell if there is an external monitor? [15:42] seb128: /sys/class/drm/ basically [15:43] it removes the first cardN-, then checks [15:43] FOREACH_STRING(i, "VGA-", "DVI-I-", "DVI-D-", "DVI-A-" [15:43] "Composite-", "SVIDEO-", "Component-", [15:43] "DIN-", "DP-", "HDMI-A-", "HDMI-B-", "TV-") { [15:43] if (startswith(dash, i)) { [15:43] external = true; [15:44] seb128: enabling debug (systemd-analyze set-log-level debug) and then closing the lid should show that [15:44] pitti, thanks [15:44]