=== ereslibre_uni is now known as ereslibre | ||
MTecknology | Interesting error - bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~ubuntu-drupal-devs/ubuntu-drupal-locomap/6.x/.bzr/) is not compatible with CHKInventoryRepository('file:///home/michael/tmp/ubuntu-drupal-locomap/.bzr/repository/') different rich-root support | 01:33 |
---|---|---|
wgrant | Surprisingly little bzr-bashing on /. so far... | 03:50 |
gutworth | some people don't like bazaar? | 03:51 |
=== abentley1 is now known as abentley | ||
akitada | Hi, can I edit history in bzr repository? | 05:41 |
lifeless | wgrant: ? | 05:55 |
wgrant | lifeless: The Slashdot article about Emacs moving to bzr has surprisingly little bzr bashing. | 05:57 |
akitada | wgrant: that news made me feel like trying bzr for the first time | 06:12 |
akitada | I use git and hg but haven't used bzr | 06:13 |
akitada | still feeling bzr is a bit peculiar. | 06:21 |
Wellark | could someone please explain to me how revision can have multiple parent_ids? | 10:25 |
Peng | Wellark: A merge. | 10:27 |
Wellark | Peng: OK, so the end result is that revision lists parent_id:s from both trees. makes sense. thanks! :) | 10:41 |
__monty__ | Hi, I'm having some trouble getting the bzr source code, could someone offer some help? | 12:05 |
franck-bret | hello, does anyone can tell me how to have compatible repository with hardy server LTS (bzr 1.14) ? | 12:05 |
Peng | franck-bret: Ideally you would use the PPA to install the latest version of bzr on it....... | 12:06 |
Peng | franck-bret: If not, you should use the 1.14-rich-root format. | 12:06 |
franck-bret | ive put my log here http://pastebin.com/d7bb155a7 | 12:08 |
Peng | franck-bret: Oh god, 1.3.1? Upgrade, dude. | 12:09 |
franck-bret | it's a server with lastes UBUNTU LTS ... | 12:09 |
Peng | franck-bret: And? | 12:09 |
Peng | franck-bret: https://launchpad.net/~bzr/+archive/ppa | 12:10 |
franck-bret | last bzr version for LTS isn't 2.** | 12:10 |
Peng | franck-bret: So use the PPA. | 12:10 |
__monty__ | How do I get the bazaar source? | 12:10 |
franck-bret | ok thanks, i'm gonna upgrade bzr, seems to be the more simple and evolutive way, thanks Peng | 12:11 |
Peng | __monty__: "bzr branch lp:bzr" or download a tarball from the website. | 12:11 |
bialix | __monty__: bazaar.canonical.com -> Download -> Sources | 12:11 |
Peng | franck-bret: :) | 12:11 |
__monty__ | Can i use "bzr branch lp:bzr bzr.dev" to download the source to a folder named bzr.dev? | 12:12 |
Peng | __monty__: Yes. | 12:12 |
__monty__ | I get this error when I try: | 12:13 |
__monty__ | Permission denied (publickey). | 12:13 |
__monty__ | bzr: ERROR: Connection closed: Unexpected end of message. Please check connectivity and permissions, and report a bug if problems persist. | 12:13 |
Peng | Uh. | 12:13 |
Peng | __monty__: You've run "bzr launchpad-login" but your local SSH key doesn't match any of the ones you have on Launchpad. | 12:14 |
__monty__ | I registered on launchpad and then I ran "bzr launchpad-login __monty__" , but this gave me | 12:15 |
__monty__ | (erroneous enter) | 12:15 |
__monty__ | I registered on launchpad and then I ran "bzr launchpad-login __monty__" , but this gave me | 12:15 |
Peng | __monty__: The username "__monty__" does not seem to exist. | 12:15 |
__monty__ | But I can login on launchpad.net | 12:16 |
Peng | __monty__: Really? And that's your username? | 12:16 |
__monty__ | Yes. | 12:17 |
Peng | __monty__: The 404 error at https://edge.launchpad.net/~__monty__ says otherwise. | 12:17 |
Peng | I'd be surprised if Launchpad allowed leading underscores in usernames. | 12:17 |
__monty__ | Ok, DisplayName probably isn't the same as Name then. | 12:19 |
__monty__ | How do I register an SSH key? | 12:20 |
Peng | __monty__: https://launchpad.net/~$name/+editsshkeys | 12:21 |
Peng | __monty__: Or, click this: https://launchpad.net/people/+me/+editsshkeys | 12:22 |
__monty__ | How do I create such a key, I'm on mac os X. | 12:24 |
Peng | __monty__: I dunno. Do you normally just use OpenSSH? ls ~/.ssh/*.pub, or the OS X equivalent. | 12:26 |
Peng | __monty__: I'm not an OS X person; you should Google it. | 12:28 |
Peng | (OTOH, there are a lot of terrible tutorials on Google, but...) | 12:29 |
* __monty__ is googling | 12:29 | |
Pilky | __monty__: follow these instructions: https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair | 12:29 |
Pilky | follow the Linux instructions | 12:29 |
Pilky | but skip 1 | 12:29 |
Pilky | OpenSSH is already installed | 12:30 |
__monty__ | Should I create an rsa or a dsa key? | 12:31 |
Pilky | rsa | 12:31 |
Pilky | OS X is just unix so whenever there are no specific OS X instructions for something relating to the command line, try using the linux instructions | 12:31 |
__monty__ | I didn't yet know os X has ~openssh builtin so I thought I couldn't follow those steps without apt-get. | 12:32 |
__monty__ | Thanks for the help. :-) | 12:36 |
__monty__ | If I were to try some debugging where would I start looking in the source? | 12:39 |
maxb | debugging what? | 12:44 |
__monty__ | Well, nothing specific, some trivial bugs, but if you need a specific example: https://bugs.launchpad.net/bzr/+bug/257170 | 12:48 |
ubottu | Ubuntu bug 257170 in bzr "log does not record bzr version" [Low,Confirmed] | 12:48 |
Peng | __monty__: I'd grep the codebase for some of the stuff that is logged to find it. | 12:53 |
__monty__ | Peng: How would you go about that with this specific bug? | 12:54 |
Peng | __monty__: I'd check ~/.bzr.log, find something juicy, and grep for it . . | 12:57 |
__monty__ | Sorry for my ignorance, but what would you call juicy? | 13:00 |
Peng | __monty__: Something that probably wouldn't have a lot of false positives. Actually, there aren't many choices, so I guess it would be "bzr arguments". | 13:02 |
__monty__ | So I just look for a line kind of like: "print "bzr arguments: %s" %(...) | 13:04 |
Peng | __monty__: That's what I'd do. | 13:05 |
__monty__ | Peng: And how would you look for this: https://bugs.launchpad.net/bzr/+bug/239523 | 13:05 |
ubottu | Ubuntu bug 239523 in bzr "bzr tag --quiet not obeyed" [Low,Confirmed] | 13:05 |
Peng | __monty__: Start in cmd_tag in bzrlib/builtins.py and/or grep for "Created tag". | 13:06 |
__monty__ | Ok, thanks for the help Peng. | 13:07 |
ronny | hi | 14:08 |
zekopeko_ | hi | 14:08 |
ronny | does bzr has some kind of concept for per-file metadata | 14:08 |
zekopeko_ | is there a simple way to check the revision of a branch? | 14:09 |
Peng | zekopeko_: bzr revno | 14:09 |
Peng | zekopeko_: bzr revision-info too | 14:09 |
zekopeko_ | cool. thanks | 14:09 |
rubbs | ronny: can you clarify your question? I'm not sure what you mean. Do you mean does bzr keep metadata on each file? | 14:10 |
ronny | rubbs: i mean if there is a way to have custom per-file metadata | 14:11 |
rubbs | mmm... not that I know of, but I'm not a dev. | 14:11 |
ronny | sup jelmer | 14:11 |
Peng | ronny: Like svn? Um, I imagine that's how the exec bit is stored, so probably. But you definitely can't add arbitrary properties without writing some Python. | 14:11 |
jelmer | hey ronny | 14:12 |
ronny | jelmer: does bzr have a way to have own per-file metadata entries, preferably versioned, too | 14:12 |
jelmer | ronny: nope, we don't have anything like that yet. | 14:12 |
jelmer | ronny: you can of course store a dictionary with files as keys in the revision properties | 14:13 |
ronny | meh, ok | 14:13 |
Peng | Oh. | 14:13 |
ronny | jelmer: any idea if the new repo format is able to actually store those? | 14:16 |
Wellark[] | ugghh.. this is depressing.. I'm trying to verify revision signatures on server side on push in pre_change_branch_tip_hook so that I can reject the push if the verification of the signatures fail or they are missing. repository.has_revision() returns True for the new revisions, but repository.has_signature_for_revision_id() returns False, even though the revision are signed before the push :/ | 14:17 |
jelmer | ronny: revision properties are supported for all formats in use today | 14:17 |
ronny | jelmer: i mean per-file properties | 14:17 |
jelmer | ronny: There is no new file format in development at the moment as far as I know. | 14:18 |
jelmer | ronny: There won't be a new default file format before 3.0 | 14:18 |
ronny | ok | 14:19 |
Wellark[] | I'm a bit lost right now.. I'm not sure if there's any way to access the signatures before the push is completed | 14:19 |
ronny | so i can just ignore that after all | 14:19 |
jelmer | wellark[]: Hmm | 14:20 |
jelmer | Wellark[]: Does repository.has_signature_for_revision_id() return True for those revisions after that push, from a new bzr instance? | 14:21 |
jelmer | (are the signatures actually pushed correctly/) | 14:21 |
Wellark[] | jelmer: I'll check | 14:22 |
za | i did this: bzr init bzr: ERROR: Already a branch: "." | 14:35 |
za | how can i change my branch? | 14:35 |
Wellark[] | jelmer: you got it right.. the signatures are not transfered.. | 14:35 |
Wellark[] | interesting.. | 14:35 |
Wellark[] | I'll investigate | 14:35 |
jelmer | wellark[]: Thanks | 14:36 |
jelmer | wellark[]: I wouldn't be surprised if there was a bug there, since the signature code isn't used very heavily at the moment | 14:36 |
Wellark[] | jelmer: I'll do my best | 14:39 |
za | i am current ly using /project for my branch. but now i want to change it to /web/project . how can make these changes? | 14:39 |
Wellark[] | last night was the first time I looked at bzr source code :) | 14:39 |
rubbs | za: just say "bzr branch /project /web/project" and that will create a mirror to the new location. After that you can delete the old branch. | 14:40 |
za | rubbs: i am getting error : "target directory already exists" | 14:45 |
rubbs | za: try using the --use-existing-dir flag | 14:46 |
rubbs | so it should read "bzr branch --use-existing-dir /project /web/project" | 14:46 |
za | rubbs: error: already a branch | 14:47 |
za | ohh sorry | 14:47 |
za | wait | 14:47 |
Wellark[] | jelmer: this was probably an "user error".. I signed some already pushed revisions with sign-my-commits and assumed that the signatures are pushed when I make a new push | 14:53 |
Wellark[] | that's not the case if there's no other changes | 14:53 |
jelmer | Wellark[]: Well, ideally we should also be fetching missing signatures for existing revisions | 14:53 |
Wellark[] | jelmer: yeah, but that's now only a minor inconvenience if I can get the hook working for new revisions. | 14:55 |
Wellark[] | jelmer: thanks for asking the right question ;) | 14:58 |
jelmer | wellark[]: np - it's working now? | 14:59 |
Wellark[] | jelmer: yes, infact it is. just tested :) | 15:02 |
Wellark[] | sweet! | 15:03 |
zombor | hello, im wondering if anyone can help me out, my auto complete doesn't appear to be working when i press tab to complete a directory for instance, anyone know why this might be? | 15:04 |
maxb | jelmer: Hi, if you're around, how should I submit a bzr-rewrite branch? The branch description on Launchpad says MPs there will be ignored. | 16:37 |
maxb | bah | 16:37 |
__monty__ | Can anyone tell me where can find documentation of "trace.mutter"? | 16:58 |
maxb | bzrlib/trace.py ? :-) | 16:59 |
__monty__ | Thank you, I thought trace.mutter referred to the builtin trace module. | 17:01 |
Wellark | gah.. the signature handling is not satisfactory.. | 17:32 |
Wellark | if I try to push revisions which do not have signatures and the push fails and I sign the revisions and push again the signatures are not sent | 17:33 |
Wellark | I haven't yet figured out what actually happens on a push | 17:55 |
Wellark | repository.py is also quite massive :) | 17:55 |
gutworth_ | welcome to version control :) | 17:56 |
=== gutworth_ is now known as gutworth | ||
Wellark | :) | 17:57 |
Wellark | at least it's nice that revision signatures are separated from actual revisions inside Repository | 18:02 |
Wellark | probably allows all sort of neat stuff to be implemented without a fear of breaking revision logic | 18:03 |
Wellark | I'm already thinking about resigning revisions etc :P | 18:04 |
maxb | On a related note it also sucks that tags aren't push/pulled unless revisions are being transferred too | 18:09 |
Wellark | maxb: really? | 18:16 |
Wellark | that's truly sucks | 18:16 |
Wellark | I'll keep an eye on that too when I _try_ to fix the signature problem | 18:17 |
Peng | maxb: That's not the case, or didn't use to be. | 18:17 |
tbnorth | hi all - the Inkscape project recently moved to bzr for VCS and someone's workflow resulted in a months worth of different people's revisions becoming sub-revisions of one person's commit. | 18:17 |
Peng | Or maybe it only applied when the destination's .bzr/branch/tags was missing. | 18:18 |
tbnorth | apart from educating people about correct workflow, is there any way to prevent this from happening? | 18:18 |
tbnorth | it upsets people ;-} | 18:18 |
Peng | tbnorth: Not really. It's a standard workflow for people to merge lots of others' revisions. | 18:18 |
tbnorth | Peng: so people should just get used to it? Part of the problem is that launchpad doesn't show the subrevisions, so people think they're lost | 18:19 |
Peng | tbnorth: Well it's not like the revisions are actually any less important or anything. | 18:20 |
tbnorth | ok, just wondered if there was any setup which made it harder for people to do this accidentally | 18:21 |
tbnorth | the preferred workflow would be to merge your local changes into a current copy of the trunk and push that, so your local commits become subrevisions, and not all the commits which occurred since you branched | 18:22 |
maxb | Peng/tbnorth: maybe append_revisions_only? | 18:32 |
maxb | Peng: (re tags) Hmm.... I guess I shall have to re-test | 18:32 |
tbnorth | maxb: thanks, sounds interesting, will investigate | 18:33 |
maxb | tbnorth: I'm guessing that the problem workflow is that of merging trunk into your feature branch, and then pushing to trunk? | 18:34 |
tbnorth | maxb: exactly | 18:34 |
tbnorth | I understand no real damage is done, but others coming from SVN are all disconcerted, thinking things are lost | 18:35 |
tbnorth | and people prefer a linear change log | 18:35 |
maxb | Well, the 'damage' is that the revision history becomes less comprehensible | 18:36 |
tbnorth | right, so append_revisions_only would help? I'm still looking for docs for it | 18:36 |
Peng | It might help, but I wouldn't be completely sure. | 18:37 |
Peng | No revisions are being *removed*, some of them just aren't mainline anymore. | 18:37 |
tbnorth | I've set up a little test script, I'll try it with that enabled | 18:37 |
maxb | Assuming I've undersstood it correctly (which I don't guarantee), it should cause bzr to deny pushes which would move revisions off the mainline | 18:37 |
Peng | tbnorth: Anyway, this is mostly a user education thing... | 18:38 |
Peng | tbnorth: BTW, I bet you can do a clever merge or two to flip the mainline over again. | 18:39 |
tbnorth | Peng: sure, I've been through the loop once on another project which is now quite happy with bzr, but on this project core developers are not happy at the moment | 18:39 |
tbnorth | Peng: I'm not going to try and undo anything, nothing's lost at the moment, I don't want to try and be clever and break something for real | 18:40 |
Peng | tbnorth: Meh, it would be hard to actually break things. | 18:40 |
tbnorth | ok, in my test code append_revisions_only blocks the push that would change the log, great, now the question is can that be set on a launchpad hosted branch? | 18:42 |
maxb | Sure, it's just a config file option | 18:45 |
maxb | You may need to get a little sneaky to change the config file though | 18:45 |
tbnorth | how so? | 18:45 |
maxb | Either doing it via the bzr API, or going in via sftp | 18:45 |
maxb | tbnorth: btw, has further development happened on trunk since this flip? | 18:46 |
tbnorth | yes, a couple of commits I think | 18:46 |
Peng | Should be really easy with the API. | 18:46 |
Peng | Hold on. | 18:47 |
maxb | python -c 'import bzrlib.branch as b; b.Branch.open("bzr+ssh://bazaar.launchpad.net/~maxb/tortoisehg/ppa").set_append_revisions_only(True)' | 18:49 |
Peng | Damn, you beat me. | 18:49 |
tbnorth | hehe, lol :-) | 18:49 |
maxb | If it's only been a few commits, it still might be worth straighening out | 18:50 |
tbnorth | what would the procedure be? | 18:50 |
maxb | branch the former mainline; merge the commit which broke things; commit; for each subsequent revision: merge; commit | 18:51 |
maxb | push the result | 18:51 |
Peng | Of course, turn off append_revisions_only first. ;-D | 18:52 |
Peng | (what maxb posted earlier, only replace True with False) | 18:52 |
tbnorth | ok, I could try that locally I guess, actually I don't have any commit permissions on this project, but those that do might want to do that | 18:52 |
tbnorth | and I'll do the set_append_revisions_only thing on the other lp project I work on. | 18:53 |
maxb | Is lp:inkscape the problem branch? | 18:53 |
tbnorth | yes | 18:53 |
tbnorth | thanks for this help, people were panicking about bzr being usable, which I knew was over reacting | 18:54 |
maxb | Right, so you'd have the problem and 4 subsequent commits which would require individually merging onto the former tip | 18:56 |
maxb | Doable | 18:56 |
maxb | Whilst you're at it, you might point out that their repository format is rather ancient | 18:57 |
tbnorth | maxb: that's an issue I've seen on a couple of projects, what's the easiest way to fix it? | 18:58 |
Peng | To fix what, ancient-formatitis? "bzr upgrade". | 18:58 |
tbnorth | followed by a push? I'm not familiar with adminning lp branches | 18:59 |
maxb | This is the first time I've seen an active branch using something that's pre-knitpack :-) | 18:59 |
tbnorth | probably the person who set it up didn't know better | 19:00 |
maxb | upgrade is an in-place operation, but can be run on a remote URL | 19:00 |
tbnorth | so if someone with the proper rights does `bzr upgrade lp:inkscape` that would do it? | 19:00 |
Peng | Yeah. | 19:01 |
tbnorth | thanks | 19:01 |
Peng | tbnorth: Tell them to be careful what they upgrade *to*. Upgrading to 2a gets a bit complicated because it has rich roots, though even an older format like 1.9 would be an improvement and put them in this century. :P | 19:02 |
tbnorth | Peng: `bzr upgrade --format=1.9 lp:inkscape` would be the safest improvement, that's what you're saying? | 19:06 |
maxb | However, given the format is already rich-root, that's not an issue | 19:07 |
maxb | Really it depends how much they care about users of old versions of bzr | 19:07 |
Peng | It is? Um. Who the heck uses an ancient rich-root format? | 19:08 |
maxb | Personally I'd hope no one would be labouring on with bzr 1.x now bzr 2.x is here, but I guess that's not a realistic expectation | 19:08 |
Peng | They're very lucky, but still. | 19:08 |
maxb | It's Knit4 | 19:08 |
maxb | (aka 'rich-root') | 19:08 |
Peng | Ah. | 19:08 |
Peng | Seriously, it was a good decision, but I'm surprised someone chose it... | 19:08 |
maxb | Of course, there's still the 'different serializers' incompatibility when switching to 2a | 19:09 |
Peng | maxb: Only a problem with stacking. | 19:09 |
maxb | An in-place upgrade to 2a would break branches stacked on the trunk... | 19:09 |
maxb | indeed | 19:09 |
maxb | So, yeah, personally I'd probably take it up to 1.9-rich-root | 19:10 |
Peng | Hold on a sec. Given how old the format is, it's unlikely anyone's using stacking. | 19:10 |
maxb | Can't you stack *on* hideously ancient formats? | 19:10 |
maxb | It's a shame there's no way to ask Launchpad "Who's stacked on me?" | 19:11 |
Peng | Does stacking depend on the repo format or just the branch format? | 19:11 |
maxb | I think it depends on the stacker's format but not the stackee's? | 19:14 |
maxb | (Other that the 2.x serializer change) | 19:14 |
maxb | jelmer: Hi, if you're around, how should I submit a bzr-rewrite branch? The branch description on Launchpad says MPs there will be ignored. | 19:20 |
jelmer | maxb: please send merge requests to me personally (jelmer@samba.org) | 19:24 |
=== tbnorth is now known as tbrown_afk | ||
maxb | ok, will do | 19:27 |
Peng | jelmer: Just curious, why? | 19:34 |
Peng | (Why not use the LP merge proposal system, I mean?) | 19:34 |
maxb | Is the reason for the word 'with' in the bzr reconfigure --with-(no-)trees options because --trees and --no-trees would be interpreted as a single boolean option with a negated form? | 19:50 |
* maxb is contemplating how to add reconfiguration of the append-revisions-only option | 19:50 | |
NfNitLoop | bleh. I'm using git-svn to work with this svn repo that bzr-svn can't deal with. It's making me miss bzr. :p | 19:52 |
NfNitLoop | had to go ask in #git how the heck to push my locally changed branch back up to svn. It was a bit convoluted. | 19:52 |
jelmer | NfNitLoop, why is bzr-svn not working? | 19:52 |
NfNitLoop | jelmer: In the history, someone checked in (then removed) a file with a \ in its name. | 19:52 |
jelmer | peng: Launchpad does not attach merge directives, only plain diffs | 19:53 |
jelmer | peng: making it impossible to deal with merge requests while offline | 19:53 |
jelmer | NfNitLoop: Ah, ok | 19:54 |
jelmer | NfNitLoop: to be pedantic, bzr doesn't allow \, bzr-svn should be fine with backslashes | 19:54 |
NfNitLoop | I actually started my own bzr branch to try removing the restriction re: '\' in file names but didn't get it to a working state. | 19:54 |
NfNitLoop | yep. I've talked about it before in here. :) | 19:54 |
jelmer | ah, sorry :-) | 19:54 |
NfNitLoop | I was mostly just complimenting you on how nice bzr-svn integration is compared to git-svn. | 19:55 |
NfNitLoop | 'bzr svn-push <my-branch-location>' is 3-4 steps in git-svn. | 19:55 |
jelmer | thanks, glad to hear :-) | 19:56 |
jelmer | the \ restriction is really silly, it should be trivial to remove | 19:56 |
jelmer | it just hasn't been done yet because we need to warn users that a created branch won't be usable on windows | 19:57 |
maxb | Is there any way to get 'bzr send' to send GPG signed merge directives, short of doing it via a GUI MUA? | 20:00 |
maxb | Ideally I'd like 'editor'-type composition, but with GPG signing | 20:01 |
zombor | hello, im wondering if anyone can help me out, my auto complete doesn't appear to be working when i press tab to complete a directory for instance, anyone know why this might be? | 20:07 |
NfNitLoop | zombor: auto-complete for directories? Might that be a better question for #bash? | 20:21 |
zombor | NfNitLoop: but it works for all other commands, and it used to work in bzr | 20:21 |
zombor | i thought maybe it was a plugin that got messed up or something | 20:22 |
=== tbrown_afk is now known as tbrown | ||
tbrown | zombor: in bash the `complete` command can impact completion for specific command lines, e.g. `complete -C ~/bin/bzropts bzr` would cause the program ~/bin/bzropts to be used to handle completion for command lines starting with bzr. | 20:26 |
zombor | `which bzropts` bzropts not found | 20:28 |
zombor | =/ | 20:28 |
zombor | im using zsh also | 20:28 |
tbrown | I made that up, there's no such program, I was just pointing out that complete, in bash, can cause inconsistent autocomplete activity | 20:29 |
tbrown | perhaps it's a question for #zsh | 20:29 |
zombor | hrm, i wonder what i did to cause it to not work... | 20:30 |
zombor | im pretty sure it stopped working after i installed bzr into my home directory | 20:30 |
NfNitLoop | zombor: if you had previously installed bzr via your package manager, it may have configured bzr autocomplete for you. | 20:46 |
zombor | probably... | 20:46 |
NfNitLoop | so if you uninstalled it to install a different version in your home directory, that would explain it. | 20:46 |
zombor | well, i didn't uninstall the system version | 20:46 |
zombor | i just added my $HOME bin dir to my $PATH | 20:47 |
zombor | im going to install the stable version from launchpad via my package manager, so maybe that will fix it | 20:48 |
=== khmarbaise_ is now known as khmarbaise |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!