| === Trevinho is now known as Trevinho|holiday | ||
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === sergiusens_ is now known as sergiusens | ||
| dholbach | good morning | 07:01 |
|---|---|---|
| === arrrghhh is now known as arrrghhhAWAY | ||
| dholbach | salut jibel, comment ça va? | 07:54 |
| jibel | guten Morgen dholbach, es geht mir gut, und dir? | 07:55 |
| dholbach | jibel, bien aussi :) | 07:56 |
| dholbach | jibel, do you know who could help nik90 and myself with https://code.launchpad.net/~dholbach/ubuntu-clock-app/reboot-packaging/+merge/229173 (it's the rewrite of the clock) to make all the test execution work in an expected way? | 07:56 |
| dholbach | jibel, I took the upstream source, added packaging to it and tried to do what I could, but I'm stuck | 07:56 |
| dholbach | jibel, there is a placeholder for unit tests, there are some autopilot tests, and I'm not sure if autopkgtest is the way to go, or the added -autopilot package | 07:57 |
| dholbach | AFAICS everything is a little bit broken, so it'd be good if somebody who knows what they're doing could help :) | 07:57 |
| jibel | dholbach, probably balloons can help. I think now autopkgtest is the preferred way to run the tests but before adding that layer tests must run without it. There are other click app that use autopilot and can be use as example. | 08:03 |
| jibel | dholbach, really balloons is well aware of all this | 08:03 |
| zyga | hey | 08:05 |
| zyga | is it just me or is all-canonical infrastructure down somehow? | 08:06 |
| zyga | chinstrap, irc, archive, etc | 08:06 |
| doko | same here | 08:06 |
| dholbach | zyga, I'm having trouble as well | 08:06 |
| zyga | yeah | 08:06 |
| psivaa | cjwatson: we are force shutting down the VM soon after we get 'ubiquity reboot' message in the install log. so filesystem corruption could be possible. i had to add a sleep before the shutdown for server installs which saw a similar issue before but not doing that for desktop now. will try and add a sleep before the shutdown and try if it improves. | 08:06 |
| zyga | thanks for confirming, so it's not anything on my end then | 08:07 |
| dholbach | zyga, it seems to work though from another machine I have access to | 08:07 |
| zyga | dholbach: can you ssh to chinstrap or get a hold of IS? | 08:07 |
| zyga | dholbach: I cannot even find the IS emergency phone number now | 08:07 |
| dholbach | zyga, #canonical-sysadmin | 08:09 |
| dholbach | jibel, the bugs we are looking at right now are 1354377 and 1355145 - it'd be good if we had a bit better idea what the general process is | 08:11 |
| dholbach | jibel, but yeah... maybe I should have a closer look at some other packages | 08:11 |
| jibel | dholbach, I can have a look later today if it can wait a couple of hours | 08:14 |
| * dholbach hugs jibel | 08:14 | |
| dholbach | merci beaucoup! | 08:14 |
| jibel | dholbach, it seems classic problems with uninitialized dbus session an stuff like that. I'll have a look. | 08:15 |
| dholbach | jibel, at this point I had no idea what I was doing :) | 08:15 |
| === dosaboy_ is now known as dosaboy-alt | ||
| xmj | good morning | 09:14 |
| xmj | does ubuntu provide a mirror for america's army as listed here - https://help.ubuntu.com/community/AmericasArmy ? | 09:14 |
| xmj | i'm working on updating the freebsd port of it, and noticed that they took all 11(!) mirrors down. | 09:14 |
| rbasak | bdmurray: re: bug 1257186, I did try a more recent patch from that bug (from upstream, actually) but samba FTBFS for other reasons, and I didn't get through figuring that all out. | 09:14 |
| ubottu | Error: Could not gather data from Launchpad for bug #1257186 (https://launchpad.net/bugs/1257186). The error has been logged | 09:14 |
| rbasak | I'll update the bug, but it's open for testing and fixing atm. | 09:14 |
| === ming is now known as Guest79564 | ||
| === vrruiz_ is now known as rvr | ||
| === chrisccoulson_ is now known as chrisccoulson | ||
| mapreri | pitti offline from 3 days?? what the hell is going on? :o | 09:28 |
| === hloeung_ is now known as hloeung | ||
| seb128 | mapreri, he's on holidays this week | 09:34 |
| cjwatson | psivaa: A sync seems more likely to help than a sleep, but maybe ... | 09:35 |
| psivaa | cjwatson: ok, i'll need to figure out how to integrate that to utah :) | 09:35 |
| mapreri | seb128: ouch, I'd rather say pitti never goes on holiday :) | 09:36 |
| seb128 | lol | 09:36 |
| cjwatson | psivaa: Should be no harder than sleep? Just another command | 09:37 |
| psivaa | cjwatson: ohh?, i'll use it then. thank you | 09:37 |
| cjwatson | psivaa: May have to experiment a bit; actually forcing everything out to disk can be a bit of a black art sometimes | 09:39 |
| doko | xnox, do you know why you did add the Breaks: clang (<< 1:3.5) in clang-3.5? | 09:55 |
| xnox | doko: such that we can change clang metapackage to default to 3.5 without need to rebuild 3.5 toolchain. | 09:58 |
| xnox | doko: i believe it's committed in debian packaging VCS as well (reported to debian developer via private email) | 09:58 |
| xnox | doko: otherwise clang defaulting to 3.5, was depending on clang-3.5 yet not coinstallable. | 09:59 |
| doko | xnox, https://launchpad.net/ubuntu/+source/creduce/2.2~pre3-2 | 09:59 |
| xnox | doko: multiple clang toolchains are not coinstallable. You are trying to install both clang-3.4 and clang-3.5 but they conflict with each other. | 10:01 |
| xnox | doko: drop "clang" build-dep, and use "clang-3.5" | 10:01 |
| doko | xnox, are you serious? | 10:01 |
| xnox | as all clang-3.x packages provide /usr/bin/clang. We are working on making them co-installable gcc style. | 10:01 |
| xnox | doko: yes. I no joke. | 10:02 |
| doko | argh, that's silly | 10:02 |
| doko | xnox, https://buildd.debian.org/status/package.php?p=creduce&suite=unstable works in debian | 10:02 |
| xnox | doko: well https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=736057 is closed now, so clang is co-installable in debian now. | 10:06 |
| ubottu | Debian bug 736057 in clang "clang: Co installable clang versions" [Wishlist,Fixed] | 10:06 |
| xnox | doko: hm, maybe my breaks is wrong now. | 10:07 |
| michagogo | whois arges arges | 10:35 |
| michagogo | erm | 10:35 |
| michagogo | Does anyone know if the 7-day thing for SRU is just on the 7th day or later, or if it has to be at least 168 hours? | 10:36 |
| cjwatson | michagogo: It's implemented by sru-report in lp:ubuntu-archive-tools. | 10:37 |
| cjwatson | michagogo: You can see the current reported age on http://people.canonical.com/~ubuntu-archive/pending-sru.html | 10:38 |
| cjwatson | That's in practice what we look at. | 10:38 |
| michagogo | Ah, okay | 10:38 |
| michagogo | So 168 hours, then? | 10:38 |
| cjwatson | I would be surprised if it were otherwise. | 10:38 |
| michagogo | okay | 10:38 |
| michagogo | cjwatson: thanks | 10:39 |
| cjwatson | Basically it's whenever an SRU admin happens to look at that page and notice something >= 7 days. | 10:39 |
| michagogo | Ah, cool | 10:39 |
| michagogo | So sometime in the next day or two, probably? | 10:39 |
| cjwatson | No idea what package you're talking about, so can't say. | 10:40 |
| michagogo | (IIRC it was accepted a week minus ~6 hours ago) | 10:40 |
| michagogo | bitcoin | 10:40 |
| cjwatson | michagogo: It's at 6 days, but has one unverified bug. See the page linked above. | 10:42 |
| michagogo | cjwatson: yeah, I have no idea what that bug is | 10:42 |
| cjwatson | We won't normally look at packages where all the bugs at the right aren't highlighted green. | 10:42 |
| michagogo | It's completely irrelevant, as the SRU is removing the package | 10:42 |
| michagogo | Looks like that bug was an older SRU that didn't get verification and got rejected | 10:43 |
| michagogo | "This SRU has remained unverified after 175 days in the -proposed queue. I've removed it now from quantal-proposed and am marking the task 'wontfix'. The package has already been removed from precise-proposed for the same reason.: | 10:44 |
| michagogo | s/:/"/ | 10:44 |
| cjwatson | I guess somebody will have to look at that and check that it's irrelevant. | 10:44 |
| michagogo | What makes that bug show up there, btw? | 10:46 |
| cjwatson | Haven't investigated. | 10:46 |
| cjwatson | It's probably walking through the versions between current -updates and current -proposed or something. | 10:46 |
| cjwatson | You can read sru-report if you fancy working it out | 10:47 |
| === juliank0 is now known as juliank | ||
| michagogo | cjwatson: ah, I think I found it | 10:50 |
| michagogo | https://www.irccloud.com/pastebin/TcMjGLhv | 10:50 |
| michagogo | er | 10:50 |
| michagogo | In the changelog: | 10:50 |
| michagogo | https://www.irccloud.com/pastebin/oQ4h6TiW | 10:50 |
| cjwatson | We can ignore it if it's genuinely not a problem | 10:51 |
| michagogo | It's not. | 10:51 |
| cjwatson | But I'll wait for the aging period to expire since that involves much less thinking | 10:51 |
| michagogo | Not a problem... | 10:51 |
| michagogo | I think I first started looking into how to get the package removed back in October, what's another 5-6 hours? :-) | 10:52 |
| michagogo | anyone know how often pending-sru.html updates? | 10:59 |
| cjwatson | michagogo: 10,40 * * * * | 11:01 |
| michagogo | What format is that in? | 11:01 |
| cjwatson | crontab | 11:01 |
| * michagogo googles | 11:01 | |
| cjwatson | man 5 crontab | 11:01 |
| cjwatson | I don't remember whether it always runs inside its window - the job is quite slow - so I guess it might be less frequent than stated | 11:01 |
| michagogo | Ah, so it's on minute 10 and 40 of every hour of every day of every month, every day of the week? | 11:02 |
| cjwatson | Yes | 11:02 |
| michagogo | Also, the timestamp on there is 10:35:54 UTC, so... | 11:02 |
| cjwatson | Implying it takes ~25 minutes. Might get quicker soon as I just released the big batch of KDE stuff | 11:03 |
| michagogo | 25? or perhaps 55? | 11:03 |
| cjwatson | michagogo: Don't know, not going to look. It doesn't matter that much. | 11:07 |
| michagogo | yeah, that's true | 11:07 |
| === pete-woods is now known as pete-woods|away | ||
| doko | jamespage, zul: any idea why python-wsme uses nosetests for 2.7, and setuptools for 3.4? and any idea why that fails (trying to download WebOb)? | 11:47 |
| psivaa | Saviq: regarding your test.xml archiving for http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/, in fact *test*.xml and *Test*.xml are already archived. so I'm not sure why you dont see the results that you're expecting | 11:55 |
| Saviq | psivaa, that's a good question, could the job collect the .xml files in artifacts? | 11:59 |
| psivaa | Saviq: that could be done | 12:03 |
| zul | doko: i dont but im on holiday this wek | 12:04 |
| doko | everbody seems to be =) | 12:04 |
| jamespage | doko, ah the joy of august | 12:09 |
| === MacSlow is now known as MacSlow|lunch | ||
| === Mikee_C_ is now known as Mikee_C | ||
| cjwatson | Laney: Hmm, do you think you could be persuaded to merge gst-plugins-bad1.0? I'm touched-it-last due to an attempted rebuild for http://people.canonical.com/~ubuntu-archive/transitions/libass.html, but it fails to build due to a strict opencv version constraint, I don't really know the package, and it looks as though it ought to be caught up with the rest of gstreamer1.0 anyway | 12:40 |
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| doko | jamespage, found it ... bad barry ... https://launchpad.net/ubuntu/+source/python-webob/1.4-1ubuntu1 | 14:10 |
| jamespage | doko, awesome - thanks! | 14:10 |
| psivaa | cjwatson: adding a 5 second sleep just before shutting down the VM fixes the issue of openssh-server installation issue for i386 desktop | 14:20 |
| psivaa | tried using sync too, but it dint help a lot. so without rocking utah too much, i'm going to use the sleep for now :) | 14:21 |
| psivaa | cjwatson: thanks for your input | 14:21 |
| psivaa | jibel: so the i386 desktop smoke tests are running after a long time and the image has been promoted to current today | 14:24 |
| Mirv | hmm, is there a process for updating release notes? | 14:24 |
| Mirv | in 10.04 LTS /etc/resolv.conf was a real file, and an upgrade to 12.04 LTS did not change it to the new default of a symlink. this did not hurt in 12.04 LTS, but upgrading to 14.04 LTS apparently yields non-working name resolving. | 14:24 |
| Mirv | my previous trusty fix fixed the case where /etc/resolv.conf was removed by user (or live CD customizer...), but it does not improve the situation when /etc/resolv.conf is there and is a normal file, like it was in 10.04 LTS | 14:25 |
| Mirv | well, there's the ubuntu-release-notes project, I'll use that instead of editing directly | 14:30 |
| jibel | psivaa, thanks for the update | 14:31 |
| === Ursinha is now known as Ursinha-afk | ||
| Mirv | so, filed bug #1355868 | 14:36 |
| ubottu | bug 1355868 in Release Notes for Ubuntu "Ubuntu 10.04 LTS upgraded to 14.04 LTS via 12.04 LTS does not have proper name resolution" [Undecided,New] https://launchpad.net/bugs/1355868 | 14:36 |
| === Ursinha-afk is now known as Ursinha | ||
| zyga | xnox: hey | 15:14 |
| zyga | xnox: do you have a moment to talk about python3.4 and libpython3.4? | 15:15 |
| zyga | doko: so, about libpython3.4 not being a dependency of python3.4 executable | 15:23 |
| doko | zyga, yes, it doesn't depend on it | 15:24 |
| zyga | doko: if it would use dynamic linking everything would be prohibitetively slower? | 15:25 |
| doko | zyga, as I did say, 10-15% | 15:25 |
| zyga | doko: the problem is that anything that links to python3 now needs to *ship* python3, with all the security issues around that (on the phablet) | 15:25 |
| doko | especially on register starved architectures like armhf and i386 | 15:26 |
| zyga | doko: I'm trying to find a way to either get the .so file back on the image | 15:26 |
| zyga | doko: or figure out something else that could prevent us from having python inside our click package while we still have it in the os | 15:26 |
| doko | zyga, no, libpython3.4 depends on libpython3.4-stdlib, not on python3.4 | 15:27 |
| zyga | doko: right, stdlib is there, this whole discussion is about the .so file | 15:28 |
| zyga | doko: if I'd like to get it as a part of touch images | 15:28 |
| zyga | doko: do you know who I should be talking to? | 15:28 |
| doko | zyga, sorry, no. why isn't that pulled in by a dependency? | 15:29 |
| doko | maybe ask Mirv, ogra_ tvoss? | 15:29 |
| zyga | doko: because nothing depends on libpython3.4 anymore, apparently | 15:29 |
| zyga | doko: python3 doesn't, all of the apps just use it as an interpreter | 15:29 |
| ogra_ | doko, recommends vs deps perhaps ? touch doesnt install recommends | 15:30 |
| zyga | doko: pyotherside does but that's different and apparently I cannot convince anyone to include it in the image | 15:30 |
| zyga | we can ship pyotherside | 15:30 |
| zyga | but shipping python3.4m.so starts to be fishy | 15:30 |
| zyga | (security) | 15:30 |
| jdstrand | zyga: I think you want lool and pmcgowan_ | 15:30 |
| zyga | and it's all just silly, we have python there anyway, just not the way (our) particular app needs it | 15:31 |
| zyga | ok, thanks | 15:31 |
| zyga | lool: hey | 15:31 |
| ogra_ | right, and as i said., we are 600MB to big in the install already | 15:31 |
| zyga | ogra_: how do you plan to cut 600MB? | 15:31 |
| zyga | ogra_: that feels unrealistic | 15:31 |
| xnox | zyga: we do not ship python on touch | 15:31 |
| ogra_ | there must be some really serioous reason to add anything now | 15:31 |
| xnox | zyga: and will not. | 15:31 |
| zyga | xnox: we ship python3 today, has that changed? | 15:31 |
| xnox | zyga: please do not rely on it being there. | 15:31 |
| zyga | xnox: will all the deps be migrated away? | 15:32 |
| xnox | zyga: well, system-image is in python3 so, yeah that is there. | 15:32 |
| ogra_ | zyga, long term by droping all the autopilot bits etc ... | 15:32 |
| xnox | zyga: and will stay | 15:32 |
| zyga | xnox: so we will ship python3.4 on the image | 15:32 |
| xnox | zyga: but it's not an app framework one is allowed to use. | 15:32 |
| zyga | xnox: I'm trying to find a RTM-ready solution | 15:32 |
| zyga | xnox: for our (hw/cert) tools | 15:32 |
| xnox | zyga: it's not part of the sdk | 15:32 |
| zyga | xnox: sure, it's not but we're special | 15:32 |
| ogra_ | so shop what you need in your package | 15:32 |
| xnox | zyga: and can be removed at whimp, or like blocked from accessing with apparmor. | 15:32 |
| zyga | xnox: we don't care, we cannot rewrite our tools and we wont, we took that higher already, we need _a_ solution | 15:32 |
| ogra_ | *ship | 15:32 |
| ogra_ | this is what you have to do long term anyway | 15:33 |
| zyga | ogra_: long term we might just do that | 15:33 |
| xnox | zyga: we seeded a bunch of packages because "something rather as a click needs it" | 15:33 |
| ogra_ | the image will massively shrink still | 15:33 |
| zyga | ogra_: but we need something for now that doesn't pull the carpet from under us | 15:33 |
| zyga | ogra_: so will python be on the RTM image? | 15:34 |
| xnox | zyga: but generally it's an exception, it's best to make your click building procedure to bundle things and/or statically link. You can't statically link python, but you should be able (at build time) to ship it into the ldpreloaded path and it will just work. | 15:34 |
| ogra_ | thats why i'm suggesting a method that works now and wil work later :) | 15:34 |
| xnox | zyga: what are you after, and what is missign? | 15:34 |
| xnox | zyga: given that python3 is on the image and is usable..... | 15:34 |
| ogra_ | zyga, perhaps | 15:34 |
| zyga | xnox: python3.4 is but libpython3.4m.so isn't (and that's what we actually need) | 15:34 |
| ogra_ | basic python will always be there for system-image | 15:34 |
| xnox | zyga: are you building compiled extensions? | 15:34 |
| ogra_ | abd currently whatever autopilot still pulls ion is there | 15:35 |
| zyga | xnox: yes and no, we depend on pyotherside, everything we have is pure python | 15:35 |
| zyga | xnox: pyotherside is pulled in from the archive as-is | 15:35 |
| xnox | zyga: then you will at compile time, will also need to copy libpython3.4m as you'd need to rebuild that everytime python shared library is. | 15:35 |
| zyga | xnox: and it links to libpyton3.4 | 15:35 |
| xnox | zyga: so pull libpython3.4m at the same time as pyotherside and ship into lib/$multiarch-tripplet inside your click, which is a set ldpreload path by ubuntu-app-launch. | 15:36 |
| zyga | xnox: that doesn't work, somehow, I just tried that | 15:36 |
| xnox | zyga: and you'd need to pull in all shared deps that are not in the sdk but are deps of the pyotherside like that. | 15:36 |
| zyga | xnox: but it's also a security issue which we wanted to avoid (shipping pyotherside, fine, shipping a part of python itself, less fine) | 15:36 |
| xnox | zyga: why is that a problem? well - did you use the correct path? check ubuntu-app-launch code to see the environment variables it sets. | 15:36 |
| zyga | xnox: we have no other deps if that matters :/ | 15:36 |
| zyga | xnox: I'll check it out but I still don't think that's the right way | 15:37 |
| zyga | xnox: we're kind of system-ish as well | 15:37 |
| xnox | zyga: we are not going to pull in libpython3.4 just for your optional component, as we will not ship qa/cert tool on the image itself. | 15:37 |
| zyga | xnox: but we get the app-level treatment | 15:37 |
| zyga | xnox: that's not entirely decided yet though | 15:37 |
| * zyga mutters something about some special modes for testing and engineering | 15:37 | |
| * zyga looks at ubuntu-app-launch | 15:39 | |
| xnox | zyga: use qml and compile c++ =)))) | 15:39 |
| xnox | zyga: that's standard sdk these days. | 15:39 |
| zyga | xnox: that's fun but we have existing tools and we cannot and won't change that | 15:40 |
| zyga | xnox: and waving magic wand won't rewrite our code | 15:41 |
| zyga | xnox: so just lib/$triplet doesn't work for what I see, the qml plugin is found but loading libpython still fails (cannot find the .so file) | 15:41 |
| zyga | xnox: ok, so LD_LIBRARY_PATH is set, hmmm, | 15:43 |
| zyga | xnox: how can I use u-a-l on the device interactively? | 15:44 |
| zyga | xnox: what's tha app id? is that the click package id? | 15:45 |
| xnox | zyga: tedg can help you more =) | 15:45 |
| zyga | xnox: thanks | 15:45 |
| zyga | tedg: ^^ | 15:45 |
| tedg | zyga, So what's the issue? | 15:46 |
| zyga | tedg: I'd like to understand how ubuntu-app-launch works to debug how it sets LD_LIBRARY_PATH and how my app fails to find some .so files it needs | 15:46 |
| zyga | tedg: how do I use u-a-l? what is tha app id? | 15:46 |
| tedg | zyga, It's a combination of three things, the package name, the app name and the version number. | 15:47 |
| tedg | zyga, Probably the easiest way to discover it is to use ubuntu-app-triplet $pkgname | 15:48 |
| zyga | tedg: so if that's a click package how does that look like in practice? | 15:48 |
| zyga | $pkgname is click package name? | 15:48 |
| tedg | For instance calculator is: com.ubuntu.calculator_calculator_1.3.307 | 15:48 |
| tedg | zyga, Correct | 15:48 |
| zyga | ok | 15:48 |
| zyga | oh | 15:49 |
| zyga | xnox: fun, so it works when I install the package, fails from SDK "run" button | 15:49 |
| zyga | odd? | 15:49 |
| xnox | zyga: not really. sdk run button doesn't create full click, nor run it fully, i believe it just pushes the files and executes them without a full click/install cycle. | 15:51 |
| zyga | xnox: ah, that would explain it then | 15:51 |
| zyga | xnox: thanks, we got some bits moving | 15:51 |
| xnox | zyga: which imho is an sdk bug or feature. Discuss that with bzoltan | 15:51 |
| zyga | who should probably be here in this channel :) | 15:52 |
| doko | mlankhorst, we need a llvm-toolchain-3.4 merge ... for clang be co-installable with clang-3.4. do you volunteer? ;p | 15:53 |
| xnox | =))))) | 16:07 |
| xnox | doko: i did leave a pile of unmerged stuff didn't i?! =) | 16:07 |
| xnox | doko: i can probably do it late in the evening tonight. | 16:07 |
| xnox | doko: don't have gpg nor ssh access to my compile box at the moment. | 16:08 |
| slangasek | xnox: leave it? goodness no, you're still TIL | 16:19 |
| xnox | slangasek: lolz =) ok. then. | 16:20 |
| xnox | slangasek: may I join ~ubuntu-release? | 16:20 |
| slangasek | uh | 16:20 |
| slangasek | in theory you could join the team and then be added to the group? :) | 16:21 |
| xnox | slangasek: in practice, how does that happen? | 16:21 |
| slangasek | xnox: by consensus of the existing team | 16:22 |
| xnox | slangasek: ack. | 16:22 |
| slangasek | xnox: so you should start schmoozing infinity | 16:22 |
| slangasek | (who, incidentally, is a team admin, where I am not :) | 16:22 |
| xnox | slangasek: i'll write an email to ubuntu-release mailing list as a start. | 16:23 |
| Laney | cjwatson: I did, it FTBFS due to bug #1358074 | 16:50 |
| ubottu | Error: Launchpad bug 1358074 could not be found | 16:50 |
| Laney | bug #1350874 | 16:50 |
| ubottu | bug 1350874 in platform-api (Ubuntu) "/usr/include/ubuntu/application/ui/input/event_deprecated.h:79:24: error: redefinition of ‘struct PointerCoordinate’" [Undecided,Confirmed] https://launchpad.net/bugs/1350874 | 16:50 |
| cjwatson | Urgh. Well hopefully somebody will sort it out and finish the transition before I get back from vac :) | 16:51 |
| Laney | I've poked a couple of times already | 16:52 |
| === roadmr is now known as roadmr_afk | ||
| === mapreri is now known as mapreri|holiday | ||
| mlankhorst | doko: erm would prefer not, I'll look tomorrow | 18:54 |
| === JanC_ is now known as JanC | ||
| === roadmr_afk is now known as roadmr | ||
| === salem_ is now known as _salem | ||
| === cmagina_ is now known as cmagina | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!