| === pvo is now known as pvo_away | ||
| micahg | lifeless: distro bugs search seems to be having issues | 02:33 |
|---|---|---|
| wgrant | micahg: Timing out? | 02:33 |
| micahg | wgrant: yep, 3 times in a row | 02:33 |
| wgrant | micahg: Which URL? | 02:33 |
| micahg | https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=kpassgen&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package= | 02:33 |
| lifeless | https://bugs.launchpad.net/launchpad/+bug/661988 | 02:34 |
| wgrant | Do you have an OOPS ID? | 02:34 |
| micahg | 2, OOPS-1859L275, I filed the other one in bug 661988 | 02:35 |
| ubot5 | Launchpad bug 661988 in Launchpad itself "Timeout on Distribution:+bugs search" [Critical,Triaged] https://launchpad.net/bugs/661988 | 02:35 |
| ubot5 | https://lp-oops.canonical.com/oops.py/?oopsid=1859L275 | 02:35 |
| lifeless | micahg: that looks like the same issue | 02:56 |
| micahg | lifeless: same as? | 02:57 |
| lifeless | bug 661988 | 02:58 |
| ubot5 | Launchpad bug 661988 in Launchpad itself "Timeout on Distribution:+bugs search" [Critical,Triaged] https://launchpad.net/bugs/661988 | 02:58 |
| micahg | lifeless: right, that's why I added the first one there, but when I got 3 in a row, I figured it was time to escalate :) | 02:58 |
| lifeless | micahg: hi | 04:06 |
| lifeless | micahg: in that bug search | 04:06 |
| lifeless | micahg: are you selecting all the incomplete options ? | 04:06 |
| lifeless | (It looks like you may be) | 04:06 |
| micahg | lifeless: I just typed in the box and hit enter on the distro bugs home page :) | 04:07 |
| lifeless | heh, ok | 04:07 |
| lifeless | thanks | 04:07 |
| lifeless | we've found a missing index | 04:07 |
| lifeless | its being built | 04:07 |
| micahg | \o/ | 04:07 |
| lifeless | this may help a little | 04:07 |
| * micahg hugs lifeless | 04:08 | |
| lifeless | the query is also rather nuts, its got mutually unnecessary options | 04:08 |
| === pvo_away is now known as pvo | ||
| === pvo is now known as pvo_away | ||
| === Lcawte|Away is now known as Lcawte | ||
| om26er | I have a complaint for a person in launchpad https://launchpad.net/~mango-k | 09:50 |
| om26er | he subscribes mark shuttleworth to almost every bug report, then sometimes assigns bugs to canonical dx team | 09:51 |
| om26er | or assigns blueprints to mark too | 09:51 |
| mrevell | Hi om26er | 09:54 |
| === mrevell changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| * mrevell looks at the profile page | 09:54 | |
| * maxb reads the description of https://launchpad.net/~mango-k/+archive/ubuntu-releases and wonders in fear at the misguidedness :-/ | 09:56 | |
| mrevell | om26er, Do you have any example bugs or blueprints? | 09:57 |
| wgrant | maxb: Intriguing. | 10:02 |
| om26er | mrevell, soory was gone, just a sec | 10:06 |
| om26er | bug 667610 | 10:06 |
| ubot5 | Launchpad bug 667610 in coreutils (Ubuntu) "Floating Point Exception when chrooting into Arch installation on external hard drive" [Undecided,New] https://launchpad.net/bugs/667610 | 10:06 |
| om26er | bug 682678 | 10:06 |
| ubot5 | Launchpad bug 682678 in network-manager-applet (Ubuntu) "nm-applet crashed with signal 5 in _XError()" [Undecided,Incomplete] https://launchpad.net/bugs/682678 | 10:06 |
| om26er | bug 667600 | 10:06 |
| ubot5 | Launchpad bug 667600 in firefox (Ubuntu) "Official UDS-N Advertsement only has audio -- no video -- when played in Firefox 4 and Flash" [Undecided,New] https://launchpad.net/bugs/667600 | 10:06 |
| om26er | https://blueprints.launchpad.net/ubuntu/+spec/desktop-indicator-applet-diaspora-support | 10:07 |
| om26er | https://blueprints.launchpad.net/ubuntu/+spec/desktop-unity-n-divide-into-separate-plugins | 10:07 |
| om26er | and so on ;) | 10:07 |
| mrevell | Thanks om26er. I'll drop the guy a friendly email. | 10:08 |
| om26er | mrevell, thank you :) | 10:08 |
| mrevell | Thanks for letting us know. | 10:08 |
| zyga | hi, I need some help to recover a few branches affected by bug in parent branch handling affected by owner change | 10:48 |
| zyga | a few of lp:launch-control related branches became broken as they still depend on the previous URL of the trunk | 10:49 |
| zyga | for example, this command fails: bzr branch lp:~zkrynicki/launch-control/use-linaro-dashboard-bundle | 10:52 |
| === matsubara-afk is now known as matsubara | ||
| zyga | anyone/ | 11:20 |
| === Ursinha-afk is now known as Ursinha | ||
| === jtv is now known as jtv-eat | ||
| === Ursinha changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: Ursinha | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| Ursinha | zyga, hi, so I'm afraid an internet hiccup caused me to lose your explanation here :/ could you paste me the log somewhere else, please, so you won't need to explain all over again? | 11:58 |
| zyga | sure | 11:59 |
| zyga | hi, I need some help to recover a few branches affected by bug in parent branch handling affected by owner change | 12:00 |
| zyga | a few of lp:launch-control related branches became broken as they still depend on the previous URL of the trunk | 12:00 |
| zyga | for example, this command fails: bzr branch lp:~zkrynicki/launch-control/use-linaro-dashboard-bundle | 12:00 |
| zyga | (this is what I wrote here some time ago) | 12:00 |
| maxb | zyga: Hello, if it's the issue that I think you're referring to, the losas can fix things up server side given a list of branches that need it, or people with write permission on the affected branches can fix them themselves. | 12:06 |
| Ursinha | zyga, hmmm that happened to me sometime ago, and I recall having a bug filed for that | 12:06 |
| mok0 | james_w: ping | 12:06 |
| Ursinha | oops | 12:10 |
| zyga | re | 12:10 |
| zyga | Ursinha, sorry, accident | 12:10 |
| maxb | zyga: the losas can fix things up server side given a list of branches that need it, or people with write permission on the affected branches can fix them themselves. | 12:10 |
| zyga | maxb, I think all launch-control branches are affected, if a few are it's easier to skip them than to make a comprehensive list | 12:11 |
| zyga | maxb, (all should point at the same stacked branch anyway) | 12:11 |
| maxb | ok. So, are there any owned by you that you'd like me to explain how to fix right now to unblock immediate work, or are you OK to wait for the LOSAs to process them all? | 12:12 |
| zyga | maxb, if you can explain how to fix that would get me going! | 12:13 |
| zyga | (the ones that I own) | 12:13 |
| maxb | OK, so you'll need to download a little script I wrote: http://j.maxb.eu/~maxb/bzr-set-stacked-url | 12:13 |
| zyga | :D | 12:13 |
| zyga | got it | 12:13 |
| maxb | And then you can run 'bzr-set-stacked-url branch-to-fix actual-correct-stacking-location' | 12:13 |
| zyga | ok, let me try this | 12:14 |
| maxb | oh, hmm | 12:14 |
| zyga | btw, can I use lp: syntax to indicate the stacked branch location? | 12:14 |
| maxb | Yes, but I think it may be necessary to use lp:~linaro-validation/launch-control/trunk rather than lp:launch-control | 12:15 |
| Ursinha | that's cool maxb | 12:15 |
| zyga | ok | 12:15 |
| maxb | This didn't use to be the case, but there were recentish changes in launchpad | 12:15 |
| maxb | If you fix just the ones you care about in the short term, we can then pass a big list over to the losas for the rest | 12:18 |
| zyga | maxb, this worked for me | 12:23 |
| maxb | Erm, so, lp hackers.... | 12:28 |
| maxb | https://code.launchpad.net/launch-control?field.lifecycle=ALL does *not* show me all branches in the launch-control project | 12:28 |
| maxb | I know this because launchpadlib shows me more | 12:28 |
| === jtv-eat is now known as jtv | ||
| zyga | hmm | 12:58 |
| zyga | maxb, btw, what is the reason lp uses stacked branches by default? to save space? | 12:59 |
| maxb | That, and network bandwidth | 12:59 |
| zyga | maxb, does not shared repository help to fix both at the same time? | 13:00 |
| maxb | It's not so much an optimization as a necessary feature - would *you* tolerate uploading the entire history of a project again every time you wanted to branch? | 13:00 |
| maxb | zyga: shared repositories are incompatible with the ability to have different levels of read-access to different branches on a project | 13:00 |
| zyga | (it seems to me that stacked branches are fragile in this regard while a shared repo is not, perhaps I'm wrong) | 13:00 |
| zyga | oh | 13:01 |
| zyga | icky | 13:01 |
| zyga | it would need bzrlib support to change that | 13:01 |
| zyga | to check ownership inside the smart server | 13:01 |
| maxb | Stacked branches are not fragile, it's just Launchpad's implementation of branch renaming that is broken | 13:01 |
| maxb | Which is compounded by Launchpad's slightly unnatural contrivance that the name of a branch includes who can access it | 13:02 |
| zyga | maxb, perhaps you are right | 13:02 |
| maxb | s/access/write to/ | 13:02 |
| zyga | btw | 13:03 |
| zyga | could I change the stacking branch of one of my branches to a private branch to access any of that resources changests? | 13:03 |
| zyga | since you mentioned security this came to my mind | 13:03 |
| maxb | no. that would be silly | 13:04 |
| maxb | Launchpad stores commercial code, you know. They have thought about security | 13:04 |
| zyga | maxb, why silly? it depends on implementation | 13:04 |
| zyga | ;-) | 13:04 |
| zyga | maxb, if that's client access then it will not work for sure, if that's server side (smart server?) access then perhaps there might be a missing access check | 13:05 |
| james_w | hi mok0 | 13:43 |
| ams_cs | is this the right place to ask about bzr/launchpad issues? | 14:08 |
| maxb | ams_cs: Yes, unless it's purely bzr not launchpad-specific, in which case #bzr | 14:09 |
| ams_cs | ok, I think it's more lp than bzr, so here goes ..... | 14:09 |
| ams_cs | when I create a *new* LP branch using bzr push it says this: | 14:10 |
| ams_cs | bzr push lp:~ams-codesourcery/gcc-linaro/lp675347-4.6 [11-01-31 17:57] | 14:10 |
| ams_cs | Using default stacking branch /~linaro-toolchain-dev/gcc-linaro/4.5 at lp-87262288:///~ams-codesourcery/gcc-linaro | 14:10 |
| ams_cs | Created new stacked branch referring to /~linaro-toolchain-dev/gcc-linaro/4.5. | 14:10 |
| ams_cs | (ignore the random date that got in there) | 14:10 |
| ams_cs | the default stacking branch seems like the wrong choice, and the upload takes forever | 14:11 |
| ams_cs | is there any way to make it stack on lp:gcc-linaro/4.6 ? | 14:11 |
| maxb | ok. Launchpad automatically stacks on the project's development focus branch. In most cases, this is a good choice | 14:11 |
| ams_cs | and yes, I tried the obvious --stack-on= flags | 14:11 |
| maxb | In this case, you would probably want to specify --stacked-on=bzr+ssh://bazaar.launchpad.net/~linaro-toolchain-dev/gcc-linaro/4.6 | 14:13 |
| maxb | Points to beware of are that lp: aliases do not work there, and it only takes effect if the push is creating a brand new remote branch | 14:13 |
| ams_cs | maxb: ah, thanks, the extra URL parts are what I'm missing then | 14:14 |
| === pvo_away is now known as pvo | ||
| === matsubara is now known as matsubara-lunch | ||
| leonardr | barry: sorry, i dropped our conversation on the floor yesterday, are you around to pick it back up? | 14:25 |
| barry | leonardr: i am, but will be starting meetings in about 35m. i think i know what you'd like me to do though. you just need to open a bug on the packaging of lazr.restfulclient | 14:57 |
| leonardr | barry: lazr.restfulclient is already up to date | 14:57 |
| leonardr | i'd like to know whether i should try to take the keyring stuff out of launchpadlib | 14:57 |
| === pvo is now known as pvo_away | ||
| === pvo_away is now known as pvo | ||
| barry | leonardr: i think if you keep it, it has to be optional. iow, if it's there *and* the app requests it then use it. is that possible and does it make sense? | 14:59 |
| barry | it can be a recommends on the package, not a depends | 14:59 |
| leonardr | barry: it's semi-optional now, but i don't think making it a 'recommends' will address the underlying concerns about packaging *keyring* | 15:00 |
| barry | it won't. but keyring is what it is and it's already packaged albeit an earlier version. so i don't see any additional harm in packaging the latest version and giving apps the option to use it. if there are security concerns, then developers have to be allowed to choose it or not, but i don't think it should necessarily be *prohibited* | 15:02 |
| barry | i also don't think it should be the default :) | 15:02 |
| leonardr | barry: ok, i thought the keyring concerns were specific to this version | 15:03 |
| barry | let me reread the whole bug report | 15:03 |
| leonardr | barry: i'd rather remove keyring entirely than make it app-specific, because the whole point of this release is the system-wide credential | 15:04 |
| barry | hang on dude, something weird just happened outside | 15:04 |
| leonardr | ok | 15:04 |
| leonardr | if some apps are looking for the credential in the keyring and some in unencrypted files on disk, we don't have a system-wide credential | 15:05 |
| leonardr | better to keep it in one unencrypted file on disk | 15:06 |
| maxb | https://answers.launchpad.net/launchpad/+question/142589 and https://answers.launchpad.net/launchpad/+question/142142 are looking somewhat neglected. Could someone route them appropriately to someone who will investigate? | 15:20 |
| Ursinha | yes sir | 15:21 |
| === matsubara-lunch is now known as matsubara | ||
| barry | leonardr: the other option is for launchpadlib to provide an api to get the credential and a hook for apps to register where their cred should be stored, but that's probably more work than its worth | 15:28 |
| leonardr | barry: apps no longer have "their cred" | 15:29 |
| leonardr | so it's not up to the app where *the* cred should be stored | 15:29 |
| leonardr | if keyring is problematic we need to not use it, period | 15:30 |
| maxb | Speaking of launchpadlib, having been poking at bzr's use of it recently, I was thinking that an API changes document would be useful | 15:31 |
| maxb | Has anyone considered starting such a thing? If I retroactively built one, would it be accepted into trunk and kept up to date? | 15:32 |
| leonardr | maxb, can you give me a little more detail what you'd like to see in this document? | 15:34 |
| maxb | leonardr: A listing of any object, method or constant added or removed, or significant behaviour change to any method parameter, by launchpadlib version | 15:34 |
| barry | leonardr: if it's all or nothing, then i would not feel comfortable with using it unless it got a passing grade from the security team | 15:34 |
| maxb | Well, any object/method/constant not clearly intended to be private - i.e. underscore-prefixed or otherwise documented as private | 15:35 |
| leonardr | maxb: are you talking about the api of launchpadlib itself, or the api of the launchpad web service as published through launchpadlib? | 15:37 |
| maxb | Of launchpadlib itself | 15:38 |
| maxb | Having spent some time poring over the bzr history recently, I'd like to write it down to be useful to others. | 15:38 |
| leonardr | maxb: how about putting that information into the NEWS file with a special prefix on each line? | 15:39 |
| maxb | that could work | 15:39 |
| barry | leonardr: let me know what you decide about python-keyring, or if you want to talk more about it. until i hear from you i'm going to unassign myself from bug 686257. as far as bug 702375 goes, please let me know if you still want me to help upgrade launchpadlib | 15:40 |
| ubot5 | Launchpad bug 686257 in python-keyring (Ubuntu) "upgrade to python-keyring 0.5 (and MIR)" [High,Triaged] https://launchpad.net/bugs/686257 | 15:40 |
| ubot5 | Launchpad bug 702375 in python-launchpadlib (Ubuntu) "Please upgrade to 1.9.3" [Medium,Triaged] https://launchpad.net/bugs/702375 | 15:40 |
| leonardr | flacoste -^ discussion with barry | 15:40 |
| leonardr | i think we should remove keyring | 15:41 |
| leonardr | if we add it back, we can write code that looks for an unencrypted credential and stuffs it into the keyring | 15:41 |
| === oubiwann is now known as oubiwann_ | ||
| === jcsackett|afk is now known as jcsackett | ||
| === zyga is now known as zyga-food | ||
| leonardr | benji -^ too | 15:50 |
| === leonardr is now known as leonardr-afk | ||
| flacoste | leonardr-afk, barry: ffs | 16:01 |
| flacoste | U1 also does cred dance in memory without using mlock | 16:01 |
| flacoste | and nobody cares | 16:01 |
| flacoste | make python-keyring recommends | 16:02 |
| flacoste | and move on | 16:02 |
| barry | flacoste: i suggested that earlier, but my understanding is that it's not easy to do that in the code (packaging issues aside). i could of course be misunderstanding leonardr-afk | 16:03 |
| flacoste | sure python-keyring as a general password maniuplation tool isn't 'secure-grade' | 16:03 |
| flacoste | but for our use case, it's good enough | 16:03 |
| flacoste | barry: you are, leonard is basically saying if's it's not good enough generally, we shouldn't be using it | 16:04 |
| flacoste | it's optional already | 16:04 |
| flacoste | and even then | 16:04 |
| flacoste | could be a depends | 16:05 |
| flacoste | i mean u1 client does similar thing and it's in main | 16:05 |
| flacoste | what's the problem | 16:05 |
| flacoste | somebody recovering a lp credential from swap file? | 16:06 |
| barry | flacoste: i didn't know u1 did that too. has anybody asked the security team for a pronouncement either way? i'd happily support whatever they decided | 16:06 |
| flacoste | we have bigger problem than then | 16:06 |
| flacoste | that | 16:06 |
| flacoste | given that argument | 16:07 |
| flacoste | all launchpadlib program should mlock themselve | 16:07 |
| flacoste | because they are going to manipulate security sensistive token | 16:07 |
| barry | flacoste: sorry, let me ask again: has anybody asked the security team for a pronouncement? i think that's a minimum for due diligence | 16:09 |
| flacoste | barry: pronouncement about what? | 16:11 |
| === beuno is now known as beuno-lunch | ||
| barry | flacoste: specifically, whether python-keyring 0.5 is secure enough to be used in launchpad lib | 16:23 |
| flacoste | barry: right, i'm following that with pitti and kees | 16:24 |
| flacoste | barry: is that the only blocker? and what is the deadline here? | 16:25 |
| barry | flacoste: fab! please update bug 686257 when you hear from them | 16:25 |
| ubot5 | Launchpad bug 686257 in python-keyring (Ubuntu) "upgrade to python-keyring 0.5 (and MIR)" [High,Triaged] https://launchpad.net/bugs/686257 | 16:25 |
| flacoste | barry: remembering that we want also some packages using launchpadlib to have time update to use the new feature | 16:25 |
| flacoste | desktop-wide integration | 16:25 |
| flacoste | things like apport, quickly and such | 16:26 |
| === zyga-food is now known as zyga | ||
| barry | flacoste: yep. once you have the nod from pitti and kees, and you want me to upgrade python-keyring to 0.5, just update the bug and re-assign it to me. if things go smoothly, it should not be difficult to get an upgraded version in natty after alpha 2 is released on thursday. sound okay? | 16:27 |
| === leonardr-afk is now known as leonardr | ||
| flacoste | barry: ok | 16:27 |
| barry | flacoste: other than bug 686257, is there anything else you'd like me to do? | 16:28 |
| ubot5 | Launchpad bug 686257 in python-keyring (Ubuntu) "upgrade to python-keyring 0.5 (and MIR)" [High,Triaged] https://launchpad.net/bugs/686257 | 16:28 |
| barry | flacoste: specifically, do you need me to help update python-launchpadlib in natty? (bug 702375 i think) | 16:28 |
| ubot5 | Launchpad bug 702375 in python-launchpadlib (Ubuntu) "Please upgrade to 1.9.3" [Medium,Triaged] https://launchpad.net/bugs/702375 | 16:28 |
| flacoste | barry: yes, that would be helpful | 16:29 |
| flacoste | barry: but until we sort out the python-keyring problem, that's blocked i | 16:29 |
| flacoste | think | 16:29 |
| barry | flacoste: sure, no problem. i can do it when the python-keyring issue is decided. i'll leave 702375 assigned to me for now | 16:30 |
| flacoste | barry: cool. thanks | 16:33 |
| barry | flacoste: np, thanks for helping sort this out | 16:33 |
| === JanC_ is now known as JanC | ||
| leonardr | barry: i'm confused by one minor point of your conversation with francis | 17:04 |
| leonardr | to the extent that we are worried about python-keyring, are we worried about having it at all, or about using it in a high-profile library like launchpadlib? | 17:05 |
| leonardr | i ask, because i investigated this just to be on the safe side, and: it would be very easy to make the keyring code present in launchpadlib but not used by default | 17:08 |
| leonardr | this would be more so we could add it back later than because i'd want anyone to use it | 17:08 |
| leonardr | it would also be easy to tear out that code altogether, but then i'm worried about where it would live until we needed it again | 17:10 |
| leonardr | it would bit-rot | 17:10 |
| === Ursinha is now known as Ursinha-lunch | ||
| === beuno-lunch is now known as beuno | ||
| === pvo is now known as pvo_away | ||
| === pvo_away is now known as pvo | ||
| === pvo is now known as pvo_away | ||
| === deryck is now known as deryck[lunch] | ||
| barry | leonardr: i'm concerned that if it's in there at all, and then you decide to rip it out, it'll be a backward compatiility issue. plus, no sense in having code there that isn't used - it's just tech debt then | 18:01 |
| flacoste | leonardr, barry: | 18:01 |
| flacoste | [13:00] <pitti> lifeless: so, just to be clear, I definitively NACK the current version 0.2 that we have in the archive (which doesn't work with lplib anyway) | 18:02 |
| === pvo_away is now known as pvo | ||
| barry | yep, i'm watching that | 18:02 |
| maxb | Well, as far as back-compat is concerned, no ubuntu is currently at later than lplib 1.6.2. Given the reasons for natty reverting back away from 1.8.0, the case could be made that 1.8.x and 1.9.x were failed experimental series from an API PoV, so long as further lplib releases maintain compat with 1.6.x | 18:10 |
| === pvo is now known as pvo_away | ||
| === pvo_away is now known as pvo | ||
| === Ursinha-lunch is now known as Ursinha | ||
| === deryck[lunch] is now known as deryck | ||
| === pvo is now known as pvo_away | ||
| === pvo_away is now known as pvo | ||
| === matsubara is now known as matsubara-afk | ||
| === Ursinha changed the topic of #launchpad to: Launchpad: https://launchpad.net/ | Read https://help.launchpad.net/ for help | On-call help contact: - | Join https://launchpad.net/~launchpad-users | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad is open source: https://dev.launchpad.net/ | ||
| === Ursinha is now known as Ursinha-bbl | ||
| === pvo is now known as pvo_away | ||
| === pvo_away is now known as pvo | ||
| barry | leonardr, flacoste: can you please try the new versions of launchpadlib and keyring in my ppa and see if they work for you? https://launchpad.net/~barry/+archive/python/+packages | 21:11 |
| barry | leonardr, flacoste: they're for natty, but let me know if you want maverick versions | 21:11 |
| leonardr | barry: i'd like a maverick version | 21:12 |
| barry | leonardr: okay, i copied the binaries. they should be published in mav soon. if you would, please comment on the relevant bugs with status (worked for you or not) | 21:14 |
| micahg | LOSAs: bohrium seems to be stuck: https://launchpad.net/builders/bohrium | 21:16 |
| === zyga is now known as zyga-nc10 | ||
| === Lcawte is now known as Lcawte|Away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!