| tsimonq2 | cyphermox: Totally unsure >_< | 00:02 |
|---|---|---|
| tsimonq2 | cyphermox: I'll find that out... | 00:02 |
| tsimonq2 | cyphermox: Also, I'm going to have to have a look at getting us a Qt slideshow that isn't completely Kubuntu branded >_< | 00:04 |
| tsimonq2 | cyphermox: s/slideshow/ubiquity/ | 00:04 |
| cyphermox | tsimonq2: Qt shouldn't mean that the slideshow is kubuntu branded | 00:05 |
| cyphermox | in any case, that would be in ubiquity | 00:07 |
| tsimonq2 | cyphermox: Hm, let's see which packages are in the seed for lubuntu-next live... | 00:08 |
| cyphermox | bbl, it's an ice cream break. | 00:09 |
| tsimonq2 | !info ubiquity-frontend-kde | 00:11 |
| ubot5 | ubiquity-frontend-kde (source: ubiquity): KDE frontend for Ubiquity live installer. In component universe, is optional. Version 17.04.9 (zesty), package size 66 kB, installed size 536 kB | 00:11 |
| tsimonq2 | Ah, ok, so it is part of ubiquity. Got it. | 00:11 |
| ahoneybun | yep tsimonq2 | 00:12 |
| ahoneybun | blaze and I fixed it a release or two ago | 00:12 |
| ahoneybun | when PyQt4 dropped webkit | 00:13 |
| ahoneybun | so we moved it to PyQt5 | 00:13 |
| tsimonq2 | ahoneybun: Mind if I fork? | 00:13 |
| ahoneybun | it's not mine | 00:13 |
| ahoneybun | fork what? | 00:13 |
| tsimonq2 | ahoneybun: Or maybe move to a common base that Kubuntu and Lubuntu Next can just share? | 00:13 |
| tsimonq2 | The Qt part of the ubiquity frontend. | 00:13 |
| ahoneybun | I'm not sure what you mean | 00:13 |
| ahoneybun | ohhh | 00:13 |
| tsimonq2 | Yeah :) | 00:13 |
| ahoneybun | fork it I guess | 00:14 |
| ahoneybun | but ubiquity provides the main UI on the side with the progress | 00:14 |
| tsimonq2 | Yeah | 00:14 |
| ahoneybun | the progress bar on the bottom is that -kde frontend | 00:14 |
| ahoneybun | the slides are ubiquity-slideshow-ubuntu | 00:14 |
| tsimonq2 | ahoneybun: Are there KDE Frameworks libraries used? | 00:15 |
| tsimonq2 | Oh, doesn't look like it? | 00:15 |
| tsimonq2 | In that case we can make something work. | 00:15 |
| ahoneybun | it's just python I think | 00:16 |
| tsimonq2 | Yay! | 00:16 |
| ahoneybun | /ubiquity/artful/ubiquity/frontend | 00:16 |
| ahoneybun | kep | 00:17 |
| ahoneybun | kde_ui.py | 00:17 |
| tsimonq2 | Oh bah, there is KDE frameworks in there... | 00:17 |
| tsimonq2 | Ugh | 00:17 |
| ahoneybun | where? | 00:17 |
| tsimonq2 | from ubiquity.frontend.kde_components import ProgressDialog | 00:17 |
| tsimonq2 | from ubiquity.frontend.kde_components.Breadcrumb import Breadcrumb | 00:17 |
| tsimonq2 | from ubiquity.frontend.kde_components import qssutils | 00:17 |
| tsimonq2 | In kde_ui.py | 00:17 |
| ahoneybun | most likely KDE4 stuff | 00:17 |
| ahoneybun | nah | 00:18 |
| ahoneybun | Qt5 now | 00:18 |
| ahoneybun | I mean you should just need to hook inot the kde qt frontend | 00:18 |
| tsimonq2 | I'll try getting a minimal LXD container and just installing that package and seeing what mess it pulls in. | 00:19 |
| tsimonq2 | If it pulls in three quarters of all KDE Frameworks then I'm noping out and rewriting it :P | 00:19 |
| ahoneybun | well the frameworks should be small now | 00:19 |
| ahoneybun | well in small pieces lol | 00:20 |
| ahoneybun | just be happy your not the first Qt based distro tsimonq2 | 00:20 |
| ahoneybun | then it would be worse | 00:20 |
| tsimonq2 | Yeah lol | 00:20 |
| * ahoneybun has a new domain | 00:21 | |
| tsimonq2 | :D | 00:22 |
| ahoneybun | and they gave me a long IP for this new linode | 00:22 |
| ahoneybun | damn it | 00:22 |
| ahoneybun | I want an .xyz domain | 00:23 |
| cyphermox | tsimonq2: all you really should have to do is remove obvious branding that is directly in ubiquity for the "KDE UI" which is really just a pretty standard Qt GUI, and in doing so no fork but just making things customizable (there should be plenty of examples of generic stuff in the Gtk sections) | 01:03 |
| cyphermox | also, might I suggest not using the Qt GUI if possible, unless you plan on spending a lot of time on it, it's definitely not as well tested as the rest (fewer users, it needs some work for other issues that were noticed) | 01:04 |
| tsimonq2 | cyphermox: Then what would we use if not the Qt GUI? | 01:05 |
| tsimonq2 | I don't want to include a bunch of GTK libraries just to run Ubiquity... | 01:05 |
| cyphermox | I mean, it's *important* that it works, for whomever wants to use it, but there are few people looking at ubiquity regularly... and by few I mean mostly just me, maybe xnox, and possibly infinity? | 01:05 |
| cyphermox | if you have time to hack on the Qt GUI to make it real solid, by all means :) | 01:06 |
| xnox | yes, i do. | 01:06 |
| cyphermox | xnox: yeah, but it's not your main focus | 01:06 |
| xnox | tsimonq2, did you fall into the trap of not specifying which frontend you want? | 01:06 |
| cyphermox | xnox: no, they actually want Qt. | 01:06 |
| cyphermox | I'm just expressing my concern for the Qt GUI not being as well tested so far, because it's only used by Kubuntu | 01:07 |
| xnox | tsimonq2, i believe there is qt4, qt5 frontends, but both are /kde/ frameworks based. I believe there was a QML frontend in progress, not sure if it is merged or not. | 01:07 |
| tsimonq2 | xnox: :/ | 01:07 |
| cyphermox | there is? | 01:07 |
| xnox | a pure QML kdeframeworkless frontend would be nice. | 01:07 |
| cyphermox | afaik it's all only Qt5. | 01:07 |
| cyphermox | xnox: none of ubiquity requires KDE really, AFAIK | 01:08 |
| xnox | there was a branch by somebody either on launchpad, or something werid like a tarball import on github. | 01:08 |
| tsimonq2 | xnox: That would be my end goal, here. | 01:08 |
| xnox | taking kde frontend as a starting point and moving that to qml would be a way forward. | 01:08 |
| xnox | unless you somehow can google up previous efforts of the same. | 01:08 |
| xnox | a QML subiquity frontend would be awesome too ;-) | 01:09 |
| tsimonq2 | xnox: You mean sub-iquity? | 01:09 |
| * tsimonq2 is a "super big fan" of the naming choice on that one :P | 01:09 | |
| xnox | yeah, new iteration of installer tech, based on cloud/maas experience. subiquity = server ubiquity | 01:10 |
| tsimonq2 | xnox: But yeah, I'll probably use that as my starting point though. | 01:10 |
| cyphermox | xnox: that would probably be a major undertaking, it's *not at all* the same thing as the usual desktop installer. | 01:10 |
| xnox | sure. | 01:11 |
| tsimonq2 | Soooo it's sub-iquity then? :D | 01:11 |
| xnox | tsimonq2, so looking at ubiquity kde frontend it is pure qt so far. | 01:11 |
| tsimonq2 | xnox: Excellent! But does it depend on KDE Frameworks? | 01:12 |
| xnox | the bits that say from ubiquity.frontend.kde_components are the custom /ubiquity/ widgets for Qt. | 01:12 |
| xnox | so should not need any KDE frameworks. | 01:12 |
| cyphermox | nope. | 01:12 |
| cyphermox | maybe ksmserver, whatever that is | 01:12 |
| cyphermox | probably easy enough to make optional. | 01:13 |
| * xnox wonders if i'm looking at old xenial qt4 build though, one second | 01:13 | |
| cyphermox | xnox: don't worry, there isn't much to look at; I have an up to date branch here. | 01:13 |
| xnox | curently requires kde-window-manager but that's probably because the ubiquity-dm is not ported to not use that. | 01:13 |
| xnox | tsimonq2, you may want to fix that ^ | 01:13 |
| xnox | there are no dependeinds declared on kdeframework anything | 01:14 |
| xnox | ubiquity-dm is the only thing that call into kde, and should be ported to support whatever LXQT wants. | 01:14 |
| tsimonq2 | xnox: Yeah, it was recently ported to Qt 5. | 01:15 |
| cyphermox | tsimonq2: short story, don't hesitate to ask on #ubuntu-installer if you have questions | 01:15 |
| tsimonq2 | cyphermox: OK :) | 01:15 |
| cyphermox | xnox or I can answer :) | 01:16 |
| tsimonq2 | I wonder how easy it would be to have some common Qt libraries between Lubuntu LXQt and Kubuntu and just have some elements customized... | 01:16 |
| cyphermox | tsimonq2: at first glance you have almost nothing to do; but I haven't seen your new image, you mentioned there was some stray branding from kubuntu. | 01:17 |
| cyphermox | tbf, there probably should not be any branding in ubiquity directly, that belongs to the theming, $flavour-default-settings, u-slideshow-$flavour and whatnot | 01:18 |
| tsimonq2 | cyphermox: tl;dr, on a system with a wired connection, boot the image into "Try Without Installing," Click OK when it gets to the X error, then right-click and select the terminal emulator. Then run ubiquity from there, and you'll see what I'm talking about irt. | 01:20 |
| tsimonq2 | s/irt/irt this/ | 01:20 |
| cyphermox | ok | 01:21 |
| tsimonq2 | I did it in virt-manager, but ymmv | 01:21 |
| cyphermox | oh boy, this is doing to take a while to download | 01:22 |
| tsimonq2 | Yeeeah, hopefully in the future we'll slim that down... :P | 01:22 |
| cyphermox | it's not about that, somehow my tubes are slow | 01:22 |
| cyphermox | I will let it download, and catch up on it / on scrollback tomorrow morning. | 01:23 |
| cyphermox | tsimonq2: if you figure it in the meantime I'll be happy to review and merge a MP. | 01:24 |
| tsimonq2 | cyphermox: ack :) | 01:25 |
| ahoneybun | any branding is done with a kubuntu.svg file in ubiquity | 01:53 |
| ahoneybun | just add the lubuntu one, make a change to one line and done | 01:53 |
| ahoneybun | tsimonq2: ^ | 01:53 |
| tsimonq2 | ahoneybun: ack :P | 01:54 |
| -queuebot:#ubuntu-release- Unapproved: thunar (zesty-proposed/universe) [1.6.11-1 => 1.6.11-1ubuntu0.17.04.1] (mythbuntu, xubuntu) | 02:04 | |
| -queuebot:#ubuntu-release- Unapproved: thunar (yakkety-proposed/universe) [1.6.11-0ubuntu0.16.10.1 => 1.6.11-0ubuntu0.16.10.2] (mythbuntu, xubuntu) | 02:09 | |
| -queuebot:#ubuntu-release- Unapproved: thunar (xenial-proposed/universe) [1.6.11-0ubuntu0.16.04.1 => 1.6.11-0ubuntu0.16.04.2] (mythbuntu, xubuntu) | 02:10 | |
| -queuebot:#ubuntu-release- Unapproved: xfce4-weather-plugin (xenial-proposed/universe) [0.8.6-1 => 0.8.9-0ubuntu0.16.04.1] (ubuntustudio, xubuntu) | 02:42 | |
| -queuebot:#ubuntu-release- New source: python-pypowervm (artful-proposed/primary) [1.1.4-0ubuntu1] | 10:19 | |
| ginggs | r-base is ready to migrate except for r-cran-spatstat on armhf and s390x http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#r-base i tried running it in lxc on amd64 locally, and it failed the first time, but not the 2nd time when i added -s . any ideas please? | 10:50 |
| alan_g | I'm trying to update the version of mir in 16.04 (SRU bug 1685186): it's reached minimum age in -proposed. Can we please proceed to -updates? | 10:53 |
| ubot5 | bug 1685186 in mir (Ubuntu) "[SRU] Mir needs to be updated to 0.26 in 16.04LTS" [High,In progress] https://launchpad.net/bugs/1685186 | 10:53 |
| apw | alan_g, this seems to leave xenial with a newer version than in well everything after, thats not good for an upgrade perspective | 11:10 |
| alan_g | apw: next on my list is 0.27 for artful. You're concerned with zesty though? | 11:12 |
| apw | alan_g, the rules are concerned with all releases, they say you can't have a version in xenial that is higher than yakkety etc | 11:13 |
| apw | alan_g, not actually sure how this got accepted into -proposed as things stand | 11:13 |
| apw | tjaalton, ^^ ? | 11:14 |
| alan_g | So, we'd need to release a 0.26.4 version on yakkety and zenial? (0.26.3 has been tweaked to build for xenial, so that would need reverting) | 11:19 |
| Laney | ginggs: Let's skip those | 11:22 |
| apw | alan_g, well something with a version number higher than that in xenial would be the norm yes; for y z and a. unless you have some kind of exception i am unaware of (and i could be) | 11:23 |
| ginggs | Laney: thanks | 11:23 |
| alan_g | How would I go about justifying an exception? | 11:38 |
| alan_g | The way we get here is that the 0.26 series was used for xenial+overlay and that was used for IoT projects on Ubuntu Core. We want to drop "overlay" now but maintain the same Mir support. | 11:39 |
| apw | alan_g, it is not clear how this would be possible without truly breaking updates, but you are LTS oriented; slangasek ^ ? | 11:40 |
| alan_g | Updating zesty from 0.26.2 to 0.26.4 would be simple enough. Yakkety was on an earlier series, so that would cause some issues. | 11:47 |
| alan_g | But the only people I think might care are UbuntuCore users that need "kiosk", or developers who I don't expect to be targeting yakkety. | 11:49 |
| jbicha | alan_g: technically, if you are not in a hurry and don't want to update Yakkety, then you could just wait until July when Yakkety is EOL | 11:50 |
| jbicha | but I think all that's being asked for now is that Yakkety has a higher version number than Xenial so that upgraders don't have a package newer than what is available in the archives | 11:51 |
| === alan_g is now known as alan_g|lunch | ||
| -queuebot:#ubuntu-release- Unapproved: rejected isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10] | 12:10 | |
| slashd | rbasak, uploaded | 12:24 |
| rbasak | ack | 12:24 |
| -queuebot:#ubuntu-release- Unapproved: isc-dhcp (trusty-proposed/main) [4.2.4-7ubuntu12.9 => 4.2.4-7ubuntu12.10] (core) | 12:24 | |
| -queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (trusty-proposed) [4.2.4-7ubuntu12.10] | 12:27 | |
| -queuebot:#ubuntu-release- Unapproved: accepted isc-dhcp [source] (xenial-proposed) [4.3.3-5ubuntu12.7] | 12:29 | |
| -queuebot:#ubuntu-release- New binary: isc-dhcp [i386] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core) | 12:33 | |
| -queuebot:#ubuntu-release- New binary: isc-dhcp [ppc64el] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core) | 12:34 | |
| -queuebot:#ubuntu-release- New binary: isc-dhcp [powerpc] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core) | 12:34 | |
| -queuebot:#ubuntu-release- New binary: isc-dhcp [amd64] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core) | 12:35 | |
| -queuebot:#ubuntu-release- New binary: isc-dhcp [armhf] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core) | 12:41 | |
| -queuebot:#ubuntu-release- New binary: isc-dhcp [arm64] (trusty-proposed/main) [4.2.4-7ubuntu12.10] (core) | 12:42 | |
| rbasak | slashd: ^ you may need to track down an archive admin to accept from NEW. | 12:44 |
| slashd | rbasak, https://launchpad.net/~ubuntu-archive ??? | 12:45 |
| rbasak | Yep | 12:45 |
| slashd | rbasak, ack will do | 12:46 |
| rbasak | slashd: https://launchpad.net/ubuntu/trusty/+queue | 12:46 |
| slashd | sil2100, the SRU that rbasak just approved is introducing ^ a new binary pkg --> https://launchpad.net/ubuntu/trusty/+queue. Could you please accept the new binary in the archive ? | 12:48 |
| sil2100 | slashd: hey! Sadly my AA privilages only allow to take care of kernel related packages - I guess you'd have to poke a real AA like apw ^ | 12:49 |
| slashd | apw ^^ could you please have a look at this request ^ ? | 12:50 |
| slashd | tks sil2100 | 12:50 |
| === alan_g|lunch is now known as alan_g | ||
| cyphermox | rbasak: could you please reject my nplan from the xenial queue? I just realized it's missing -v | 13:00 |
| rbasak | ack | 13:08 |
| -queuebot:#ubuntu-release- Unapproved: rejected nplan [source] (xenial-proposed) [0.22~16.04.1] | 13:09 | |
| cyphermox | rbasak: ta | 13:27 |
| -queuebot:#ubuntu-release- New: accepted isc-dhcp [amd64] (trusty-proposed) [4.2.4-7ubuntu12.10] | 13:29 | |
| -queuebot:#ubuntu-release- New: accepted isc-dhcp [armhf] (trusty-proposed) [4.2.4-7ubuntu12.10] | 13:29 | |
| -queuebot:#ubuntu-release- New: accepted isc-dhcp [powerpc] (trusty-proposed) [4.2.4-7ubuntu12.10] | 13:30 | |
| -queuebot:#ubuntu-release- New: accepted isc-dhcp [arm64] (trusty-proposed) [4.2.4-7ubuntu12.10] | 13:30 | |
| -queuebot:#ubuntu-release- New: accepted isc-dhcp [ppc64el] (trusty-proposed) [4.2.4-7ubuntu12.10] | 13:30 | |
| -queuebot:#ubuntu-release- New: accepted isc-dhcp [i386] (trusty-proposed) [4.2.4-7ubuntu12.10] | 13:30 | |
| apw | slashd, ^ | 13:30 |
| -queuebot:#ubuntu-release- Unapproved: nplan (xenial-proposed/universe) [0.21~16.04.1 => 0.22~16.04.1] (no packageset) | 13:30 | |
| slashd | apw, thanks | 14:09 |
| -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (xenial-proposed) [1.157.11] | 15:52 | |
| -queuebot:#ubuntu-release- Unapproved: util-linux (zesty-proposed/main) [2.29-1ubuntu2 => 2.29-1ubuntu2.1] (core) | 16:12 | |
| -queuebot:#ubuntu-release- Unapproved: util-linux (yakkety-proposed/main) [2.28.2-1ubuntu1.1 => 2.28.2-1ubuntu1.2] (core) | 16:14 | |
| -queuebot:#ubuntu-release- Unapproved: util-linux (xenial-proposed/main) [2.27.1-6ubuntu3.2 => 2.27.1-6ubuntu3.3] (core) | 16:16 | |
| bdmurray | cyphermox: How did you verify bug 1680279? | 16:37 |
| ubot5 | bug 1680279 in shim-signed (Ubuntu Yakkety) "attach secureboot state files to shim-signed apport reports" [Undecided,Fix committed] https://launchpad.net/bugs/1680279 | 16:37 |
| bdmurray | cyphermox: specifically how did you review the report? | 16:37 |
| cyphermox | bdmurray: I can generate a crash file, and look in to see if we have a value for the two variables (SecureBoot-* and MokSBStateRT-*) | 17:31 |
| cyphermox | the fact that the value is an unprintable character isn't too much an issue (we can "decipher" that, but just knowing that the files are there or not helps a lot already) | 17:32 |
| bdmurray | cyphermox: You viewed the .crash in /var/crash with a text editor or something? Was it not apport-gtk's dialog? | 17:34 |
| cyphermox | as I remember I went to vi the .crash file in /var/crash. | 17:34 |
| bdmurray | Maybe we should let slangasek decide since he did the SRU work | 17:38 |
| bdmurray | cyphermox: Also might these files not exist? there is attach_file_if_exists() instead of attach_file() | 17:39 |
| cyphermox | yes, at least MokSBStateRT can be absent | 17:39 |
| slangasek | fwiw when I was testing this I used apport-gtk's dialog | 17:41 |
| bdmurray | And did you choose not to use attach_file_if_exists()? | 17:43 |
| bdmurray | It won't cause a problem as apport will carry on, it'll just be extra baggage with the bug. | 17:47 |
| bdmurray | Oh, I guess its okay | 18:00 |
| bdmurray | Error: [Errno 2] No such file or directory: '/sys/firmware/efi/efivars/MokSBStateRT-605dab50-e046-4300-abb6-3dd810dd8b23' | 18:01 |
| bdmurray | slangasek: is the fact that its an unprintable character an issue? | 18:09 |
| slangasek | bdmurray: the 'no such file or directory' messages are actually useful information to me, it shows a recent enough version of the hook was run and found nothing | 18:21 |
| slangasek | bdmurray: the unprintable character is an issue, but IMHO having unprintable character is better than nothing | 18:21 |
| slangasek | and I told cyphermox I wasn't going to be working on the unprintable character problem any time soon, which was why he switched from v-failed to v-done | 18:22 |
| bdmurray | slangasek: okay, cool | 18:23 |
| cyphermox | ^that. unprintable character is better than nothing, as just existence already give you all you need for the MokSBStateRT case anyway (it's either there or not) | 18:25 |
| bdmurray | Sure it just seems like you could store this information as a boolean e.g. MokSBStateRtExists: True and it'd be cleaner. | 18:27 |
| slangasek | bdmurray: for most of them we do care about the content, and it is possible if inconvenient to extract that info from the unprintable character IIRC | 18:28 |
| slangasek | ultimately I want the content | 18:28 |
| bdmurray | slangasek: Understood. | 18:42 |
| bdmurray | Bug 1659618 mentions a kexec-tools SRU ftbfs on armhf but that's not showing up on the pending-sru report... | 18:44 |
| ubot5 | bug 1659618 in kexec-tools (Ubuntu Yakkety) "Enable ARM64 support in kexec-tools" [High,Fix committed] https://launchpad.net/bugs/1659618 | 18:44 |
| bdmurray | I see some other ftbfs on the report. | 18:44 |
| slangasek | bdmurray: under yakkety I see 'kexec-tools armhf: Failed to build', is that not what you're talking about? | 18:54 |
| bdmurray | slangasek: I'm talking about 1:2.0.10-1ubuntu2.1 for xenial which FTBFS but come to find out there is an even newer version in xenial which isn't in the bug comments at all. | 18:59 |
| slangasek | ok | 19:00 |
| bdmurray | So while I was looking at the wrong package version an SRU team member didn't comment on the bug when accepting the new version in. | 19:01 |
| bdmurray | That should have flipped the tags for xenial too. | 19:02 |
| === mcasadevall is now known as NCommander | ||
| -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu4 => 2.02~beta3-4ubuntu4] (core) | 20:18 | |
| -queuebot:#ubuntu-release- Unapproved: grub2 (artful-proposed/main) [2.02~beta3-4ubuntu4 => 2.02~beta3-4ubuntu4] (core) | 20:40 | |
| gaughen | cyphermox, would you have a look at this MIR request please - https://bugs.launchpad.net/ubuntu/+source/vine/+bug/1688091 | 21:40 |
| ubot5 | Ubuntu bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New] | 21:40 |
| cyphermox | sure | 21:40 |
| gaughen | thank you cyphermox! | 21:43 |
| jbicha | cyphermox: and LP: #1686726 too? | 21:44 |
| ubot5 | Launchpad bug 1686726 in gnome-getting-started-docs (Ubuntu) "[MIR] gnome-getting-started-docs" [High,Triaged] https://launchpad.net/bugs/1686726 | 21:44 |
| bdmurray | tjaalton: Why was mir accepted in xenial-proposed when it doesn't seem to be fixed in Artful and the version number will be greater than any other release? | 21:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!