[00:16] <lifeless> fuding
[00:19] <Pieter> *funding
[00:35] <lifeless> abentley: ping
[00:36] <lifeless> Pieter: it was a reference to a cartoon, wherein a dog has written 'Cat fud' on the door of a tumble dryer
[00:49] <jonoxer> Another noob question: how do I get a list of files changed in a commit? With svn it's something like "svnlook changed MyRepo -r 123"
[00:50] <lifeless> bzr st -c revno
[00:50] <lifeless> or bzr st -r x..y for arbitrary ranges
[00:50] <jonoxer> lifeless: perfect, thanks!
[00:53] <Pieter> how does bazaar show a diff with conflicts?
[00:53] <lifeless> Pieter: I don't know what you mean by that
[00:53] <Pieter> well, what does it look like?
[00:53] <Pieter> (can I get an example somewhere)
[00:54] <lifeless> do you mean 'if I run "bzr diff" when I have conflicts, what do I see?' ?
[00:54] <james_w> Pieter: you can only get them in your working tree, but it will just show the addition of the conflict markers and the "OTHER" block
[00:54] <Pieter> lifeless: yes
[00:54] <Pieter> james_w: ok, so no double +'s like git does?
[00:54] <lifeless> Pieter: bzr diff doesn't report on conflicts at all, so as james_w says you just see the herringbone markers
[00:55] <james_w> Pieter: you mean with diff --c etc?
[00:56] <Pieter> james_w: I guess.. git does it with --cc, which is a compacted version
[00:56] <Pieter> james_w: like in http://pastie.org/291669
[00:57] <Pieter> I was wondering if bazaar did the same thing with triple @'s
[00:57] <james_w> there's --c and --cc I think
[00:57] <james_w> it doesn't currently
[00:57] <james_w> I played with adding it once
[00:57] <Pieter> ok.. I want to use that to detect conflicting diffs in my app
[00:57] <lifeless> so, it marks the whole region, not just one side?
[00:58] <Pieter> So I thought I'd check other VCS's do that too
[00:58] <lifeless> james_w: file a bug please :P
[01:00] <james_w> Pieter already did: bug 250783
[01:01] <Pieter> Ah right, I thought bzr did the --c, but not the --cc
[01:02] <lifeless> we have the code internally to do it
[01:02] <lifeless> multiparent diffs
[01:02] <lifeless> but we don't have a UI
[01:03] <james_w> ah, didn't think of that, I was trying to do it around SequenceMatcher
[02:28] <akahn_> Does bazaar make it easy to collaborate with a co-worker on a lan the way git does?
[02:29] <arjenAU> akahn_: evenif they're 10k high and offline, yes
[02:30] <akahn_> i'm thinking bazaar might be easier for the two of us to manage our work (web development) and put it online
[02:30] <arjenAU> bzr rocks. and i'm not just saying that because it's the #bzr chan
[02:34] <lifeless> akahn_: yes; we have avahi integration, a built in server and other such things
[02:35] <akahn_> avahi?
[02:35] <lifeless> zeroconf
[02:35] <akahn_> not familiar with that
[02:35] <lifeless> its for completely adhoc networking
[02:35] <lifeless> no servers at all sort of thing
[02:36] <akahn_> i see
[02:36] <akahn_> ah, what apple calls bonjour
[02:40] <akahn_> thanks people
[03:07] <abentley> lifeless: pong
[03:07] <lifeless> abentley: I had a weird revert failure
[03:07] <lifeless> abentley: I suspect I did something to find a new corner case; so I filed a bug with the dirstate that caused it
[03:07] <abentley> lifeless: Okay.
[03:10] <abentley> lifeless: Is it possible reverting would have changed the root-id?
[03:10] <lifeless> abentley: non-rich-root trees *as far as I know*
[03:10] <lifeless> abentley: what I did was a parallel import of mysql, the pulled rev 1 of the import john did over that
[03:11] <lifeless> abentley: (which conflicted on everything, moving them 'to the root'). Then a 'bzr revert' and boom.
[03:12] <abentley> lifeless: I don't know whether that importer would create unique root-ids.  Can't say it wouldn't.
[03:12] <lifeless> abentley: indeed. I know the parallel import didn't.
[03:12] <lifeless> abentley: I can check one sec
[03:13] <poolie> lifeless: re your earlier question, if the previous job is still running the new one will just exit
[03:13] <lifeless> abentley: the mysql import has a unique root id, even though its not a rich roots repo:
[03:13] <lifeless> >>> r = b.last_revision()
[03:13] <lifeless> >>> t = b.repository.revision_tree(r)
[03:13] <lifeless> >>> t.path2id('')
[03:13] <lifeless> 'sp1f-changeset-20000731191004-fzqw7vgyzfnpbmw6f5gziiclvgyq4nc4'
[03:14] <abentley> lifeless: Sounds like we have a corner case with root ids changing.  I thought I had a test for that, but..
[03:15] <lifeless> abentley: yah
[03:16] <abentley> vila: ping
[03:18] <abentley> lifeless: Could you review http://bundlebuggy.aaronbentley.com/project/bzr/request/<48EFE285.7090402%40aaronbentley.com> please?
[03:21] <lifeless> abentley: I think it needs a default on the if
[03:21] <lifeless> in create_from_tree
[03:21] <lifeless> else:
[03:21] <lifeless>     raise AssertionError("unknown kind %r" % kind)
[03:22] <lifeless> all the rest has been reviewed by folk already
[03:22] <lifeless> so I don't think you need a review of the other parts of the patch
[03:24] <abentley> lifeless: I'm not sure the rest has been reviewed by others.
[03:25] <lifeless> abentley: poolie did the initial review saying that the iter_entries_by_dir hack was funky
[03:25] <abentley> lifeless: That was on another patch.
[03:25] <lifeless> abentley: which lead through the iterations to where we are today; I'm happy with the rest of the branch anyhow
[03:25] <poolie> (well, i was just noticing that fairly long repeated expression)
[03:26] <abentley> lifeless: Thanks.  I'll fix and submit.
[05:51] <lifeless> poolie: ping
[07:25] <vila> hi all
[07:30] <vila> abentley: pong
[08:06] <nubbun> Can one use the Intrepid APT repository for Debian Lenny systems?  or is there a more suitable repository?
[08:09] <jml> bazaar really can chew up memory when it wants too.
[08:09] <jml> s/too/to/
[08:11] <jml> oh wow, it's greying out my terminal :)
[08:17] <lifeless> poolie: ping
[08:42] <haoyu> is TortoiseBZR  included in bzr installer?
[08:48] <lifeless> for windows, yes I believe so
[08:48] <lifeless> poolie: on the off chance that you look at this tonight; usertest's in progress log has stopped at the set stage, the actual test run is progressing but not visible anywhere
[08:50] <haoyu> I have download bzr-setup-1.8rc1.exe
[08:50] <haoyu> but seems tortoisebzr not included..
[08:51] <haoyu> should I restart after install?
[08:56] <speakman> yo folks :)
[08:58] <speakman> (I was thinking of asking about PQM, but now I found the linuxfoundation.org article)
[09:09] <Odd_Bloke> poolie: What's "Kerguelen"?
[09:56] <poolie> kerguelen is (a) an island in the southern ocean, and (b) a windows virtual server for testing and building packages
[09:57] <speakman> how is bzrbashprompt.sh supposed to work?
[09:57] <Odd_Bloke> poolie: Ah, right.
[09:57] <poolie> speakman: do you mean what's it meant to do or how does it do it?
[09:57] <Odd_Bloke> Google told me the former, but not the latter. :D
[09:58] <speakman> oh, I loaded it wrong, now it works :)
[09:58] <speakman> (god it makes bash slow though...)
[09:59] <speakman> are there any generic ways to speed up bzr?
[10:00] <poolie> first you should make sure you're using the compiled extensions
[10:00] <poolie> (ie are running from a package or have run make)
[10:00] <poolie> then there is 'bzr shell' (in bzrtools) and bzr-client (a plugin)
[10:01] <lifeless> poolie: any thoughts on usertest ?
[10:01] <speakman> I'm running from ppa apt repo
[10:03] <speakman> bzr shell doesn't load my .bashrc or .bash_profile, and seems to lack tab completion :/
[10:04] <lifeless> speakman: in the last round of discussions folk were saying bzr is plenty fast for them; modulo really-big-trees
[10:04] <lifeless> speakman: are you talking basic response time
[10:04] <lifeless> speakman: or time to clone/do network stuff/etc ?
[10:07] <speakman> basic response time mostly, but the thought was more to make the bzrbashprompt.sh works a bit faster (it's a cool thing though!)
[10:09] <speakman> I do not have a problem with bzr in general (doing bzr commit and stuff), else I wouldn't promote it the way I do ;)
[12:03] <lifeless> l
[12:37] <guilhembi> abentley: hello! I am reading
[12:37] <guilhembi> http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07
[12:37] <guilhembi> and wondering: does 1.8rc1 include all of 1.7.1?
[12:38] <guilhembi> and is there a way to tell (for next time I wonder :) ?
[12:38] <guilhembi> To rephrase: 1.7.1 contained fixes to --weave, are they in 1.8rc1 too?
[12:39] <abentley> guilhembi: Yes, 1.8rc1 includes everything in 1.7.1.  They always do.
[12:39] <guilhembi> abentley: thanks!
[12:40] <abentley> guilhembi: Anything in the NEWS file for a given release will pertain to that release.  If 1.7.1 wasn't listed in the NEWS, you might wonder.
[12:41] <guilhembi> abentley: the NEWS file, you mean I should download the tar.gz of the release and read NEWS?
[12:43] <abentley> guilhembi: No, you can look at http://doc.bazaar-vcs.org/bzr.1.8/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07
[12:47] <guilhembi> abentley: how did you arrive to the link above? I was able to find http://doc.bazaar-vcs.org/bzr.dev/en/release-notes/NEWS.html#bzr-1-8rc1-2008-10-07 .
[12:48] <abentley> guilhembi: I went to http://doc.bazaar-vcs.org/
[12:49] <guilhembi> abentley: thanks!
[14:50] <ngnp> can I push/pull between server/debian bzr (0.11.0) together with laptop/ubuntu bzr (1.3.1) ... I guess not but how to solve this?
[14:51] <pysquared> Help please: I emailed someone a bzr branch.  They made changes and emailed me a merge-directive (MD). I merged the MD, made more changes, and I want to send back to them another MD.
[14:52] <beuno> oleavr, what's the problem?
[14:52] <pysquared> If I create a copy of the branch I originally emailed them and "bzr pull" their MD, I can then do "bzr send ../original_plus_pulled_md"
[14:52] <pysquared> But can I do this without creating a copy of what their branch looks like?
[14:53] <oleavr> beuno: ?
[14:53] <pysquared> e.g. something like "bzr send -r-2.. ." (which does not work by the way)
[14:53] <beuno> oleavr, misstyped, meant pysquared   :)
[14:54] <oleavr> beuno: ah :)
[14:54] <beuno> pysquared, so, you want to create a merge directive, without creating a branch?
[14:55] <beuno> I don't think you can do that, because you need to have his revisions in the ancestry
[14:55] <beuno> so you do actually have to create the branch
[14:55] <beuno> but abentley is the expert on the subject
[14:57] <abentley> pysquared: The only way to calculate which revisions need to be sent is using a branch that lacks the revisions they lack.
[14:57] <pysquared> Or specifying which is the last revision of the current branch they have??
[14:57] <pysquared> (Or am I being dumb?)
[14:57] <abentley> pysquared: No, that's a way of specifying what merge you want them to perform, not which revisions need to be sent.
[14:58] <pysquared> Sorry, please could you elaborate on "what merge" means.
[15:00] <abentley> Merge is a bzr command.  It combines two lines of development.  It can merge either from a branch or from a merge directive.  When it uses a merge directive, it performs the merge that was specified in the merge directive.
[15:01] <abentley> So when you specify bzr send -r 53..54, you're saying "merge just the changes from 53..54, even if you haven't merged 52"
[15:03] <pysquared> I have used merge before (just a beginner though).  I'm just testing some merges now...
[15:04] <pysquared> Is this correct: If I specify bzr send -r 10-30, and they are already at revision 20, then part of the merge directive is ignored, and they get the latest 10 revs?
[15:05] <abentley> That is true.
[15:06] <pysquared> Good, so it seems like I can do what I want: generate a merge-directive without having access to their branch, as long as I know what is a common ancestor revid?
[15:07] <abentley> pysquared: Do they already have copies of your revisions?
[15:08] <pysquared> Hmmm?  I think that is what I am trying to send them in the merge directive no?
[15:10] <abentley> pysquared: No, you're telling them *what* to merge.
[15:10] <pysquared> I basically want to find the most efficient way to generate the smallest merge directive which contains the work I have done since merging the work they did.
[15:11] <abentley> pysquared: In your example, if they already have revision 20, bzr only needs to send revisions 21..30.
[15:11] <pysquared> Cool.  What is the incantation?
[15:11] <abentley> pysquared: In my example, if they don't have 52, it needs to be sent, because it will be used indirectly.
[15:12] <abentley> pysquared: bzr send path/to/mirror/of/their/branch
[15:12] <pysquared> I cannot find a way to produce a merge directive using a standalone branch which matches the one generated using a copy of their branch.
[15:13] <pysquared> I think using path/to/mirror/of/their/branch should be unnecessary, but perhaps I am missing something important.
[15:13] <abentley> pysquared: If you use your own branch as the submit location, you will always get an empty bundle, and that will never be what you want.
[15:13] <abentley> pysquared: It is used to calculate which revisions need to be sent.
[15:13] <pysquared> *Yes* that was what I was getting - empty bundles
[15:14] <abentley> pysquared: By default, it is also used to calculate the merge to be performed, though you can override this with -r.
[15:15] <pysquared> Can I tell "bzr send" which revisions need to be sent and the merge to be performed, and therefore lose the dependency on path/to/mirror/of/their/branch?
[15:15] <abentley> pysquared: No.
[15:16] <pysquared> Oh :-(
[15:16] <pysquared> That felt strangely like chasing my own tail :-)
[15:16] <abentley> pysquared: I said that at the start.  You need to use a branch that lacks the revisions they lack.
[15:17] <ahasenack> bzr is giving me a weird url to break a lock, does this look right?
[15:17] <ahasenack> bzr break-lock chroot--1217453396:///some/path/trunk/.bzr/branch/lock
[15:17] <abentley> ahasenack: No.  Just use the normal URL for that branch.
[15:18] <pysquared> abentley: Is it possible do you think to add this feature?
[15:18] <ahasenack> abadger1999: thanks
[15:18] <ahasenack> er
[15:19] <ahasenack> abentley: thanks. Known bug? Should I open one?
[15:19] <abadger1999> heh.  I need to change the first two letters of my nick.
[15:19] <abentley> pysquared: It is possible, but pretty pointless.  Branches are ~44k
[15:20] <abentley> pysquared: And the overhead of keeping track of their branch manually instead of letting bzr do it seems not worth it.
[15:26] <pysquared> abentley: thanks for your patience and help.
[15:40] <abentley> vila: I'd like lp-login to set the username that is used whenever bzr+ssh://bazaar.launchpad.net is specified.  It seems like the best way to achieve this is to use AuthenticationConfig.  Does that make sense to you?
[15:41] <vila> abentley: yes
[15:42] <abentley> vila: Where would be the best place for this?  In the SSHVendor code, or the individual transports?
[15:43] <vila> I didn't address it at times because... can't remember exactly, lack of test infra or shyness to touch the launchpad plugin code
[15:43] <vila> Well, if you do declare bazaar.launchpad.net in the file, it should already work
[15:44] <vila> That is the intent at least :)
[15:44] <abentley> vila: Really?  I see that for paramiko, but I thought the rest didn't use it.
[15:44] <vila> hmm, let me refresh my memory
[15:48] <vila> Ha yes, only paramiko implement access to auth
[15:49] <vila> The sub process ones are alien to me (I use only paramiko), but I guess the right place is in connect_[ssh_sftp] for SubprocessVendor, LoopbackVendor doesn't care
[15:50] <abentley> vila: Any suggestions how to test that?
[15:51] <vila> Tricky :)
[15:51] <vila> I think we lack the infrastructure for authenticating test servers
[15:52] <vila> So... the closest existing code will be in test_http/http_utils/http_server I guess
[15:54] <vila> I tested the AuthConfig in test_config.py and then there are some full stack tests in test_http (test_prompt_for_password, test_no_prompt_for_password_when_using_auth_config)
[15:54] <jam> vila: do we actually use AuthenticationConfig for ssh ?
[15:55] <vila> Only for paramiko apparently
[15:55] <vila> scratch apparently
[15:55] <jam> well, we would like it there
[15:55] <jam> I'm not sure if we should be more consistent
[15:55] <jam> but as paramiko doesn't have another way to configure it
[15:55] <abentley> jam: My motivating example is Launchpad.
[15:55] <jam> that is at least a start
[15:55] <jam> abentley: I understand what you are after, and I've read the bugs as well
[15:55] <vila> jam: more consistent ?
[15:56] <jam> I think that having a way to configure the username for paramiko is a good thing
[15:56] <jam> and perhaps "launchpad-login" is good enough
[15:56] <jam> vila: If we are going to use AuthConfig for paramiko, shouldn't we also use it for ssh and plink?
[15:56] <jam> arguable either way
[15:57] <abentley> jam: launchpad-login doesn't do enough.  It doesn't allow users to use "bzr+ssh://bazaar.launchpad.net" URLs that have no username.
[15:57] <abentley> jam: If we are going to insist that people specify their username via launchpad-login, not .ssh/config, we should ensure that it works all the time.
[15:58] <vila> abentley: well, I'd argue that either you use lp: or you use<EMAIL_ADDRESS>No ?
[15:58] <abentley> vila: That's not a shareable URL, so it can't function as a public URL.
[15:59]  * vila should stop editing branch.conf and put lp: urls there ? :-)
[15:59] <abentley> vila: I think that forcing a username into bzr+ssh urls is a bad choice because the resulting URLs can't be shared with other users.
[15:59] <vila> Haaa, misunderstood
[16:00] <vila> but then use lp: !
[16:00] <abentley> vila: That's not usable by people who don't have the launchpad plugin.
[16:00] <vila> and propagate it to .conf files so I can stop editing them :)
[16:00] <abentley> And it's not a real URL.
[16:01] <vila> there are people who don't have the lp plugin and want to use lp, oook. Fair enough :)
[16:01] <vila> abentley: shaking the tree, don't take it personally :)
[16:01] <abentley> I've implemented lp as a directory service.  This makes much more sense than implementing it as a transport.  But it means that the canonical url is whatever lp resolves to.
[16:01] <jam> abentley: the number of users that are going to be using launchpad with bzr but not have the launchpad plugin is roughly -10% at the moment
[16:01] <jam> (yes negative)
[16:01] <jam> :)
[16:02] <abentley> jam: Are you proposing to make it part of the core, not a plugin?
[16:02] <vila> on the subject of AuthConfig with ssh, we decided to refuse to handle passwords, pointing people to agents instead (just a reminder)
[16:02] <jam> abentley, vila: care to comment on bug #283123, I don't really want it to be just me versus bialix
[16:03] <jam> abentley: well, how many installs *right now* don't have the plugin... 0
[16:03] <jam> how many installs in the future to we expect to not have it
[16:03] <jam> roughly 0
[16:03] <jam> unless something changes dramatically
[16:03] <abentley> jam: If we're going to require it, it shouldn't be a plugin.  If it's a plugin, we shouldn't require it.
[16:03] <jam> abentley: I think requiring it for people using lp: urls is just fine
[16:04] <jam> as private urls won't resolve for everyone anyway
[16:04] <jam> some people won't be able to reach your server, etc.
[16:04] <jam> and branches move from time to time, servers disappear
[16:04] <jam> I think we can make a "reasonable effort" without having to turn the world around
[16:04] <jam> Obviously you feel stronger about it, and you're welcome to feel that way
[16:05] <jam> I think using "lp:" urls is a nice pretty way to do things
[16:05] <jam> that actually helps more than hurts
[16:05] <jam> that said, I agree that I'd rather not have "bzr+ssh://myuser@"
[16:05] <abentley> I really dislike lp urls, because they mask what's really happening.
[16:05] <abentley> Having a way to look up URLs is great.
[16:05] <abentley> Pretending it's the actual url... gross.
[16:06] <jam> anyway bbiab, taking my son to day-care
[16:12] <Verterok> mornin' all
[16:18] <abentley> jam: I think that if a user specifies a username in authentication.conf, Bazaar should respect that.  I think it simplifies documentation and knowledge transfer to have this work for all SSH vendors.  However, if they haven't specified something in authentication.conf and the SSH vendor has its own configuration mechanism, that should be respected.  Do you disagree?
[16:37] <jam> abentley: so I think it should be "URL username", "auth.conf", "ssh/config", in that order
[16:37] <jam> I'm a bit concerned about "accidental" entries in authentication.conf
[16:37] <jam> because we put them there, rather than just users
[16:37] <jam> however, if we are careful, it should be finee
[16:37] <jam> oh, and I wanted to point out an advantage of using lp:...
[16:38] <jam> users who *don't* have an lp account or haven't issued 'lp-login' can still get the public branch
[16:38] <abentley> jam: I agree with your order.
[16:38] <jam> (the only bug I know of is problems behind an http_proxy, because xmlrpc doesn't support it)
[16:39] <abentley> jam: We currently do add entries to auth.conf, or we would?
[16:39] <jam> abentley: probably "we would", though I thought vila had some specs about adding things automatically when we connect to a server for the first time and prompt the user
[16:40] <jam> I'm not sure what has been implemented
[16:40] <abentley> jam: Okay.
[16:41] <vila> abentley: we currently don't add entries to auth.conf, but we would
[16:42] <abentley> jam: Certainly it would be possible supply credentials via AuthenticationConfig without touching auth.conf if we decided we wanted to.
[16:44] <abentley> Something like that would happen if we supported native keychains/seahorses anyway.  But I doubt it's the right choice here.
[16:44] <vila> jfroy is working on supporting OS X keychain
[16:45] <vila> I made an attempt to accept pluggable credential stores at: lp:~bzr/bzr/pluggable-credential-stores
[16:46] <vila> but that doesn't address your need which is to provide a *user* name (not a password)
[16:48] <vila> And if we want to provide more public URLs, that may be needed
[17:36] <abentley> vila: I took a look at lp:~bzr/bzr/pluggable-credential-stores.  I'm confused because it says "We don't use the netrc ability to provide a user since this is not handled by authentication.conf".  AIUI, authentication.conf can provide users.
[17:37] <abentley> vila: Do you mean that only authentication.conf should provide users, not .netrc?
[17:37] <vila> abentley: netrc can provide a default user, but we don't get it
[17:37] <vila> abentley: yes
[17:37] <vila> badly phrased, AuthConfig can't handle it, of course authentication.conf can
[17:39] <vila> May be we should rename 'password_encoding' to 'credential_store' and allows the user to be provided :)
[17:39] <vila> may be that 'we' is really an 'I' :)
[17:39] <abentley> I'm confused.  AuthConfig has a get_username method.
[17:40]  * jfroy|work listens to the conversation
[17:41] <abentley> Maybe I don't understand the intended layering.
[17:41] <vila> but it doesn't delegate to the credential stores so it can't get the user provided by netrc in that case
[17:41] <vila> it just get the ones that are declared in authentication.conf
[17:42] <vila> as described in the spec, only the password was intended to stored outside of authentication.conf
[17:42] <vila> s/to/to be/
[17:42] <abentley> vila: So I think you want authentication.conf to specify the user, and then to allow credential stores to provide credentials for that user.
[17:44] <vila> Well, either the user is specified in authentication.conf or provided by the credential store, otherwise users would get confused
[17:45] <vila> credentials are for user at a host, optionally at a path and so far is only a password
[17:45] <vila> at a path or at a realm even
[17:46] <vila> rephrasing: now, the user in authentication.conf only and credential stores can provides passwords
[17:46] <vila> We can change that so that credential stores can provide user and password. But in that case the user shouldn't appear in authentication.conf (IMHO)
[17:55] <vila> abentley: is the following clearer :
[17:55] <vila>                 # We don't use the netrc ability to provide a user since there
[17:55] <vila>                 # is no way to give it back to AuthConfig. So if the user
[17:55] <vila>                 # doesn't match, we don't return a password.
[17:57] <abentley> vila: That's better.  But it implies a flaw in AuthConfig, rather than a design decision.
[17:58] <vila> abentley: agreed, especially with your new use case
[18:01] <abentley> vila: Oh.  I thought you believed that AuthConfig should not allow a user to be specified.  So I thought you should say something like "To reduce confusion, users are specified only on AuthConfig.  So we don't use netrc to choose a default user."
[18:02] <abentley> vila: But if you now think it makes sense for credential providers to specify a user, then your revised comment is good.
[18:04] <vila> It makes sense for credential stores to be able to provide user, in which case the user shouldn't be specified in authentication.conf. If the credential store doesn't provide user then it should be specified in .conf.
[18:04] <vila> So I will work in that direction in that branch which is  work-in-progress with a nick that perfectly fits :)
[18:05] <vila> abentley: Thanks for the feedback
[18:06] <abentley> vila: No problem.
[19:03] <woutc__> hello
[19:04] <woutc__> i am trying to use the bzrlib in my application
[19:04] <LarstiQ> evening woutc__
[19:05] <woutc__> but now i want to know the best function to check if a branch was changed by other people (somebody pushed the branch to a new rev)
[19:05] <woutc__> so i would like the log and the new rev number
[19:05] <woutc__> without pulling the branch
[19:06] <LarstiQ> woutc__: are the two branches the same (same url), or do you have one local branch you want to check against a remote one?
[19:06] <LarstiQ> woutc__: ala `bzr missing`
[19:06] <woutc__> i want to check a local branch to a remote one
[19:06] <LarstiQ> ok
[19:06] <rocky> jelmer: bzr-svn 0.4.13 is for bzr 1.7.x right?
[19:07] <jelmer> rocky, also for 1.8
[19:07] <rocky> ah cool
[19:07] <woutc__> bzr missing does what i need?
[19:07] <jelmer> rocky, I'll probably release a 0.4.14 that silences the compatibility warning at some point
[19:07] <rocky> jelmer: am i better off playing with bzr-svn 0.4.x branch (bzr 1.7.1 here) or bzr-svn 0.4.13 ?
[19:08] <LarstiQ> woutc__: yes. Looking at that code, it seems to be find_unmerged(local_branch, remote_branch, ...)
[19:08] <jelmer> the 0.4 branch is for bzr 1.9.x
[19:08] <LarstiQ> woutc__: see bzrlib/builtins.py, search for cmd_missing
[19:08] <woutc__> thank you so much! :)
[19:08] <LarstiQ> woutc__: let me have a look at the IDE integration page btw
[19:08] <LarstiQ> woutc__: if it isn't on there, it should be
[19:08] <rocky> jelmer: huh? so no more releases for bzr 1.7.x or 1.8.x ?
[19:09] <jelmer> rocky, not for 1.7, maybe one for 1.8 that is 0.4.13 + silences the compatibility warning
[19:09] <woutc__> LarstiQ: it seems that it isn't listed on the integration page
[19:09] <rocky> jelmer: i take that to mean bzr 1.8 is right around the corner?
[19:09] <LarstiQ> woutc__: right. When you figure out exactly what to do, could you add it to http://bazaar-vcs.org/Integrating_with_Bazaar?
[19:10] <LarstiQ> woutc__: I'm happy to review or help otherwise
[19:11] <woutc__> ok, i am the developer from specto (http://specto.sf.net) and i am trying to create a watch that notifies you when somebody committed to a branch :)
[19:15] <LarstiQ> woutc__: do you also support events instead of polling? Would need the help of the remote branch to work though, but would be less intensive.
[19:18] <woutc__> the current specto design works only with polling
[19:19] <woutc__> so if the refresh (or poll) time is not set too low, it is not really a problem
[19:23] <LarstiQ> k
[19:24] <rocky> jelmer: looks like that ghost revision bug thing i talked to you about before is back (it went away there for a bit) .... http://cluebin.appspot.com/pasted/2401
[19:39] <woutc__> i found the function but i get an error
[19:39] <woutc__> >>> local_branch = Branch.open_containing(u".")[0]
[19:39] <woutc__> >>> parent = local_branch.get_parent()
[19:39] <woutc__> >>> local_extra, remote_extra = find_unmerged(local_branch,parent)
[19:39] <woutc__> Traceback (most recent call last):
[19:39] <woutc__>   File "<stdin>", line 1, in <module>
[19:39] <woutc__>   File "/usr/lib/python2.5/site-packages/bzrlib/missing.py", line 62, in find_unmerged
[19:39] <woutc__>     remote_branch.lock_read()
[19:39] <woutc__> AttributeError: 'unicode' object has no attribute 'lock_read'
[19:47] <abentley> woutc__: You have the location of a branch as a unicode string, and you're treating it like a Branch object.
[19:49] <woutc__> but the variable local_branch is a Branch object, no?
[19:49] <woutc__> >>> type(local_branch)
[19:49] <woutc__> <class 'bzrlib.branch.BzrBranch6'>
[19:50] <LarstiQ> woutc__: but 'parent' is not
[19:50] <the-geek-inside> Programming Python, O'Reilly, Mark Lutz, ISBN-10: 0-596-51398-4
[19:50] <LarstiQ> woutc__: the two first arguments to find_unmerged are the two branches you want to compare
[19:50] <LarstiQ> woutc__: and branch.get_parent() returns a url, not a branch
[19:51] <woutc__> haha so i have to create a branch object with the url :)
[19:52] <woutc__> ok that did the trick
[20:01] <the-geek-inside> OSamaK: Learning Python is good when you don't know about the language, so I guess thath you find some a little more advanced
[20:03] <jelmer> rocky, yeah, afaik 1.8 should be released soon
[20:04]  * rocky finds it odd that he's the only person in the world to have such a glaring problem
[20:09] <jelmer> rocky, ?
[20:10] <rocky> jelmer: well this is preventing me from using bzr-svn (whether it's bzr's fault or not) ... just seems strange that this "showstopper" isn't severe enough to have fixed for bzr 1.7.1
[20:10] <jelmer> rocky, which showstopper?
[20:10] <LarstiQ> jelmer: http://cluebin.appspot.com/pasted/2401
[20:10] <rocky> jelmer: you didn't see my paste above?  http://cluebin.appspot.com/pasted/2401
[20:10]  * LarstiQ does drive by pasting and leaves the house
[20:11] <rocky> lol
[20:11] <jelmer> LarstiQ, :-)
[20:11] <jelmer> rocky, :-(
[20:18] <jelmer> rocky, That's a bzr-svn bug primarily, unfortunately (IIRC caused by older versions of bzr-svn that wrote incorrect data)
[20:19] <rocky> jelmer: old data shouldn't be an issue... how do i get rid of old data?
[20:22] <jelmer> rocky, the old data in the svn repository, if you do a fresh checkout (remove ~/.bazaar/svn-cache) outside of your existing shared repo it should work
[20:34] <jelmer> james_w, ping
[20:34] <james_w> hey jearl
[20:34] <james_w> er, jelmer
[20:34] <james_w> how are you?
[20:34] <jelmer> Very good, thanks (-:
[20:34] <jelmer> james_w, You asked about bzr-notify crashes earlier
[20:34] <james_w> cool
[20:35] <jelmer> I've uploaded a new snapshot of bzr-gtk that should fix those issues
[20:35] <james_w> yeah, apport has shown that it affects a few people
[20:35] <james_w> ah, great
[20:35] <james_w> to experimental?
[20:35] <james_w> bug 283294 arrived today, but I'm not sure why that only seems to affect Ted
[20:36] <jelmer> yep, I uploaded to experimental
[20:36] <jelmer> I'm not sure what Ted's bug is about either
[20:37] <james_w> I mean no mainloop is defined as far as I can see, so it's right
[20:37] <james_w> but why isn't that always a crash?
[20:39] <jelmer> I think it (used to ?) creates a mainloop implicitly
[20:42] <james_w> jelmer: I'd like to just cherry-pick the fixes out, as we're two days from RC freeze, and it will avoid a freeze exception request
[20:43] <jelmer> james_w, One sec, I'll look up the relevant revnums
[20:44] <james_w> jelmer: there are a couple of fixes missing that I put in to the Ubuntu package, I'm sure I checked they were fixed in trunk though
[20:44] <james_w> http://paste.ubuntu.com/57563/ for a start
[20:47] <james_w> thanks for the heads up, I'm going to eat now, I'll work on it after that
[20:47] <jelmer> james_w: http://people.samba.org/bzr/jelmer/bzr-gtk/trunk, revisions 607-611
[20:47] <james_w> thanks
[20:48] <jelmer> james_w, bon appetit
[20:48] <jelmer> james_w, I think we may not have those changes, will check
[21:07] <rocky> jelmer: i'll take a crack at that as soon as i finish preparing supper for the kids )
[21:07] <rocky> :)
[21:20] <ryanakca> could somebody help me figure out the mess I got myself into please? bzr is telling me to resolve a file that isn't conflicted: http://paste.ubuntu.com/57581/
[21:27] <poolie> hello all
[21:28] <poolie> ryanakca: maybe you're not in the base directory of the tree?
[21:28] <poolie> like you're already in ./debian/?
[21:28] <poolie> in which case you just want 'resolve changelog'
[21:28] <poolie> jam, ping?
[21:28] <jam> poolie: pong
[21:29] <ryanakca> poolie: nope
[21:29] <poolie> hey, Shang was just checking about bug 242510
[21:29] <poolie> that is definitely fixed in 1.8 right?
[21:29] <poolie> well, news says so
[21:29] <poolie> lp is unreachable atm
[21:30] <jam> poolie: that one should indeed be fixed in 1.8
[21:31] <jam> bug 153786 is not, though
[21:32] <poolie> ryanakca: what does 'bzr st' show
[21:39] <ryanakca> poolie: http://paste.ubuntu.com/57588/
[21:39] <poolie> oh, i see
[21:40] <poolie> so someone has actually committed three files called changelog.BASE .OTHER and .THIS
[21:40] <poolie> maybe you :)
[21:40] <poolie> that might not really be what you want?
[21:41] <ryanakca> poolie: bzr ls debian/ doesn't show those files?
[21:43] <poolie> what about plain ls?
[21:44] <ryanakca> poolie: same
[21:45] <poolie> how about just 'bzr resolve' then
[21:47] <ryanakca> poolie: it tells me it auto-resolved nothing and then it spewed out the same as the conflicts part of bzr status
[21:47] <GhostFreeman> Is there a channel for tortoisebzr?
[21:47] <poolie> no, just ask here
[21:49] <GhostFreeman> Ok. Well I installed Bazaar on my windows vista machine (1.8rc1) and while bzr works, I can't get TortoiseBzr to show up in Windows Explorer
[21:50] <poolie> GhostFreeman: using the python-based 1.8rc1 installer?
[21:50] <poolie> GhostFreeman: i think that only includes bzr, not any plugins
[21:50] <poolie> the person who normally makes windows builds, mhammond, is on holidays
[21:50] <poolie> i'm getting set up to build 1.8 myself
[21:50] <GhostFreeman> I did install using win32-py2.5
[21:51] <poolie> in the meantime you could try 1.7-setup.exe, which does have it
[21:51] <poolie> s/it/tbzr
[21:51] <GhostFreeman> Alright. Should I remove 1.8 before I revert to 1.7?
[22:10] <poolie>  probably a good idea
[22:10] <poolie> jam, yeah it'd be good to fix 153786
[22:32] <mwhudson> is it expected that you can call branch.set_stacked_on_url() on a branch that is write-locked by another process?
[22:35] <lifeless> mwhudson: no, bugger a file please
[22:35] <mwhudson> lifeless: okidoke
[22:36] <jam> poolie: when it comes time for the standup, ping me. If I don't respond, call my cell phone
[22:36] <poolie> ok
[22:36] <poolie> that sounds painful
[22:40] <lifeless> poolie: did you see my query re usertest log ?
[22:40] <poolie> mm, i did
[22:40] <lifeless> http://benchmark.bazaar-vcs.org/usertest/log/usertest.log.inprogress <- shows only the pull phase
[22:40] <poolie> and then i fell asleep :)
[22:40] <lifeless> fair enuff
[22:41]  * poolie looks
[22:41] <mwhudson> lifeless: https://bugs.edge.launchpad.net/bzr/+bug/283457
[22:42] <lifeless> mwhudson: I suspect its really 'config objects don't honour lock status of their branch'
[22:42] <mwhudson> mm, that would make sense
[22:47] <jfroy|work> jelmer: ping
[22:47] <jfroy|work> (and hi!)
[22:47] <jelmer> jfroy|work, pong!
[22:48] <jfroy|work> So, I have mostly addressed the issues I've (suddently) been having with bzr-svn, at the cost of a rather large performance problem.
[22:49] <jfroy|work> What showed up as corrupted knit exceptions in bzr 1.7.1 and bzr-svn 0.4.3 became not-a-branch exceptions or problems in top of tree (both for bzr and bzr-svn).
[22:49] <jfroy|work> The svn repository I'm working with has ... a tortured history of projects being moved around several times, not always following svn conventions.
[22:50] <jfroy|work> And it was clearly tripping bzr-svn up.
[22:51] <jfroy|work> So I managed to write up a list of branch paths in subversion.conf that made it mostly work (some branches in certain projects no longer can be checked out, the entire project (e.g. the root containing trunk, branches, tags) has to be checked out).
[22:51] <jfroy|work> However, now, sending a changeset takes upward of 15 seconds to complete, pegging Python to 100% of the core it's running on.
[22:52] <jfroy|work> Any ideas why that might be?
[22:53] <jfroy|work> Also, how reasonable would it be to have an option to force a specific svn revno to be considered the "baseline", from bzr-svn's POV. E.g. it wouldn't look in the Subversion history earlier than that revno, to help deal with old svn repositories that have had a less than ideal history.
[22:55] <jonoxer> jfroy|work: you could dump from a specific revision using svnadmin, populate a new repo with just that history, then convert that
[22:55] <jfroy|work> Not viable in this case, I do not control or own the subversion repository in question.
[22:55] <jonoxer> Ah, right
[22:58] <jonoxer> It's kinda brute-force, but I did something nasty once where I scripted a sequence of "svn up -r $i" updates to let me pull a sequence of commits from a remote repo and run analysis on them. Maybe something similar?
[22:59] <jfroy|work> Well my understanding is bzr-svn has to map svn paths to branches (since svn has no formal notion of branches), and when a svn repository is really messed up, bzr-svn blows up :p
[23:00] <jfroy|work> You can grab its hand by specifying a custom list of branches, but that has limits, and apparently bad performance implications for commit operations.
[23:02] <jelmer> re
[23:03] <jelmer> jfroy|work, 0.5 will be a lot of better in that regard
[23:03] <jfroy|work> jelmer: 0.5 is "working" for the most part, commits are exceedingly slow though
[23:04] <jfroy|work> And for one project the branches trick didn't quite work because of a svn mv operation (IIRC my analysis of the bzr log)
[23:05] <jfroy|work> if log files can help, I'd be happy to provide them to you, just let me know the debug flags you need
[23:05] <jelmer> jfroy|work, s/0.5/0.4 ?
[23:05] <jfroy|work> I'm using bzr and bzr-svn mainline
[23:05] <jfroy|work> I'm bleeding-edge :p
[23:05] <jelmer> jfroy|work, trunk or 0.4 ?
[23:05] <jfroy|work> 0.4 just explodes, and 0.5 needs what appear to be 1.9 API
[23:05] <jfroy|work> trunk
[23:06] <jelmer> jfroy|work, Please be careful with that, you wouldn't want to use it with production-type stuff
[23:06] <jelmer> jfroy|work, how does 0.4 blow up?
[23:07] <jfroy|work> I am using it on production stuff, I trust it to not delete every file :p
[23:07] <jfroy|work> 0.4 throws corrupted knit errors
[23:07] <jfroy|work> I haven't, though, tried 0.4 with the custom branches option
[23:08] <jfroy|work> I never would have found out what the problem even was without 0.5's much more helpful errors.
[23:13] <jfroy|work> So yeah, if there's anything useful I can do, let me know.
[23:14] <jfroy|work> I have, incidentally, a small change to trunk that addresses assertions (usually on branch names) that checked if certain parameters were str objects, also allowing unicode objects
[23:21] <jam> lifeless: for bzr.dev, 'time bzr pack' w/ normal compression: 39.5s & 5.7MB, w/ max compression: 42.7s and 4.5MB
[23:21] <jam> I'm off for now
[23:21] <lifeless> jam: ciao
[23:22] <lifeless> jam: I do wonder about just turning it on; indices are never done in isolation
[23:23] <lifeless> jam: and the proportion to data written should be roughly constant
[23:23] <lifeless> jam: (we'd want spill indices to have it off)
[23:23] <awilkins> jelmer: The trunk of bzr-svn is the not-tied-to-a-fixed-concept-of-branch-mapping branch, yes?
[23:24] <jelmer> awilkins, yes
[23:24] <awilkins> jelmer: E.g. - if you have a wacky repo layout it's ok
[23:24] <jelmer> jfroy|work, any chance you can send me those patches?
[23:24] <jam> lifeless: so for 'bzr pack' it is 10% more time for 25% less space. I was tuning it to be minimal by request for 'bzr commit' time.
[23:24] <jam> Which seemed reasonable
[23:24] <awilkins> jelmer: How stable is that now?
[23:24] <jelmer> awilkins, not recommended for use with production code
[23:24] <awilkins> jelmer: I have some really horrible repos I can run it on :-)
[23:25] <awilkins> jelmer: I don't mind it not being OK for production at the moment but I'm happy to devote a few CPU cycles to trying it out
[23:26] <awilkins> jelmer: We are moving to another office that may have limited bandwidth and I think people might appreciate something that can buffer the gap to the server a bit
[23:26] <awilkins> jelmer: 0.4 struggled with the repo layout of our main repo the last time I tried it (large revisions where there should have been tiny ones for branches)
[23:27] <awilkins> jelmer: And of course, there's that KeyError thing (is that fixed?)
[23:27] <jfroy|work> jelmer: can I bzr send that to some email address?
[23:28] <jfroy|work> awilkins: I saw those key errors a bunch of times too
[23:29] <jfroy|work> I had to experiment a few times on my branches setting to get bzr-svn to checkout.
[23:29] <jelmer> jfroy|work, just "bzr send" against the main branch should do the right thing
[23:29] <jfroy|work> commits are also exceedingly slow
[23:29] <jelmer> awilkins, use of trunk may silently break the ability to use bzr-svn in the future on those branches
[23:30] <jfroy|work> jelmer: bzr send complains it wants a mail-to address
[23:30] <jfroy|work> whoa, really?
[23:30] <jelmer> jfroy|work, are you using http://people.samba.org/bzr/jelmer/bzr-svn/trunk ?
[23:30] <jfroy|work> jelmer: ah no, that was against the launchpad mirror
[23:31] <jfroy|work> Complained against that branch too :/
[23:32] <jelmer> Ah, looks like I've only got it set on 0.4
[23:32] <jelmer> one sec
[23:32] <jfroy|work> I didn't know a branch could specify a mail-to address, that's kind of very cool :)
[23:33] <jelmer> jfroy|work, please try again
[23:34] <jelmer> jfroy|work, you can set "child_submit_to = email@address" in .bzr/branch/branch.conf
[23:36] <mwhudson_> something doesn't seem right here: http://pastebin.ubuntu.com/57627/
[23:36] <mwhudson_> lifeless: more set_stacked_on_url/write lock interaction nasties :(
[23:36] <mwhudson_> ^
[23:36] <awilkins> jelmer: Do you mean the ability to use bzr-svn on the actual SVN branches?
[23:36] <awilkins> jelmer: Or just the bzr branches?
[23:37] <jelmer> awilkins, the ability to use bzr-svn on the actual SVN branches
[23:37] <awilkins> jelmer: That down to the bzr: properties?
[23:37] <jelmer> awilkins, yep
[23:37] <awilkins> jelmer: Is this because experimental progression is neglecting to put migration steps for the properties in?
[23:38] <jelmer> awilkins, that, and the fact that several corner cases are not well tested yet for trunk
[23:38] <jelmer> and so may set invalid values for the properties
[23:38] <awilkins> jelmer: Is this only a problem if you push?
[23:39] <jelmer> awilkins, generally, yes
[23:39] <jelmer> awilkins, however, if you use trunk for pulling you may also corrupt your local bzr branch
[23:39] <jelmer> awilkins, since trunk may sometimes be broken (it warns you every time you use it for a reason)
[23:40] <awilkins> jelmer: Fair enough - less of a risk if you are just pulling branches on a particular trunk revision for experimental purposes?
[23:41] <awilkins> jelmer: Since 0.4 can't pull the trunk of my "big nasty" repo, it's not too much of a loss
[23:41] <jfroy|work> ack, this is kind of scary -- to never be able to use bzr-svn again on a repository.
[23:42] <awilkins> jelmer: If you dropped the bzr: properties, and re-pulled your branches, you'd lose some metadata but the compatibility problem would be fixed, yes?
[23:43] <jelmer> awilkins, you can'y drop them without taking the repository down
[23:44] <awilkins> jelmer: Are they all revprops or are there fileprops there too?
[23:45] <jelmer> all fileprops at this point
[23:45] <awilkins> jelmer: So you'd need a dump | filter | load ?
[23:45] <jelmer> awilkins, yep
[23:45] <jfroy|work> jelmer: do you think a "baseline" revno option would be a suitable workaround for the extreme case of a broken subversion repository that is not under your control?
[23:46] <awilkins> Happily, I am the server admin :-)
[23:46] <jelmer> jfroy|work, that means you can't allow dir push to svn
[23:46] <jelmer> s/dir/direct/
[23:46] <jfroy|work> I don't know enough about how this stuff is working to understand why that is, but I'll trust you on that
[23:47] <jfroy|work> Urg, I might have owned myself for all time :|
[23:47] <jfroy|work> (patch sent, btw)
[23:47]  * mwhudson_ bounces
[23:48] <mwhudson_> lifeless, poolie: could one of you look at http://pastebin.ubuntu.com/57627/ for me?
[23:56] <poolie> mwhudson: really
[23:57] <poolie> mwhudson: and where is the repository for them?
[23:57] <poolie> i presume they're in the same repository?
[23:57] <poolie> that's probably the bug, can you file it?
[23:58] <mwhudson> poolie: i don't think that matters, actually, it seems you get this when the branches are both standalone
[23:58] <mwhudson> poolie: i can check though


[05:35] <knightwise> Morning
[05:50] <knightwise> hey Hornet-
[07:50] <brobostigon> morning boys and girls.
[08:00] <MooDoo> morning brobostigon
[08:00] <brobostigon> morning MooDoo
[08:01] <MooDoo> :)
[08:06] <mapps> hi all
[08:06] <mapps> im back in uk atm;p
[08:06] <MooDoo> nice wb
[08:06] <mapps> next stop is Ukraine:)
[08:07] <MooDoo> you doing a eurovision tour ;)
[08:07] <mapps> haha nah
[08:07] <mapps> im a lone warrior remeber
[08:08] <mapps> but my next stop is kiev
[08:12] <brobostigon> stay out of the war. dont get hot by bullets.
[08:12] <brobostigon> hit*
[08:15] <MartijnVdS> getting hot by bullets..
[08:15] <MartijnVdS> friction or burning?
[08:15] <brobostigon> both.
[08:15] <elfy> so don't get hit by hot bullets
[08:16] <mapps> brobostigon thats eastn ukraine;p
[08:16] <brobostigon> mapps: i know, it was meant to be a joke.
[08:16] <mapps> ie got a friend who said he'll meet me at the airport
[08:16] <mapps> :D
[08:16] <MartijnVdS> I went the other way -- I drove around the UK for a week :)
[08:16] <brobostigon> maybe it was a burning arrow being carries on the back of a bullet?
[08:17] <brobostigon> carried*
[08:18] <mapps> my friend said he
[08:18] <mapps> 'is scary to come'
[08:18] <mapps> but i think we will be ok at ukraine:)
[08:19] <SuperEngineer> mapps, why do you keep going on about uk rain?
[08:19] <SuperEngineer> [& there's no "e" in rain]
[08:19] <mapps> because its where im going
[08:20] <MartijnVdS> SuperEngineer: Ye Olde Raine.
[08:20] <SuperEngineer> ;)
[08:20] <MartijnVdS> aka tap water
[09:35] <knightwise> hey everyone
[09:41] <popey> yo
[11:18] <zmoylan-pi> wow, nearly forgot, happy towel day everyone...
[11:36] <bashrc> happy towel day
[11:44] <knightwise> hey everyone
[11:44] <knightwise> happy towel day  :)
[11:45] <knightwise> hmm.. i wish Xorg still existed
[11:45]  * knightwise having trouble with his ultrawide monitor
[11:45] <shauno> so you'd like 2 problems instead?  ;)
[11:46] <knightwise> Dunno .. at least in Xorg I knew how to add a resolution
[11:46] <knightwise> Ati card is having trouble with the 2560x1440 res of my screen
[11:52] <knightwise> somehow it just goed up to 2560x1080
[11:52] <penguin42> for X I'd know where to suggest looking
[11:52] <knightwise> I assume its x (14.04 on a mac mini)
[11:52] <penguin42> knightwise: Well, in that case look in /var/log/Xorg.0.log and look for errors or warnings
[11:53] <penguin42> knightwise: and also xrandr to see what it lists as available resolutions
[11:53] <knightwise> according to xrandr the max res it knows is 2560x1080
[11:54] <penguin42> knightwise: ok, so /var/log/Xorg.0.log is the best thing to look at
[11:55] <penguin42> knightwise: Look for any lines with (EE) or (WW) in that are errors or warnings (there are normally a few WW anyway) and also see if the 2560x1440 appears anywhere in it
[11:55] <knightwise> no errors , but 2560x1440 doesnt show up anywhere either
[11:56] <penguin42> fun
[11:56] <penguin42> knightwise: What's the card and which driver?
[11:56] <knightwise> checking , holdon
[11:57]  * penguin42 was expecting it to list it but reject it at some point
[11:57] <knightwise> radeon 6600/6700 fglrx-updates proprietary driver
[11:59] <penguin42> hmm, I've not used the proprietary one for a few years; I use the open one on my hd4350
[12:01] <penguin42> knightwise: OK, not sure if this will work, but.....
[12:02] <penguin42> knightwise: install the read-edid package  then do           find /sys -name edid            it will find one pseudo-file for each output
[12:02] <penguin42> knightwise: then do       parse-edid < /sys/devices/whatever      where the whatever comes from the find
[12:02] <penguin42> knightwise: That should give you the information that the monitor is telling the host
[12:09] <knightwise> i have been looking at adding the resolution to xrandr but  that does not seem to work
[12:11] <penguin42> knightwise: Since you're using the fglrx driver perhaps you should use the setup tool that comes with it?
[12:11] <knightwise> aha i'll look for that
[12:12] <knightwise> erm .. how do i open that tool ?
[12:15] <knightwise> i think i found it :)
[12:15] <penguin42> knightwise: Anyway, if you don't get the monitor working, just ship it here
[12:17] <knightwise> ah wait
[12:17] <knightwise> the res of my screen IS 2560x1080
[12:18] <knightwise> it was throwing up an error when I booted because it saw 1920x1080
[12:18] <zmoylan-pi> i was using 800x600 in 2010 :-)
[12:18] <penguin42> knightwise: Ah ha!
[12:19] <knightwise> ok , so this appears to be working :)
[12:20] <knightwise> ok , all I need to fix now is Chrome
[12:20] <knightwise> looks like it gets all jumbled up when i scroll
[12:22] <penguin42> that sounds like a driver bug
[12:30] <knightwise> ok , rolling back to the open source driver , see if that helps :)
[13:48] <diddledan_> eh? wish xorg still existed? <-- does it not then?
[13:59]  * SuperEngineer ponders the declination of this new verb "then"
[14:01] <diddledan__> I hope you're not expecting me to even. because I can't even.
[14:01] <zmoylan-pi> perhaps they a word?  What version of the 14.04 (or 15.04) distro do you use to install on a mac mini with Xeon processorts
[14:23] <knightwise> the 64 bit right ?
[14:23] <penguin42> either 32 or 64 should work
[14:23] <penguin42> hang on, a mac mini with a Xeon?
[14:24] <knightwise> its an I7 mac mini
[14:24] <penguin42> why do they put the xeons in them rather than the i7 variant?
[14:24] <knightwise> i have 16 gigs of ram , so i should go for the 64 bit version , correct ?
[14:25] <penguin42> yes, always use teh 64bit version unless your hardware doesn't support it
[14:26] <knightwise> so does EFI boot matter ?
[14:27]  * zmoylan-pi casts ward silliness at mention of efi....
[14:28] <penguin42> knightwise: I don't think so these days; the only weirdness now is that if you have a 32bit EFI (that's very very rare) then you need to do special stuff
[14:31] <knightwise> ok , because I downloaded the 64 bit version of elementary and got the error code "controller not found'
[14:33] <penguin42> now which controller is the question
[14:34] <knightwise> i think it might be the video controller, holdon , i'll boot
[14:35] <knightwise> i8042 no controller found
[14:37] <penguin42> oh that's OK I think - that's just saying you've not got PS/2 keyboard
[14:38] <knightwise> yep .. but it hangs on that screen
[14:38] <knightwise> I have a wireless logitech keyboard with one of those little remote usb controllers
[14:38] <knightwise> do i need to plug in a generic usb keyboard ?
[14:39] <penguin42> I don' the i8042 message is relevant to your problem; it's just the last message before it went wrong - but it's worth trying a generic usb keyboard if you've got one, I'd heard other people having problems with some of the logitech wireless
[14:40] <knightwise> ok , getting a kb from the basement now
[14:41] <zmoylan-pi> something with an at connector so you can connect a at -> ps2 -> usb adapter... :-)
[14:42]  * penguin42 isn't sure where his at->ps2 adapter is, I'd like to see if some of my more keyboards still work
[14:43] <knightwise> got a generic mac keyboard (wired)
[14:44] <knightwise> nope , same problem
[14:45]  * penguin42 guesses more likely a graphics problem
[14:45] <knightwise> hmm there is a radeon 6600 in there
[14:46] <penguin42> should work
[14:46] <knightwise> god .. this used to just work ...
[14:57] <diddledan_> knightwise: good to see the new season of your podcast \o/
[15:00] <diddledan_> jeebers. win10 is bsodding every other minute today
[15:01] <diddledan_> hmm, seems my surface overheated
[15:01] <diddledan_> it's shutdown with a thermometer icon on the screen just prior
[15:01] <zmoylan-pi> that's not good
[15:01]  * diddledan_ leaves it for a bit to cool-off
[15:01] <zmoylan-pi> surface 4... now with noisy cooling fans... :-P
[15:02] <zmoylan-pi> and being ms they'll face upwards so that if you use it outside in the rain it'll be a funnel... :-D
[15:07] <penguin42> an over heating tablet, there had to be a time
[17:37] <bujji> popey:when i use "rm  <file name>"as a user with 777 permissions in file its not warn me why?
[17:38] <dutchie> why would it warn you?
[17:38] <bujji> if i use run that command as aroot user its warn me?
[17:39] <bujji> dutchie:may i know the reason ?
[17:40] <dutchie> what was the warning?
[17:42] <bujji> dutchie:rm:remove regular empty file 'file.txt' ? when i run as a root user with 777 perm
[17:44] <bujji> dutchie:"rm file.txt"
[17:44] <MartijnVdS> Some distributions alias "rm" to "rm -i" for the root account
[17:44] <MartijnVdS> to protect against accidents
[17:45] <dutchie> yes it's most likely that
[17:45] <MartijnVdS> you can check by running the command "aliasA"
[17:45] <MartijnVdS> uh
[17:45] <MartijnVdS> the command "alias"
[17:45] <MartijnVdS> also, probably, in .bashrc or .bash_profile, or similar (there's a list of startup scripts in the bash manual, "man bash")
[17:46] <bujji> yeah i found that
[17:47] <bujji> MartijnVds:if i unalias that one it wont ask like that
[17:48] <bujji> MartijnVdS:let me check in user
[17:51] <bujji> MartijnVdS:got it,thank you.
[18:22] <diddledan_> canonical might IPO?
[18:22]  * diddledan_ googles
[18:23] <diddledan_> http://www.zdnet.com/article/mark-shuttleworth-considering-canonical-ipo/
[18:56] <shauno> lol "We now have a story that the market will understand."
[18:56] <shauno> the desktop/server/cloud/mobile/container/throw spaghetti at the wall story?
[18:56] <diddledan_> lol
[18:58] <zmoylan-pi> well if you substitute the spaghetti... :-P
[19:16] <popey> evening all
[19:16] <popey> \o/ free wifi in pubs
[19:16] <diddledan_> \o/
[19:21] <zmoylan-pi> i don't use free wifi, i don't trust it paranoid sod that i am :-)
[19:23]  * popey hugs ssl
[19:25] <zmoylan-pi> i think it was when i went to my first hacker meetup and they announced they had at last minute arranged free wifi... just made my spider sense tingle... :-)
[19:25] <diddledan_> eep
[19:25] <diddledan_> yeah free wifi in hacker cons are bad bad
[19:26] <zmoylan-pi> and sure enough they showed what folks were browsing during the meetup at one of the last talks.
[19:26] <diddledan_> also check your mobile phones don't connect to random gsm networks
[19:26] <zmoylan-pi> at the time gsm fake networks were next to impossible.  not impossible but very rare
[19:27] <zmoylan-pi> there was an android app that could show all the 2g/3g towers in an area so you could check them out


[11:04] <jarnos> What package handles mounting of USB devices automatically?
[11:07] <jarnos> I suppose it is not rdesktop Bug #1333354
[19:13] <EOBeav> Does wine function in lubuntu?
[19:13] <wxl> EOBeav: yep.
[19:13] <EOBeav> wxl, thanks
[19:13] <wxl> EOBeav: np
[19:14] <EOBeav> Have to get it through synaptic, though, right?  Or just through regular terminal apt-get install?
[19:14] <wxl> EOBeav: either
[19:15] <EOBeav> k, sounds good, I'll go check it out
[20:17] <BobbyBobson> Hi guys, thanks for Lubuntu, best distro out there for a couple of years now ! I was wondering if one of you guys could help me with a problem I have. How do I  (from terminal) make applications run at start. I obviously googled this issue, and tried out 6 diffrent ways. None of witch was succesfull, one of witch bricked my system
[20:17] <BobbyBobson> and when I say "at start" I mean, when the desktop loads up
[20:23] <EOBeav> BobbyBobson: Generally speaking, look for your startup menu, then get your app from your /usr/bin folder


[01:26] <guest_____> tsimonq2 we agreed a truce, please pop back onto #phillw-social for a chat.
[01:26] <guest_____> waves to redwolf :)
[01:26] <tsimonq2> Please leave.
[01:27] <guest_____> simon, if that is your wish. I will do so. You were the one to offer out the olive branch. But, c'est la vie.
[01:28] <tsimonq2> ...
[01:28] <guest_____> easy to kick me.
[01:28] <tsimonq2> I'm not an OP here.
[01:28] <krytarik> I would..
[01:29] <guest_____> krytarik for what reason?
[01:29] <krytarik> Ban evasion.
[01:31] <guest_____> as you wish. I was trying to cool things down. I'll have to refer to the freenode staffers over that. But, not knowing the story Op'ping your self is frowned upon.
[01:32] <krytarik> Not if action seems to be required soon.
[01:34] <guest_____> as Simon had approached me over an issue and we were agreeable, my suspicion is that he would be okay with continuing a dialogue.
[01:38] <guest_____> kryst you are increasing the 'heat' on the channel, just as I'm trying to "cool" it.  Why not follow that promise
[01:39] <wxl[m]> guest_: if you want to engage with the community in any way, you need to start with the community council first. Until then, leave.
[01:40] <wxl[m]> There is no more discussion to be had on this subject beyond that. I don't care what other discussions may or may not have happened.
 Hello
[01:42] <guest_____> wxl[m]: well, simon is more aware than you think. But, to save issues. I will part. The truth will come out.
[01:42] <wxl[m]> Good bye. Do not return until you get cleared by the Council.
[01:42] <wxl[m]> Ugh


[10:43] <pef> hello
[02:00] <verwilst> Riddell?
[02:00] <verwilst> is kdevelop 3.3rc1 packaged too for ubuntu?
[02:27] <Tm_T> aerh, is there ready list of dapper repositories? I'm too lazyto write them myself
[02:59] <Tm_T> yup, upgrading to dapper
[03:38] <jeroenvrp> hi folksa
[03:38] <jeroenvrp> can someone please tell me when all KDE3.5RC1 packages will be available?
[03:40] <Tm_T> define all
[03:40] <Tm_T> :p
[03:40] <jeroenvrp> Tm_T: the rest :-)
[03:40] <Tm_T> haha
[03:40] <jeroenvrp> but can you tell me?
[03:40] <Tm_T> well, I think 3.5 will have them all
[03:41] <Tm_T> as soon as you package them ;)
[03:41] <jeroenvrp> kubuntu.org says: "KDE 3.5 Release Candiate 1 has been released, the base packages are available for Kubuntu with more being uploaded this weekend."
[03:55] <OculusAquilae> hi
[03:56] <author-psi> hi OculusAquilae
[03:56] <OculusAquilae> what would you think of customize minicli for kubuntu like that: http://oculusaquilae.de/kubuntu/dapper/minicli-sudo.png
[03:56] <OculusAquilae> you know it already author-psi, right?
[03:57] <author-psi> yes, an the idea shows perfekt
[04:04] <Tm_T> OculusAquilae: to add "administrator" option? not bad
[04:05] <OculusAquilae> yes, and let the "other user"-option be only for different users not root
[04:05] <Tm_T> why not root too?
[04:06] <Tm_T> :)
[04:06] <OculusAquilae> hm
[04:06] <Tm_T> another users, including root
[04:06] <OculusAquilae> ok
[04:07] <OculusAquilae> that would make it more intuitive for new users, who don't know anything about root or something like that
[04:07] <OculusAquilae> and it would display the idea of sudo in the gui
[04:11] <OculusAquilae> a user without sudo rights could open a program with root-rights as a different user if he knows the password
[04:11] <\sh> OculusAquilae: hum?
[04:12] <OculusAquilae> [16:11]  <\sh> OculusAquilae: hum?
[04:12] <OculusAquilae> [16:11]  <\sh> OculusAquilae: hum?
[04:12] <\sh> OculusAquilae: u mean user X is not in group admin, he will be asked to become user Y which is in group admin?
[04:12] <\sh> to fire up program A which needs root rights?
[04:13] <OculusAquilae> hm
[04:13] <OculusAquilae> first I think of minicli
[04:14] <OculusAquilae> the "Run as administrator" is greyed out if you are not in "admin", if you use "Run as different User" with a user in "admin" it would become black or something like that
[04:15] <Riddell> verwilst: not yet
[04:15] <OculusAquilae> perhaps not greying out and you are asked to become a user in "admin"
[04:15] <Riddell> jeroenvrp: I'll make them today
[04:15] <\sh> well, there must be a reason, that User X is not in the admin group
[04:15] <OculusAquilae> :-)
[04:16] <OculusAquilae> perhaps user Y want's to run a program while only user X is logged in
[04:16] <\sh> OculusAquilae: no user who is not in the admin group should run applications which need root access
[04:16] <OculusAquilae> right
[04:17] <\sh> even not when he knows the password of a user which is in the admin group...that means, he could login as the admin user
[04:17] <OculusAquilae> he could
[04:18] <OculusAquilae> but he only wants to run one small application, because he is for example helping user X with something
[04:18] <\sh> so User X who is not in the admin group, doesn't need to run application A as root or as another user
[04:19] <OculusAquilae> that would in this case take time
[04:19] <\sh> OculusAquilae: but admins, u know, are quite sensitive with their passwords...so the admin user will take his time...or use "switch user"
[04:20] <OculusAquilae> hm
[04:20] <OculusAquilae> he could
[04:21] <\sh> he will
[04:21] <OculusAquilae> but in a private environment he won't perhaps
[04:21] <\sh> OculusAquilae: so..u don't think about edubuntu :)
[04:22] <\sh> OculusAquilae: which is using as well some parts of kde :)
[04:22] <OculusAquilae> but it doesn't use minicli right?
[04:22] <OculusAquilae> i only think of minicli at the moment
[04:23] <\sh> OculusAquilae: honestly i don't know..if it's installed by default from kdelibs, it has this feature after install of edubuntu
[04:23] <OculusAquilae> im additionally of the opinion that programs like adept should show up in the menus of normal users
[04:23] <\sh> OculusAquilae: adept should not show up in the menus of normal users..
[04:24] <OculusAquilae> right
[04:24] <\sh> OculusAquilae: a change of behaviour of becoming administrator will confuse the user much more...leave it the way it is..well...actually adept needs more love in UI and handling
[04:24] <OculusAquilae> i meant that :-)
[04:26] <OculusAquilae> additionally it would partly solve the problem that the minicli user change option doesn't work for normal users
[04:26] <OculusAquilae> it only accepts the root-password
[04:26] <OculusAquilae> :-)
[04:26] <OculusAquilae> i meant only if you are in admin
[04:31] <mornfall> tell me tell me
[04:32] <mornfall> what adept needs?
[04:33] <\sh> mornfall: a better UI...
[04:33] <OculusAquilae> mornfall: the things in the feature plan
[04:33] <\sh> mornfall: press the cursor down key continously and see
[04:34] <mornfall> \sh: cursor down key where?
[04:35] <\sh> mornfall: in the package list
[04:35] <\sh> mornfall: i showed it to Riddell during the conference
[04:35] <mornfall> well, it moves selection down and scrolls
[04:36] <\sh> if u press the cursor down key continously...the list cursor disappears, and the list is not scrolling :)
[04:36] <mornfall> oh, yeah, terrible
[04:36] <mornfall> that's because of doublebuffering and event compression, i suppose
[04:36] <\sh> the other things are speed, and layout
[04:36] <\sh> kynaptic which is crap is much faster...
[04:36] <mornfall> that's because it doesn't really do anything :)
[04:37] <\sh> and the layout e.g. for changing the sources.list should have a dialog box and not swapping the windows
[04:37] <mornfall> "should have" says who
[04:37] <\sh> the plain user
[04:37] <mornfall> you think it would be better, eg... i don't
[04:37] <mornfall> gah
[04:37] <mornfall> plain user
[04:37] <mornfall> who's that
[04:37] <mornfall> i don't buy into that
[04:38] <\sh> mornfall: lets say it like this...all people I know using kubuntu and trying to adjust their sources.list and clicking the close button instead of going back
[04:38] <OculusAquilae> :-)
[04:38] <mornfall> hmm, food, brb
[04:38] <mornfall> \sh: interesting i never heard the complaint before :-)
[04:39] <mornfall> either everyone but your friends keep it secret or it happens more among your friends than everywhere else...
[04:39] <mornfall> anyway, food now, really
[04:39] <\sh> mornfall: well...the users I know are coming from the windows world...I converted them all to use ubuntu or kubuntu...and even I have problems seeing where I am..I e.g. just thought, it was a dialog box
[04:45] <OculusAquilae> \sh: about a normal user doesn't wan't to be admin: If a user didn't want to run applications as a different user, we could completely remove "Run as different user"
[04:46] <OculusAquilae> or completely remove the Options in minicli
[04:48] <\sh> OculusAquilae: hmm....sure..realtime scheduling is only possible when it runs as root, right?
[04:48] <OculusAquilae> right
[04:49] <OculusAquilae> increasing priority too
[04:49] <\sh> so u have to change the UI actually
[04:50] <\sh> disable the last 2 options and enabling it actually only if run as admin is checked
[04:50] <OculusAquilae> yes
[04:51] <\sh> and run as admin and run as diff user should only be enabled when the user is in the admin group or in sudoers.conf
[04:51] <OculusAquilae> runas diff user could be enabled if you are normal user too
[04:52] <\sh> well..after a 5th and 6th thought..yes
[04:54] <Tm_T> python-qt3-gl: Depends: python (< 2.4) but 2.4.2-0ubuntu2 is to be installed
[04:54] <Tm_T> err
[04:54] <Tm_T> dapper
[04:55] <Tm_T> interesting
[04:55] <mornfall> back
[04:56] <mornfall> \sh: well, is there some actual survey resulting in "dialog boxes are good"?
[04:56] <\sh> mornfall: dunno....
[04:56] <mornfall> \sh: because from all the remotely-usability-related people i have heard that not using dialog boxes was good :)
[04:57] <mornfall> so this poses an interesting challenge
[04:57] <\sh> mornfall: but what do u think if we sit together with mvo and build an update-manager with a backend interface and 2 UI frontend interfaces?
[04:57] <mornfall> with the semi-obvious solution being that the window close action goes to normal mode instead of closing when in non-normal mode
[04:58] <mornfall> eventually popping up a dialog box asking which of the two you prefer (and do not ask again checkbox)
[04:58] <mornfall> \sh: what do you mean, sit with mvo?
[04:58] <mornfall> \sh: mvo promised he will branch synaptic to use libapt-front at some point
[04:58] <\sh> mornfall: well...for update manager and others there will be a change in UI anyways especially for the sources.list adjustements
[04:59] <mornfall> change in ui in which sense?
[04:59] <\sh> mornfall: mvo and I were talking about an update-manager for gnome and kde..which means we have to split the UI stuff out of the backend stuff (using python-apt)
[04:59] <\sh> mornfall: the naming conventions are changed and it should be easier for the user to select the ubuntu repositories
[05:00] <Riddell> \sh: the adept updater doesn't use python-apt
[05:00] <\sh> Riddell: i know :)
[05:00] <mornfall> \sh: in which case you will have to write the updater
[05:00] <mornfall> \sh: since i am not touching python with a 10 yard pole
[05:00] <mornfall> nor python-apt or pykde for that matter
[05:02] <mornfall> \sh: on another hand, when swig team gets around to make a release, we will have a single backend for both c++ and python software in libapt-front
[05:02] <\sh> mornfall: the question was in general to find a way to get ubuntu and kubuntu vital admin utils as close as it can be...means one source and at least 3 binary packages e.g. update-manager-be, ubuntu-update-manager, kubuntu-update-manager
[05:02] <mornfall> -be?
[05:02] <\sh> backend
[05:03] <mornfall> wha?
[05:03] <mornfall> doesn't make much sense to me
[05:03] <mornfall> neither why should it come from a single source package
[05:04] <mornfall> i guess you want checkboxes for sources.list selection
[05:04] <mornfall> anything else that currently adept-updater cannot do?
[05:04] <\sh> mornfall: update-manager-backend is only the logic behind all apt stuff...the frontends are only interacting with the backend...and this can be done with two python implementations one for gnome the other for kde
[05:04] <mornfall> what logic?
[05:05] <mornfall> adept udpater is 340 lines of C++, which is largely redundant and will be cut down considerably
[05:05] <\sh> mornfall: w8.i'll get the spec
[05:05] <mornfall> i don't see what there could be split into backend
[05:06] <\sh> https://wiki.ubuntu.com/RepositoryDialogRedesign
[05:06] <Riddell> \sh: adept{,-updater} uses libapt-front to abstract all the logic, it's synaptic that should be ported to that to get to what you propose :)
[05:08] <mornfall> \sh: http://rafb.net/paste/results/Ci6XuN79.html -- this is heart of the adept updater
[05:08] <Riddell> RepositoryDialogRedesign looks nice
[05:08] <mornfall> \sh: rest of the code is setting up the gui and stuff like that... parts of which will be cut down
[05:08] <\sh> Riddell: synaptic and update-manager are not using the same source...so synaptic needs to be fixed, right...update-manager is a separate python app..which needs a bit more love to have it separated between logic and ui
[05:09] <\sh> Riddell: that's why I wanted to have the same source base for ubuntu and kubuntu
[05:09] <\sh> Riddell: regarding this repo dialog
[05:09] <mornfall> \sh: so what logic exactly there is?
[05:09] <\sh> Riddell: the repo dialog is in gnome-software-properties
[05:10] <OculusAquilae> wasn't it planned to port synaptic to libapt-front?
[05:10] <\sh> mornfall: installing, updating, upgrading, reading changelogs etc.
[05:10] <mornfall> \sh: all that logic should be in libapt-front (and apart from reading changelogs, it's there for some time anyway)
[05:11] <mornfall> \sh: i guess i'm missing your argument, sorry
[05:11] <\sh> mornfall: again....update-manager is using python-apt which is libapt-front for python :)
[05:11] <mornfall> \sh: not at all
[05:12] <\sh> mornfall: sorry..libapt-pkg
[05:12] <mornfall> right
[05:12] <mornfall> and there are python bindings to libapt-front which can be used and already have most of the backend stuff you are talking about
[05:12] <mornfall> they are only waiting for swig to make a release
[05:12] <mornfall> right now
[05:12] <\sh> mornfall: the idea was not to reinvent the wheel again...and to share the work between the two UIs
[05:13] <\sh> mornfall: and to give the user a "similar" UI design for both desktop environments
[05:13] <mornfall> i am not reinventing the wheel, it's just that libapt-pkg has a sort of useless api (demonstrated by eg synaptic wrapping it in a rather big library that happens to be somewhat specific to synaptic)
[05:14] <mornfall> (and same goes to nearly every package manager out there having an own specific library)
[05:14] <mornfall> (and i am thinking that libapt-front is the first one to be shared by at least 2 otherwise independent projects)
[05:14] <mornfall> err 3
[05:14] <Riddell> mornfall: what's the other projects?
[05:14] <mornfall> Riddell: debtags and packagebrowser
[05:15] <Riddell> oh, cool
[05:15] <mornfall> oh and debtags-edit but that doesn't completely count
[05:15] <mornfall> (debtags-edit is a gtk ui for editing the debtags data)
[05:15] <mornfall> synaptic was promised to be ported as well
[05:16] <mornfall> so maybe update-manager should follow too, instead of rewriting all that in python again?
[05:16] <mornfall> (now that would probably be reinventing wheels...)
[05:17] <\sh> mornfall: update-manager is python :)
[05:17] <OculusAquilae> \sh: and libapt-front will have a python interface, right?
[05:17] <mornfall> \sh: so it needs to reimplement all the logic that is bound to python because of what?
[05:18] <mornfall> \sh: or you imply that instead we should rewrite everything else in python so we don't reinvent wheels?
[05:20] <\sh> mornfall: the idea was to have one source base for the logic and two or more UIs attached to it...so we have only one source package for two or more flavours
[05:21] <mornfall> *sigh*
[05:22] <mornfall> can you explain *why*?
[05:22] <mornfall> why it needs to be single source package
[05:22] <mornfall> and what you mean with that "logic" again
[05:22] <mornfall> because all the logic you so far mentioned belongs at least one level down the chain
[05:22] <mornfall> and should be shared with package managers as well
[05:23] <mornfall> not only update managers
[05:23] <mornfall> what you propose obviously locks out synaptic and adept from using whatever "logic" there is
[05:23] <mornfall> (and any other tool that one may want to write)
[05:24] <mornfall> given libapt-front and swig bindings, you have all the logic in libraries that you can use from c++ *and* python (*and* ruby, at some point)
[05:24] <mornfall> so all the update managers *and* package managers *and* other tools can use it
[05:25] <mornfall> *and* it is not specific to (k)ubuntu so plain debian tools can use it as well
[05:25] <\sh> mornfall: we have right now different ui approaches for the same things...regarding sources.list adminstration, update managers etc. to make it as easy as it can for the users who are switching desktops we should avoid different ui approaches..
[05:26] <mornfall> \sh: now, IMHO, that's bs
[05:27] <mornfall> \sh: in that case, just use bluecurve and write the tools only once and they will be identical
[05:27] <mornfall> \sh: that's about what you want, anyway, no?
[05:27] <\sh> mornfall: which was also an idea :)
[05:30] <mornfall> in the end, i'm glad i'm not using kubuntu (it's enough that i have to fight this on fedora...)
[05:31] <Riddell> you use fedora?
[05:31] <mornfall> i work for redhat
[05:31] <\sh> hehee
[05:31] <mornfall> at work i use fedora
[05:31] <mornfall> at home debian
[05:31] <\sh> I worked for redhat :) and that's why i'm not using fedora
[05:32] <mornfall> i eventually add rpm support to libapt-front and make adept work on it as well
[05:32] <\sh> mornfall: what u want is "smart"
[05:32] <\sh> mornfall: which will be used eventually for dapper +1
[05:33] <OculusAquilae> hm
[05:33] <mornfall> \sh: heh, no
[05:33] <OculusAquilae> don't like smart
[05:33] <mornfall> \sh: it may be used, but i won't use it
[05:33] <mornfall> it's sort of like yum
[05:33] <mornfall> and yum is the worst mistake i have seen so far
[05:33] <\sh> mornfall: well....it's decided already as I understand mark :)
[05:34] <mornfall> \sh: i don't care, i don't use ubuntu anyway :)
[05:34] <Riddell> it's not decided, it's an idea
[05:34] <\sh> Riddell: u know mark :) if he wants something :) he's the sabdfl :)
[05:34] <mornfall> smart is in python
[05:34] <\sh> yes
[05:34] <mornfall> and python is dumb
[05:34] <mornfall> not to mention slow
[05:35] <Riddell> \sh: mvo suggested you make a kde frontend to smart
[05:35] <mornfall> well, smart works around that by writing parts in C
[05:35] <\sh> Riddell: WHAT?
[05:35] <mornfall> yeh, good idea
[05:35] <OculusAquilae> for small things python is nice
[05:35] <mornfall> \sh: go ahead :)
[05:35] <mornfall> OculusAquilae: i find octave better for arithmetic thanks ;-)
[05:35] <\sh> Riddell: well actually I was pissed, that smart has only a gtk front
[05:35] <OculusAquilae> (but a package manager is to my mind not "small")
[05:36] <mornfall> there're really few python/kde coders out there
[05:36] <mornfall> so you will have to do it yourself
[05:36] <mornfall> even kde apt frontend had to be written by someone outside kubuntu
[05:36] <mornfall> and for me, smart is not an option
[05:37] <\sh> mornfall: is fedora using now apt4rpm as default?
[05:37] <mornfall> \sh: no, yum
[05:37] <mornfall> \sh: another python package manager
[05:37] <Riddell> \sh: sounds like you're the man for the job.  apparantly it's really easy since smart is python and has all the logic in it
[05:37] <\sh> mornfall: hmmm...in combination with RHN?
[05:37] <mornfall> \sh: i would prefer installshield though, it's lots faster
[05:38] <mornfall> \sh: no, RHEL is using up2date
[05:38] <mornfall> \sh: i guess we don't dare to unload the load of crap yum is on paying customers
[05:38] <\sh> mornfall: btw..is spot still working for RH?
[05:38] <mornfall> spot = ?
[05:39] <Riddell> mornfall: \sh used to work for red hat, but presumably in a different country
[05:40] <\sh> mornfall: I don't know his realname anymore..he was sitting at raleigh/durham in the nerd department :) I think he was working for 3rd support when I was visiting RH HQ
[05:40] <\sh> Riddell: EMEA yes :)
[05:41] <\sh> Riddell: together with harald hoyer, who is doing a lot of fedora stuff nowadays
[05:41] <mornfall> ok this doesn't matter and i have a polynomial group to find a generator for
[06:01] <\sh> Riddell: i'll have a look at smart later during this cycle
[06:46] <LeeJunFan> wouldn't it make sense to have artsd startup somehow during init bound to <IP_ADDRESS> with network enabled so multiple logins can all have sound or has this been hashed over before already?
[06:48] <Riddell> LeeJunFan: network would add lag (even localhost), and mostly multiple logins are ok either because the sound card driver can handle multiple programs or because arts lets go of the sound card after 60 seconds
[06:48] <LeeJunFan> if course then there's the problem of having an administator mode configurator for arts.
[06:48] <Tm_T> Riddell: using dapper ?
[06:48] <Riddell> Tm_T: hmm?
[06:48] <Tm_T> Riddell: found interesting thing when compiling kopete
[06:48] <Tm_T> in breezy, all fine
[06:49] <Tm_T> dapper... well, trouble with visibility
[06:49] <Tm_T> let's see if one # fixes it :p
[06:50] <Riddell> Tm_T: kopete 3.5rc1 compiled fine for me
[06:50] <Tm_T> Riddell: ah yes, dev-0.12 branch here :p
[06:50] <Tm_T> http://kubuntu.pastebin.com/427962
[06:51] <Tm_T> and one before
[06:51] <Riddell> Tm_T: that's not visibility, that's just gcc 4 being fussy
[06:52] <Riddell> or something
[06:52] <Tm_T> ah
[06:52] <Tm_T> Riddell: well, Darkshock said it might be it
[06:53] <Tm_T> ah yes, same error again
[06:53] <Tm_T> Riddell: hmm, any fixes?
[06:54] <Riddell> Tm_T: use 3.5?
[06:55] <Tm_T> hmh
[06:55] <Tm_T> have to try
[07:04] <verwilst> arts should die a violent death :p
[07:04] <Riddell> verwilst: if you use beta 2 it usually does
[07:04] <verwilst> hehe
[07:05] <verwilst> i'll be glad that kde 4.0 is here for soo many reasons :p
[07:07] <Tm_T> heh
[07:08] <Tm_T> http://img334.imageshack.us/my.php?image=kopetekde3kde4sidebyside5qc.jpg
[07:08] <Tm_T> KDE4 is here ;)
[07:08] <Tm_T> no, that's not my desktop
[07:11] <author-psi> Tm_T: looks like my desktop :P kde 3.4.3
[07:11] <Tm_T> heh
[07:12] <Tm_T> I'm using rc1
[07:13] <author-psi> im not the big fan of beta..
[07:14] <Tm_T> heh
[07:19] <author-psi> Tm_T: hehe how often you reinstall your system :D
[07:19] <Tm_T> my Kubuntu? not once
[07:20] <Tm_T> I even find apps working better in "unstable" branch than stable releases
[07:20] <verwilst> kde always looks clunky :$
[07:20] <verwilst> i hope it'll be solved with kde 4 :p
[07:22] <Tm_T> clunky?
[07:24] <Tm_T> I don't understand
[07:25] <author-psi> me2
[07:27] <Tm_T> Riddell: yup, different gcc and things working ok
[10:45] <mae> is it true that MS wants to make kubuntu rock more now? :)
[10:46] <Riddell> mae: Mark Shuttleworth does, Microsoft doesn't :)
[10:47] <mae> yes
[10:47] <mae> well - i assumed you would not think M$ wants to make kubuntu rock
[10:47] <mae> kde has a lot of potential but its missing alot of the nice automagic features that the current ubuntu gnome has
[10:48] <Riddell> mae: any specific examples?
[10:48] <mae> well you know - the nice extensions that ubuntu wrote for synaptic
[10:49] <mae> um - digikam doesn't autodetect cameras nicely like gthumb
[10:49] <Riddell> mae: specific example would help here, so we can write them
[10:49] <mae> the autoupdate applet
[10:50] <Riddell> we do have adept-updater, we just need a thingy to poke the user when updates are needed
[10:50] <mae> Riddell: do you work for canonical?
[10:51] <Riddell> which we will get in dapper with any luck
[10:51] <Riddell> mae: I'm contacted (until the end of the week)
[10:51] <mae> contracted?
[10:51] <mae> :P
[10:54] <Riddell> mae: yes
[10:54] <Riddell> mae: broodwar?
[10:54] <mornfall> Riddell: how, until end of the week?
[10:54] <mae> starcraft
[10:55] <mornfall> starcraft is a wicked game
[10:55] <mae> who wrote adept?
[10:55] <mornfall> mae: i did
[10:55] <Riddell> mornfall: well it runs out at the end of the week, I suppose I should ask what happens after that
[10:55] <mornfall> Riddell: hmm, i guess you should have it prolonged :)
[10:55] <mae> when did you write it?
[10:57] <mornfall> mae: august till breezy release, cca
[10:57] <mornfall> august and september, basically
[10:57] <mae> ah
[10:58] <mae> have you considered swiping some of synaptics icons ?
[10:58] <mae> or are you trying to keep it BSD pure
[10:58] <mornfall> mae: it's not bsd pure, given it uses libapt for now (which is gpl)
[10:58] <mornfall> mae: (and for forseeable future it will)
[10:58] <mornfall> as for icons, i am not sure they fit kde though
[10:58] <mae> heh
[10:59] <mae> well i meant for the columns -- like where it says 'installed'
[10:59] <mae> etc
[11:00] <mornfall> yes, and those are pretty gtkish :-)
[11:00] <mae> heh
[11:00] <mae> I like gtkish :\
[11:01] <mornfall> when i get around to use icons for states (not critical, color coding seems to work better anyway), you will probably be able to swap them with a theme :-)
[11:01] <mae> ic
[11:02] <mae> well it looks nice!
[11:02] <mornfall> i mean, how often you look at icons in say kmail to see if a message is new/seen/...
[11:02] <mae> synaptic is more feature-complete right now
[11:02] <mornfall> they look to me like a decoration
[11:02] <mornfall> of course
[11:02] <mae> i think it depends on the person -- i can recognize icons much faster once i get used to them.
[11:02] <mornfall> it wasn't written in 2 months, either x)
[11:03] <mae> mornfall: oh -- that wasn't meant to be a negative comment -- rather I'm just critiquing
[11:03] <mae> its very good for the time you put into it so far
[11:03] <mornfall> it intends to beat everything else, eventually x)
[11:03] <mae> good
[11:04] <Riddell> mae: if you have specific features that you miss that's useful to know
[11:04] <mornfall> mae: check http://web.ekhis.org/adept.html for the current feature plan
[11:04] <mae> already been there :)
[11:04] <mornfall> mae: anything you would add to it? :)
[11:05] <mae> it looks pretty complete
[11:05] <mae> the individual .deb install would be very nice -- but i think it should be decoupled from adept -- rather have a generic interface and the two access apt through it.
[11:05] <mornfall> mae: everything in adept is decoupled and this won't be different
[11:06] <mornfall> mae: all the generic features are in libapt-front
[11:06] <mae> ah
[11:06] <mornfall> write a library that will make writing your program easy first :)
[11:06] <mae> is it written in C++?
[11:06] <mornfall> yes
[11:06] <mae> ah
[11:07] <mornfall> libapt-front is covered with unit-tests fairly well
[11:07] <mae> ic.
[11:07] <mae> is adept mostly qt4 ready?
[11:07] <mornfall> i don't think so, and the bump won't come before adept 3.0
[11:08] <mae> mornfall: one thing about the individual deb install
[11:08] <mornfall> substantial part of libept (adept's own library, mostly generic GUI elements) is concerned with intimate listview fiddling :)
[11:09] <mornfall> and listviews changed a lot in qt 4
[11:09] <mae> a nice feature would be when you install non-repo debs that it would automatically grab the dependencies if available in the repo
[11:09] <Riddell> qt4 would be nice for the faster list handling, but it would mean loosing KDE stuff for now
[11:09] <mornfall> Riddell: i don't think i'll go with pure-qt
[11:09] <Riddell> agreed
[11:09] <mae> best idea is to bump when kde upgrades their libs?
[11:09] <mae> :)
[11:10] <mornfall> mae: for non-repo debs, well, that's given, no? :)
[11:10] <mornfall> mae: (i mean, that's the whole point of it...)
[11:10] <mae> mornfall: right :)
[11:11] <mornfall> ah, and if you break it, you gotta keep both pieces
[11:11] <mornfall> mae: do you know Enrico Zini?
[11:11] <mae> no.
[11:12] <mornfall> he helped out with libapt-front, specifically debtags parts of it (given enrico wrote debtags and ported the debtags utilities over to libapt-front as we were doing it)
[11:13] <mae> nice
[11:13] <Riddell> mornfall: what's the status of debtags in debian now?  is it part of the debs?
[11:13] <mornfall> there's one unfortunate thing with libapt-front... doxygen and older compilers all choke on it...
[11:13] <mae> :\
[11:14] <mornfall> well, doxygen doesn't specifically choke, it just produces trash output
[11:14] <mornfall> and gcc 3 doesn't seem to be able to compile it either
[11:14] <verwilst> gui i mean
[11:14] <mornfall> verwilst: another one, huh? :)
[11:14] <verwilst> mornfall, well, adept seems pretty nice..
[11:15] <verwilst> but i don't really like the gui
[11:15] <verwilst> way too complex :$
[11:15] <mornfall> what would you prefer?
[11:15] <mornfall> it's still lot simpler than say synaptic
[11:15] <verwilst> i like something like this better : http://www.kde-look.org/content/pre1/24793-1.jpg
[11:15] <verwilst> mornfall, well this one isn't perfect either
[11:15] <verwilst> but it's more like it ;)
[11:15] <mornfall> verwilst: okey, that's not really a package manager
[11:16] <verwilst> yeah i know
[11:16] <mae> I think the interface is nice -- but i agree with verwilst -- I think that at least the search interface is a bit complex
[11:16] <verwilst> but it's the idea ;)
[11:16] <mornfall> verwilst: but yeah, something like it shouldn't be hard on top of libapt-front (and libept, eventually)
[11:16] <verwilst> mornfall, that was my plan ;)
[11:16] <mae> I like the search interface of synaptic better
[11:16] <mae> and how it had the categories on the left
[11:17] <mornfall> mae: categories utterly don't scale
[11:17] <verwilst> idd
[11:17] <mae> maybe with searching if you don't like dialogs you could do something like FF where ctrl-f or toggles the search box at the bottom of the window
[11:17] <mae> or \/ rather
[11:17] <verwilst> mornfall, what's libept?
[11:17] <mornfall> mae: i think searching is one of the very central concepts of package management
[11:17] <mae> argh you know front slash like vi
[11:17] <mornfall> verwilst: the library between adept and libapt-front
[11:18] <mornfall> mae: yes, but right now, the absolutely most common pattern in #kubuntu seems to be "type <x> into adept"
[11:18] <verwilst> mornfall, is it qt or plain c++?
[11:18] <mae> mornfall: it is.. ok forget about the categories -- you know it wasnt just categories that synaptic has on left it has sections status etc. i liked how i could just click on local or obsolete and see all my residual stuff
[11:19] <mornfall> mae: oh yeah, that will surely come
[11:19] <mornfall> mae: all with a sidebar x)
[11:19] <mae> ok :)
[11:19] <mornfall> mae: (which may or may not be hidden by default, i'll contemplate :)
[11:19] <verwilst> mornfall, adept is good for power-users
[11:19] <mae> mornfall: and a shortcut for focusing on the quick search box would be nice -- like ctrl-f or a front slash
[11:19] <verwilst> but normal joe schmoe users are sooo lost :$
[11:20] <verwilst> and is there something like update-notifier in the works for kde?
[11:20] <mornfall> mae: the add filter thingy will eventually work via d&d from the sidebar or something like that... the "easy tag filter" will eventually go away and be replaced by a smart search tab in the sidebar
[11:21] <mae> ah
[11:21] <verwilst> http://www.kde-look.org/content/show.php?content=29426
[11:21] <verwilst> suhweet
[11:21] <mornfall> mae: anyway, this is for long thinking and i am not in that state right now :)
[11:21] <mae> heh
[11:22] <mornfall> i am glad i managed to make this galois field code work as it was intended to and all :)
[11:22] <Riddell> mae: that's moodin engine, which we'll probably use in dapper
[11:22] <Riddell> verwilst: rather
[11:22] <mornfall> moodin huh?
[11:23] <Riddell> ksplash engine
[11:23] <mae> hmm
[11:23] <mornfall> everything is "moodin" these days eh?
[11:23] <verwilst> Riddell, http://www.kde-look.org/content/show.php?content=16962
[11:23] <mornfall> wasn't a new amarok thingy called like that?
[11:23] <mae> I just wish kde wasn't so damn flashy
[11:23] <verwilst> Riddell, lots of rubberband speedups lately ;)
[11:23] <verwilst> Riddell, yeah, mooding rocks :$
[11:23] <verwilst> moodin :p
[11:24] <Riddell> verwilst: that hasn't been updated since Nov 04
[11:24] <verwilst> it's the 13th :p
[11:24] <verwilst> oh
[11:24] <verwilst> haha
[11:24] <verwilst> stupid me :p
[11:24] <verwilst> nm then :p
[11:24] <verwilst> rubberband still is a bit slow
[11:25] <mae> I want my gecko engine for konq!
[11:25] <mornfall> i consider the rubberband patch too intrusive to be applied externally
[11:25] <mornfall> eww gecko, as if konq wasn't slow enough already
[11:25] <mae> lol
[11:25] <mornfall> whatever =)
[11:26] <mae> at least it doesn't choke on some sites
[11:26] <mornfall> let me have my broodwar
[11:26] <mornfall> i let you have your gecko or whatever lizards you want
[11:26] <mae> no one cares about technical purity if the damn thing doesnt work
[11:26] <mae> lol
[11:26] <mae> ok -- i need to install that on my puter again
[11:26] <mae> i'll have to play you sometime
[11:26] <mornfall> hehe :)
[11:26] <mornfall> i'll be hanging around
[11:27] <mornfall> pvpgn works with broodwar+wine these days
[11:27] <mornfall> (pvpgn the unofficial battle.net)
[11:27] <mae> that rocks
[11:27] <mae> i just wish i still had my bw
[11:27] <mae> i lost my cds
[11:27] <mae> ebay
[11:27] <mornfall> i have tarball x)
[11:27] <mae> i am absolutely addicted to yakuake
[11:28] <mae> mornfall: send it!
[11:28] <mae> i will roxor you with my hydralisks
[11:29] <mornfall> x)
[11:29] <mornfall> carriers own
[11:29] <mae> wha?
[11:29] <mae> since what patch
[11:29] <mornfall> no idea :)
[11:29] <mornfall> i guess since always :)
[11:29] <mae> you play with your carriers
[11:29] <mae> i'll roxor them with hydras
[11:29] <mae> lol
[11:30] <mornfall> hydras cannot fly over water x)
[11:30] <mae> doesnt matter
[11:30] <mae> they will waste your carriers
[11:30] <mornfall> and well, dark templars + reavers own too x)
[11:30] <mae> and then it takes you a long time to build them again
[11:30] <mae> you kill my hydras and i can amasse another army in less than a min
[11:31] <mornfall> but then, i haven't played against humans in ages
[11:32] <mornfall> good hunter killers cannot be created x)
[11:33] <mornfall> but then, i was never en-masse player, in any game
[11:33] <mornfall> well, apart from masses of interceptors ;-)
[11:34] <jjesse> ping Riddell
[11:35] <Riddell> jjesse: yo
[11:40] <Riddell> jjesse: yo
[11:40] <jjesse> Riddell: kubuntu docs should they be published on help.ubuntu.com?
[11:41] <Riddell> jjesse: sure
[11:44] <jjesse> Riddell: can we then get the links on kubuntu.org/documentation.php linked to help.ubuntu.com?
[11:44] <jjesse> and the corresponding documentation?
[11:45] <Riddell> jjesse: yep
[11:45] <jjesse> Riddell: awesome thanks :)
[11:45] <Riddell> but I need to fix the stylesheets first presumably
[11:45] <jjesse> Riddell: yes you still do
[11:47] <Riddell> unfortunatly kde 3.5 got in the way of that so far
[11:48] <jjesse> Riddell: no worries on that
[11:48] <jjesse> Riddell: i'll just keeping bugging you like you asked me to do
[11:49] <Riddell> yes, do
[11:56] <mae> ehm
[11:56] <mae> what package do i need to enable vector graphics in kde
[11:57] <Riddell> mae: how do you mean?
[11:57] <mae> well
[11:57] <mae> none of these vector themes work
[11:57] <mae> that are included in kubuntu
[11:58] <Riddell> vector themes?
[11:58] <mae> "SphereCrystal" "Vector Them" shows up blank icons for me
[11:58] <Riddell> never heard of them
[11:59] <mae> o you know what
[11:59] <mae> I think its showing the gnome icons in here