| === alan_g is now known as alan_g|afk | ||
| willcooke | morning all | 08:59 |
|---|---|---|
| davmor2 | Morning all | 09:00 |
| seb128 | hey willcooke davmor2 Laney | 09:01 |
| seb128 | how is u.k today? | 09:01 |
| Laney | sup | 09:02 |
| Laney | i like this anticipation thing | 09:02 |
| Laney | it's nice! | 09:02 |
| Laney | blue sky | 09:02 |
| seb128 | :-) | 09:02 |
| seb128 | we had that yesterday, very nice day, 13°C | 09:03 |
| seb128 | rain in the evening and colder/grey today now | 09:03 |
| Laney | did you get out in it? | 09:03 |
| seb128 | no, but tennis tonight, weather should be good to play, looking forward the exercice! | 09:04 |
| davmor2 | seb128: ditto on blue sky and sunshine it's like we are in the tropics if it wasn't for the chill in the air | 09:04 |
| flexiondotorg | Morning Laney seb128 davmor2 willcooke | 09:09 |
| seb128 | hey flexiondotorg | 09:09 |
| seb128 | how are you? | 09:09 |
| davmor2 | flexiondotorg: Morning dude | 09:09 |
| flexiondotorg | seb128 All good here, mostly due to Trevinho being awesome yesterday :-) | 09:10 |
| seb128 | he fixed your indicator issue? | 09:10 |
| seb128 | what was it? | 09:10 |
| flexiondotorg | Yes and complicated. | 09:10 |
| flexiondotorg | Trevinho has a silo and some SRUs being lined up. | 09:11 |
| flexiondotorg | Sec... | 09:11 |
| flexiondotorg | https://github.com/3v1n0/snapd/commit/694a27e413de09e0aa4ffb25cf3b3196566d22c7 | 09:11 |
| flexiondotorg | https://bileto.ubuntu.com/#/ticket/2477 | 09:12 |
| seb128 | oh, nice | 09:12 |
| flexiondotorg | Chroimum is a edge case, is the TL;DR. | 09:13 |
| flexiondotorg | ANd I ran into an issue Trevinho had seen a couple of days previous and already prepared a fix for. | 09:13 |
| flexiondotorg | However, current snap I'm working on. | 09:13 |
| flexiondotorg | I have clean logs, nothing on stdout. | 09:14 |
| flexiondotorg | And audio doesn't work. | 09:14 |
| flexiondotorg | At this moment, you realise, closed source is deeply inconvenient. | 09:14 |
| flexiondotorg | seb128 I was thinking about our conversation yesterday, exposing ~/.config/autostart to snaps. | 09:17 |
| seb128 | yeah | 09:17 |
| flexiondotorg | https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L134 | 09:17 |
| seb128 | right, something similar would work I guess | 09:18 |
| flexiondotorg | That link to a file in "real" user home. Could we not use the same tedhnique to link the ~/.config/autostart directory? | 09:18 |
| seb128 | easy to try | 09:18 |
| flexiondotorg | Just wanted a second opinion. | 09:18 |
| flexiondotorg | OK, I'll give that a go later. | 09:18 |
| seb128 | sounds like a good option to me yes | 09:19 |
| seb128 | great | 09:19 |
| seb128 | let me know how it goes | 09:19 |
| flexiondotorg | Wilco. | 09:19 |
| Laney | that should probably check XDG_CONFIG_HOME first | 09:22 |
| Laney | wait | 09:23 |
| Laney | what is /home/$USER/? | 09:23 |
| Laney | the real home directory? | 09:23 |
| JanC | AFAIK /home/$USER/ would be the default but not necessarily the real home directory? | 09:27 |
| === alan_g|afk is now known as alan_g | ||
| seb128 | Laney, wdym? | 09:32 |
| Laney | https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/common/desktop-exports#L140 | 09:32 |
| Laney | is that trying to symlink from your real home directory into the snap thing? | 09:33 |
| seb128 | Laney, I don't think the snapd interface allows for re-allocatable userdir | 09:33 |
| seb128 | same issue with that apparmor profiles | 09:33 |
| seb128 | that with* | 09:33 |
| seb128 | so it only works in the standard case, which is not universal yes | 09:33 |
| seb128 | re-allocatable->relocatable | 09:34 |
| Laney | if it used $HOME then could you set /etc/apparmor.d/tunables/home and get it working? | 09:34 |
| seb128 | no idea | 09:35 |
| seb128 | feel free to try and submit a patch for the launcher if it does :-) | 09:35 |
| Laney | riiiiiiight | 09:35 |
| seb128 | but yeah, you probably have a point | 09:36 |
| seb128 | worth a bug | 09:36 |
| seb128 | but probably not enough of a priority that I'm going to look at it this cycle | 09:36 |
| seb128 | but maybe Didier or other would pick it up | 09:36 |
| seb128 | Laney, https://bugs.launchpad.net/snappy/+bug/1577472 is sort of an issue with relocated userdir | 09:37 |
| ubot5 | Ubuntu bug 1577472 in Snappy "The remapped $HOME directory shows as read-only to applications running in a snap" [Undecided,Confirmed] | 09:37 |
| seb128 | or maybe not, comments are bit confusing | 09:38 |
| Laney | :-) | 09:40 |
| * Laney filed an issue for now, thanks! | 09:46 | |
| happyaron | wonders who to ask about NEWing packages? | 09:53 |
| happyaron | got this one... https://launchpad.net/ubuntu/zesty/+queue?queue_state=0&queue_text=zfs-linux | 09:53 |
| Laney | Usually you would wait for a bit before asking :P | 09:54 |
| Laney | especially syncs are processed regularly | 09:54 |
| happyaron | sure, :) | 09:54 |
| Laney | oh I forgot, happy feature freeze day! | 09:54 |
| willcooke | cking, hi! Hopefully you can see in the scrollback happyaron's comment on the NEW queue ^ that's your ZFS sync | 10:10 |
| cking | willcooke, yep, very grateful for this! kudos to happyaron | 10:10 |
| Laney | happyaron: well done on making it be synced again | 10:12 |
| cking | yep, that is a heroic piece of work | 10:15 |
| ximion | Laney: hey :) Is libmo usable already? | 10:19 |
| ximion | looks pretty good to me, tbh | 10:19 |
| Laney | ximion: It works | 10:19 |
| Laney | I think it wants a _new_from_bytes thing | 10:20 |
| ximion | yeah, that would be nice for asgen | 10:20 |
| Laney | exactly | 10:20 |
| Laney | that should be not too bad to implement | 10:20 |
| Laney | *also* I fuzzed it and it has some crashes | 10:20 |
| Laney | needs to check file lengths and stuff | 10:20 |
| Laney | so I would do those fixes before making a release, but you can work against it now if you want | 10:21 |
| * ximion always wanted to fuzz AppStream - so farthis is still on my todo list | 10:21 | |
| Laney | afl is pretty easy to use | 10:21 |
| Laney | oh also it has no testsuite of course /o\ | 10:21 |
| ximion | Laney: a release of libmo would be nice | 10:22 |
| Laney | sure, just need to do the crash fixes | 10:22 |
| Laney | could call that 0.1 then | 10:22 |
| Laney | ah, I saw that the submodule bug in meson was fixed too | 10:22 |
| ximion | well, asgen is also pretty light on tests... :-/ (but it's also one of those harder-to-test cases) | 10:22 |
| ximion | jup | 10:22 |
| Laney | so you could have it as a submodule for now if you wanted | 10:22 |
| Laney | i.e. the outer meson.build should (if it is really fixed) be able to set libdir and so on | 10:23 |
| Laney | to put libmo in a private directory | 10:23 |
| ximion | Meson is getting so much better lately - they now have fixed all issues I complained about in the past | 10:23 |
| ximion | yes, maybe I'll do that | 10:23 |
| Laney | otherwise, I want to get to those bugs within a week or so | 10:24 |
| ximion | I also want to submit patches to the Git-to-D tool to make it possible to invoke it as part of the build process and also to switch between dynamically loading libraries and linking to them directly | 10:25 |
| ximion | basically get my changes upstreamed | 10:25 |
| Laney | s/git/gir? | 10:25 |
| ximion | but I need to finish my review essay first | 10:25 |
| ximion | yes, GIR | 10:25 |
| ximion | as in Invader-Zim-GIR | 10:26 |
| Laney | GrrrrrrRRRRrrr | 10:28 |
| Laney | ximion: what are you planning with mo files? :-) | 10:29 |
| Laney | the languages thing? | 10:29 |
| ximion | yes - the languages thing was the original reason for me wanting libmo | 10:29 |
| ximion | although reading out that information from .mo files is trivial even without libmo | 10:30 |
| ximion | but if we are going to have it anyway for the Ubuntu part, we can just as well use it for more | 10:30 |
| ximion | btw, the D language situation is also getting better - Red Hat has a guy working on things with D upstream, and kalev recently made the Fedora side work well | 10:31 |
| ximion | some guy wrote a NixOS backend for asgen | 10:31 |
| ximion | things look good | 10:32 |
| ximion | except for the RAM usage, which is still insane | 10:32 |
| Laney | nice | 10:34 |
| Laney | what are redhat using it for? | 10:34 |
| ximion | I think at time it's just a general "we want to have all languages work well" thing, paired with GNOME developers looking for alternative languages to recommend people when developing for GNOME (C and JavaScript both have disadvantages to newcomers, and Vala isn't very healthy) | 10:36 |
| ximion | so, no formal company-wide interest, but some people doing stuff I assume - either way, it already massively improved things | 10:37 |
| === ember_ is now known as ember | ||
| Laney | nod | 10:44 |
| ximion | Laney: I recently played around with the D-based web framework vibe.d, which is - unlike the standard library - really well designed and has very useful features | 10:50 |
| ximion | if I really add a MongoDB or SQL backend to asgen one day, maybe depending on the whole web framework wouldn't be a terrible idea | 10:50 |
| ximion | (e.g. its logging facilities are good, it has a nice streaming interface, sane JSON serialization, async I/O, etc.) | 10:52 |
| hikiko | fatal error: error in backend: IO failure on output stream. | 10:57 |
| hikiko | has anyone seen this error before? | 10:57 |
| hikiko | I upgraded to zesty | 10:57 |
| hikiko | and tried to build something | 10:57 |
| JanC | I think D is more common for game programming than for desktop programming... | 11:01 |
| happyaron | :) | 11:20 |
| happyaron | was at dinner | 11:20 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| Sweet5hark | seb128: urgh, ricotz was right about the changes for the autopkgtests missing. They are in git (https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-zesty-5.3&id=fa92df6e10606bfb020872121bbf8e7011a4a852), but somehow not in the upload. Must have messed up my jenkins here ... | 13:29 |
| * Sweet5hark investigates. | 13:30 | |
| Sweet5hark | arrrgh | 13:35 |
| Sweet5hark | lets have generated files in git, it will be awesome | 13:36 |
| Sweet5hark | like, when was that actually ever a good idea? | 13:36 |
| Sweet5hark | the good news is: there is nothing wrong with my CI ... | 13:37 |
| seb128 | Sweet5hark, you might want to ask on #ubuntu-release if they can skip the autopkg for that one, explaining that following upload is going to fix things but that we might get the new version in zesty before waiting for another build/infra round | 13:49 |
| seb128 | Sweet5hark, you might want to mention what package/issue you are talking about in addition of the text copy ;-) | 13:52 |
| Sweet5hark | seb128: heh, yeah, done. http://people.canonical.com/~bjoern/zesty/5.3.0/libreoffice_5.3.0~rc3-0ubuntu3_source.changes <- has the proper change, SCM diff is here: https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=ubuntu-zesty-5.3&id=f4b5ece6b1783202ed286e1f149ab60c3471f180 | 13:56 |
| seb128 | Sweet5hark, k, I'm waiting a bit to see if they want to move the current version over before sponsoring the new one | 14:01 |
| GunnarHj | seb128: Hi Seb, what about the langpack update? Should we postpone it again? | 14:03 |
| seb128 | shrug | 14:05 |
| GunnarHj | seb128: Sorry to be a nuisance. ;) | 14:06 |
| Sweet5hark | seb128: k, thanks | 14:06 |
| seb128 | GunnarHj, next you are going me to re-review xkeyboard-keyconfig aren't you? ;-) | 14:06 |
| GunnarHj | seb128: Well, ... yes | 14:07 |
| GunnarHj | seb128: Saw that wgrant will open zesty translations soon. At least one good news. | 14:09 |
| seb128 | GunnarHj, I plan to have another look to that one ... langpack I'm going to try to have a look this afternoon if I see what's the issue, as said I set up the new account/key but somehow it's not working and I don't really know how to debug so need to sit down and learn more about that stack | 14:09 |
| seb128 | GunnarHj, right | 14:09 |
| === dandrader is now known as dandrader|afk | ||
| GunnarHj | seb128: I see. Probably only you and I know about that schedule, so it's not a big deal. Please let me know when we are ready to go with the call for testing. | 14:12 |
| seb128 | GunnarHj, k, I let you know when I figure things out | 14:15 |
| GunnarHj | seb128: Ack. | 14:16 |
| andyrock | qengho: hey do you know if chromium uses a custom version of mesa? | 14:17 |
| andyrock | there is a mesa in third_party but it looks old | 14:17 |
| qengho | andyrock: Er, I didn't think it used mesa at all. | 14:20 |
| qengho | andyrock: I have never noticed, is a better way of saying that. | 14:20 |
| andyrock | i think it does and we need include the mir patches there | 14:23 |
| qengho | andyrock: I guess you can tell easiest by running "find pathtolocalmesa -type f -exec touch {} \;" and if running "ninja" needs to build anything new, then it does. | 14:23 |
| andyrock | or maybe not (maybe they're using it just for chromeos not sure) | 14:29 |
| === dandrader|afk is now known as dandrader | ||
| attente | desrt: do you remember how to get the ipc_dir and app_id for snaps in your proxy? | 16:11 |
| desrt | you have to give them to me | 16:11 |
| desrt | it's part of what the security backend is supposed to do | 16:11 |
| desrt | for snaps i think ipc_dir is xdg_runtime_dir + "snap.snap-name". take a look at what directory gets added to the apparmor stuff there. | 16:12 |
| attente | yeah, i was trying to remember the location, but actually i don't know how to get the app_id through apparmor | 16:13 |
| attente | desrt: i can give you the context/label but i don't know if this corresponds to an app_id correctly | 16:14 |
| desrt | i pass you that gvariant with the dbus peer credentials | 16:14 |
| desrt | the apparmor label is inside of that | 16:14 |
| desrt | ah. talk to snap people about that :) | 16:14 |
| desrt | but i guess it does, no? | 16:14 |
| attente | no clue. i remember seeing some labels like usr.bin.firefox so i thought that was just a re-write of the path of the binary... | 16:15 |
| desrt | ya.. but snaps follow some sort of scheme, don't they? | 16:15 |
| desrt | like confined:snap.whatever | 16:15 |
| attente | actually, the context is the binary location it seems like | 16:17 |
| desrt | well, it is surely possible to that that into a snap id | 16:18 |
| tyhicks | hey | 16:18 |
| tyhicks | we're mixing two different things here | 16:18 |
| jbicha | Laney: for Feature Freeze, are you ok if I upload onboard 1.4 later this week so that we can merge from Debian experimental or should I just upload to zesty now? | 16:19 |
| tyhicks | the apparmor label can be anything and is defined at the top of the AppArmor profile | 16:19 |
| tyhicks | traditionally, we've used the path to the binary and substituted '/' chars for '.' | 16:20 |
| tyhicks | snap confinement does things differently | 16:20 |
| tyhicks | it uses the following pattern: snap.<snap>.<app> | 16:20 |
| Laney | jbicha: Ok, if you test it properly | 16:20 |
| attente | tyhicks: that isn't necessarily the same as the app id is it? | 16:21 |
| tyhicks | attente: it is in the case of snap confinement | 16:22 |
| attente | but we can't rely on this in the case of non-snaps, right? | 16:23 |
| tyhicks | attente: correct | 16:24 |
| attente | ok | 16:24 |
| tyhicks | attente: do you have a need to differentiate between snaps and non-snaps? | 16:25 |
| attente | tyhicks: also is the ipc directory location standardized? | 16:25 |
| tyhicks | attente: hmmm... ipc directory? are you talking about a location in the filesystem that the snap can create named socket? | 16:26 |
| attente | tyhicks: i'm just trying to think of a situation where i might end up passing the apparmor label to desrt's proxy and it doesn't correspond to an appropriate app id | 16:26 |
| desrt | tyhicks: there is a feature in snappy that happened a while ago where there is a hole punched in the xdg runtime dir | 16:26 |
| * tyhicks reads https://bugs.launchpad.net/snap-confine/+bug/1620442 | 16:28 | |
| ubot5 | Ubuntu bug 1620442 in Snappy "snap fails because XDG_RUNTIME_DIR is set to /run/user/1000" [High,Fix released] | 16:28 |
| desrt | oh. you found it before me :) | 16:28 |
| tyhicks | looks like XDG_RUNTIME_DIR is now set specifically for snaps running under confinement | 16:29 |
| tyhicks | but note comment #9 :/ | 16:29 |
| desrt | ya | 16:29 |
| desrt | imho they messed things up | 16:30 |
| desrt | BUT | 16:30 |
| desrt | the /run/user/1000/snap.qt5-systray/ thing being created and shared is absolutely correct | 16:30 |
| desrt | and that's what we set ipc_dir to | 16:30 |
| tyhicks | attente: remind me what piece of code are you're referring to when talking about passing the apparmor label to the proxy | 16:31 |
| attente | tyhicks: it's a small function in desrt's proxy that obtains the dconf paths using libapparmor with the added patches jjohansen sent to the ML | 16:33 |
| desrt | tyhicks: basically, i need two things | 16:34 |
| desrt | 1) a place to put a file, and 2) a unique identifier | 16:34 |
| desrt | from a really practical standpoint, i actually only need 1 | 16:34 |
| desrt | since that could act as a unique identifier | 16:34 |
| attente | desrt: but it seems like all we can really obtain is the apparmor label | 16:35 |
| attente | and i don't even think that's enough to get you the correct ipc dir | 16:36 |
| desrt | can't you parse the apparmor file or something? | 16:36 |
| desrt | and is it really the case that the label can be just anything? | 16:36 |
| desrt | doesn't snappy force it to follow the expected format? | 16:36 |
| tyhicks | all snappy profiles followed the expected format | 16:37 |
| desrt | so that's the answer | 16:37 |
| tyhicks | yes | 16:37 |
| attente | desrt: does it matter for non-snaps? | 16:37 |
| desrt | well | 16:37 |
| desrt | as long as non-snaps aren't called with something that looks like a snap id... | 16:37 |
| tyhicks | it is common for things in userspace that deal with apparmor confinement to look for the "snap." prefix and treat those profiles/processes specially | 16:38 |
| desrt | yes. exactly that. | 16:38 |
| tyhicks | as a distro, we won't ship an apparmor profile that looks like a snap id unless it is for snap confinement | 16:39 |
| desrt | attente: do you have everything you need to know, now? | 16:39 |
| tyhicks | a system admin may make the mistake of creating a local apparmor profile that begins with "snap." but it is highly unlikely | 16:39 |
| attente | sorry if i'm being obtuse guys... but how exactly do i go from apparmor label to /var/snap/${snap_name}/current | 16:40 |
| desrt | you rather go to /run/user/xxx/snap.${snap_name} | 16:41 |
| desrt | that's the ipc dir | 16:41 |
| desrt | and the apparmor label is snap.${snap_name}... so it's pretty easy | 16:41 |
| attente | so the reason i'm not seeing the directory is that it hasn't been created by anything yet? | 16:41 |
| desrt | ya... that's arguably a bug | 16:42 |
| desrt | i think someone opened a new one fort hat | 16:42 |
| attente | desrt: and you don't really care if the app id is an app id, as long as it's a unique id? | 16:43 |
| desrt | what case are you imagining? | 16:43 |
| attente | well i was just thinking of throwing the apparmor label in there | 16:44 |
| desrt | attente: if i understand tyhicks correctly, then this is always correct | 16:45 |
| desrt | just make sure it starts with "snap." and you're good | 16:45 |
| attente | and we don't care about confinement of non-snaps, right? | 16:45 |
| desrt | correct. | 16:45 |
| tyhicks | hmm? | 16:45 |
| attente | ok :) | 16:45 |
| tyhicks | we're not going to be mediating dconf/gsettings access by non-snap processes? | 16:46 |
| tyhicks | attente, desrt: ^ | 16:47 |
| attente | tyhicks: how does dconf know the difference? by checking if the label starts with "snap."? | 16:48 |
| tyhicks | attente: yes, that's how you would know the difference | 16:49 |
| jdstrand | snappy is going to be the main consumer, but I would hope that this wouldn't be a snapd only thing. it should be possible to craft your own policy for something outside of a snap that uses this mechanism | 16:49 |
| tyhicks | attente: however, I feel like we still want to mediate non-snap processes that are confined | 16:49 |
| * jdstrand notes he hasn't been following terribly closely to the conversation | 16:49 | |
| tyhicks | I agree | 16:49 |
| jdstrand | I mean, upstreamableness alone makes it that we want to make it not snap-specific, but yeah, there is still a lot of software in the distros and from 3rd parties that people might want to apply policy to | 16:50 |
| tyhicks | what we may do is add a rule to /etc/apparmor.d/abstractions/dconf to grant blanket access to the confined apps that are already using dconf | 16:51 |
| tyhicks | the typical flow is to get the apparmor label of the connecting process | 16:53 |
| tyhicks | if it is "unconfined", grant full access | 16:53 |
| attente | if it starts with "snap.", then the ipc directory is /var/snap/${snap_name}/current | 16:54 |
| attente | if it doesn't, then the ipc directory is just /run/user/1000 | 16:54 |
| tyhicks | that'd work but I don't if that's the best ipc directory for the snap case | 16:55 |
| attente | and always use the apparmor label as the unique identifier that desrt needs | 16:55 |
| tyhicks | yes | 16:55 |
| tyhicks | and always query apparmor about what to do unless the label is "unconfined" | 16:55 |
| attente | tyhicks: which directory is best? it pretty much has to be something standard and easily derivable from the label | 16:55 |
| jdstrand | tyhicks: well, in the past this is where we introduced -strict. eg, dbus abstraction got rules to connect to all of the system bus, but a new dbus-strict was added that only allowed a few things. that way existing policy doesn't break and people can use the stricter abstraction as the desire | 16:56 |
| jdstrand | snapd would use -strict and build up what it needs | 16:56 |
| tyhicks | jdstrand: yeah, that'd work | 16:56 |
| tyhicks | jdstrand: do you have a suggestion for where attente should create a file for IPC in the case of snap confinement? | 16:56 |
| jdstrand | I need to read backscroll for full context | 16:57 |
| tyhicks | attente: the proxy is creating this file on behalf of the app? | 16:57 |
| tyhicks | jdstrand: we still need to gather full context because I don't know all of the details regarding who is creating the file and what it is used for | 16:57 |
| tyhicks | jdstrand: don't worry about backscroll | 16:57 |
| attente | tyhicks: i don't know, desrt ^? | 16:57 |
| desrt | ... | 16:59 |
| desrt | like, just use the xdg runtime dir subdirectory | 16:59 |
| desrt | this is already decided and supported | 16:59 |
| tyhicks | that seems reasonable to me but I wasn't sure why attente settled back on /var/snap/${snap_name}/current | 17:00 |
| desrt | i have no idea either. it's xdg_runtime_dir + "/snap." + snap_id | 17:00 |
| desrt | there's only one option | 17:00 |
| attente | ok | 17:01 |
| desrt | so it's all clear now? | 17:01 |
| attente | yes | 17:01 |
| tyhicks | cool | 17:02 |
| === dandrader is now known as dandrader|afk | ||
| Laney | jbicha: can you push gnome-session please? | 17:26 |
| jbicha | Laney: done | 17:29 |
| Laney | merci | 17:29 |
| * Laney breaks all the things | 17:29 | |
| ogra_ | Laney, dont steal davmor2's job ! | 17:30 |
| * davmor2 break Laney | 17:30 | |
| davmor2 | ogra_: that was easy to fix | 17:30 |
| ogra_ | hah | 17:30 |
| * Laney keeps davmor2 in a job | 17:30 | |
| Laney | now someone else gets to put me back together | 17:31 |
| Laney | then davmor2 gets to verify that they did it right | 17:31 |
| Laney | and so on | 17:31 |
| davmor2 | \o/ | 17:31 |
| ogra_ | :) | 17:31 |
| === dandrader|afk is now known as dandrader | ||
| jdstrand | tyhicks: fyi, that was what I thought we all agreed to as well | 17:38 |
| tyhicks | jdstrand: are you talking about using a subdir under xdg_runtime_dir? | 17:39 |
| jdstrand | yes | 17:39 |
| tyhicks | good | 17:40 |
| Laney | night! | 18:27 |
| willcooke | nighty night all | 18:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!