| * zyga-x240 is tired, very bad night | 05:22 | |
| mborzecki | morning | 06:19 |
|---|---|---|
| dot-tobias | morning | 06:28 |
| pstolowski | morning | 07:00 |
| mvo | pstolowski: good morning! just fyi, I'm about to push some support thing around the import PR | 07:00 |
| zyga-x240 | good morning guys | 07:00 |
| mvo | pstolowski: so probably best to not also work on it right now or we risk conflicts | 07:00 |
| mvo | good morning zyga-x240 | 07:00 |
| mborzecki | mvo: hey | 07:01 |
| mvo | hey mborzecki ! good morning to you as well :) | 07:01 |
| mvo | how are you all? | 07:01 |
| pstolowski | mvo: hey, ack. i'll get back to it in the afternoon then, i'll focus on tests for cleanup on interrupted import | 07:02 |
| * zyga-x240 is pretty sleepy, lucy gave us a beating at night | 07:02 | |
| mvo | pstolowski: we should probably have a quick chat, we discussed with samuele last night, there is this problem that the current import approach is racy, we don't need many changes but a little bit, give me 5min and I can push a sketch of what we discussed | 07:03 |
| pstolowski | mvo: ok | 07:03 |
| mvo | pstolowski: there is 9461,9462 and 9467 (all relatively small) in the meantime if you feel like it :) | 07:04 |
| pstolowski | sure | 07:08 |
| mvo | pstolowski: I wrote the idea down in https://github.com/snapcore/snapd/pull/9036#discussion_r499816703 now - hope it makes sense(?) | 07:09 |
| pstolowski | mvo: interesting points there. should we also delay our own restarts, or not start import if restart is pending? | 07:14 |
| mborzecki | mvo: i think that the comments i made in 9461 can be addressed in #9467 | 07:15 |
| mborzecki | and perhaps have the former closed actually | 07:15 |
| mvo | mborzecki: sure, probably too granular all of this, sorry for that :/ | 07:16 |
| dot-tobias | ijohnson xnox I'm trying to build the 20-armhf (or 20-arm64) pi-gadget snap, fails both on a Focal amd64 machine as well as remote-build with arm* --build-on flag. Anything I'm missing for the 20 build, since README instructions seem to be for uc18? | 07:16 |
| mvo | mborzecki, pstolowski thanks for the reviews! | 07:16 |
| zyga-x240 | mvo: I commented on that idea | 07:17 |
| zyga-x240 | just drive by comment | 07:17 |
| mborzecki | mvo: pstolowski: fwiw, can we actually detect the real snapshot size when reading the body? what if someone appends just some random content at the end after the legitimate zip data is finished? | 07:17 |
| mvo | mborzecki: we have the content-length and the limited reader now, that should help or am I misunderstanding? | 07:21 |
| mborzecki | mvo: hm maybe i'm complicating this a bit, what if i have a 1k snapshot, send content-length: 1G, and send the fill the rest with garbage? | 07:25 |
| pstolowski | mborzecki: i believe you need to be root to import. we do check if zip is valid, plus we will have disk space check there | 07:29 |
| pstolowski | or am i misunderstanding the concern here? | 07:30 |
| mvo | mborzecki: it will error when reading the tar content but yeah, in general we can not protect much about bad actors here. the content-length is mostly to ensure we can do size checks and that we protect against accidents | 07:30 |
| mborzecki | mvo: otoh as pstolowski mentioned, you need to be root, so there's easier ways to break stuff | 07:31 |
| zyga-x240 | brb | 07:32 |
| mvo | mborzecki: yeah | 07:39 |
| mvo | pstolowski, pedronis how does https://github.com/snapcore/snapd/compare/master...mvo5:snapshot-import-3?expand=1 look ? this should make the import race-free (at least on the filesystem level) | 07:51 |
| mvo | pstolowski, pedronis also (to me but I'm biased) slightly easier to read(?) | 07:51 |
| mvo | (tests need updating still but integration works) | 07:52 |
| pstolowski | mvo: the url seems broken, wants me to open a PR | 07:52 |
| mvo | pstolowski: sorry! is this one better? https://github.com/snapcore/snapd/compare/master...mvo5:snapshot-import-3 | 07:53 |
| mvo | https://github.com/snapcore/snapd/compare/master...mvo5:snapshot-import-3 | 07:54 |
| pedronis | mvo: did you see zyga comment, not that I understand it | 07:54 |
| mvo | pedronis: I did, not sure how this helps against reboots, but once he is back I will ask him | 07:56 |
| pedronis | yes, that's the same question I have, also not clear what we would lock | 07:56 |
| mvo | pedronis: yeah, we could lock the $setid_importing file but not sure about the gain | 07:57 |
| pedronis | anyway checking for hashes will add more questions as well | 07:59 |
| mvo | pedronis: right, which ones to be exact? if we have hashes in export.json we can validate them after line 582. or am I missing something? | 08:01 |
| pedronis | mvo: we'll need to do some locking and put some data in importing to avoid importing the same thing twice if asked in quick succession | 08:02 |
| pstolowski | mvo: not sure, it shows all the changes against master i think | 08:02 |
| mvo | pedronis: oh, interessting. yes! | 08:03 |
| pedronis | anyway we are not there yet | 08:03 |
| mvo | pstolowski: oh, right, let me try to compare against just the old pr if that helps? | 08:03 |
| pstolowski | mvo: nah, i think i'll just look at entire thing again | 08:04 |
| mvo | pstolowski: might actually be easier | 08:04 |
| pstolowski | mvo: i think i'll hold off from touching import PR for now, it's moving too much | 08:26 |
| mborzecki | 2020-10-06 08:03:25 Cannot allocate google:centos-8-64: cannot allocate new Google server google:centos-8-64 hmm (oct060800-322222): timeout waiting for google:centos-8-64 (oct060800-322222) to provision | 08:28 |
| mvo | pstolowski: sorry for that, it should calm down very soon I think | 08:37 |
| mborzecki | zyga-x240: https://developers.redhat.com/blog/2020/09/24/new-c-features-in-gcc-10/?sc_cid=7013a00000260vRAAQ | 08:37 |
| pstolowski | mvo: no worries | 08:39 |
| pstolowski | mvo: i've fun with services now and that issue from the forum ;) | 08:39 |
| zyga-x240 | mborzecki: nothing really interesting | 08:40 |
| zyga-x240 | mborzecki: C++ is a sprawling mess | 08:40 |
| mvo | pstolowski: ha! great. | 08:40 |
| * zyga-x240 keeps hacking | 08:40 | |
| zyga-x240 | there was a bit of worry as city-wide alarm sirens were on for like 10 minutes | 08:41 |
| zyga-x240 | fortunately it's just a test | 08:41 |
| zyga-x240 | but man, a bit nervous for a moment | 08:41 |
| zyga-x240 | *those are LOUD* | 08:41 |
| dot-tobias | Is cloud-init still unsupported/buggy when building a core20 image, or does ubuntu-image need an update after https://github.com/CanonicalLtd/ubuntu-image/pull/186? I have some additional setup for my images in a cloud.conf that can't be reliably replicated through gadget or other supported mechanisms. | 08:41 |
| zyga-x240 | bombing run alarm test | 08:41 |
| mvo | 9462 is an easy win | 08:42 |
| mvo | very small | 08:42 |
| mborzecki | mvo: pedronis: https://github.com/snapcore/pc-amd64-gadget/pull/50 | 08:43 |
| zyga-x240 | +1 | 08:44 |
| pedronis | dot-tobias: depending what kind of model grade you are building, you'll have to put the cloud-init config in the gadget itself | 08:45 |
| dot-tobias | pedronis: Thanks, re-read https://core.docs.ubuntu.com/en/reference/gadget at Setup files. Don't remember why I didn't go that route initially, but it's been > 1 year so why not try again. Could you please elaborate what you mean by “model grade”? 😊 | 08:50 |
| pedronis | dot-tobias: https://core.docs.ubuntu.com/en/releases/uc20 | 08:52 |
| pedronis | under Model definition | 08:52 |
| dot-tobias | pedronis: Thank you very much! Overlooked this page, I knew there was a new way to specify the channel for required snaps now … | 08:54 |
| dot-tobias | ijohnson: Re https://bugs.launchpad.net/snapd/+bug/1898622 – can you give me a hint where/which logs to check to see if this happens in my case as well? I have a local uc20 gadget snap (i.e. model grade set to “dangerous” + passing local snap via --snaps) and the image boots on a Pi 4, but only with a blinking cursor like the thread opener in https://forum.snapcraft.io/t/ubuntu-core-20-hangs-with-added-snap/20342. | 12:17 |
| ijohnson | hi dot-tobias | 12:21 |
| ijohnson | I see you had a couple questions earlier, did you get your cloud-init question answered firstly? | 12:22 |
| ijohnson | and secondly, re building the 20 pi-gadget, what architecture are you trying to build for and what's the host system where you are trying to build the gadget? | 12:22 |
| dot-tobias | hi ijohnson, sorry for brevity without proper thanks and please 😊 First: | 12:24 |
| ijohnson | haha no worries | 12:25 |
| dot-tobias | Re cloud-init: Kind of, I placed it in the gadget but can't test if it works because I first need to have it boot properly 😄 Like https://forum.snapcraft.io/t/how-to-preconfigure-custom-image/4154/15?u=tobias describes, at some point way back, cloud.conf in the gadget wasn't applied – at least in my testing. Feeding it to ubuntu-image worked. | 12:25 |
| ijohnson | dot-tobias: for uc20 specifically the inverse is now true, feeding to ubuntu-image no longer works, but putting it in your gadget should work, we have tests for this, but in all honesty I haven't tested it for a couple weeks now so maybe something has broken again on this front | 12:26 |
| dot-tobias | Second, the pi20-gadget: I'm trying to build for armhf, I applied your patch from https://github.com/snapcore/pi-gadget/pull/43 and it builds just fine on an amd64 host. Then I build the image with ubuntu-image and flash to an SD. The Pi 4 seems to boot, but only to a blinking cursor on the screen. | 12:27 |
| dot-tobias | ijohnson: Will let you know if cloud.conf inside gadget snaps works for me as soon as I have the system booting properly 😄 | 12:29 |
| ijohnson | dot-tobias: ok, great happy to hear that patch works, I need to go back and address the comments on that pr before it can be merged but still good to know it works :-) | 12:31 |
| dot-tobias | ijohnson: Unfortunately, I have to hurry to pick up my daughter at kindergarden. May I DM you on the snapcraft forum, because my IRC bouncer isn't as reliable as I would like it to be? | 12:31 |
| ijohnson | dot-tobias: yes of course | 12:31 |
| ijohnson | I'll wait to hear from you there then | 12:31 |
| dot-tobias | s/at/from/i 😄 Great, thanks in advance ijohnson! | 12:31 |
| mborzecki | ijohnson: standup or are you at the roadmap review? | 13:04 |
| ijohnson | mborzecki: I'm watching the roadmap | 13:04 |
| * zyga-x240 is on roadmap review | 13:04 | |
| ijohnson | cachio: have you seen the journal-state test fail like this: https://pastebin.ubuntu.com/p/HgxDDBNXgd/ | 14:30 |
| ijohnson | ? | 14:30 |
| ijohnson | the code looks rather odd `test 0 -eq 1` will never be true no matter how many iterations are run ... | 14:31 |
| cachio | ijohnson, no, weird | 14:31 |
| cachio | let me check if I can reproduce it | 14:31 |
| cachio | ijohnson, just happening in ubuntu 20.10? | 14:32 |
| ijohnson | cachio: yes that's where I just saw it fail | 14:32 |
| ijohnson | cachio: also did you see my update in the su doc about uc20-recovery ? | 14:32 |
| ijohnson | I can reproduce it now like 80+% of the time with your qemu cmdline but 0% with my qemu cmdline | 14:33 |
| cachio | yes | 14:33 |
| ijohnson | it's very odd and confusing and frustrating | 14:33 |
| cachio | could be associated to "no secure boot" | 14:33 |
| cachio | ? | 14:33 |
| ijohnson | I don't think so because I changed my cmdline to boot without secure boot and still couldn't reproduce it | 14:34 |
| cachio | ijohnson, I could reproduce the error on jounal-state test | 14:44 |
| ijohnson | cachio: interesting, what's the issue? | 14:45 |
| cachio | ijohnson, don't know yet | 14:47 |
| cachio | just failed | 14:47 |
| ijohnson | well good that you can reproduce it, that's always better than not being able to reproduce it :-) | 14:47 |
| cachio | ijohnson, well, seems to be that I used incorrectly the retry | 14:49 |
| cachio | ijohnson, I'll fix it and create a PR | 14:50 |
| ijohnson | nice thanks | 14:58 |
| * zyga goes for PT | 15:04 | |
| * cachio lunch | 15:33 | |
| ijohnson | cachio: I just saw the journal-state test fail again this time on uc20: https://pastebin.ubuntu.com/p/xKPMcypjDq/ is it the same thing ? | 15:51 |
| mvo | pedronis: 9469 is the snapshot work as discussed last night, still some gaps in the tests but should be without races | 16:11 |
| === King_InuYasha is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as King_InuYasha | ||
| ijohnson | cachio: I think I finally figured out the uc20-recovery problem with your qemu command line args, or at least some kind of explanation | 17:38 |
| ijohnson | cachio: your command line has this: `-net nic,model=virtio -net user,hostfwd=tcp::8022-:22` while mine has `-netdev user,id=mynet0,hostfwd=tcp::8026-:22 -device virtio-net-pci,netdev=mynet0` | 17:39 |
| ijohnson | I don't know precisely what the difference in behavior is, but if I use your qemu command line net args the test fails, but with mine it passes | 17:39 |
| cachio | ijohnson, nice | 18:03 |
| cachio | I'll update my docs to start using yours | 18:03 |
| cachio | thanks for the research | 18:04 |
| zyga | back from pT | 18:20 |
| ijohnson | hey zyga | 18:26 |
| zyga | hey! | 18:26 |
| ijohnson | I gave a +1 to your notifications pr last night, it looks good! | 18:26 |
| zyga | ijohnson thank you, I will iterate to add some tests and then ask macieck for a re-review | 18:27 |
| zyga | I think he and mvo asked for tests on IRC | 18:27 |
| ijohnson | I started and am about halfway through the biggest file on your udev pr too | 18:27 |
| zyga | ijohnson woot! | 18:27 |
| zyga | it's a bit tedious | 18:27 |
| zyga | but I tried to structure the boring parts to be readable | 18:27 |
| ijohnson | it is a bit tedious and takes some close eyes for sure | 18:27 |
| zyga | thank you so much! that's my oldest really useful PR that has yet to land | 18:27 |
| zyga | (well, others are older but this is ready IMO) | 18:27 |
| zyga | I'm working on spread tests for inhibition locks now, just got back and noticed the test failed, but it worked interactively in spread -debug shell | 18:28 |
| zyga | must be missing something simple :) | 18:28 |
| ijohnson | simple missing things are the best missing things imho | 18:28 |
| zyga | I got tea and am digging into things :) | 18:35 |
| zyga-x240 | weird | 18:43 |
| zyga-x240 | my other PC disconnected | 18:43 |
| zyga-x240 | hmm | 18:43 |
| zyga-x240 | back | 18:44 |
| zyga-x240 | :) | 18:44 |
| zyga-x240 | hmm, nothing looking out of the ordinary, trying -debug | 19:01 |
| zyga-x240 | DOH | 19:14 |
| zyga-x240 | ijohnson: + snap install --classic SNAP_NAME | 19:14 |
| zyga-x240 | what could be wrong ;D | 19:14 |
| ijohnson | haha | 19:14 |
| ijohnson | SNAP_NAME | 19:14 |
| ijohnson | classic | 19:14 |
| zyga-x240 | not enough $ | 19:14 |
| zyga-x240 | ;D | 19:14 |
| ijohnson | haha good one | 19:14 |
| zyga-x240 | I was trying to come up with a way to get some measurements done while a compound operation like "snap refresh" runs | 19:15 |
| zyga-x240 | and I ended up using inotify in tests | 19:15 |
| zyga-x240 | I think that's a first for us | 19:15 |
| ijohnson | yeah all I see is a comment from Maciej about arch linux in prepare.sh about d-bus needing to inotify on some path | 19:16 |
| zyga-x240 | I will break out a few helpers | 19:16 |
| zyga-x240 | yeah, that's related to the fact that dbus uses inotify to detect .service files | 19:17 |
| zyga-x240 | but this only works if the relevant directory exists at the time dbus itself starts | 19:17 |
| zyga-x240 | so we created it so that it works on first install IIRC | 19:17 |
| zyga-x240 | inotify is a pretty poor API | 19:17 |
| ijohnson | yep that's exactly what the comment says :-) | 19:17 |
| ijohnson | good memory! | 19:17 |
| zyga-x240 | haha, this time | 19:18 |
| zyga-x240 | I forget many many things now | 19:18 |
| zyga-x240 | ijohnson: did you see the nvidia ai video conferencing thing? | 19:19 |
| ijohnson | zyga-x240: no I don't think so | 19:19 |
| zyga-x240 | https://www.youtube.com/watch?v=NqmMnjJ6GEg | 19:20 |
| zyga-x240 | pretty interesting IMO, would love to see this in practice | 19:20 |
| ijohnson | yeah that's really cool | 19:22 |
| ijohnson | I wonder how well it works with a non-static background though | 19:24 |
| zyga-x240 | I suspect it needs more keyframes with real image | 19:24 |
| ijohnson | yeah | 19:24 |
| zyga-x240 | but it's an interesting evolution of "motion vectors" and other classic video tricks | 19:25 |
| zyga-x240 | cannot wait for voice equivalent | 19:25 |
| zyga-x240 | bi-directional audio to text to audio codec | 19:25 |
| zyga-x240 | with emotions :) | 19:25 |
| zyga-x240 | maybe irc and mumble could merge | 19:26 |
| ijohnson | ah that's interesting, but I imagine very difficult to get right but without lots of data on individual users which is a bit of a privacy concern | 19:26 |
| ijohnson | like imagine if this service can impersonate the voice of someone you know / trust | 19:27 |
| ijohnson | with arbitrary text | 19:27 |
| zyga-x240 | yeah | 19:27 |
| zyga-x240 | I think in the age of deep fakes we are really there already | 19:27 |
| zyga-x240 | this just makes it mass market | 19:27 |
| ijohnson | true I guess I just haven't seen that for audio yet | 19:28 |
| zyga-x240 | (or so the AI overlord told me to type ;-) | 19:28 |
| ijohnson | deepfake video is definitely a thing which I guess implies that audio is already there and maybe it just wasn't scary enough to make headlines the way video did | 19:28 |
| zyga-x240 | ijohnson: there's a bunch of "obama speaks anything" videos on YT, given that he's got lots of public domain recordings available | 19:28 |
| zyga-x240 | no need to do trump variant though, he really speaks anything just like that ;-) | 19:29 |
| * zyga-x240 refrains from more political joes | 19:29 | |
| zyga-x240 | *jokes | 19:29 |
| ijohnson | look you just made one! | 19:30 |
| ijohnson | while trying to refrain from making them | 19:30 |
| * ijohnson goes away and tries to debug pi things | 19:30 | |
| zyga-x240 | haha | 19:30 |
| zyga-x240 | so the test was useful | 19:58 |
| zyga-x240 | I broke something in snapstate, checking | 19:59 |
| zyga-x240 | I mean, in my branch | 19:59 |
| zyga-x240 | it's just refactoring to make it fit the model | 19:59 |
| zyga-x240 | DOh | 20:18 |
| zyga-x240 | nothing is broken | 20:18 |
| zyga-x240 | I patched the test in the wrong spot | 20:18 |
| * zyga-x240 adjusts | 20:18 | |
| ijohnson | zyga-x240: could you +1 9378? I addressed your feedback and you said your review was a +0.9 :-) | 20:20 |
| zyga-x240 | looking | 20:20 |
| ijohnson | cachio: also could you take a look again at #9378 ? | 20:20 |
| ijohnson | would be great to land this finally | 20:20 |
| zyga-x240 | done, thanks for changing @HOLD... | 20:21 |
| ijohnson | thank you! | 20:21 |
| zyga-x240 | cachio: btw, I realized that my comment about prepare/restore on nested helpers may have been confusing | 20:22 |
| zyga-x240 | I didn't imply that we should not have prepare/restore | 20:22 |
| zyga-x240 | but that they are unclear in the context of explicit resource management performed by other commands | 20:23 |
| zyga-x240 | I'm sure all those functions do something useful | 20:23 |
| cachio | ijohnson, sure | 20:23 |
| zyga-x240 | I was trying to understand their function and see if any of that functionality should shift from one command to another | 20:23 |
| cachio | zyga-x240, ah, ok | 20:23 |
| cachio | zyga-x240, I'll go back to that PR once I finish the current one | 20:24 |
| zyga-x240 | ok | 20:24 |
| cachio | zyga-x240, you are talking about the nested one, right? | 20:26 |
| zyga-x240 | yes | 20:26 |
| zyga-x240 | cachio: btw, did you know about $'foo' in bash? | 20:27 |
| cachio | bo | 20:27 |
| cachio | no | 20:27 |
| cachio | zyga-x240, what? | 20:27 |
| zyga-x240 | I found out today | 20:27 |
| zyga-x240 | echo $'hello\n $world' | 20:27 |
| ijohnson | what does that do | 20:28 |
| zyga-x240 | handles specific \ sequences | 20:28 |
| zyga-x240 | acts as ' ' otherwise | 20:28 |
| zyga-x240 | I also found | 20:28 |
| * ijohnson is ready to run for the hills at mention of more bashisms | 20:28 | |
| zyga-x240 | ${foo@Q} | 20:28 |
| zyga-x240 | which is genuinely very useful | 20:28 |
| zyga-x240 | it expands foo as variable and quotes correctly for bash to read again | 20:28 |
| zyga-x240 | the @xxx syntax has a few more things it can do | 20:28 |
| zyga-x240 | but this one is most practical for our stuff | 20:29 |
| zyga-x240 | as it would let us quote things and pass to nested bash easily | 20:29 |
| zyga-x240 | anyway | 20:29 |
| ijohnson | oooh that is really cool | 20:29 |
| zyga-x240 | just more ladmines | 20:29 |
| zyga-x240 | in the no-mans bash land | 20:29 |
| zyga-x240 | just those pop candy | 20:29 |
| zyga-x240 | not your leg off | 20:29 |
| cachio | zyga-x240, cool | 20:30 |
| cachio | zyga-x240, how did you discover that? | 20:30 |
| cachio | reading docs? | 20:30 |
| zyga-x240 | cachio: by reading twitter and reading bash to correct an almost-useful reference | 20:31 |
| zyga-x240 | and finding more | 20:31 |
| zyga-x240 | "marry has a little lamb" | 20:31 |
| zyga-x240 | !:q | 20:31 |
| zyga-x240 | run that in a bash | 20:31 |
| zyga-x240 | it's another quoting mechanism | 20:31 |
| zyga-x240 | but only for interactive job | 20:32 |
| zyga-x240 | ${foo@Q} is generic | 20:32 |
| cachio | zyga-x240, nice | 20:33 |
| cachio | learning bash in twitter hehehe | 20:33 |
| cachio | it is cool | 20:34 |
| * zyga-x240 should get green pass now | 20:35 | |
| * zyga-x240 goes to brush his teeth | 20:37 | |
| zyga-x240 | cachio: I wrote a small add-on to tests.cleanup | 20:37 |
| zyga-x240 | tests.cleanup pop | 20:37 |
| zyga-x240 | it's useful when you do something | 20:37 |
| zyga-x240 | install cleanup via defer | 20:37 |
| zyga-x240 | want to clean up on failure (which runs in restore) | 20:38 |
| cachio | zyga-x240, awesome | 20:38 |
| zyga-x240 | but also want to clean up early on the happy code path | 20:38 |
| zyga-x240 | so that you don't have to repeat the "undo" logic in any way | 20:38 |
| zyga-x240 | anyway, I'll clean that up (add tests) and propose tomorrow | 20:38 |
| zyga-x240 | today I'm just going to see this inhibition lock test pass on 18.04 and 20.04 and call it a day | 20:39 |
| zyga-x240 | OUCH | 20:54 |
| zyga-x240 | I was cleaning the kitchen | 20:54 |
| zyga-x240 | and we routinely cut milk boxes in half to clean them (those are recycled and get collected twice a month) | 20:55 |
| zyga-x240 | and cut right through my thumb nail and good part of thumb | 20:55 |
| zyga-x240 | so... | 20:55 |
| * zyga-x240 EODs | 20:55 | |
| zyga-x240 | but I got x3 pass | 20:55 |
| zyga-x240 | so some good in the ene | 20:55 |
| zyga-x240 | *end | 20:55 |
| * zyga-x240 pushed handlers changes, more tomorrow | 20:56 | |
| zyga-x240 | need to find some bandage | 20:57 |
| zyga-x240 | good that I don't use my right thumb for typing that often | 20:57 |
| zyga-x240 | my left thumb is space bar | 20:57 |
| zyga-x240 | right.... dunno | 20:57 |
| zyga-x240 | maybe sometimes space | 20:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!