| === JanC is now known as Guest16348 | ||
| === JanC_ is now known as JanC | ||
| hikiko | hi | 05:33 |
|---|---|---|
| duflu | Morning hikiko | 05:40 |
| hikiko | hi duflu | 05:41 |
| TheMuso | Hey hikiko. | 05:57 |
| hikiko | hi TheMuso | 05:58 |
| FJKong | hi all | 06:32 |
| allison[m] | good morning | 06:55 |
| allison[m] | pindrop | 07:08 |
| flocculant | :) | 07:09 |
| sil2100 | seb128: hey! Who's the langpack work going? I see some zesty-specific langpacks in the archive, so I guess it's all good? :) | 07:57 |
| robert_ancell | allison[m], do you know much about g_main_context_iteration? | 08:01 |
| allison[m] | a bit, yes :) | 08:14 |
| robert_ancell | allison[m], I use this in snapd-glib to do the sync calls, but for some reason it never returns when you using it in a thread. | 08:17 |
| robert_ancell | I can confirm the callback (a socket read) occurs, but g_main_context_iteration never exits so the sync call never completes even through it now has the result. | 08:18 |
| allison[m] | wait wat? | 08:19 |
| jbicha | good morning | 08:19 |
| allison[m] | i'm not sure what the problem is, but i'm pretty sure you're "doing it wrong" :) | 08:19 |
| allison[m] | first, you should never call that function from a thread, unless it's on a mainloop that you created directly for the purpose of that thread | 08:19 |
| robert_ancell | allison[m], I expected you'd say that, so I'm hoping you can tell me how to do it rigght | 08:20 |
| allison[m] | second, mainloops should not interact with sync calls at all, except through thread-emulation of async calls... | 08:20 |
| allison[m] | robert_ancell: can you back up a bit and tell me what you're trying to do first, then? | 08:20 |
| robert_ancell | allison[m], in snapd-glib you have a socket you send requests on / get responses. I have a bunch of methods that do sync and async calls on it. I want to be able to do multiple async calls and handle timeouts on it, which doesn't seem easily do-able with threads. | 08:22 |
| robert_ancell | Also threads suck and this all should be possible without them just doing async calls | 08:22 |
| allison[m] | sure... | 08:22 |
| allison[m] | so what calls are you trying to do? | 08:23 |
| allison[m] | or are you implementing async calls? | 08:23 |
| robert_ancell | https://github.com/snapcore/snapd-glib/blob/master/snapd-glib/snapd-client.h | 08:23 |
| robert_ancell | allison[m], orinally I implemented the sync calls, which was easy (just block on the socket until get our reply). But that stops other callbacks you might have | 08:25 |
| seb128 | hey allison[m] robert_ancell sil2100 | 08:25 |
| robert_ancell | seb128, hi | 08:25 |
| seb128 | robert_ancell, staying late! | 08:26 |
| robert_ancell | seb128, wanted to check if any info regarding Canonical and I needed some allison[m] help | 08:26 |
| seb128 | k | 08:26 |
| allison[m] | robert_ancell: API looks fine | 08:26 |
| robert_ancell | allison[m], yeah, I figured the API should survive a refactor behind the scenes to "do it right" (TM) | 08:27 |
| allison[m] | robert_ancell: so basically you will end up doing async socket calls inside of those async calls of your own | 08:27 |
| allison[m] | spin up a GTask in the _async start function, pass it in as the user_data to the subcall and from your own finish handler, use g_task_return()... | 08:28 |
| allison[m] | just one async call inside of another... no threads, etc. | 08:28 |
| robert_ancell | allison[m], aha, I was confused by GTask only having the _run_in_thread methods. I didn't consider you don't need them at all | 08:29 |
| allison[m] | they're useful if you need to emulate the operation in a thread... | 08:29 |
| robert_ancell | allison[m], yeah | 08:29 |
| allison[m] | but if you can chain other async ops (which is the correct thing to do in this case) then it's not necessary | 08:30 |
| robert_ancell | allison[m], so do I have to implement sync equivalents? There's some code I was hoping to de-duplicate | 08:30 |
| allison[m] | if your operation ends up being really complicated with a lot of talking back and forth then you might consider it | 08:30 |
| Laney | hello | 08:30 |
| Laney | !!! | 08:30 |
| allison[m] | since implementing a 5-step handshake in async all the way is ... not awesome (unless you take the vala approach) | 08:30 |
| allison[m] | so sometimes people just punt over to sync land in that case | 08:30 |
| sil2100 | Hi! | 08:30 |
| allison[m] | robert_ancell: so there is a "trick" for implementing sync versions of async calls | 08:31 |
| robert_ancell | it will be less readable than what I've got, but not out of control | 08:31 |
| allison[m] | (1) create new mail context | 08:31 |
| allison[m] | (2) set it as the thread local default | 08:31 |
| allison[m] | (3) do the async call | 08:31 |
| allison[m] | (4) iterate your new loop until the result handler comes | 08:31 |
| allison[m] | (5) tear it all down again | 08:31 |
| allison[m] | this is how GDBus does its sync calls | 08:31 |
| robert_ancell | allison[m], right, so that's sort of what I had (I think I copied it from somewhere). But that didn't work in the threads (in gnome-software) | 08:31 |
| allison[m] | if you set the thread-default maincontext correctly, iterate the new context, and use GTask properly then it should "just work" | 08:32 |
| allison[m] | unless there is something in your async chain that pings back to the global default mainloop | 08:32 |
| allison[m] | (ie: something that is implemented incorrectly) | 08:32 |
| robert_ancell | allison[m], thanks, I'll try some refactoring tomorrow | 08:33 |
| sil2100 | seb128: just remember - if you need any help with the langpacks, give me a sign | 08:58 |
| sil2100 | I guess it's still in progress as I don't see zesty in the crontab for l-o-m | 08:58 |
| sil2100 | btw. did we get the zesty potemplate stats in the end from dpm? | 08:59 |
| sil2100 | (or how those were generated) | 08:59 |
| andyrock | morning all | 09:03 |
| seb128 | sil2100, hey, sorry I was in an hangout earlier, do you need anything particular with langpacks? | 09:08 |
| seb128 | sil2100, I did an update to zesty a week ago and I'm going to do another one now | 09:09 |
| seb128 | sil2100, I didn't sort out the stats job yet, feel free to look at that if you want, for now I workarounded and use the xenial stats on zesty | 09:09 |
| sil2100 | seb128: excellent, we're just going through the list of things for the release | 09:09 |
| sil2100 | seb128: ok, will do | 09:10 |
| seb128 | thanks | 09:10 |
| seb128 | you are in London? | 09:10 |
| sil2100 | Yes | 09:10 |
| b4n | Trevinho: hi! regarding a11y shortcuts in Compiz: I've got roughly 1 week left at my job to work on that, and we'd love to get this to work by then. What do you think would be the best approach to go ahead on that? Also, could you give some hand/guidance on it? Porting InputMonitor to Compiz was what we discussed last time, and although I'm not at all familiar enough with it yet to be sure on how it'd be used to solve the plugin | 09:24 |
| Trevinho | b4n: mh, I guess it could be done yeah... the thing is that compiz is in final freeze now, so we can't merge things | 09:25 |
| Trevinho | I can do that once A opens though | 09:25 |
| b4n | when would that be? | 09:25 |
| Trevinho | b4n: however, yeah.... Trying to have that input monitor at compiz level would be nice, I can try to have a look on that too | 09:25 |
| b4n | that would be awesome :) | 09:25 |
| Trevinho | b4n: release is in 3 days, so.... after that | 09:26 |
| b4n | OK. anything I could work on to get ahead of it? | 09:26 |
| b4n | I guess you'd have more ease to port the module as you probably already know it fairly well, but if there's anything I could do would be nice | 09:27 |
| b4n | for example, maybe you have an idea how the monitor could be used to get actions triggered, like how i'd integrate | 09:28 |
| b4n | I could possibly research/test on that (not sure how easy that'd be without actually having the monitor in Compiz, but maybe) | 09:29 |
| Trevinho | b4n: speaking of the events... Is there a reson why you used raw events instead of normal one? | 09:31 |
| Trevinho | I think you wrote that, but... | 09:31 |
| b4n | Trevinho: yeah, the reason was primarily not to block Core events | 09:32 |
| b4n | and I need to re-check (I did too many tests…), but I think some grabs also blocked XI2 non-raw events | 09:32 |
| duflu | Trevinho: Nice sunset? ;) | 09:33 |
| Trevinho | duflu: yeah, it was awesome | 09:33 |
| Laney | hey seb128 duflu allison[m] & Trevinho | 09:34 |
| Trevinho | hey Laney | 09:34 |
| duflu | Moring Laney | 09:34 |
| duflu | Morning even | 09:34 |
| Laney | how's it going? | 09:34 |
| happyaron | hey guys | 09:34 |
| seb128 | Hey Laney, in London now? | 09:34 |
| Laney | yep | 09:34 |
| Laney | hey happyaron | 09:35 |
| seb128 | had a good w.e and easy trip? | 09:35 |
| Laney | seb128: was suuuuuuuuuuuuuuuuper sunny yesterday | 09:35 |
| seb128 | hey happyaron | 09:35 |
| Laney | yeah | 09:35 |
| Laney | just 1 train, is easy | 09:35 |
| seb128 | same here | 09:35 |
| seb128 | and it was a tennis day | 09:35 |
| seb128 | that was grrrrrreat | 09:35 |
| Laney | \o/ | 09:35 |
| Laney | i did some walking around London | 09:35 |
| Laney | had a juice that cost £6.50 | 09:36 |
| Laney | what a magical place | 09:36 |
| Trevinho | Laney: I might have a neko++ version, is that too late? :-) | 09:36 |
| Laney | yes | 09:36 |
| Laney | sorry | 09:36 |
| seb128 | I hope it was good for this price! | 09:36 |
| Trevinho | ok... fair enough... Sure, I knew it. | 09:36 |
| Laney | it was okay | 09:36 |
| seb128 | Trevinho can get food and drinks for a day for the price of that juice | 09:37 |
| duflu | And a massage | 09:37 |
| Trevinho | Yeah, thta0s sure | 09:37 |
| Trevinho | yesterday's massage was awesome though | 09:37 |
| b4n | Trevinho: anyway, the main reason was I didn't wanted to have *all* actions ignore grabs, so I didn't want to forward *all* XI2 events as Core ones anyway | 09:40 |
| b4n | for example I didn't want window sicther to work when locked or alike | 09:40 |
| b4n | switcher* | 09:40 |
| Trevinho | b4n: sure, we can do tha too with the input manager | 09:41 |
| Trevinho | like enabling callbacks only if a such kind of customer is there | 09:41 |
| b4n | hum… yeah but the actions of e.g. the ezoom plugin should always work (e.g. ignore grabs) | 09:42 |
| b4n | and the plugin will be loaded all day long | 09:42 |
| b4n | yet it shouldn't affect how the other plugin work | 09:42 |
| b4n | and I'm not sure how we would do that with the event forwarding technique | 09:42 |
| b4n | unless tracking Core grabs and conditionally forwarding ourselves? | 09:43 |
| willcooke | DashView.cpp line 1438: <3 | 09:57 |
| b4n | Trevinho: BTW, I didn't test yet but the conflicts andyrock saw are possibly due to multiple XGetEventData() calls and the awful semantics of the return value of that function (e.g. no way to collaboratively use it from 2 sources) | 09:58 |
| Laney | ssssssshhhhhhhhhhhhhhhh | 09:59 |
| Laney | https://www.youtube.com/watch?v=EHNL8iSh4pM | 10:01 |
| willcooke | :) | 10:02 |
| ogra_ | hmm ... so i looked at ubuntu gnome 17.04 on the weekend ... and noticed that there is a gdm session idling after login that eats about 600MB ram ... | 10:04 |
| ogra_ | do we plan to keep lightdm ? | 10:04 |
| Laney | #ubuntu-gnome | 10:04 |
| ogra_ | Laney, well, that was more with a view on 18.04 | 10:04 |
| Laney | ok, well it's extremely early for that kind of decision | 10:05 |
| Laney | unknown :( | 10:05 |
| Laney | but there will certainly be bugs to fix | 10:05 |
| ogra_ | 600MB for just doing nothing are quite hilarious | 10:05 |
| jbicha | ogra_: did you install from the latest daily? | 10:07 |
| ogra_ | jbicha, yeah | 10:07 |
| jbicha | gnome-shell probably has several memory leaks :( | 10:07 |
| ogra_ | in a kvm vm ... 4GB ram, 10GB disk | 10:07 |
| ogra_ | jbicha, well, these 600M come from summing up RSS of all gdm owned processes in the ps output ... there is a gazillion settings-daemon bits each eating around 15-20MB ... it simply sums up | 10:08 |
| jbicha | https://bugzilla.gnome.org/780555 | 10:10 |
| ubot5 | Gnome bug 780555 in plugins "reduce resident memory footprint of gsd plugins" [Enhancement,Resolved: fixed] | 10:10 |
| Laney | gdm's used for screen locking in shell afaik | 10:11 |
| ogra_ | jbicha, well ... that affects everything ... but ... my point is that you essentially duplicating the complete session | 10:11 |
| jbicha | ogra_: you could file a gdm bug to request that it not run as many g-s-d plugins | 10:11 |
| Laney | so I think that it's likely to (1) be used, and (2) need to have a session open | 10:11 |
| Laney | (ICBW though) | 10:12 |
| flexiondotorg | Morning desktopers | 10:12 |
| ogra_ | right after boot my desktop eats 1.1G ... 600 of that are gdm, the others are the user session | 10:12 |
| jbicha | ogra_: yes, gdm needs to keep running; that's part of how it's designed | 10:12 |
| darkxst | hey desktopers | 10:12 |
| darkxst | ogra_, are you using NVIDIA proprietry drivers? | 10:13 |
| ogra_ | jbicha, right, but it could perhaps unload quite some bits if only handling locking, dunno | 10:13 |
| ogra_ | darkxst, in that VM ? no | 10:13 |
| ogra_ | (outside of it i do :) ) | 10:13 |
| jbicha | it also handles login on vt1 | 10:13 |
| GunnarHj | seb128: Hi Seb, are you about to upload fresh zesty langpacks? | 10:13 |
| chrisccoulson | ogra_, what we need is a display server that isn't so over-engineered. We're doing a full circle here ;) | 10:14 |
| ogra_ | jbicha, well, perhaps a reduces session and less gsd plugins might make some sense there :) | 10:14 |
| chrisccoulson | server -> manager | 10:14 |
| darkxst | ogra_, so one of the problems with the NVIDIA drivers is they end up putting their texture caches in the main process | 10:14 |
| ogra_ | *reduced | 10:14 |
| darkxst | that makes it look bad, but is not a real issue | 10:15 |
| darkxst | that obviously shouldnt transfer across to a VM though | 10:15 |
| ogra_ | darkxst, well, my point isnt the amount of ram but rather the fact that the ram use is permanently duplicated for something that mostly idles | 10:15 |
| jbicha | in 3.24 g-s-d was split up into separate plugins which hopefully will make some things better in the future | 10:16 |
| ogra_ | half of the used ram is used for gdm ... the sessions that run seem to be close to identical and i higly doubt thats required to just provide a login window and screen locking | 10:16 |
| ogra_ | anyway ... just an observation :) | 10:16 |
| darkxst | jbicha, that has nothing to do with the NVIDIA stuff | 10:17 |
| darkxst | ogra_, but on NVIDIA its not a true reading of memory use since it includes caches that are on the GPU RAM | 10:18 |
| ogra_ | darkxst, sure ... but even if gdm would only consume 100MB of a 200MB session i would find it weird ... it is the duplication of two running sessions, while only one is necessary that i dont like ... it makes the overall ram use (and thus the minimal reqs.) massively higher for no valid reason (IMHO) | 10:20 |
| darkxst | in a VM or say intel drivers it should never get anywhere near 600MB | 10:20 |
| darkxst | ogra_, there are valid reasons to keep gdm running, security is one | 10:31 |
| === infinity1 is now known as infinity | ||
| Laney | darkxst: ?????????????????????????????????????????????????????????????????????????????????????????????? | 10:31 |
| ogra_ | darkxst, welll, why does it need to run a full gnome-session to show a password box and fullscreen picture :) | 10:32 |
| ogra_ | (yes, i'm aware you want a11y and such but that doesn really not require a full gnome-shell session) | 10:32 |
| darkxst | hey Laney! | 10:33 |
| ogra_ | especially regarding security that just adds additional attach vecrots | 10:33 |
| Laney | hey | 10:33 |
| Laney | how's it going? | 10:33 |
| ogra_ | *vectors | 10:33 |
| darkxst | Laney, still in the mountains, stuggling with internets, but getting ADSL soon | 10:33 |
| Laney | do you have a massive zen beard? | 10:34 |
| darkxst | beard yes, massive zen beard probably not | 10:35 |
| Laney | :) | 10:35 |
| TheMuso | c | 10:36 |
| TheMuso | whoops wrong window | 10:36 |
| * TheMuso waves hello anyway. | 10:36 | |
| darkxst | hey TheMuso | 10:36 |
| TheMuso | Hey darkxst. | 10:36 |
| darkxst | ogra_, all authentication is handled by gdm, including drawing the lock/login screens | 10:38 |
| ogra_ | darkxst, yes ... but why does it noeed to run its own gnome-shell for that ? | 10:38 |
| ogra_ | *need | 10:38 |
| darkxst | I'm not 100% sure on the reasons for the full session, but it was related to wayland | 10:39 |
| ogra_ | all it does is show a login box on a fullscreen picture | 10:39 |
| tjaalton | is there a way to avoid the annoying swipe on lock screen? | 10:39 |
| darkxst | it is not a full gnome-shell session | 10:40 |
| ogra_ | so it could ship with a super minimal shell instead that does exactly that ... pls a few gsd plugins for things like a11y and kdb etc | 10:40 |
| darkxst | it is a majorly cut back gnome-shell session | 10:40 |
| jbicha | tjaalton: you don't need to swipe, just start entering your password | 10:40 |
| ogra_ | well, it uses the same amount of ram the user session uses ... (independent of how much that ram is, it isnt lees than the normal session ... thats my point) | 10:41 |
| tjaalton | jbicha: ah, ok | 10:41 |
| tjaalton | jbicha: yep, works | 10:42 |
| jbicha | ogra_: my gdm3/zesty says it's using 1M memory, 292MB virtual mem, 7.4 MB resident mem, 6.4 MB shared mem | 10:44 |
| ogra_ | jbicha, your gdm or all processes the gdm user owns ? | 10:44 |
| jbicha | I don't know, I opened System Monitor, right-clicked on gdm3 and selected Properties | 10:45 |
| ogra_ | right | 10:45 |
| ogra_ | ps aux| grep ^gdm ... | 10:45 |
| jbicha | you can also click the hamburger menu in System Monitor to see Dependencies | 10:45 |
| jbicha | and All Processes | 10:47 |
| jbicha | I don't know much about memory but isn't resident memory a better measure of what we should be looking at? | 10:49 |
| ogra_ | yes | 10:54 |
| ogra_ | http://paste.ubuntu.com/24353954/ | 10:56 |
| ogra_ | that sums up the RES field from ps | 10:56 |
| jbicha | ok | 10:58 |
| tjaalton | the system monitor and ps show different results for memory consumption.. SM shows just 3,4MiB for gsd-xsettings for instance, ps shows ~20 | 11:12 |
| tjaalton | ah, most of it is shared | 11:14 |
| tjaalton | ogra_: so you're result includes shared memory too ;) | 11:17 |
| tjaalton | your | 11:17 |
| tjaalton | bah | 11:17 |
| seb128 | Laney, seems fair to me to have GNOME/ubuntu-desktop here no? (/me is not on #ubuntu-gnome and not interested to move things to another channel if they impact us) | 11:35 |
| Laney | seb128: It doesn't impact Ubuntu atm | 11:36 |
| Laney | Once it does, that's fine | 11:37 |
| Laney | I don't really care though so whatever | 11:37 |
| seb128 | right, I guess it makes sense for us to start being aware of things that might need some looking at | 11:38 |
| seb128 | but yeah no big deal either way | 11:38 |
| Laney | can haz langpacks please? | 11:39 |
| Laney | to get on topic :-) | 11:39 |
| seb128 | yeah, I was going to reply to GunnarHj about that | 11:39 |
| Laney | thx! | 11:39 |
| seb128 | yw | 11:39 |
| Laney | we're trying to get 'everything' (that we know about) in today | 11:39 |
| seb128 | I started the job but it takes a bit of time | 11:40 |
| seb128 | hope to have them in about an hour | 11:40 |
| Laney | cool | 11:40 |
| GunnarHj | seb128: Great! | 11:41 |
| jbicha | Firefox :( | 11:41 |
| seb128 | what's the issue with firefox? | 11:41 |
| Laney | armhf build failure | 11:41 |
| seb128 | oh | 11:41 |
| Laney | I guess it'll just be able to go into security after though | 11:46 |
| Laney | or maybe before | 11:46 |
| ximion | Laney: D's reference compiler is fully open source now: http://forum.dlang.org/thread/oc8acc$1ei9$1@digitalmars.com | 12:22 |
| ximion | all it took was Red Hat to accelerate the process | 12:22 |
| ximion | I'll run some tests later to see whether dmd makes asgen slower or whather the speed difference is small (probably the latter, since a lot of performance-sensitive code is in C anyway) | 12:24 |
| ximion | (using dmd reduces the frequency with which I encounter compiler bugs dramatically at least :P) | 12:24 |
| Laney | ximion: nice | 12:30 |
| Laney | does it have a different stdlib implementation? | 12:30 |
| Laney | i thought ldc was alright | 12:30 |
| ximion | LDC and GDC both use a stdlib fork from dmd, so yes, we have another stdlib version :P | 12:31 |
| ximion | LDC is fine, but I am still hitting compiler bugs, including gems like https://github.com/ldc-developers/ldc/issues/2022 , while the reference compiler doesn't have those. Also, Red Hat told me they will use dmd | 12:32 |
| ximion | and I am currently thinking about what to do for Debian so we don't end up with something as bad as the OCaml or Haskell world :P | 12:33 |
| ximion | (which isn't bad per-se, but rather maintenance-intensive) | 12:33 |
| ximion | I asked the D guys for advice on the issues: http://forum.dlang.org/thread/hhefnnighbowonxsnbdy@forum.dlang.org | 12:33 |
| ximion | the outcome could be that we will just stick with LDC as the best option and only use dmd occasionally | 12:34 |
| ximion | Laney: but from the looks of it it appears like Red Hat / GNOME is really giving D a shot as GNOME platform language, which is rather nice | 12:36 |
| ximion | at least a better choice than the "JavaScript is the language you shall write new GNOME apps in" :P | 12:37 |
| ximion | *idea from a few years ago | 12:37 |
| qengho | 'Sup. | 12:53 |
| Laney | ximion: what are they using it for? | 13:09 |
| ximion | Laney: at time as something to recommend for newcomers besides C in case Vala doesn't cut it | 13:09 |
| Laney | does it have good bindings? | 13:10 |
| ximion | jup - the GTK+ D bindings are superb | 13:10 |
| ximion | (from a developer's viewpoint at least) | 13:10 |
| ximion | initially I thought that this was just some random exploration, but it looks like some serious work was invested into getting Fedora & Co. support D nicely - with LDC at time, but soon with DMD, as far as I was told | 13:12 |
| tsdgeos | was a pleasure working for Canonical! /me waves | 13:32 |
| Laney | :/ | 13:33 |
| Laney | ximion: sounds like libraries in D is painful though | 13:35 |
| Laney | from your thread | 13:35 |
| ximion | Laney: it's far better than Haskell and OCaml, but not as nice as C or C++ | 13:39 |
| ximion | D fascinates me in that it always manages to do something really awesome and then screws it up with some stupid papercut | 13:40 |
| ximion | (e.g. the JSON interface in the standard library sucks, but the language itself is capable of doing Python-esque neat serialization from raw structs (https://dlang.org/phobos/std_json.html vs. http://vibed.org/api/vibe.data.json/)) | 13:43 |
| willcooke | I'm going to start drinking. o/ | 17:16 |
| seb128 | goo | 17:16 |
| seb128 | doh, he did a didrocks again | 17:16 |
| ogra_ | seems to be in fashion recently | 17:16 |
| didrocks | but but, it's copyrighted | 17:17 |
| seb128 | Laney, sil2100, GunnarHj, langpacks base refresh uploaded | 17:17 |
| Laney | you little beauty | 17:17 |
| sil2100 | seb128: wooo hooo! | 17:17 |
| * sil2100 hugs seb128 | 17:17 | |
| seb128 | :-) | 17:17 |
| seb128 | they are still making they way to the queue so wait a few minutes | 17:18 |
| seb128 | on that note I'm off to prepare diner, enjoy the evening desktopers | 17:18 |
| kenvandine | good night seb128 | 17:19 |
| seb128 | night | 17:19 |
| === bregma__ is now known as bregma | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!