| === mbarnett` is now known as mbarnett | ||
| SpamapS | Can I get a quick IRC FFE for git-review 1.21 ? (unseeded leaf package) | 01:27 |
|---|---|---|
| === Ursinha is now known as Ursinha-afk | ||
| SpamapS | debdiff is here: http://paste.ubuntu.com/5694217/ | 01:38 |
| ScottK | SpamapS: You've tested this? | 01:56 |
| SpamapS | ScottK: have done 3 review submits with it to openstack projects. Not 100% code coverage .. but itI don't smell any smoke. | 01:58 |
| ScottK | SpamapS: OK. Got for it. | 01:58 |
| ScottK | Got/Go | 01:59 |
| SpamapS | ScottK: cool thanks :) | 01:59 |
| ScottK | You're welcome. | 01:59 |
| SpamapS | ugh, what a wonderful time for my home cable connection to die | 01:59 |
| bkerensa | heh | 02:00 |
| === superm1_ is now known as superm1 | ||
| SpamapS | ScottK: finally got internet back on in my build box, so if you're still around git-review is uploaded now. | 03:12 |
| ScottK | OK. I'll have a look when it appears. | 03:13 |
| ScottK | SpamapS: Accepted. | 03:19 |
| SpamapS | ScottK: ^5 | 03:21 |
| === doko_ is now known as doko | ||
| jamespage | please could the rtslib update be accepted into raring-proposed | 10:31 |
| ScottK | doko: I absolutely don't have time to deal with this today because I need to leave for $work meetings soon, but ypur python3-defaults SRU moves py3versions from python3-minimal to python3 and causes Bug 1167183 and some dupes. | 11:45 |
| ubot2 | Launchpad bug 1167183 in python3-defaults (Ubuntu) "package python3 3.2.3-5ubuntu1 failed to install/upgrade: trying to overwrite '/usr/bin/py3versions', which is also in package python3-minimal 3.2.3-5ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/1167183 | 11:45 |
| ScottK | Anyone who's in the SRU team ^^^^ | 11:45 |
| doko | ScottK, ok, looking ... | 11:45 |
| ScottK | I didn't check if anything else changed. | 11:46 |
| === agateau_ is now known as agateau | ||
| doko | ScottK, hmm, there is more ... looking to fix it for raring first | 12:20 |
| === ogra_` is now known as ogra_ | ||
| === cyphermox_ is now known as cyphermox | ||
| === hggdh_ is now known as hggdh | ||
| === Ursinha-afk is now known as Ursinha | ||
| xnox | dobey: slangasek: Old U1 music store screenshot is removed from the slideshow in raring images the day before UI freeze, and replaced with my rhythmbox playing Adele =) | 13:14 |
| xnox | not sure if we want to fix 12.04.3 slideshow as well. | 13:15 |
| dobey | xnox: i think we'll want to fix the slideshow for 12.04, once the rhythmbox-ubuntuone changes land in 12.04 updates, i think | 13:26 |
| xnox | dobey: ok. i will check if we can reuse the raring slide image & change the screenshot to have e.g. precise theme on the window decorators. | 13:27 |
| xnox | dobey: what was the bug number such that I can assign it to myself. | 13:28 |
| dobey | bug #1166356 | 13:29 |
| ubot2 | Launchpad bug 1166356 in ubiquity-slideshow-ubuntu (Ubuntu Raring) "[UIFe] Old music store interface going away on server" [Undecided,New] https://launchpad.net/bugs/1166356 | 13:29 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| rtg_ | infinity, I think linux-ti-omap4 should be removed from raring-proposed. I think armhf generic should supersede that kernel. That will also get it off the FTBS list. | 14:23 |
| ogra_ | rtg_, err, nope | 14:23 |
| ogra_ | panda will stay with the quantal kernel | 14:23 |
| rtg_ | why? | 14:24 |
| ogra_ | becauase we will keep the desktop image | 14:24 |
| ogra_ | (dont ask ) | 14:24 |
| ogra_ | and we have no way in i.e. flash-kernel to easily handle both | 14:24 |
| rtg_ | so, should the Raring mainline kernel still be supplying omap4-panda-es.dtb ? | 14:24 |
| ogra_ | so the quantal one has to stay for server too | 14:24 |
| ogra_ | optionally for the brave i'd say | 14:25 |
| ogra_ | and in 13.10 we actually want to drop that mess | 14:25 |
| rtg_ | ogra_, ah, we talked about this a week or so ago, didn't we. | 14:25 |
| ogra_ | yeah | 14:25 |
| rtg_ | doh! | 14:25 |
| * ogra_ would have happily dropped desktop panda | 14:25 | |
| ogra_ | as woulld infinity i think | 14:26 |
| rtg_ | this was the case where infinity was going to re-sync from Quantal if that kernel ever changed. | 14:26 |
| ogra_ | right | 14:26 |
| ogra_ | in 13.10 server we should actually use generic ... so i dont think it makes sense to artificially rip it out now | 14:27 |
| rtg_ | yeah, there is no harm in carrying the DTB. | 14:27 |
| rtg_ | so I guess at the very least linux-ti-omap4 should get promoted to release ? | 14:28 |
| ogra_ | yeah | 14:29 |
| doko | RAOF, ^^^ | 14:42 |
| kenvandine | can someone please look at friends? | 15:24 |
| didrocks | kenvandine: finally having a changelog content from what I saw? ;) | 15:25 |
| seb128 | slangasek, infinity, cjwatson: do we have any work in progress/release notes for raring somewhere? | 15:26 |
| kenvandine | yes, we are going to make sure that always happens :) | 15:26 |
| didrocks | \o/ | 15:26 |
| seb128 | Laney, do you do approval in freeze times? ;-) | 15:29 |
| seb128 | it seems a bit suboptimal that almost nothing from the main/desktop goes through on european hours atm | 15:29 |
| Laney | yeah, I can do | 15:29 |
| Laney | will do some in a bit | 15:29 |
| seb128 | Laney, thanks | 15:29 |
| Laney | slangasek was looking at friends though wasn't he? | 15:29 |
| seb128 | I think so | 15:30 |
| seb128 | but I see -intel s-c rhythmbox glib etc in the queue | 15:30 |
| seb128 | im-config | 15:30 |
| seb128 | sessioninstaller | 15:30 |
| seb128 | note, I uploaded some of those, but still would be good to have stuff going during the european day ;-) | 15:30 |
| kenvandine | Laney, last i saw slangasek said he was going to leave friends, so not sure if he still is | 15:34 |
| kenvandine | i am mostly anxious for a fix that landed on friday to make it in, people keep bugging me about it :) | 15:34 |
| doko | seb128, I'm not -release, and only doing the ftbfs fixes | 15:35 |
| seb128 | doko, thanks for approving the build fixing, that's useful ;-) | 15:36 |
| seb128 | we just need a release team member as well to approve the other uploads... | 15:36 |
| Laney | well, my ported indicator-session seems to mostly work so I'll do some queue reviews now and tidy that up tomorrow | 15:44 |
| seb128 | Laney, thanks | 15:45 |
| * Laney rejects 3 of the 4(!) friends in the queue | 15:45 | |
| seb128 | joys of daily landing :p | 15:45 |
| ogra_ | poor friends | 15:46 |
| * Laney the loner | 15:46 | |
| ogra_ | you kept one at least :) | 15:46 |
| kenvandine | :) | 15:47 |
| skellat | Hello. I've got a Fix Committed flag on Launchpad Bug #1158431 and haven't seen yet if the new package has built and hit the queue to fix this bug for Xubuntu. | 15:52 |
| ubot2 | Launchpad bug 1158431 in shimmer-themes (Ubuntu) "lightdm graybird login issues on raring" [Undecided,Fix committed] https://launchpad.net/bugs/1158431 | 15:52 |
| ochosi | skellat: i set it to "fix committed" because the fix is in git (this is what mr_pouit and i settled on for bug management) | 15:55 |
| ochosi | skellat: so i guess the bug status should be changed to whatever the "general public" here sees as fit | 15:56 |
| skellat | Crud | 15:56 |
| skellat | ochosi: Let us take this back to #xubuntu-devel | 15:56 |
| ochosi | skellat: sure | 15:56 |
| cjwatson | fix committed for "fix is in version control" is generally fine | 15:57 |
| cjwatson | at least for development releases. rules are different for stable updates | 15:57 |
| skellat | Okay | 15:57 |
| skellat | Since our developers are tied up it looks we need a sponsor too to navigate this in | 15:58 |
| ochosi | yes, please | 15:58 |
| ochosi | it's a bit unfortunate that i'm only the artwork lead and can't update my own packages... | 15:58 |
| ogra_ | bdmurray, the seed change and upload for g-c-c-u happened i didnt edit the changelog, can you close the bug by hand ? | 16:05 |
| bdmurray | ogra_: will do | 16:05 |
| ogra_ | thx | 16:05 |
| slangasek | seb128: release notes> https://wiki.ubuntu.com/RaringRingtail/TechnicalOverview, unfortunately it went out very bare for the desktop at beta time... | 16:07 |
| slangasek | Laney: I was no longer looking at friends; happy for someone else to take it | 16:07 |
| seb128 | slangasek, hum, yeah, not a lot of desktop there ... is that the right page to edit toward release? | 16:08 |
| doko | slangasek, could you look at the two python3-defaults uploads? RAOF doesn't seem to be there | 16:08 |
| slangasek | seb128: "joys of daily landing" - well, I think there's a bug in how the autolanding code handles the unapproved queue, it seems to think that because it hasn't reached the archive yet it needs to upload *again* with no other changes | 16:08 |
| seb128 | slangasek, that's another side effect of "can't get content of the syncs in the queue" :-( | 16:09 |
| slangasek | seb128: for the moment, yes - we usually refactor between beta and release, but we haven't started that yet so anything you put there now will be ported over | 16:09 |
| seb128 | slangasek, but yeah, agreed it's a bug | 16:09 |
| slangasek | doko: I'm about to step away from the keyboard for a bit, but can look when I return. This is for precise/quantal? | 16:09 |
| doko | slangasek, yes | 16:11 |
| antarus_ | slangasek: wow this nvidia thing is really screwed up ;) | 16:13 |
| === antarus_ is now known as antarus | ||
| cjwatson | seb128: you can't get the content but you can get their versions easily enough | 16:20 |
| cjwatson | seb128: after all, the queue tool shows that | 16:20 |
| Laney | all of the friends had genuine changes | 16:21 |
| seb128 | cjwatson, the version doesn't tell us if there is an actual diff between the version in the queue and the current daily though :-( | 16:22 |
| seb128 | or we would need to add special logic to reconstruct the version of the queue from the vcs to debdiff it | 16:23 |
| Laney | can't you map from that back to a vcs tag? | 16:23 |
| Laney | Have you seen this behaviour though? I don't believe friends to be a case of it, like I just said | 16:24 |
| seb128 | Laney, we could, but same, we would move from a standard workflow to a special logic that needs to trace back to the vcs used and do diffs in there | 16:25 |
| Laney | or you know which PPA you uploaded to and the package name so you can easily download from that | 16:25 |
| seb128 | the version is not in the ppa anymore | 16:25 |
| seb128 | it got replaced by the new daily | 16:25 |
| seb128 | since that's a daily ppa | 16:25 |
| seb128 | and ppas don't keep deprecated versions | 16:25 |
| Laney | you're deciding whether to push a new daily at this point aren't you? | 16:25 |
| Laney | so this is before the upload | 16:26 |
| seb128 | no | 16:26 |
| seb128 | we always push dailies in the ppa | 16:26 |
| Laney | even if there's no change? | 16:26 |
| seb128 | even if we don't copy to distro | 16:26 |
| seb128 | yes | 16:26 |
| seb128 | because that's part of ensuring that things keep building | 16:26 |
| didrocks | hum, what do you mean? | 16:26 |
| seb128 | no? | 16:26 |
| didrocks | that's not the case at all | 16:26 |
| seb128 | ok | 16:26 |
| didrocks | only component which have a diff between the vcs and latest published version in distro are rebuilt | 16:27 |
| didrocks | components* | 16:27 |
| seb128 | didrocks, what was the reason you couldn't avoid queuing new versions in freeze time when there is no diff? | 16:27 |
| Laney | I'm not sure I believe that does happen | 16:27 |
| didrocks | seb128: I told "published version" | 16:27 |
| Laney | do you have evidence? | 16:27 |
| didrocks | seb128: if I want to support the "things in the queue", there is a little bit of logic needed | 16:27 |
| didrocks | from launchpad api to get what's in the unapproved queue | 16:28 |
| didrocks | then, trace back to something downloadable | 16:28 |
| Laney | we'd see it for every component every day if it was, surely? | 16:28 |
| didrocks | because as it's a sync, you can't download the source | 16:28 |
| Laney | and we don't, at least AFAIK ... | 16:28 |
| didrocks | so trace that back to the ppa | 16:28 |
| didrocks | and download from it | 16:28 |
| didrocks | and making a second diff against it | 16:28 |
| didrocks | so quite a little bit of work, but doable as told | 16:28 |
| seb128 | didrocks, right, that's exactly what I was saying (the sync, can't download the source, need extra logic, bits) | 16:29 |
| didrocks | when we evocated the idea with seb128, we decided it didn't worth the pain as the queue is normally reviewed within 24 hours | 16:29 |
| didrocks | (and this is only for things having stalled changes) | 16:29 |
| didrocks | 18:26:18 seb128 | we always push dailies in the ppa | 16:30 |
| didrocks | 18:26:24 Laney | even if there's no change? | 16:30 |
| didrocks | 18:26:26 seb128 | even if we don't copy to distro | 16:30 |
| didrocks | 18:26:31 seb128 | yes | 16:30 |
| didrocks | seb128: I think people would think from that that we are rebuilding everything ^ | 16:30 |
| didrocks | which is not the case ;) | 16:30 |
| didrocks | only the things not published in distro | 16:30 |
| didrocks | (which has a change) | 16:30 |
| Laney | so you could have <daily release> <change> <daily release stuck in queue> <daily release> <daily release ...> ? | 16:31 |
| seb128 | yeah, that was not really clearly written | 16:31 |
| didrocks | so yeah, it's possible to skip it, but the launchpad api with sync will make it quite some extra work | 16:34 |
| Laney | If it's like ^, you might be able to get away with just comparing versions | 16:34 |
| didrocks | so I think we just need to assess if reviewed in freeze period not being in 24 hours is that annoying compared to "reject olds" | 16:34 |
| didrocks | Laney: what version do you want to compare? | 16:34 |
| seb128 | Laney, comparing versions don't tell you if you have actual content change between daily_stuck_in_queue and new_daily | 16:35 |
| didrocks | right | 16:35 |
| Laney | if there are changes then you don't need to check the queue | 16:35 |
| didrocks | as we don't require debian/changelog change | 16:35 |
| seb128 | Laney, how do you determine if there are changes? | 16:35 |
| Laney | a commit since the last daily release | 16:36 |
| didrocks | Laney: doesn't work | 16:36 |
| didrocks | Laney: that was the old logic I removed | 16:36 |
| Laney | how the bot decides whether to do a daily release or not | 16:36 |
| didrocks | like, you can have a manual upload | 16:36 |
| didrocks | then backport that to the vcs | 16:36 |
| seb128 | Laney, it compares/diff to the archive version | 16:36 |
| didrocks | so comparing commit revisions is way more complex than it sounds | 16:36 |
| didrocks | comparing the diff from the archive is version 2 | 16:36 |
| didrocks | and the only reliable way | 16:37 |
| Laney | I thought that stuff put it into manual mode | 16:37 |
| seb128 | Laney, which is the "canonical" version | 16:37 |
| didrocks | Laney: it's in manual if the version in distro is more advanced than the release | 16:37 |
| didrocks | (well, it doesn't put it manual, it skips it + got the component hilighted) | 16:37 |
| didrocks | basically, as seb128 told, the reference version is always what is published in distro | 16:38 |
| didrocks | that's the gold rule to ensure we don't loose anything | 16:38 |
| didrocks | (and yeah, it's way more complicated than just comparing commits, the whole code being 3000 lines prooves it ;)) | 16:38 |
| Laney | I thought it was something like "if there's something in the distro that I didn't upload, then a human needs to take a look" | 16:39 |
| didrocks | Laney: yeah, it's hilighed and need to be ported back to the vcs | 16:39 |
| didrocks | but if you wanted to compare commits numbers to know that "something is new" or not | 16:39 |
| didrocks | you need to count the number of potential manual uploads | 16:40 |
| didrocks | (sometimes, there is more than one in a raw…) | 16:40 |
| didrocks | and rely on the fact there is one commit per backport | 16:40 |
| didrocks | which doesn't always happened as per experience ;) | 16:40 |
| didrocks | so reliable on just commits to think "there is something new to consider for release" doesn't work | 16:40 |
| Laney | so what's the issue? that manual uploads which get stuck in the queue can mess up the machinery? | 16:41 |
| didrocks | Laney: I meant that if there has been 3 manual uploads in a raw | 16:42 |
| didrocks | and you expect then 3 backport commits | 16:42 |
| didrocks | + 1 commit for the release | 16:42 |
| didrocks | so, you are telling "only if the diff is 5 commits, there is something to release" | 16:42 |
| didrocks | now, imagine the 3 manual uploads were done in a short time | 16:43 |
| didrocks | and someone only backport those 3 manual uploads in one commit | 16:43 |
| didrocks | you are waiting for 2 additional commits to tell "there is something to release", even if it's not true | 16:43 |
| didrocks | as the 3rd commit had something significative | 16:43 |
| Laney | I don't know why we're counting commits or diffing - isn't that all done by a human when they reconcile it and manually kick a daily release? | 16:43 |
| didrocks | that's why counting commits doesn't work | 16:43 |
| didrocks | Laney: you proposed counting commits | 16:44 |
| didrocks | that's what I did for a while | 16:44 |
| didrocks | and it doesn't work, hence the diff today :) | 16:44 |
| infinity | rtg_: It'll migrate its way out of proposed when I do the next d-i upload. | 16:44 |
| Laney | no, I proposed seeing if there were /any/ commits | 16:44 |
| didrocks | and I explain you why it doesn't work :p | 16:44 |
| didrocks | Laney: so, if there is any commits | 16:44 |
| didrocks | Laney: imagine, you have a manual upload | 16:44 |
| rtg_ | infinity, ack | 16:44 |
| didrocks | then, you have to put that back in the vcs, right? | 16:44 |
| didrocks | so you have /any/ commits, being one | 16:45 |
| didrocks | and you daily release exactly the same content | 16:45 |
| didrocks | than the manual upload | 16:45 |
| cjwatson | you know I'm not totally certain you can't get hold of the source by URL hacking | 16:46 |
| cjwatson | it must still be in the librarian | 16:46 |
| didrocks | cjwatson: that would help to not hack around to get a version from the ppa as a source | 16:47 |
| Laney | yeah that's right --- I had a working assumption that this doesn't happen often enough to make it a big problem ;-) | 16:48 |
| didrocks | Laney: you will notice that -V is using latest version published in distro so that we don't miss anything :) | 16:48 |
| didrocks | Laney: it did happen and it's not right that we reupload if someone did a manual upload, that's when I introduce diff as a source of truth | 16:49 |
| didrocks | (which makes more sense, it's authorative) | 16:50 |
| Laney | anyway, if this does indeed happen before you upload again to the PPA then you can trace back because you know which PPA it came from | 16:50 |
| didrocks | Laney: yeah, the question is "it's adding quite a bunch of logic, is it something which should be supported?" (as it uploads with the right -V and we don't miss anything) | 16:50 |
| didrocks | the other day, we went to the "no" conclusion with seb128, I'm happy to look at it back | 16:51 |
| Laney | like I said earlier I haven't personally seen repeated uploads with the same content, so I'm not convinced it happens very often | 16:51 |
| didrocks | Laney: btw, the commit I removed the "count commits" check is at http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/revision/276 | 16:52 |
| seb128 | Laney, right, the conclusion was "we don't have so many hard freezes, and the issue only happen if reviews take over 1 day in hard freeze time" | 16:52 |
| seb128 | and the "issue" is small, we just have outdated versions in the queue | 16:52 |
| seb128 | the most recent one will be published when accepted | 16:52 |
| seb128 | so it's just a small annoyance | 16:52 |
| Laney | in the friends case you'd have pushed them all anyway because there were commits every day | 16:53 |
| didrocks | I think there was one since start of the hard freeze | 16:53 |
| didrocks | one indicator thing | 16:54 |
| Laney | seb128: that glib patch is funny | 16:55 |
| seb128 | Laney, talk to desrt :p | 16:55 |
| didrocks | desrt is funny ;) | 16:55 |
| seb128 | Laney, they went "no, you can't do that anymore" but it broke bindings so desrt agreed to put an exception for the bindings until they are fixed | 16:56 |
| cjwatson | Laney: your agda and agda-stdlib uploads should be available for syncing now | 17:05 |
| Laney | woot | 17:05 |
| * Laney retires to the climbing centre | 17:12 | |
| seb128 | Laney, thanks for the reviews, have fun! | 17:16 |
| cjwatson | Laney: oh, we'll need geniplate, of course ... | 17:23 |
| cjwatson | oh, it's in raring-proposed already | 17:23 |
| cjwatson | fine | 17:23 |
| zul | can someone reject the horizon upload please? | 17:36 |
| ScottK | zul: Done | 17:37 |
| zul | thanks | 17:38 |
| rbasak | I don't understand why the armhf binary for samba4 was rejected. Help? https://launchpad.net/ubuntu/+source/samba4/4.0.0+dfsg1-1ubuntu1/+build/4482847 | 17:57 |
| ogra_ | rbasak, looks like a launchpad bug ... (iirc there is one open thatr cjwatson opened for a similar issue i once had years ago) | 18:02 |
| ogra_ | https://launchpadlibrarian.net/136881857/upload_4482847_log.txt | 18:02 |
| ogra_ | INFO Rejection during accept. Aborting partial accept. | 18:02 |
| ogra_ | oh, wait, binary you said ... mine was source | 18:03 |
| rbasak | Thanks. But does someone need to do something? :) | 18:04 |
| ogra_ | i would ask an LP person in #launchpad | 18:04 |
| ogra_ | it looks definitely buggy | 18:05 |
| ogra_ | (if the other bianries just got accepted) | 18:05 |
| ogra_ | *binaries | 18:05 |
| infinity | rbasak: It's an LP oops, retrying is the simplest way forward. | 18:14 |
| ogra_ | infinity, retrying for a binary ? | 18:15 |
| ogra_ | how would he do that | 18:15 |
| infinity | Retrying the build... | 18:15 |
| infinity | Which I did. | 18:15 |
| ogra_ | ah | 18:15 |
| rbasak | infinity: thanks! | 18:31 |
| rtg_ | can I get some love for Raring linux-firmware and pciutils ? | 18:39 |
| slangasek | antarus_: nvidia> you mean the fact that we have to ship a billion upstream versions of the driver to make sure everybody has one that works? | 18:44 |
| antarus | slangasek: no, 295 => 300 | 18:46 |
| antarus | slangasek: not saying there was anything else you could have done | 18:46 |
| antarus | slangasek: just that we had a fun morning ;_) | 18:46 |
| mdeslaur | antarus: what happened? | 18:47 |
| antarus | mdeslaur: well 295 doesn't support RANR, 304 does | 18:48 |
| antarus | we have some bits that need to be flipped to migrate | 18:48 |
| antarus | been plannign the migration for about 6 weeks ;) | 18:48 |
| mdeslaur | antarus: ah, I see...yeah, quite unfortunate, but we didn't have much of a choice | 18:49 |
| antarus | I know ;) | 18:52 |
| slangasek | doko: why does this python3-defaults upload include so much reordering of debian/rules? | 18:59 |
| slangasek | doko: AFAICS, the only bit related to the bug is a one-line change, and all the rest should be omitted from the SRU: | 18:59 |
| slangasek | - dh_link -ppython3 /usr/share/python3/py3versions.py /usr/bin/py3versions | 18:59 |
| slangasek | + dh_link -ppython3-minimal /usr/share/python3/py3versions.py /usr/bin/py3versions | 19:00 |
| Laney | cjwatson: yeah, I uploaded that one straight away | 19:26 |
| doko | rejected and reuploaded python3.3 to fix the testsuite-dbg autopkg test | 21:06 |
| === Ursinha is now known as Ursinha-afk | ||
| doko | whoever did accept the python2.7 upload yesterday, could you accept the python3.3 upload too? | 22:41 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| infinity | doko: That was me, I'll look at it tonight. | 23:12 |
| doko | infinity, thanks, afk now | 23:13 |
| === Ursinha-afk is now known as Ursinha | ||
| === Ursinha is now known as Ursinha-afk | ||
| === slangase` is now known as slangasek | ||
| === Ursinha-afk is now known as Ursinha | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!