| asac | pace_t_zulu: stripping down the third_party libs/source that are required in the source tree is a continuous task i would say | 00:00 |
|---|---|---|
| asac | pace_t_zulu: there might be some third party sources that could be packaged (e.g. skia for instance) | 00:01 |
| asac | fta: do you know how stable skia is abi/api wise? | 00:01 |
| fta | i don't think it is, it's very chromium oriented | 00:02 |
| pace_t_zulu | asac: http://skia.googlecode.com ... make a skia.deb or libskia.deb ? | 00:02 |
| asac | hmm. then i dont see why they dont fix the skia font api to allow proper on-demand fallback through fontconfig | 00:02 |
| fta | and chromium is now pulling skia from trunk | 00:02 |
| fta | same for v8 and webkit | 00:02 |
| asac | from how the bug read they seemed to rather not change skia | 00:02 |
| asac | fta: yeah. but trunk doesnt necessarily mean that the ABI/API is unstable | 00:03 |
| asac | but i see what you mean. | 00:03 |
| fta | asac, they are evolving in parallel. so we'll have to bump them at the same pace. like ff and xul | 00:04 |
| pace_t_zulu | asac: i suppose their modifications to webkit make it unreasonable to depend on libwebkit | 00:04 |
| pace_t_zulu | ? | 00:04 |
| asac | fta: yeah. but skia is also used by gears | 00:04 |
| asac | so i thought there was potential | 00:04 |
| fta | gears is small in comparison | 00:04 |
| asac | yes, still needs reduction :) | 00:04 |
| fta | pace_t_zulu, upstream said chromium will never work with libwebkit | 00:05 |
| ion_ | Why is that? | 00:05 |
| pace_t_zulu | fta: *never*? | 00:05 |
| fta | tricky. their copy of webkit is built with chromium specific flags, and it needs the chromium sources to build | 00:07 |
| pace_t_zulu | fta: i know they wanted to push their webkit modifications upstream... | 00:07 |
| fta | they did, for the most part | 00:07 |
| pace_t_zulu | fta: i understand why it wouldn't right now... but *never* seems quite absolute | 00:07 |
| fta | to be more accurate, when i asked how far it was from building with a system webkit, they said "pretty far. We'll never work with something like webkitgtk." | 00:09 |
| fta | if you look at the code, it's easy to understand why | 00:09 |
| pace_t_zulu | fta: fair enough | 00:10 |
| fta | i want as many system libs as possible since day 1, but it's not the priority upstream, they want feature parity with windows 1st | 00:12 |
| pace_t_zulu | fta: understandable... i'm with you on system libs | 00:12 |
| fta | i worked last year to move about 12 libs to system libs, but it was creating so many regressions in the testsuite that i decided to fallback | 00:14 |
| fta | most of our libs are sort of "not good enough" | 00:14 |
| fta | our libjpeg for example, far too old | 00:15 |
| fta | we lack about 10 years of patches and optimizations | 00:15 |
| pace_t_zulu | fta: why would we have such an old libjpeg? | 00:17 |
| fta | i introduced the -testsuite package to easily spot regressions when moving libs to system libs, but the testsuite needs some love | 00:17 |
| fta | pace_t_zulu, because upstream is dead | 00:18 |
| asac | fta: do we know where they too the libjpeg from? | 00:18 |
| fta | yes, from mozilla | 00:18 |
| asac | fta: maybe they copied firefox libjpeg which seems to be a fork | 00:18 |
| asac | yeah | 00:18 |
| fta | mozilla should be the new upstream, the jpeg consortium died 10y+ ago | 00:18 |
| asac | right | 00:18 |
| pace_t_zulu | what if we package a 'libjpeg-mozilla' ? | 00:18 |
| asac | so we might wnat to consider that | 00:18 |
| pace_t_zulu | or something like that | 00:19 |
| fta | asac, i asked mconnor, he liked the idea | 00:19 |
| pace_t_zulu | how does wegkitgtk get away with using libjpeg? | 00:19 |
| asac | well. for that i would at least like to know someone who can explain to me what changes were done :) | 00:19 |
| asac | but even in mozilla tree most changes are so long ago that its hard to find out | 00:20 |
| pace_t_zulu | fta and asac: did you guys see my blueprint for giving chromium a "Human" theme? | 00:21 |
| fta | i tried to split the patches between moz trunk and the last known upstream jpeg, got like 110 commits since the "free the lizard" day (when the netscape code was freed), plus a giga commit before that | 00:21 |
| fta | chromium is not yet "themable" | 00:21 |
| asac | right. we looked at that at some point. i stopped looking at patches when there were commits without even a bug referenced | 00:21 |
| pace_t_zulu | does mozilla have a libjpeg or has it become too much embedded in the mozilla codebase? | 00:22 |
| fta | they have their own version, but it's easy to split | 00:23 |
| fta | i wanted a clean patch stack on top of our lib, it turned out to be almost impossible | 00:24 |
| pace_t_zulu | fta: what if we were to try to split it and create a libjpeg-mozilla ? whatever the name may be | 00:24 |
| fta | it only makes sense if it replaces our lib | 00:24 |
| pace_t_zulu | or is that undesirable... i suppose patching our libjpeg is what you are looking for | 00:25 |
| pace_t_zulu | fta: right... | 00:25 |
| pace_t_zulu | fta: i assume our libjpeg comes from Debian... correct? | 00:26 |
| fta | yes | 00:26 |
| pace_t_zulu | asac: i know you are on the firefox team... would it be useful to build firefox against a patched libjpeg? | 00:27 |
| fta | one experiment could be to package from the mozilla sources and see if it creates regressions in gnome | 00:27 |
| fta | we used to build firefox with system jpeg, until it started to crash when printing | 00:28 |
| fta | and it was also much slower as we don't have the mmx/sse/sse2 optimization mozilla have | 00:28 |
| fta | so i guess the whole desktop could benefit from that | 00:29 |
| pace_t_zulu | fta is this something that is doable before karmic is released? | 00:31 |
| asac | i think its worth to look at that during UDS | 00:31 |
| lifeless | TheMuso: btw I'm done on the isw bug | 00:31 |
| lifeless | TheMuso: nothing further to do at this point pending that kernel patch and upstream waking up | 00:31 |
| fta | pace_t_zulu, everything is doable, depending on how much time you can spend on this ;) | 00:31 |
| pace_t_zulu | asac how long would it take to pull libjpeg from the mozilla codebase? | 00:32 |
| pace_t_zulu | fta, like i said... i am very interested in contributing... | 00:32 |
| pace_t_zulu | fta, i am also a fast learner | 00:33 |
| fta | to pull libjpeg from the mozilla, hm, 1 sec ? | 00:33 |
| fta | well, with hg, more, you have to clone the full trunk | 00:33 |
| pace_t_zulu | !hg | 00:34 |
| ubottu | Sorry, I don't know anything about hg | 00:34 |
| asac | i think its technically easy | 00:34 |
| asac | the problem is more of figuring what we really want | 00:34 |
| fta | http://hg.mozilla.org/mozilla-central/file/38d50cc03a72/jpeg/MOZCHANGES :( | 00:35 |
| TheMuso | lifeless: right | 00:35 |
| fta | "????/??/?? -- Lots of undocumented changes. :(" | 00:35 |
| fta | asac, eh.. a fast libjpeg creating no regression? :) | 00:38 |
| pace_t_zulu | fta ftw | 00:40 |
| pace_t_zulu | the discussion has fallen silent | 00:47 |
| asac | i think there is a consent that this is a good idea and that we will look at UDS at this | 00:49 |
| fta | asac, is mconnor coming? | 00:50 |
| asac | not that i know ;) | 00:50 |
| pace_t_zulu | i would love to go to UDS | 00:51 |
| pace_t_zulu | maybe next one | 00:52 |
| pace_t_zulu | asac: http://pastebin.ubuntu.com/172669/ | 00:52 |
| asac | you need to install a package called bzr-builddeb | 00:52 |
| pace_t_zulu | asac, thank you | 00:53 |
| pace_t_zulu | shouldn't that be in ubuntu-dev-tools? | 00:53 |
| pace_t_zulu | hmmm.... | 00:54 |
| pace_t_zulu | the builddeb is checking out a new copy of chromium | 00:55 |
| pace_t_zulu | seems as if fewer commands are needed | 00:56 |
| pace_t_zulu | i'm learning here... i'll figure out why it is going through these steps | 00:56 |
| asac | pace_t_zulu: i think we should move that discussion to #ubuntu-motu ;) | 00:57 |
| pace_t_zulu | asac and ftw: thank you for being patient w/ me | 00:57 |
| asac | pace_t_zulu: you didnt place the tarball in the right dir | 00:57 |
| lamont | hrm.. someone correct me if I'm wrong... when I say 'extract' to sound juicer, it's not supposed to immediately terminate, right??? :-( | 01:20 |
| lamont | in jaunty | 01:20 |
| lamont | where does it drop logging/watever? | 01:20 |
| lifeless | valgrind sound-juicer | 01:20 |
| lifeless | :) | 01:20 |
| lamont | strace comes to mind as more appropriate... this is totally immediate | 01:21 |
| lifeless | yeah | 01:21 |
| lamont | --- SIGSEGV (Segmentation fault) @ 0 (0) --- | 01:21 |
| lifeless | you're thinking 'deliberately quit | 01:21 |
| lifeless | I'm thinking 'fail | 01:21 |
| lifeless | and.. I win :) | 01:21 |
| lamont | no, I wasn't thinking deliberately quit | 01:22 |
| lamont | seb128 wouldn't do that to me | 01:22 |
| pace_t_zulu | so asac... i'm not seeing a libjpeg in the firefox source | 01:33 |
| pace_t_zulu | asac: would libjpeg need to be checked out directly from mozilla? | 01:33 |
| pace_t_zulu | asac: i suppose i need to learn mercurial now :) | 01:34 |
| lamont | lifeless: never try to extrack with a blank title | 01:44 |
| lifeless | lamont: fun | 01:51 |
| lifeless | lamont: This is why writing a desktop environment in C is a good idea | 01:51 |
| lamont | well the alternative is to have it perform like it's interpreted. :-p | 01:52 |
| lamont | brb | 01:52 |
| Sarvatt | is the gcc atom patch going to be permanently dropped now then? :( | 04:32 |
| quentusrex | I think I've found a memory issue with Xorg | 04:51 |
| quentusrex | Xorg is currently taking up 1.8GB or residential ram on my box that has 4 GB of ram. | 04:52 |
| Chipzz | quentusrex: 1) this is not the right channel to report bugs; 2) there is #ubuntu-x (or ubuntux, dunnow off-hand) and 3) are you sure it actually takes up that much? what top reports is not the amount of memory it actually uses | 05:05 |
| Chipzz | that being said, please move to #ubuntu-x | 05:06 |
| dholbach | good morning | 06:28 |
| lifeless | hmmm, must fix dmraid udev rules | 06:39 |
| lifeless | 'dmraid -ay' in console on every boot isn't pretty | 06:40 |
| TheMuso | lifeless: I'd be interested in why either dmraid-activate is not being run, or a log of dmraid-activate with -x itself. | 06:43 |
| lifeless | TheMuso: have you seen other like issues before? | 06:44 |
| lifeless | TheMuso: if so point me at bugs and I'll just fix this | 06:44 |
| lifeless | dmraid-activate is in the initramfs | 06:44 |
| TheMuso | lifeless: yes, and no I haven't seen issues like this so far as I have determined. | 06:46 |
| TheMuso | lifeless: no hurry, just whenever you can get a log of dmraid-activate running in the initramfs | 06:47 |
| TheMuso | ./c | 06:47 |
| lifeless | ok | 06:49 |
| lifeless | 358255 may be related | 06:49 |
| lifeless | though I'm not using lvm its possible the root cause isn't an interaction | 06:50 |
| lifeless | (filing a bug to track my case) | 06:50 |
| lifeless | TheMuso: Is there anything more I need to do, or you'll land it in karmic? | 06:55 |
| TheMuso | lifeless: to fix that problem? I will land it in karmic first, and if needed, can SRU for jaunty. | 06:55 |
| lifeless | as long as dmraid isn't altered in jaunty I don't care if you do/don't | 06:56 |
| lifeless | but if it gets changed, I'd really like the patch in, so that it doesn't regress :) | 06:56 |
| TheMuso | Ok. | 06:56 |
| lifeless | how do you log output from a initramfs ? | 06:57 |
| TheMuso | What I'd do, is modify dmraid-activate to log a file output to /dev/.initramfs/filename and set -x | 06:57 |
| lifeless | thanks | 06:58 |
| pitti | Good morning | 06:58 |
| lifeless | hi pitti | 06:58 |
| pitti | 05/15/09 02:40:02: checking #376771 for duplicate | 07:01 |
| pitti | DEBUG: blacklisted from auto-duplication 260001 | 07:01 |
| pitti | cjwatson: ^ seems to work | 07:01 |
| dholbach | can someone please get ibus-table-extraphrase out of binary new? | 07:22 |
| saravanan | hi | 07:26 |
| dholbach | ara: you rock! :) | 07:38 |
| ara | dholbach: :) | 07:39 |
| c_korn | '%WN?hzJ9".pzG3MRPpkD | 08:08 |
| c_korn | oops, this was my passphrase :P | 08:09 |
| dholbach | c_korn: it very much looked like one :) | 08:09 |
| pitti | c_korn: very good one, though; too bad it got busted now | 08:11 |
| pitti | must have taken a week to learn it | 08:11 |
| dholbach | can an ubuntu-archive member please get ibus-table-extraphrase out of binary new? :-) | 08:11 |
| pitti | dholbach: done | 08:13 |
| * dholbach hugs pitti | 08:13 | |
| dholbach | that'll make reviewing, building and testing the other ibus-* packages on REVU a bit easier :) | 08:13 |
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | pitti, hi | 08:39 |
| tkamppeter | pitti, I have uploaded the SRU for bug 376732 now. | 08:39 |
| ubottu | Launchpad bug 376732 in foomatic-filters "Hardy foomatic-rip PageSetup is broken, fails LSB tests" [Undecided,Fix released] https://launchpad.net/bugs/376732 | 08:39 |
| pitti | tkamppeter: I had some questions in the bug report | 08:43 |
| tkamppeter | pitti: I have answered in the bug report. It is really a regression against Hardy and the patch to fix it is MUCH smaller than the diff attached to the original LSB bug report. | 08:49 |
| pitti | bryce: if you have scripts which evaluate HalComputerInfo from apport-generated bugs, you need to adapt them; I ripped out hal from apport now and replaced it with udev db/log. Please let me know if you need any help with that | 09:19 |
| bryce | pitti: I don't actually interpret HalComputerInfo in particular, but that's good to know | 09:22 |
| pitti | bryce: ok; I checked the source_xorg.py hook, and it shouldl still be okay; I'll run a few tests, just to be sure | 09:22 |
| bryce | pitti: I've been thinking it would be nifty to have some stock python code that reads/writes a data "structure" from the bug description that provides basic hardware/software version information | 09:22 |
| pitti | bryce: you know that there's code to convert a LP bug report back into an apport.Report dictionary? | 09:23 |
| pitti | bryce: would that help? | 09:23 |
| bryce | something like, "foobar: 1.2.3\nbarfoo: 3.2.1" etc. | 09:23 |
| bryce | maybe; I'll have to take a look | 09:23 |
| pitti | phone, brb | 09:23 |
| pitti | bryce: so you would say "report = download(12345)" | 09:24 |
| pitti | bryce: and then could access report['Package'], report['Uname'], report['UdevDb'] etc. | 09:25 |
| pitti | bryce: the download call is about two or three lines of code | 09:25 |
| bryce | pitti: I think what I'm thinking of is a touch orthogonal | 09:30 |
| bryce | pitti: I'm thinking more along the lines of a plain and simple set of "key: value" pairs in the bug description | 09:31 |
| bryce | that can be loaded, modified, and saved back into the bug | 09:31 |
| pitti | bryce: don't we have that already? | 09:31 |
| pitti | not the 'save back' of course | 09:31 |
| bryce | pitti: well that's the magic; it builds on what is already there | 09:32 |
| bryce | justs adds a more read/write aspect to it | 09:32 |
| bryce | which allows us to "accumulate knowledge" as the bug progresses | 09:32 |
| pitti | right now, crashdb.update() for launchpad only attaches new comments | 09:33 |
| pitti | but it should be possible to make it change the description | 09:33 |
| bryce | what we don't have right now is an API for doing this | 09:33 |
| bryce | but it ought to be pretty trivial. | 09:34 |
| pitti | bryce: I think I have a rough idea about it; let's talk about it in Barcelona, shall we? | 09:40 |
| bryce | pitti: sounds good | 09:41 |
| bryce | pitti: won't have to wait long :-) | 09:41 |
| directhex | i think i've lost my euros again. i should put them somewhere safe | 09:42 |
| === dpm_ is now known as dpm | ||
| lool | pitti: Can apport be reenabled now? ISTR some work is ongoing for soyuz support of ddebs | 09:48 |
| pitti | lool: that's pretty independent of soyuz | 09:49 |
| seb128 | please don't reopen apport now, we will be flooded by crash bugs, it's early in the cycle, after uds rather | 09:50 |
| pitti | it's primarily a matter when we start wanting to open the floodgates | 09:50 |
| lool | Waiting is fine for me; I'll just turn it on where I need it | 09:50 |
| seb128 | pitti: the gvfs gdu monitor crash every time I start gedit on my desktop btw, did you get the same issue? | 09:50 |
| seb128 | I noticed yesterday because I enabled apport to take screenshots | 09:51 |
| pitti | seb128: I have apport enabled, too | 09:52 |
| pitti | gedit starts fine here | 09:52 |
| seb128 | pitti: gedit starts fine but I get a gdu crash after that | 09:52 |
| pitti | hm, I don't | 09:53 |
| seb128 | pitti: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/376145 | 09:54 |
| ubottu | Ubuntu bug 376145 in gvfs "gvfs-gdu-volume-monitor crashed with SIGSEGV in gdu_pool_get_presentables()" [Medium,Triaged] | 09:54 |
| lool | Can I get apport to run with a SIGABRT? | 09:54 |
| seb128 | no | 09:55 |
| seb128 | there is a spec about that I think | 09:55 |
| * pitti is on the phone | 09:55 | |
| lool | Ah I can't run strace under valgrind | 09:56 |
| lool | I guess both use ptrace | 09:57 |
| seb128 | lool: https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-apport-abort | 09:58 |
| cjwatson | I wouldn't have thought valgrind used ptrace - it's more like an emulator | 09:59 |
| lool | seb128: thanks | 10:00 |
| lool | cjwatson: Me neither; it's the only reason I could think of for its non-transparency | 10:00 |
| === fta_ is now known as fta | ||
| lool | Actually "valgrind strace ls" works fine | 10:03 |
| lool | So I get permission denied under valgrind + strace and not under strace | 10:06 |
| tjaalton | pitti: hal ships 10-x11-input.fdi, but so does evdev in debian. maybe we should take the one from evdev instead? | 10:07 |
| pitti | tjaalton: is that in upstream evdev? (since it's in upstream hal) | 10:08 |
| pitti | I wouldn't mind removing it from hal upstream | 10:08 |
| pitti | tjaalton: OTOH, xorg's -evdev should better be converted to not use hal at all any more :) | 10:08 |
| pitti | Keybuk: apart from /var/log/udev and an udev db dump, can you think of anything else an udev-extra apport hook should collect? | 10:11 |
| Keybuk | pitti: could we get a udev hook to do that at the same time? :p | 10:11 |
| pitti | Keybuk: hm, perhaps we should add that hook to udev itself, and udev-extra just ships a symlink to it | 10:11 |
| Keybuk | dmesg/kern.log is often helpful | 10:11 |
| pitti | Keybuk: snap :) | 10:11 |
| pitti | Keybuk: attach_hardware() does that, too | 10:12 |
| pitti | Keybuk: in fact, attach_hardware() already has all of that | 10:12 |
| pitti | cpuinfo, cmdline, lsusb, lspci, DMI, udev db, udev log, dmesg | 10:12 |
| Keybuk | yeah, that bunch | 10:13 |
| pitti | Keybuk: will do that then | 10:13 |
| tjaalton | pitti: actually not from upstream, debian added it. well, I don't mind keeping status quo for now | 10:14 |
| pitti | tjaalton: since I hope all of this will disappear very soon, I don't particularly mind either :) | 10:14 |
| tjaalton | pitti: you can hope, but upstream has no plans beyond hal :/ | 10:15 |
| pitti | tjaalton: do you happen to know if there's some upstream movement to move away from hal towards asking udev for input devices? | 10:15 |
| pitti | hm, is that a lot of code? | 10:15 |
| tjaalton | pitti: the server already supports dbus | 10:15 |
| pitti | I can't imagine xorg would have been infested by lots of hal specific code | 10:15 |
| Keybuk | pitti: the cabal certainly spoke to keith at it in SF | 10:15 |
| Keybuk | he was keen | 10:16 |
| Keybuk | especially since the libudev socket filtering stuff allows it to only receive input subsystem events | 10:16 |
| seb128 | lool: btw where have you seen ongoing soyuz ddeb work? | 10:19 |
| pitti | Keybuk: attaching the file names in /etc/udev/rules.d/ might also be interesting? | 10:25 |
| Keybuk | pitti: possibly, though in practice everything in that directory is user-generated | 10:26 |
| pitti | Keybuk: exactly | 10:27 |
| Keybuk | in general, it's better to get udevadm test results as they're more revealing | 10:27 |
| pitti | we might check for weird local customizations | 10:27 |
| Keybuk | but sure | 10:27 |
| pitti | Keybuk: that needs a devpath, though? | 10:27 |
| tjaalton | pitti: it's 660 lines, so not that much ;) | 10:28 |
| lesshaste | hi all | 10:28 |
| pitti | Keybuk: is there some general command we could put into the hook for that? | 10:28 |
| cjwatson | seb128,lool: https://bugs.launchpad.net/soyuz/+bug/285205 | 10:30 |
| ubottu | Ubuntu bug 285205 in soyuz "Soyuz needs to be able to process and publish ddebs" [Medium,Fix committed] | 10:31 |
| pitti | ! | 10:31 |
| pitti | *bounce* | 10:31 |
| cjwatson | I was about to ask whether anyone had been coordinating with pitti - guess not ;-) | 10:31 |
| pitti | cjwatson: well, we discussed how the system needs to look like about a year ago | 10:31 |
| cjwatson | I meant for deployment | 10:32 |
| pitti | not so far | 10:32 |
| seb128 | excellent | 10:32 |
| seb128 | I didn't know they were actively working on it now | 10:32 |
| Keybuk | pitti: only if you have a devpath that's broken | 10:34 |
| lesshaste | is it well known that if you install adobe-flashplugin with gnash already installed mozilla just silently ignores it? | 10:34 |
| lesshaste | s/mozilla/firefox | 10:35 |
| lesshaste | it's quite an annoying feature | 10:35 |
| seb128 | firefox let you choose which one to use | 10:35 |
| lesshaste | seb128: no it completely ignores it.. i.e. it doesn't show up in about:plugins | 10:36 |
| seb128 | what ubuntu version do you use? | 10:36 |
| lesshaste | hardy | 10:36 |
| seb128 | ok, that's a new feature, it was not in hardy | 10:37 |
| seb128 | it's there in jaunty | 10:37 |
| lesshaste | ah I see | 10:37 |
| lesshaste | maybe this counts as a bug? | 10:37 |
| lesshaste | it certainly confused me for about an hour | 10:37 |
| seb128 | it does count as a bug but that's not likely to change in hardy | 10:37 |
| lesshaste | cough.. lts.. cough :) | 10:38 |
| pitti | Keybuk: check out https://bugs.staging.launchpad.net/ubuntu/+source/udev/+bug/376248 | 10:38 |
| ubottu | Ubuntu bug 376248 in teeworlds "Ubuntu 9.04 has an obsolete version of teeworlds" [Undecided,New] | 10:38 |
| lesshaste | shall I report it? | 10:38 |
| pitti | Keybuk: (ubuntu-bug udev) | 10:38 |
| seb128 | lesshaste: no | 10:39 |
| seb128 | lesshaste: lts means security support, not that every new feature will be added to the lts | 10:40 |
| pitti | Keybuk: CustomUdevRuleFiles will only appear if there are actually files besides 70-persistent-* and README | 10:40 |
| seb128 | lesshaste: the firefox code to let you choose what plugin to use is probably non trivial and will not be considered as a stable update candidate | 10:40 |
| seb128 | lesshaste: and it's easy to workaround, uninstall the one you don't want to get used | 10:41 |
| Keybuk | pitti: perfect | 10:41 |
| Keybuk | pitti: odd errors in CurrentDmesg.txt | 10:41 |
| pitti | Keybuk: whoopsie, good catch | 10:42 |
| pitti | Keybuk: ugh, I have some serious trouble building an udev source package | 10:49 |
| pitti | complains all the way about test/sys/ | 10:49 |
| tjaalton | pitti: you wanted to know if the hotkeys ceased working? The battery/suspend keys don't work on my thinkpad X61, although it could be that what should be listening to those is busted | 10:49 |
| pitti | Keybuk: I pushed my apport hook, but i got to leave for ~ 1 hour; I'll wrestle with it later, unless you beat me to it | 10:51 |
| pitti | tjaalton: ok, later, need to leave, sorry | 10:51 |
| tjaalton | pitti: heh, ok | 10:51 |
| Keybuk | pitti: -i'(^|/)(\.bzr|\.gitignore|test)($|/)' :p | 10:52 |
| jazzdog | hi | 10:52 |
| jazzdog | i have fixed a lot of warnings in the sniffit package. this should fix this bug: https://bugs.launchpad.net/ubuntu/+source/sniffit/+bug/107180 | 10:53 |
| ubottu | Ubuntu bug 107180 in sniffit "Segmentation Fault" [Undecided,Invalid] | 10:53 |
| jazzdog | how can i help the community with this? :) | 10:53 |
| Keybuk | jazzdog: https://wiki.ubuntu.com/DeveloperGuide/Sponsorship | 10:54 |
| jazzdog | Keybuk: thanks. could you please explain the 1st and 4th point under "attach your work" and the difference between them? sorry I'm new to ubuntu, coming from slackware | 11:03 |
| Keybuk | jazzdog: if you're looking to get involved, try #ubuntu-motu | 11:05 |
| lifeless | TheMuso: what are the parameters to run dmraid-activate with ? I happen to have needed to reboot... | 11:09 |
| TheMuso | lifeless: Probably the best way to get a log is to modify the file, adding set -x and dumping to a log file in /dev/.initramfs, regenerating the initramfs and rebootingv. | 11:12 |
| lifeless | TheMuso: yeah, I will | 11:12 |
| lifeless | TheMuso: the reboot was hardware :P | 11:12 |
| lifeless | TheMuso: but as I had it at the prompt I thought I'd ask | 11:13 |
| TheMuso | lifeless: ah ok. | 11:13 |
| TheMuso | best bet to see whats going on at a glance is to run sh -x /sbin/dmraid-activate sda or dmraid-activate sdb | 11:13 |
| TheMuso | sorry dmraid-activate /dev/sda/b | 11:14 |
| TheMuso | so either drive | 11:14 |
| lifeless | yah | 11:14 |
| lifeless | I tried that | 11:14 |
| lifeless | dmraid-activate /dev/sda | 11:14 |
| lifeless | dmraid-activate /dev/sdb | 11:14 |
| lifeless | no output, no activation | 11:14 |
| TheMuso | and nothing? | 11:14 |
| TheMuso | cdid you run with sh -x? | 11:15 |
| TheMuso | s/cdid/did/ | 11:15 |
| lifeless | no didn't think to run it that way | 11:15 |
| TheMuso | right | 11:15 |
| Keybuk | cjwatson: have you ever seen make utterly fail to traverse deps? | 11:24 |
| cjwatson | Keybuk: not in a way I ever proved to be make's fault :-) | 11:26 |
| cjwatson | usually turned out to be me misunderstanding some abstruse feature of GNU make | 11:27 |
| Keybuk | I think it's bzr's fault | 11:27 |
| Keybuk | shelve has done weird things to my timestamps | 11:27 |
| lool | Ok so my strace/valgrind issues were: setuid/setgid executable can't be run by valgrind; strace was crashing in jaunty, I filed bug #376858, but the karmic version fixes this | 11:39 |
| ubottu | Launchpad bug 376858 in strace "strace: malloc(): memory corruption (fast): 0x00000000026452c0" [Undecided,Fix released] https://launchpad.net/bugs/376858 | 11:39 |
| lool | Otherwise it's perfectly fine to run python or strace under valgrind | 11:41 |
| cjwatson | lool: I was going to suggest set-id problems earlier, but you gave ls as your example so I decided not to bother ... | 11:44 |
| cjwatson | I don't suppose that a similar set-id-handling trick to the one mentioned in strace(1) works with valgrind? | 11:45 |
| lool | cjwatson: having an alternate suid valgrind? (there's also the -u flag, but didn't see the corresponding valgrind flag) I guess I can try out | 11:59 |
| cjwatson | that's what I meant, yes | 11:59 |
| lool | cjwatson: It didn't work to run valgrind suid root | 12:13 |
| lool | Albeit interestingly I didn't get the warning | 12:14 |
| lool | that said, I'm not running the suid root program directly, but via pyhton | 12:16 |
| Riddell | pitti: we have a couple of non-trivial SRU requests | 12:33 |
| Riddell | pitti: firstly plasma-widget-network-manager is broken in many ways in jaunty which is quite a big problem for people | 12:34 |
| Riddell | we have a new version which fixes a lot of scenarios but it's a new snapshot and not a simple patch | 12:34 |
| directhex | who should i poke if a link on summit.ubuntu.com is 404ing? | 12:52 |
| Hobbsee | directhex: Keybuk, usually | 12:55 |
| pitti | Keybuk: ah, thanks for the magic :) | 12:55 |
| directhex | Keybuk, the link for "Xorg: Driver Selection for nvidia hardware" points to +spec/driver-selection-for-nvidia-hardware instead of the correct +spec/desktop-karmic-xorg-driver-selection-for-nvidia-hardware/ | 12:56 |
| pitti | Riddell: my primary requirement is "does it cause regressions" | 12:57 |
| pitti | Riddell: so if not a lot is working with the current version, and it's a major regression wrt. intrepid, it sounds feasible | 12:57 |
| pitti | how intrusive are the chnages? | 12:57 |
| pitti | just 100 individual bug fixes or a complete rewrite? | 12:58 |
| Riddell | pitti: 100 bug fixes | 12:58 |
| Riddell | beta quality vs alpha | 12:58 |
| === azeem_ is now known as azeem | ||
| Riddell | we've been testing it quite a bit and havn't heard of any regressions | 12:59 |
| pitti | Riddell: sounds like we should let it mature in -proposed for a while then | 12:59 |
| Riddell | yes | 12:59 |
| Riddell | pitti: the other SRU is KDE 4.2.3 | 13:00 |
| Riddell | which has also been tested in PPAs and seems to have no problems | 13:00 |
| directhex | the whole thing? | 13:02 |
| pitti | Riddell: that sounds quite a bit more ambitious, and much harder to test for regressions.. | 13:02 |
| Riddell | nothing we have done before for intrepid | 13:02 |
| Riddell | directhex: sure why not, if upstream make bugfix releases it seems impolite not to use them | 13:03 |
| pitti | yeah, unfortunately we were pretty lax with intrepid SRUs because that was so broken in the first place | 13:03 |
| pitti | but jaunty itself should be much better? | 13:03 |
| directhex | Riddell, it's never been 100% clear to me the attitude towards bugfix releases versus bug fix patches | 13:04 |
| pitti | they just bind a lot of work and cause instability, so we shouldn't do them too liberally | 13:04 |
| pitti | can we at least limit it to individual components were people filed actual bugs against? | 13:06 |
| Riddell | ok, maybe ScottK will want to argue the case more or knows of paticular packages which have important fixes | 13:06 |
| * ScottK looks up. | 13:06 | |
| ScottK | pitti: I would argue that our experimentation in Intrepid showed that we we can reasonably reliably deliver KDE point releases without regression. Equally it shows that users benifit from the update (I certainly did). I think that if we can repeat the process for Jaunty it would be of benifit to the users. | 13:10 |
| ScottK | pitti: I also think that we should minimize proliferation of of unofficial repositories and deliver this via the Ubuntu archive. | 13:10 |
| pitti | ScottK: that's a knockout argument | 13:10 |
| pitti | because it applies to all packages | 13:11 |
| pitti | and kind of defeats the purpose of a stable release | 13:11 |
| pitti | we had that major exception in intrepid because it was particularly bad when released, but jaunty wasn't | 13:11 |
| ScottK | I can also see this being a case where you might want the tech board to decide. | 13:11 |
| pitti | and if we keep concentrating on fixing stables instead of fixing development releases, we invest in the wrong direction | 13:12 |
| ScottK | I do think the benifit from from 4.1.4 was less than 4.1.3. | 13:12 |
| pitti | we stretched the SRU policy a lot in intrepid, but we can't maintain this forever | 13:12 |
| ScottK | I think it might be reasonable just to deliver the first update and not the 2nd. | 13:12 |
| pitti | ScottK: of course you are welcome to challenge this on the TB, of course I'll comply to a TB decisisuionm | 13:13 |
| ScottK | pitti: I'd rather not have it be a challenge against what you say, I was hoping more we could come up with something you could support. | 13:13 |
| ScottK | TB specifically is the authority to grant microversion update exceptions. | 13:14 |
| directhex | compromise: ubuntu-backports ? | 13:14 |
| lool | Is there no special provision for point updates to KDE sources like there is for GNOME packages? | 13:14 |
| Riddell | we want backports for new KDE versions | 13:14 |
| ScottK | So if Intrepid was an experiment, then we get official approval before doing it in Jaunty (or not). | 13:14 |
| ScottK | directhex: That would be my plan B, but as Riddell says has other complications. | 13:15 |
| Riddell | lool: what special privision does gnome have? | 13:15 |
| ScottK | lool: There is not (I think we should get one). | 13:15 |
| pitti | ScottK: it's not "against me", it's "against SRU policy" | 13:15 |
| ScottK | pitti: OK. | 13:15 |
| pitti | it's not like I'd arbitrarily decide that :) | 13:15 |
| pitti | lool: we don't update GNOME packages either | 13:16 |
| lool | I thought GNOME had special exception to not have a too heavy SRU process just after release | 13:16 |
| pitti | lool: that only applied to hardy | 13:16 |
| pitti | a decision by TB | 13:16 |
| lool | Hmm ok, for some reason I thought it was permanent, nevermind then | 13:16 |
| pitti | and we really, really, REALLY need to stop throwing so much time at stables | 13:16 |
| ScottK | Riddell: How about jaunty-backports for now and then ask TB to add KDE to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions | 13:16 |
| pitti | we do not have enough development power for that, and users don't appreciate installing 100 MB of updates every day either | 13:17 |
| lool | The thing is that we don't get enough QA and we push a lot of changes until the last minute, I'm in a bad position to criticize this as I had to do so myself to reach some goals in previous releases | 13:17 |
| ScottK | pitti: For the KDE updates it isn't a manpower issue. We will package them. The only question is where do we deliver them. | 13:17 |
| Riddell | ScottK: can do although if they don't approve Gnome I doubt they'll approve KDE | 13:18 |
| ScottK | Did Gnome ever ask? | 13:18 |
| lool | When I say QA above, I mean community testing; I think QA works well on some key stacks, but not on the less used packages :-/ | 13:18 |
| ScottK | Riddell: I wouldn't have dared ask for KDE in the KDE3 timeframe as they did not do bugfix only releases. I think in 4.1/4.2 they have shown discipline about it. | 13:19 |
| pitti | ScottK: you also need to test them heavily, and the bigger the updates get, the harder it is to ensure that it doesn't have major regressions | 13:19 |
| pitti | and there's also the user inconvenience of downloading tons of updates | 13:19 |
| ScottK | pitti: This is true, but I think we've shown we can do the testing. | 13:19 |
| ScottK | We also have a lot of user demand for the updates. | 13:19 |
| seb128 | lool: the issue is that stable is what most users are using | 13:19 |
| lool | seb128: Yeah | 13:20 |
| pitti | ScottK: right, but it still binds manpower | 13:20 |
| ScottK | 4.2 is a lot better than 4.1, but it's not nearly as stable as KDE3 yet. | 13:20 |
| seb128 | I had the discussion this week with pitti about GNOME stable updates | 13:20 |
| pitti | some people demand updates all the time, but *shrug8 | 13:20 |
| lool | seb128: But we have a really large window where people are encouraged to upgrade to shake out bugs | 13:20 |
| ScottK | pitti: Yes, but we are going to do the work anyway. | 13:20 |
| pitti | ScottK: see, and that's what I'd like to see stopped :) | 13:20 |
| ScottK | In this case we've already done it, so it's a sunk cost in any case. | 13:21 |
| lool | seb128: Usually, from beta to final I am always too busy to take new stuff on my plate, such as new bugs discovered by people upgrading | 13:21 |
| seb128 | lool: I consider jaunty as a good version and worth stabilizing it a bit, especially where karmic shape to be a bumpy one | 13:21 |
| seb128 | lool: I expect lot of people will want to stay on jaunty over karmic | 13:21 |
| ScottK | Oh dear. | 13:21 |
| lool | seb128: Makes sense | 13:21 |
| ScottK | seb128: Hopefully not Intel video users. | 13:21 |
| ScottK | I hope that gets better. | 13:21 |
| seb128 | I'm not interested in trolls | 13:22 |
| ScottK | seb128: I'm not trollilng. The Intel video experience on Jaunty is sub par and saying so is just stating facts. | 13:22 |
| Hobbsee | is karmic any better yet, though? | 13:22 |
| pitti | ScottK: agreed | 13:22 |
| pitti | Hobbsee: it will be differently broken | 13:23 |
| seb128 | it's not an issue problem and not something ubuntu has total control on | 13:23 |
| Hobbsee | pitti: well, yeah, I guess that's normal :) | 13:23 |
| seb128 | issue -> easy | 13:23 |
| pitti | Hobbsee: intel, I mean, with all the new UXA/KMS stuff | 13:23 |
| ScottK | seb128: I wasn't laying blame. I was hoping next time it would be better. | 13:23 |
| seb128 | hey Hobbsee, long time that I didn't talk to you, how are you? | 13:23 |
| Hobbsee | pitti: that's true. | 13:23 |
| pitti | yeah, intel wise jaunty was quite a dent :( | 13:23 |
| * directhex thinks calm & beer should be liberally issued | 13:24 | |
| seb128 | I expect that karmic will not be a good luser version | 13:24 |
| tjaalton | ScottK: it can't get any worse ;) | 13:24 |
| Hobbsee | seb128: heya! I'm doing OK. Not really active, focussing mainly on uni work, to get it finished. Done at the end of the year, into the big wide world - woot! | 13:24 |
| Hobbsee | tjaalton: sure it can. Hardy I could'nt play video most of the time ;) | 13:24 |
| Hobbsee | tjaalton: intrepid plays video. | 13:24 |
| Hobbsee | er, wait. s/hardy/intrepid; s/intrepid/jaunty/ | 13:25 |
| tjaalton | Hobbsee: lucky you :) | 13:25 |
| Hobbsee | tjaalton: oh, indeed. I just didn't watch any movies on this laptop for 6 months or so ;) | 13:25 |
| jazzdog | comeon, everything plays video if one builds mplayer himself :) | 13:26 |
| Hobbsee | jazzdog: actually, the only thing that would work for me was xine-ui ;) | 13:27 |
| Hobbsee | which was...interesting | 13:27 |
| ScottK | pitti and Riddell: Did we reach some resolution on a path forward? | 13:27 |
| pitti | ScottK: I'd really like you to reconsider and focus efforts on karmic, but as I said, if you think you want an exception, you should feel free to ask the TB | 13:28 |
| ScottK | pitti: OK. Thanks. | 13:29 |
| Riddell | I'm pretty sure the kubuntu team will always want to make backports, they're very popular (at least we get a lot of complains from being late with 4.3 beta) | 13:29 |
| ScottK | Riddell: ? Backports and then think about it (backports won't conflict until 4.3.0 so we have some time) | 13:29 |
| Riddell | ScottK: yeah go for it | 13:29 |
| * Riddell out for a bit | 13:30 | |
| Hobbsee | Riddell: not to mention they've routinely made backports on kubuntu.org, too | 13:30 |
| Hobbsee | or at least, back when I ran it | 13:30 |
| directhex | Hobbsee, exciting career plans yet? | 13:32 |
| Keybuk | directhex: poke rickspencer or pitti ;) | 13:32 |
| Hobbsee | directhex: none yet. Hoping to get bites when I've finished the degree, or close to it. | 13:32 |
| * directhex redistributes buck | 13:32 | |
| ScottK | Hobbsee: That's a good point (re kubuntu.org). | 13:33 |
| ogra | cjwatson, poke ... http://ports.ubuntu.com/ubuntu-ports/pool/universe/l/linux/ seems all linux packages for armel landed in universe again | 14:06 |
| cjwatson | ogra: OK, I'll have a look, thanks | 14:11 |
| ogra | thanks for looking | 14:11 |
| cjwatson | ogra: should be fixed for the next relevant publisher run (visible a bit over 1.5 hours from now) | 14:17 |
| ogra | cjwatson, thanks a lot | 14:17 |
| soren | I see this is accepted for UDS, but I can't see it on the schedule anywhere? https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-swapfile | 14:29 |
| cjwatson | soren: we took it off as it's already been discussed twice and just needs time to implement | 14:33 |
| soren | cjwatson: Alright. Thanks. | 14:34 |
| === asac_ is now known as asac | ||
| pitti | what the heck went wrong with the PPAs? | 15:11 |
| pitti | amd64 6010 builds waiting in queue | 15:12 |
| pitti | i386 11538 builds waiting in queue | 15:12 |
| pitti | if that isn't a DoS, what is? | 15:12 |
| directhex | 11539 builds is. | 15:12 |
| directhex | 11538 is merely popularity | 15:12 |
| directhex | cjwatson/test-rebuild-20090513 | 15:13 |
| directhex | that answer your question? | 15:13 |
| pitti | ah, I see | 15:13 |
| pitti | *phew* | 15:13 |
| pitti | I thought something was going crazy and reuploaded infinitely or so | 15:14 |
| directhex | i can do that if you want | 15:14 |
| sistpoty|work | oh, pitti: did your copying from jaunty-updates forward to karmic somehow confuse MoM? faumachine is now listed in universe-manual despite an identical tarball? | 15:16 |
| sistpoty|work | (not that it matters in regards to faumachine, but maybe other packages are affected as well) | 15:17 |
| pitti | sistpoty|work: hm, entirely possible, I don't know | 15:28 |
| pitti | but we have done that for a long time already | 15:28 |
| * apw looks for a main-sponsor to upload a grub change to karmic/jaunty, on bug #376879 | 15:40 | |
| ubottu | Launchpad bug 376879 in grub2 "grub2 installer modifies grub 0.97 menu.lst incorrectly and fails to chainload grub2" [Medium,In progress] https://launchpad.net/bugs/376879 | 15:40 |
| * seb128 points apw to ubuntu-main-sponsors on launchpad to subscribe to the bug | 15:41 | |
| apw | seb128, t'is done | 15:43 |
| seb128 | apw: ok something will look at it while doing sponsoring I guess | 15:45 |
| pitti | oh, argh | 15:45 |
| pitti | lool: you uploaded sqlite-3 to -updates instead of -proposed, and I failed to spot that | 15:45 |
| lool | pitti: Crap; sorry | 15:46 |
| lool | I really am not in a good shape today | 15:46 |
| pitti | I removed the package again | 15:46 |
| lool | pitti: Thanks | 15:46 |
| lool | pitti: Do you have the .Dsc? I had removed it since it was accepted | 15:47 |
| lool | otherwise I'll rebuild it | 15:47 |
| pitti | lool: please reupload | 15:47 |
| pitti | lool: yes, you can grab it from launchpad | 15:47 |
| lool | In "Done"? | 15:47 |
| pitti | https://edge.launchpad.net/ubuntu/+source/sqlite3/3.6.10-1ubuntu0.1 | 15:48 |
| lool | Thanks | 15:48 |
| pitti | I set the build score to -1 and will reject any binaries that still make it | 15:48 |
| lool | pitti: I'm upload a .2 built with -v to include both versions | 15:49 |
| pitti | lool: just rename it .2 | 15:50 |
| pitti | lool: but your's is fine as well | 15:50 |
| pitti | as you like | 15:50 |
| lool | pitti: uploaded and | 15:50 |
| lool | sorry not accepted yet | 15:51 |
| lool | I need a break, bbl | 15:51 |
| pitti | I guess they'll just fail to upload, but I'll watch it anyway | 15:52 |
| lool | pitti: subject: [ubuntu/jaunty-proposed] sqlite3 3.6.10-1ubuntu0.2 (Waiting for | 16:01 |
| pitti | lool: accepted | 16:02 |
| cjwatson | apw: your kexec-tools patches all look fine, thanks (and sorry for the delay); the only change I'm making is that the upload target in debian/changelog for jaunty needs to be "jaunty-proposed" | 16:05 |
| apw | cjwatson, doh thanks | 16:05 |
| cjwatson | trivial to fix at sponsorship time though :) | 16:06 |
| apw | i get caught by that automatic installation of the current distro a lot | 16:06 |
| apw | i need to change ti to YOUARESTUPID or something by default | 16:06 |
| apw | .. it is all a learning expierence. one day i'll get one right first time | 16:07 |
| cjwatson | apw: by dch -i? | 16:07 |
| cjwatson | or dch -r? | 16:07 |
| apw | yeah it puts in your local distro release by default (dch -i) | 16:07 |
| cjwatson | if you put DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts then dch -i will put UNRELEASED in there instead; that said, dch -r will still use the current release (but you could set it by hand as an alternative) | 16:08 |
| apw | yeah that would be fine, as it goes nice and RED in there to tell me i've not set it if its UNRELEASED | 16:08 |
| apw | cjwatson, perfect thanks | 16:09 |
| lool | Do people like the dch -r defaulting to Ubuntu dev under Ubuntu? | 16:10 |
| lool | I keep mixing the Debian and Ubuntu behaviors because I work on Ubuntu packages from Debian and vice-versa | 16:11 |
| lool | Usually Debian's dch -r does what I want; Ubuntu's is wrong half of the time | 16:11 |
| seb128 | I almost never use dch -r, I usually use -i or -v new_version | 16:12 |
| * ScottK would like a dch -rd or something like that to get unstable | 16:12 | |
| cjwatson | I use dch -r all the time and like its behaviour | 16:12 |
| cjwatson | when I'm working on Debian packages I do so in a Debian chroot, since I need to do binary uploads anyway | 16:13 |
| ScottK | I find dch -r works well for me for Ubuntu | 16:13 |
| cjwatson | StevenK: can you or one of your team merge libhildon? I'd have no idea where to start | 16:15 |
| pitti | lool, ScottK: -d exists, it's called -U | 16:35 |
| Keybuk | hmm | 16:36 |
| ScottK | pitti: Thanks. | 16:36 |
| Keybuk | kernel panic on boot, at exactly the same time, thunder rolls outside | 16:36 |
| geser | where is your Igor? | 16:36 |
| doko | please could somebody process binutils in NEW (binutils-gold -> universe) | 16:38 |
| Awsoonn | Thank you seb128 | 16:42 |
| lool | pitti: That's just for the version number, right? jaunty is set unconditionally | 16:44 |
| lool | (well unless -Dfoo is used) | 16:44 |
| pitti | ah, right | 16:45 |
| pitti | -Dunstable would be the target | 16:46 |
| seb128 | Awsoonn: you're welcome, thanks for the work on the bug | 16:46 |
| === dpm is now known as dpm-afk | ||
| === ArneGoet1e is now known as ArneGoetje | ||
| cjwatson | asac: I've synced wpasupplicant into karmic, since Kel incorporated my patches; you might care | 18:29 |
| * asac *nods* | 18:55 | |
| === rickspencer3 is now known as rickspencer3-afk | ||
| ebroder | Anyone from motu-sru who could provide an opinion on bug #371581? | 20:37 |
| ubottu | Launchpad bug 371581 in erlang "erlang-base conflicts with old erlang-doc-html" [Undecided,New] https://launchpad.net/bugs/371581 | 20:37 |
| ion_ | Anyone feel like uploading command-not-found with the patch from LP #377065, or should i just wait for mvo? :-) | 21:56 |
| ubottu | Launchpad bug 377065 in command-not-found "zsh_command_not_found should use the pre*_functions arrays instead of overwriting the singular preexec/precmd functions" [Undecided,New] https://launchpad.net/bugs/377065 | 21:56 |
| directhex | how would i define which files should be uploaded by apport in the event of an app dying? | 22:07 |
| ion_ | directhex: /usr/share/apport/package-hooks | 22:09 |
| directhex | i should look into what would be needed for apport to get triggered by Managed exceptions in mono apps | 22:12 |
| ajmitch | directhex: I remember looking at that awhile ago, back then we discussed havign a small patch to the mono runtime to dump out the right info | 22:18 |
| directhex | ajmitch, i'll ask miguel what he thinks | 22:21 |
| === jldugger is now known as pwnguin | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!