[07:08] <mihir__> hello :)
[09:41] <JamesTait> Good morning all; happy Stress Awareness Day!  :-D
[12:20] <popey> Ubuntu Touch needs a chess app.
[12:23] <boiko> popey: awhile ago I wrote a Qt chess sample game that used gnuchess as the backend for the AI player
[12:24] <popey> you should totally port that ☻
[12:59] <boiko> popey: it requires C++ code to interact with gnuchess not sure how to adapt that to a click package
[13:01] <boiko> popey: http://git.gustavoboiko.org/cgi-bin/gitweb.cgi?p=chess.git;a=summary
[13:01] <dpm> boiko, you can compile the code to produce an arm binary and just put it in the click package. mzanetti has done that already for a few apps and can probably give you some pointers
[13:01] <boiko> dpm: interesting, I might try to do that when I find some spare time
[13:02] <boiko> popey: dpm: in case you want to check the code: http://git.gustavoboiko.org/cgi-bin/gitweb.cgi?p=chess.git;a=summary
[13:02] <dpm> (obviously you'll need to provide an interface from C++ to QML, e.g. make it a QML C++ extension)
[13:02] <boiko> yep, but that's fine probably
[13:03] <dpm> boiko, cool. I'm at a conference this week, will have a look next week, thanks for the link!
[13:26] <ogra_> *sniff*
[13:26] <ogra_> seems my music taste is to weird for eyrie ...
[13:38] <JoeyChan> Hi tmoenicke   this is Joey   the man who mentioned Chinese input method in the email
[13:46] <cwayne> woo! got charts working in my app with chart.js :D
[13:46] <cwayne> http://chrismwayne.com/weighttab.png
[13:47] <ogra_> geez you lost a lot in 4 days !
[13:47] <cwayne> lol not really, the scale is only like 2 pounds
[13:47] <ogra_> heh
[13:47] <cwayne> but i removed the scales so i'm not showing people how much i weigh :P
[13:48] <ogra_> lol
[13:48]  * ogra_ totally understands
[13:58] <davmor2> ogra_: eyrie doesn't like my music either :(
[14:04] <davmor2> ogra_: not even tubular bells
[14:04] <ogra_> probably a bug
[14:05] <davmor2> ogra_: it is if it can't find tubular bell :D
[14:05] <ogra_> or it only knows the 90s or some such :)
[14:05] <davmor2> ogra_: yeah it knows every song from 1990 to 1991
[14:05] <ogra_> see :P
[14:11] <aquarius> popey, where should I be hanging out for listening to the design app clinic?
[14:11] <davmor2> aquarius: ubuntu-on-air ?
[14:11] <aquarius> aha, that sounds likely
[14:17] <davmor2> ogra_: hmmm apparently echonest.com has quite a large music sample library so I don't think it is that some how
[14:30] <aquarius> davmor2, not quite
[14:30] <aquarius> The Echo Nest have two databases of song fingerprints: the old one using ENMFP, and the new one using echoprint.
[14:31] <aquarius> ENMFP was a closed-source fingerprinting tool; echoprint is open source.
[14:31] <aquarius> Eyrie uses echoprint.
[14:31] <aquarius> The ENMFP database has about thirty million songs in it.
[14:31] <davmor2> aquarius: ah okay
[14:31] <aquarius> The echoprint database has about one million songs in it.
[14:32] <aquarius> What this means is that Eyrie doesn't find a lot of songs, not because it's Eyrie's fault but because the echoprint database is missing a lot of songs.
[14:32] <aquarius> the Echo Nest people have been promising to grow the echoprint database for a few years now :(
[14:34] <davmor2> aquarius: I'm surprised they don't allow users to just update the echoprint db save them having to, kinda like musicbrainz or whatever the track listing thing is
[14:34] <aquarius> they allow users to copy the echoprint database and run their own
[14:34] <aquarius> but not to submit things to the central echoprint db
[14:34] <aquarius> at least partially because, I suspect, they do not have the resources to check the data that's submitted.
[14:35] <aquarius> and you don't want someone submitting a fingerprint for the latest Ke$ha song and claiming it's All Along The Watchtower by Jimi Hendrix.
[14:36] <aquarius> crowdsourcing data like this is not good when someone's response to wrong data will be "I'll use shazam instead" rather than "I should submit a fix to this".
[14:36] <davmor2> indeed which is a shame really
[15:06] <danielholm> where is the doc of how to add screenshots to my click app?
[15:14] <danielholm> never mind
[15:43] <cwayne> hm, with the latest ui-toolkit, my tab titles disappeared
[15:47] <Elleo> davmor2: musicbrainz is planning on supporting echoprint fingerprints as part of their metadata, unfortunately they only have it on a test server at the moment
[15:48] <Elleo> once it's supported properly I'll shift to using the musicbrainz database in Eyrie instead of the one hosted by the echoprint guys
[15:52] <danielholm> validate click packages myself?
[15:52] <danielholm> how do I do that?
[15:53] <davmor2> Elleo: nice :)
[15:55] <popey> danielholm: http://launchpad.net/click-reviewers-tools
[15:55] <popey> danielholm: grab that
[15:55] <danielholm> from the ppa: ppa:ubuntu-sdk-team/staging ?
[15:55] <popey> no, bzr branch the above
[15:56] <danielholm> okay.
[15:56] <popey> then run bin/click-run-checks <foo.click>
[15:56] <Elleo> aquarius: if I was sneaky I'd run my own echoprint server and build fingerprinting into cutespotify, so I get reliable results harvested from spotify listeners :P
[15:57] <danielholm> popey: okay. got something.. hmm
[15:57] <Elleo> I did wonder about writing a quick program that did just try to finger print every spotify thing it could find, but programs that aren't used by people listening to stuff violates their ToS
[15:57] <aquarius> Elleo, yeah. It did occur to me that having the Ubuntu music app harvest fingerprints would crowd-source a library prety quickly, except that a few people would go nuts about it and so it'd never happen.
[15:58] <Elleo> I might add it as an optional tick box in cutespotify
[15:58] <Elleo> although I'm not sure my little VM would really be up to running an echoprint server
[15:58] <danielholm> popey: same thing as you, obviously (duh) but unsure what it meant. I do have a string in the comment..?
[15:59] <popey> danielholm: Comment=
[16:00] <popey> thats blank in your .desktop file
[16:00] <Elleo> although I suspect secretly buffering a whole song to genreate a fingerprint from might violate spotify's ToS too
[16:00] <popey> danielholm: you can just delete that line
[16:00] <aquarius> Elleo, you could harvest the fingerprints there and then once you've got loads, work out how to spin up a fingerprint server to serve fingerprints.
[16:00] <danielholm> popey: aha, I dont need it?
[16:00] <aquarius> but I suspect that scanning a whole library would be better than only the songs that get listened to
[16:01] <popey> danielholm: no
[16:01] <danielholm> and how do I change my default email in QtCreator? I set the wring one
[16:01] <danielholm> popey: thanks!
[16:01] <popey> danielholm: not sure in qtcreator, maybe mhall119  knows
[16:02] <popey> Elleo: i would happily leave my spotify playing all day if it helped fingerprinting. not that they need fingerprints of the same daft punk cd 50 times
[16:02] <Elleo> heh
[16:02] <Elleo> I might see if I can get in touch with spotify and see if they'll grant me some sort of exception for this sort of thing
[16:03] <mhall119> danielholm: popey: I'm not sure either, bzoltan1 should though, or someone on his team
[16:10] <danielholm> mhall119: ok, thanks
[16:24] <randomcpp> is there already a webdav file manager app?
[16:28] <bzoltan1> danielholm: do you mean in the packaging info? that comes from your bzr identity
[16:29] <danielholm> bzoltan1: aha, crap.. need to update that then
[16:29] <danielholm> thanks
[16:29] <bzoltan1>  danielholm: np
[16:44] <cwayne> does anyone else have disappearing tab titles with today's ui-toolkit?
[16:54] <aquarius> bzoltan1, what happens if you don't have a bzr identity? Most ubuntu app devs won't have one
[16:55] <t1mp> cwayne: the header is supposed to hide now when you interact with the app contents. scroll down to get it back
[16:55] <t1mp> cwayne: um.. swipe down to scroll up to get it back I mean
[16:56] <t1mp> cwayne: probably it is this "fix" you are talking about
[16:56] <t1mp> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1223604
[16:56] <ubot2> Launchpad bug 1223604 in Ubuntu UX "Close tabbar and toolbar when user interacts with app contents" [Critical,Fix committed]
[16:56] <cwayne> that seems.. very wrong to me..
[16:56] <cwayne> it doesnt hide the tabbar, it just blanks it
[16:57] <cwayne> and what if i want to know what tab im in?
[16:57] <t1mp> cwayne: if it blanks the tabbar instead of hiding it, then that is a bug :(
[16:58] <cwayne> t1mp: yeah, that's what it does for me at least in today's -proposed image
[17:00] <t1mp> cwayne: can you report a bug here? http://bugs.launchpad.net/ubuntu-ui-toolkit please mention the app (or paste your code) that shows this to reproduce the issue
[17:00] <t1mp> thanks in advance
[17:03] <t1mp> cwayne: if you assign me (tpeeters) to the bug I will have a look tomorrow. gotta go now
[17:04] <cwayne> t1mp: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1248631
[17:04] <ubot2> Launchpad bug 1248631 in Ubuntu UI Toolkit "Tabbar is not hidden, but blanked, when user interacts with app" [Undecided,New]
[17:04] <cwayne> sure thing, will assign to you :)
[17:05] <cwayne> erm, it won't let me assign you.. weird
[17:07] <t1mp> cwayne: I assigned myself. I'll verify it tomorrow.
[17:07] <cwayne> t1mp: great, thanks!
[17:33] <mrqtros> Hello everyone!
[17:33] <mrqtros> popey ping :)
[17:33] <popey> yo
[17:42] <mrqtros> popey how can we update our Shorts app in store? :)
[17:43] <mrqtros> popey I've done a lot of improvements and optimizations, now app is ready to be published :)
[17:43] <mrqtros> popey *new version ready
[17:43] <popey> awesome!
[17:45] <mrqtros> popey should we build click package? :)
[17:45] <mrqtros> popey or how we can update it? :) I have no any ideas :)
[17:45] <popey> mrqtros: am on the phone at the moment, might be worth asking sergiusens in #ubuntu-touch as he builds the click packages and puts them in the store
[17:46] <mrqtros> popey thanks!
[18:11] <bzoltan1>  aquarius:  in that case you have to fill the fields manually ... using the bzr identity is more like  a help. The developers are free to change those fields
[18:12] <bzoltan1>  aquarius: as it is well explained in the docs .... _NOT_ :D
[18:13] <aquarius> bzoltan1, ah, cool. It might be nice if it picked up my Ubuntu One identity from Online Accounts rather than my bzr identity?
[18:13] <aquarius> since you have to sign in to the uploader with U1 :)
[18:14] <aquarius> (they are the same thing, mostly, of course, but more developers will have a U1 identity because they have to.)
[18:14] <bzoltan1> aquarius:  not a bad idea ... actually the QtC should offer you to choose from various identities ... one could be the the U1 of course
[18:14] <bzoltan1> bzoltan1:  how to get the U1 identity?
[18:15] <aquarius> online accounts has it. Not sure how to get stuff from online accounts, but there are qml bindings to it, so it's possible. mardy will know :)
[19:27] <mhall119> bfiller_afk: bzoltan1: we have a few slots let in the AppDev track for the upcoming UDS, is there something either of your teams would like to get added to the schedule so we can discuss it?
[19:28] <mhall119> aquarius: bzoltan1: Online Accounts API docs: http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.OnlineAccounts/
[19:28] <mhall119> could use a how-to page, just like Friends, but it's something
[19:29] <mhall119> aquarius: I haven't seen you propose an appdev session, and I *know* you have opinions on the matter ;)
[19:39] <bfiller> mhall119: working on the sessions now, will let you know
[19:40] <mhall119> thanks
[19:48] <cwayne> anyone successfully setup a Picker?  mine's always blank
[20:15] <project245> can anyone helo with a query?
[21:46] <mhall119> beuno_: why http://summit.ubuntu.com/uds-1311/meeting/22082/click-software-store-status-and-future-development/ is not a blueprint?
[21:58] <beuno_> mhall119, what does that get me?
[22:00] <mhall119> beuno: work item tracking and a spot on status.ubuntu.com
[22:00] <mhall119> if you don't need those things, then I'll approve it and we'll see where we can schedule it
[22:01] <beuno> mhall119, I have my own tracking atm


[00:01] <lifeless> ronny: put it in .bzrmeta/yourapp - make that a file that records what you need for each fileid
[00:01] <lifeless> ronny: we don't have a scalable lookaside engine for arbitrary metadata
[00:02] <lifeless> ronny: or put the metadata in the files - what metadata is needed for moin ?
[00:02] <ronny> its arbitrary key value storage per revision of an item
[00:03] <ronny> a revlog based backend is on my todo, they already have a normal hg one (metadata in the file tree), a anyvc one based on that is also on my todo
[00:04] <lifeless> ronny: what keys and values?
[00:04] <ronny> keys are strings, values are strings/lists of strings
[00:04] <lifeless> so you could do metadata in the file tree easily with bzr too
[00:05] <lifeless> what query patterns are used on the metadata
[00:05] <ronny> moinmoin will index the metadata
[00:06] <ronny> lifeless: file level metadata i can keep track of would be rather nice, practically versioned xattrs
[00:06] <lifeless> so - a full scan - how often ?
[00:06] <lifeless> does it do partial scans? when? do they read the current file content at the same time?
[00:07] <ronny> it will keep a separate index, it doesnt have to read file data for metadata indexing
[00:07] <lifeless> thats a disk index ?
[00:08] <ronny> yes
[00:08] <lifeless> heh
[00:08] <lifeless> sounds like there is duplication there, then.
[00:08] <ronny> well, the cache is there to make querying fast, its discardable
[00:10] <ronny> so the storage doesnt have to deal with metadata indexing/querying, just storage/retrival
[00:14] <ronny> lifeless: so its not really duplication, its just speed-up for disk space
[00:19] <pickscrape> If I upgrade a shared repository from pack-0.92 to rich-root-pack, do I need to do anything with the branches in that repository?
[00:19] <bob2> can you go all the way to the 2a format?
[00:19] <pickscrape> Not in this case
[00:20] <pickscrape> We are actually moving to 2a, but need to keep an older format mirror around to allow for out debian-bound sysadmins who are seemingly opposed to upgrading anything :)
[00:21] <pickscrape> But in order to be able to mirror from 2a, we need rich root
[00:24] <pickscrape> Hmm, a test conversion seems to suggest that I don't need to do anything with the branches...
[00:24] <pickscrape> In fact, bzr complains if I try to. Well, that makes the instructions easier. :)
[00:28] <sven_oostenbrink> Does bzr recognize symlinks?
[00:28] <sven_oostenbrink> what if I use symlinks pointing to directories inside and / or outside bzr WTs?
[00:29] <pickscrape> It will still version control the symlink AIUI.
[00:29] <sven_oostenbrink> AIUI?
[00:29] <pickscrape> As I Understand It
[00:30] <sven_oostenbrink> pickscrape: And what if I have a symlink to a directory within the WT? Will that directory be VCSed twice?
[00:31] <pickscrape> The symlink will be version controlled as a symlink, and nothing else. So effectively its content will be a string
[00:31] <sven_oostenbrink> pickscrape: that should be perfect.. thanks!
[00:32] <sven_oostenbrink> pickscrape: bzr st . also shows it ending with an @, so it recognizes it..
[00:32] <pickscrape> sven_oostenbrink: yes, that makes it nicely clear :)
[00:34] <sven_oostenbrink> bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50'
[00:34] <sven_oostenbrink> reason: The file id was deleted but its children were not deleted.
[00:34] <sven_oostenbrink> Possible bzr bug? bzr: ERROR: An inconsistent delta was supplied involving 'lib.je/php-ext/resources/ext-2.0.2', 'ext2.0.2-20100106002643-5jhck8c23hf464tt-50' reason: The file id was deleted but its children were not deleted.
[00:34] <shodan45> I'm trying to "easy_install bzr" on a centos5/rhel5 box, but get compile errors. Is this a known problem?
[00:34] <pickscrape> sven_oostenbrink: That doesn't look good :)
[00:35] <sven_oostenbrink> pickscrape: nah, found it already, my bad :)
[00:35] <sven_oostenbrink> fixed
[00:35] <pickscrape> sven_oostenbrink: was a directory replaced by a symlink under bzr's nose there?
[00:36] <sven_oostenbrink> pickscrape: not really... added tree, removed (with rm) a sub dir, then bzr remove --keep tree
[00:37] <sven_oostenbrink> pickscrape: ow, better even, the sub dir was replaced with that symlink yeah... man, Im messing up here!
[01:14] <neoTheCat> how can i restore an accidently deleted file if i am using the centralized repository?
[01:15] <neoTheCat> in svn, i was able to do an "svn update", and it would pull any missing files from the directory?
[01:15] <neoTheCat> thanks...
[01:15] <gutworth> bzr revert
[01:15] <bob2> bzr revert filename
[01:24] <neoTheCat> thanks.
[02:43] <mac9416> How can I clear a branch of everything without deleting it?
[02:43] <gutworth> clear of changes you mean?
[02:44] <mac9416> Yep.
[02:44] <gutworth> bzr revert
[02:44] <mac9416> I'm new to bzr BTW, so don't beat me up.
[02:44] <mac9416> OK, thanks. :-)
[02:44] <mac9416> Hmmm, that didn't remove all the commits.
[02:45] <_Andrew> Hi guys, I'm checkout out a copy of our bzr repo and it's so slow. They have 400 commits and over 1.6 gig in the repo. Is there anyway to make the checkout process faster?
[02:45] <_Andrew> We have**
[02:46] <gutworth> mac9416: bzr uncommit then, but be careful
[02:46] <gutworth> _Andrew: what protocol?
[02:46] <_Andrew> from file.. it is checking out on the same machine
[02:47] <mac9416> gutworth, how do I uncommit a _lot_ of revisions?
[02:47] <gutworth> do you have a shared repo?
[02:47] <gutworth> mac9416: why do you want to do that?
[02:48] <mac9416> gutworth, the short story is that I pushed 88 revisions to an empty branch that I should have branched, merged the code into and pushed.
[02:48] <mac9416> So now I have 88 revisions I want to get rid of so I can do it right.
[02:49] <mac9416> gutworth, the project I work on has very loose bzr rules. Small development team.
[02:49] <gutworth> try pulling from your own branch and giving -r
[02:49] <mac9416> -r?
[02:49] <_Andrew> shared between different users? Yes
[02:49] <gutworth> mac9416: specify a revision
[02:49] <gutworth> _Andrew: no, like bzr init-repo
[02:49] <mac9416> OK, I'll try.
[02:51] <_Andrew> I'm not sure
[02:51] <gutworth> if you branch within a shared repo, revisions don't have to be copied
[02:53] <mwhudson> mac9416: you can do bzr pull --overwrite -r -88 .
[02:55] <_Andrew> I'm using the bzr checkout command ?
[02:57] <mac9416> mwhudson, that got it. Thanks.
[02:57] <spiv> _Andrew: checkouts can use shared repositories too.
[02:57] <mwhudson> mac9416: np
[02:58] <spiv> _Andrew: although perhaps you simply want "bzr checkout --lightweight"?
[02:58] <_Andrew> maybe, i'm not sure on what they all mean
[02:58] <spiv> _Andrew: basically, if it's on the same machine, you probably don't want to actually make second copy of the 1.6 gig of history.
[02:59] <_Andrew> ah yes
[03:00] <spiv> _Andrew: a lightweight checkout will simply point to an existing branch and repository (the repo is the bit that holds all that history), rather than copy it.
[03:00] <_Andrew> ah...
[03:01] <_Andrew> So it doesn't copy the .bzr data just the files
[03:01] <spiv> _Andrew: the other option mentioned is to make a shared repository with "bzr init-repo"... all branches (and heavyweight checkouts) created inside that repository will use the shared repository rather than keeping a standalone copy.
[03:01] <spiv> _Andrew: well, there will still be a .bzr directory, just less stuff in it :)
[03:01] <_Andrew> I think the first option is what I need
[03:02] <spiv> Yeah, sounds like it, if you want to use checkouts anyway.
[03:02] <spiv> If you want to keep multiple branches you may want a shared repository as well at some point, but worry about that when it happens :)
[03:07] <_Andrew> We have multiple branches too
[03:08] <_Andrew> for example we have different tags etc
[03:08] <spiv> Well, there's the 'bzr tag' command so you don't need branches for that.
[03:10] <spiv> A common way to work is to have a shared repository made with "bzr init-repo --no-trees", so that the branches in it don't have working trees automatically.
[03:11] <spiv> So you have a directory that has all your branches, and all those branches share a single repository so disk isn't wasted and making new branches is really fast, etc.
[03:11] <spiv> And then you might have a single lightweight checkout somewhere else, and you use 'bzr switch' to switch it to different branches depending on which one you're working on.
[03:12]  * spiv -> lunch
[03:16] <poolie> hello all
[03:16] <mac9416> bzr: ERROR: RemoteRepository(bzr+ssh://bazaar.launchpad.net/~keryx-admins/keryx/devel/.bzr/)
[03:16] <mac9416> is not compatible with
[03:16] <mac9416> CHKInventoryRepository('file:///home/mac9416/aaaaaa/.bzr/repository/')
[03:16] <mac9416> different rich-root support
[03:16] <mac9416> Pardon the paste. Any ideas?
[03:18] <gutworth> mac9416: you need to upgrade the remote repo apparently
[03:18] <poolie> mac9416: or, perhaps easier, rename it and push a new one
[03:19] <mac9416> Hmm, how do I upgrade the remote one?
[03:19] <mac9416> Because I'm kinda attached to the name.
[03:20] <mkanat_> mac9416: Maybe you could just rename the existing one and then push a new one with the same name.
[03:20] <gutworth> bzr push --overwrite
[03:20] <gutworth> (I believe)
[03:21] <mac9416> Overwrite didn't work. Same error.
[03:21] <mac9416> mkanat_, I'm sorry, I don't quite understand...
[03:21] <mac9416> Perhaps bzr upgrade <branch> ?
[03:25] <RAOF> bzr upgrade $BRANCH will work, yeah.
[03:25] <RAOF> It'll possibly take a while, though; it (still!) needs to download & re-upload everything :(
[03:25] <mac9416> lol, I was about to ask you if it was normal to take a while. :-)
[03:25] <mac9416> It's a fairly small branch.
[03:45] <poolie> jml: just what is bzr-tools-grep
[03:49] <mwhudson> poolie: it's an emacs thingy
[03:49] <mwhudson> it basically does the bzr ls | xargs grep thing into a grep-mode buffer
[04:31] <jml> poolie, what mwhudson said. the exact shell command it uses is in the email
[04:32] <poolie> mm
[04:32] <poolie> i thought it was a bzr alias or plugin
[05:10] <dOxxx> good evening
[06:12] <lifeless> jml: I disagree on cleanups
[06:12] <lifeless> jml: I hope I've made a convincing case in mail; please let me know if otherwise.
[07:17] <vila> hi all
[07:19] <vila> lifeless: I'm not sure I understand where you stand about cleanups, in one mail you said: "we should be able to reinstate that behaviour - it was removed by oversight, not intention.", as in cleanups before tearDown and in an other you said: "If you put cleanups after teardown...I argue that this is safer"
[07:20] <vila> lifeless: ISTM you prefer the later but can you confirm ?
[07:25] <lifeless> vila: the behaviour I refer to is not running teardown if setup raises an exception
[07:25] <lifeless> that was an oversight
[07:25] <lifeless> the order of teardowns vs cleanups is deliberate
[07:27] <vila> ok. So in the end, that means banning tearDown for bzrlib (I think there are still a couple of classes that use it, in a safe way)
[07:28] <lifeless> vila: well we can make teardown always run again
[07:28] <lifeless> thats what I was saying
[07:29] <vila> ok on that (and that's important), I mixed the two.
[07:43] <lifeless> we could even do it in bzrlib
[07:43] <lifeless> addCleanup(self.maybeTearDown)
[07:43] <lifeless> def maybeTearDown(self): if not self._teardon_run: self.tearDown()
[07:43] <lifeless> def tearDown(self):
[07:43] <lifeless>     self._teardown_run = True
[07:44] <lifeless> [/sketch]
[09:23] <bialix> hello all
[09:56] <jszakmeister> Hi bialix
[10:13] <bialix> hi jszakmeister
[10:36] <jszakmeister> Bummer.  The shelve-editor hasn't made it into bzr.dev yet.
[10:36] <jszakmeister> s/shelve-editor/shelve-editor branch/
[10:39] <jszakmeister> Geez... updating bzr.dev pulled involved 9.5MB of transfer. :-(
[10:42] <jszakmeister> I take that back... shelve-editor did make it in!
[11:19] <saedelaere> is there a changelog for the latest version of the bzr-explorer?
[11:21] <jszakmeister> The most up-to-date one is here: http://bazaar.launchpad.net/%7Ebzr-explorer-dev/bzr-explorer/trunk/annotate/head%3A/NEWS
[11:22] <jszakmeister> Or here (for 0.10.0): https://launchpad.net/bzr-explorer/trunk/0.10.0
[11:22] <saedelaere> ah yes thank you very much
[11:23] <jszakmeister> You're welcome.
[11:33] <_Andrew> is there anything similar to propset in bzr so that I can insert the revision number into my files?
[11:38]  * saedelaere waves
[12:52] <ahasenack> when I do a "bzr info" and get back "format: unnamed", what does it mean?
[12:52] <ahasenack> what format is it?
[12:52] <ahasenack> if I do it at the shared repository level, I get 2a
[12:52] <ahasenack> but if I cd into a checkout (bound branch) and repeat it, I get "unnamed"
[12:57] <jelmer> ahasenack: a named format is a combination of a repository format, branch format and working tree format
[12:58] <jelmer> in your case the branch format/repository format combination used is not available as a named "bzr init --format=" option
[12:58] <jelmer> ahasenack: if you run "bzr upgrade --2a" in the branch it should make a trivial change to the branch and "bzr info" should display 2a as the format name
[12:58] <jelmer> ahasenack: "bzr info -v" should show you the names of the branch, repository and working tree formats
[12:59] <ahasenack> jelmer: is it possible for the root of the shared repository to have one format and the checkouts inside it have a different one?
[12:59] <jelmer> this situation be introduced when you upgrade a repository but not the branches inside of it
[12:59] <ahasenack> it's quite possible this is what happened
[12:59] <ahasenack> I have no idea now what was upgraded and what wasn't
[13:00] <jelmer> ahasenack: I'd recommend just running "bzr upgrade" in the repository root and the branches
[13:00] <jelmer> that should be a no-op if the control dir is already up to date
[13:00] <ahasenack> bzr: ERROR: The branch format Meta directory format 1 is already at the most recent format.
[13:00] <ahasenack> I guess it is
[13:00] <ahasenack> or at least the root of the shared repository is
[13:01] <ahasenack> so I can run "bzr upgrade" at the root of the shared repo
[13:01] <ahasenack> and I can also run it inside each repo from this shared repo?
[13:01] <ahasenack> it's a bit confusing
[13:01] <ahasenack> the shared bits can be upgraded separately from the rest?
[13:02] <jelmer> yes
[13:02] <jelmer> I agree it's a bit confusing
[13:03] <ahasenack> if I run the upgrade at the root level of the shared repository, I still have to run it inside each repository?
[13:03] <jelmer> ahasenack: inside of each branch, yes.
[13:03] <ahasenack> ok
[13:11] <ahasenack> weird:   shared repository: bzr+ssh://bazaar.launchpad.net/~landscape/landscape/trunk/
[13:11] <ahasenack> trunk itself is a shared repo?
[13:11] <ahasenack> ops, wrong channel
[13:13] <vila> ahasenack: a branch uses a repository, it is not a repo itself. As such, a repo can be shared between branches. Standalone branches use their own (private, not shared) repo
[13:22] <maxb> ahasenack: bzr info -v will tell you the repository branch and tree formats separately - handy when they rollup is 'unnamed'
[13:23] <ahasenack> maxb: even remotely?
[13:23] <maxb> You might need to prefix the URL with nosmart+ for that
[13:23] <ahasenack> aha, magic tricks
[13:23] <ahasenack> because just bzr info -v lp:~landscape/landscape/trunk doesn't tell me that
[13:47] <jam> morning all
[13:47] <__monty__> Good afternoon.
[13:48]  * bialix waves at jam
[14:15]  * vila waves
[15:20] <vila> jam: inventory paths use /\'/ as \\
[15:20] <vila> grrr
[15:20] <vila> jam: inventory paths use /\'/ as \\
[15:20] <jam> hey vila
[15:20] <vila> argh
[15:21] <jam> waiting for one more "growl" :)
[15:21] <vila> jam: inventory paths use '/' as separator on *all* platforms right ?
[15:21]  * vila curses Apple keyboard and its \ / delete and return keys all in the same place :)
[15:23] <jam> vila: id2path will always return '/' in the path
[15:23] <jam> we try (too) hard to make sure we always use '/' internally
[15:23] <jam> if you look at the os functions
[15:23] <jam> sorry
[15:23] <jam> osutils
[15:24] <jam> on windows, lots of them end with ".replace('\', '/')"
[15:24] <jam> vila: so yes, internally '/' is our path separator
[15:24] <vila> ok so changes_from() most likely obeys that rule
[15:26] <jam> I would assume so
[15:26] <vila> I just discovered/realize that I can't filter changes_from output with is_ignored() (in bzr-upload context) because smart_add is the only place where *parents* are pruned when they are ignored :-/
[15:26] <jam> the main issue with supporting '\' in filenames, is just that right now, we do all we can to squash '\' to '/'
[15:27] <jam> vila: so you mean if I "ignore foo/" then "foo/bar" isn't getting added?
[15:27] <vila> jam: yes
[15:27] <jam> if I ignore "foo/" but add "foo/bar/" then "foo/bar/baz" (i believe) will show up as unknown
[15:27] <jam> testing
[15:27] <vila> 'ignore foo' is enough
[15:28] <jam> vila: confirmed
[15:29] <jam> I was using '/' to denote that they were dirs
[15:29] <vila> ok
[15:29] <jam> vila: so ignoring 'foo/' just means we won't recurse by default
[15:29] <jam> but if 'foo/bar' is versioned, then we will search everything underneath
[15:29] <vila> hmm, the context is .bzrignore-upload
[15:29] <jam> vila: I expected as such
[15:30] <jam> I just wanted to mention *why* it seems to work for add
[15:30] <vila> So there is no way to "force" as we do with bzr add
[15:30] <jam> and that is because we don't recurse into ignored dirs
[15:30] <vila> sure, makes sense
[15:30] <jam> vila: you may want "foo/**/*"
[15:30] <jam> which is "ignore everything under foo"
[15:31] <jam> note that it *doesn't* ignore foo
[15:31] <vila> yup, but that doesn't ignore foo itself :-/
[15:31] <vila> hehe
[15:31] <jam> vila: so I don't know what you want to do with bzr-ignore-upload
[15:31] <jam> I just wanted to note that there *is* a syntax for "ignore everything under foo"
[15:32] <vila> don't upload items described in .bzrignore-upload
[15:33] <vila> the main difference is that we are talking about inventory paths here, not filesystem paths, so I have to check if a filename is ignored or any of its parents (this isn't needed in bzrlib except in smart_add)
[15:33] <vila> that also means I can't use osutils.dirname :-/
[15:34] <jam> vila: dirname works fine
[15:34] <jam> as would "osutils.split"
[15:34] <jam> splitting doesn't involve adding a '/'
[15:34] <vila> err, on windows dirname() will recognize '/' ?
[15:34] <jam> vila: windows already recognizes '/' as a path chare
[15:34] <jam> char
[15:34] <jam> it just *also* recognizes '\'
[15:34] <vila> s/char/pathsep/ ?
[15:35] <jam> vila: well in python pathsep == : or ;
[15:35] <jam> directory separator
[15:35] <jam> Windows recognizes both '\' and '/' as directory separators
[15:35] <vila> grr, not pathsep, the other one :)
[15:35] <vila> oooh, good news
[15:36] <vila> Do we accept '\' in .bzrignore as meaning '/' ?
[15:37] <vila> Or do we just don't handle them ?
[15:38] <jam> vila: I think we switch them to '/', checking
[15:38] <vila> globbing.normalize_pattern seems to handle the formet
[15:39] <jam> vila: yep
[15:39] <vila> pfew
[15:39] <vila> I'm glad I asked :)
[15:39] <jam> _slashes = re.compile('[\\/]')
[15:39] <jam> so, '\/\/\/' will be treated as 1 '/'
[16:26] <vila> beuno-lunch: lunch is for... well, may be not :) .bzrignore-upload was far more complex than I thought, see the new merge proposal
[16:31] <barry> hi everyone.  recently, i've been getting tons of 'No handlers could be found for logger "bzr"' messages for things like 'bzr push'.  google seemed unhelpful.  anybody know what's going on, or how to fix or debug the issue?  i'm sure it's a python logging thing, but i'm not clear on how bzr sets that up.  ftr: Bazaar (bzr) 2.0.3 on karmic
[16:32] <james_w> it's usually permissions, but I think you ruled that out?
[16:34] <barry> james_w: i did verify that ~/.bzr.log is owned by me
[16:34] <barry> james_w: as are everything in ~/.bazaar
[16:35] <barry> james_w: that is the one issue google spewed up for me, but i can't find anything e.g. owned by root
[16:37] <james_w> are the permission bits sensible on ~/.bzr.log?
[16:38] <barry> james_w: yep. 664
[16:38] <james_w> if you strace it is it trying to open another log file?
[16:38] <barry> james_w: hmm, good idea. let me try
[16:39] <james_w> strace -e open /usr/bin/bzr info 2>&1 | grep log
[16:40] <james_w> and this is usual bzr operations with a plain unpatched bzr?
[16:40] <james_w> does it still happen with --no-plugins?
[16:41] <jam> barry: also, if you could do a run where you see it, and stop with ^\ to get into the debugger
[16:41] <james_w> c = self
[16:41] <james_w> while c:
[16:41] <jam> then we can poke around with what is going on
[16:41] <james_w> that's rather odd code in a method isn't it?
[16:41] <jam> james_w: that does look a little odd
[16:41] <barry> james_w: i only see it trying to open ~/.bzr.log; this is stock /usr/bin/bzr; still happens with --no-plugins
[16:42] <james_w> barry: and it succeeds in opening ~/.bzr.log?
[16:42] <barry> james_w: it does
[16:42] <barry> james_w: and writing to it
[16:43] <barry> jam: let me see if i can catch it
[16:43] <jam> barry: if i understand the problem correctly, it should happen any time you try to connect to an sftp location, or ssh location using paramiko
[16:43] <jam> barry: this is using bzr 2.0.3 ?
[16:44] <barry> jam it is and this is a bzr+ssh url
[16:44] <jam> do you have BZR_SSH set?
[16:45] <jam> (env var)
[16:45] <barry> jam: no
[16:45] <james_w> del bzr_logger.handlers[:]
[16:45] <james_w> doesn't that delete a copy of the list, and so is basically a no-op?
[16:45] <jam> k, well if it is 2.0.3, I'm pretty sure poolie's "stop using the logging" module isn't present
[16:45] <idnar> james_w: no, it empties the list
[16:45] <jam> james_w: no, that is python syntax for clear the list
[16:45] <james_w> ok
[16:46] <idnar> del "operates" on names, not references
[16:46] <jam> bad syntax IMO, but that is the syntax
[16:46] <idnar> there's effectively a whole bunch of special forms of del
[16:46] <jam> same as 'del d[key]'
[16:47] <barry> lists should really have a .clear() method like dicts, but that's a digression :)
[16:47] <idnar> "del foo" deletes a local name, "del foo.bar" invokes __delattr__, "del foo[bar]" invokes __delitem__
[16:47] <jam> idnar: so is it the parser that turns it into the special construct?
[16:48] <barry> jam: so it sounds like this is a known issue in 2.0.3.  if so, i will happily ignore it :)
[16:48] <jam> barry: I don't think it is
[16:48] <jam> It sounds like something strange happening
[16:48] <jam> you could also just try
[16:48] <jam> from bzrlib import logging
[16:48] <jam> sorry
[16:48] <barry> jam: ok!  i'd file a bug, but it seems like i don't have enough information yet :/
[16:48] <jam> from bzrlib import trace; trace.enable_default_logging()
[16:48] <idnar> jam: I'm not sure of the exact mechanics, but it ultimately compiles to different bytecode ops
[16:48] <jam> and see if that has a problem
[16:48] <jam> idnar: *glee*
[16:49] <jam> barry: and what were you using before you ran into this problem? 2.0.2 ?
[16:49] <idnar> there's DELETE_GLOBAL and DELETE_FAST for names, DELETE_SUSCR for del foo[bar], and DELETE_ATTR for del foo.bar
[16:49] <jam> (I'm trying to understand how it "just started" )
[16:50] <barry> jam: python -c "from bzrlib import trace; trace.enable_default_logging()" produces no such message
[16:50] <jam> barry: Now I would expect: "from bzrlib import trace; trace.mutter('foo')" to generate that
[16:50] <jam> and
[16:50] <jam> "from bzrlib import trace; trace.enable_default_logging(); trace.mutter('bar')" not to
[16:51] <barry> jam: well, that's the thing, i'm not entirely sure when it started.  "recently" is the best i can say.  the only thing that comes to mind is that i started using etckeeper, but i would have thought --no-plugins would eliminate that (and i'm not doing pushes in /etc)
[16:51] <jam> sorry 'trace.note()' but I can't reproduce that here
[16:51] <jam> barry: and once again I'm proven wrong
[16:52] <jam> it takes "trace.warning" to provoke the handlers issue
[16:52] <barry> jam:
[16:52] <barry> % python -c "from bzrlib import trace; trace.enable_default_logging(); trace.warning('bar')"
[16:52] <barry> bar
[16:52] <barry> no logger warning
[16:52] <jam> barry: and without the "enable_default_logging"
[16:53] <barry> jam: bingo!
[16:53] <jam> barry: right
[16:53] <barry> warning and no "bar"
[16:53] <jam> so you have to try to log something that looks severe enough, but not have a handler enabled
[16:53] <barry> jam: why, or maybe who, is not installing the handler?
[16:54] <jam> barry: we install the handler as part of main, IIRC
[16:54] <jam> checking
[16:54] <james_w> the difference between note and warning is that warning will go through the added stderr handler
[16:54] <jam> barry: it looks like it is in the "bzr" main script
[16:54] <jam> before calling main
[16:55] <jam> barry: care to put an "import pdb; pdb.set_trace()" in 'bzr' and step through it to see when the warning hits?
[16:55] <GaryvdM> jszakmeister: ping
[16:55] <beuno> vila, ah, that's quite a change
[16:55] <barry> jam: yep, that does seem like the next step.
[16:55] <jam> barry: looking at the 'bzr' code, it looks like we would have to be emitting a warning during import
[16:56] <vila> beuno: yeah, not that simple :)
[16:56] <jam> as plugins aren't even loaded yet
[16:56] <jam> barry: the common case is when "enable_default_logging()" itself fails
[16:56] <jam> specifically:     except IOError, e:
[16:56] <jam>         warning("failed to open trace file: %s" % (e))
[16:56] <jam> which because it cannot open the trace file has not yet set up logging, and ends up getting suppressed
[16:57] <jam> we should probably just change that to "sys.stderr.write()"
[16:57] <james_w> jelmer: isn't that log bug caused by ghosts?
[16:57] <jam> barry: however, you claimed that ~/.bzr.log isn't a problem
[16:57] <james_w> jelmer: oh no, ignore me, sorry
[16:57] <barry> jam: right.  does not seem to be!
[16:57] <jam> barry: you know what, check ~/.bzr.log.old
[16:58] <jam> I wonder if your log is full, and it is failing to get rid of the old one
[16:58] <barry> jam: i have no ~/.bzr.log.old
[16:58] <jam> barry: anyway, stepping through with pdb is the best way to isolate it
[16:58] <jam> barry: what size is ~/.bzr.log ?
[16:58] <barry> jam: 782715
[16:58] <jam> hmm.. we roll at 4MB, so no issue there
[16:59] <jam> back to pdb :)
[16:59] <barry> :)  trying...
[17:06] <barry> jam: so far, i've narrowed it down to push.py:83 in bzr.dev
[17:06] <barry> dir_to = bzrdir.BzrDir.open_from_transport(to_transport)
[17:08] <jam> barry: so this seems to be happening a long time after bzrlib.trace.enable_default_logging() has been called
[17:08] <barry> yep
[17:08] <jam> barry: does that fit what you are seeing
[17:08] <jam> very strange
[17:08] <barry> remote.py:124
[17:08] <jam> barry: you could try putting something into 'trace.warning' but I have the feeling something is going directly to the logging module
[17:10] <barry> jam: happens before we hit the first call to warning()
[17:10] <jam> barry: I think error would also trigger it
[17:10] <jam> but 'note' and 'mutter' seem to be defaulted to silence
[17:10] <jam> maybe there is an 'info' call?
[17:10] <barry> happens before the first call to error too
[17:11] <barry> and before the first call to info()
[17:11] <barry> in fact, before the first call to anything in trace.py
[17:11] <jam> barry: btw, does *python* guarantee that "open().name" works?
[17:12] <jam> I'm trying to define an api, and I want to know whether I have to pass a path as well as a file object, or if I can assume the file object has a .name attribute
[17:13] <barry> jam: well, the stdlib says "may not be present on all file-like objects" but i belive for actual file objects, yes it does guarantee that
[17:14] <jam> barry: sure, StringIO may not have it, but that doesn't have an fs path either :)
[17:14] <barry> right :)
[17:15] <barry> jam: narrowed down to client.py:87
[17:16] <barry> jam: where method='BzrDir.open_2.1'
[17:16] <jam> barry: sure, I'm guessing that send_request is causing an actual connection to be spawned
[17:17] <jam> oh, and if you are sitting there
[17:17] <jam> we can try something else
[17:17] <jam> namely, check the transport
[17:17] <jam> and its connection
[17:17] <jam> and see whether it is using paramiko itself
[17:17] <jam> etc
[17:17] <barry> would that be self?
[17:18] <barry> or rather, i'm not sure where transport and connection are
[17:19] <barry> protocol.py:1303
[17:19] <barry> or maybe 1302
[17:23] <barry> jam: well, here's an interesting thing.  in ssh.py:367 it calls subprocess.Popen() where argv[0] == 'ssh'.  it is in this call that the No handlers warning gets emitted
[17:23] <barry> jam: is it possible this is happening on the server?
[17:23] <jam> barry: hmm... that at least looks like the server is generating an error
[17:23] <jam> barry: it is definitely possible
[17:23]  * barry checks the server
[17:23] <jam> and the error would get propogated over ssh's stderr output
[17:23] <jam> without bzr doing anything
[17:23] <jam> so if on the *server* you have a problem with ~/.bzr.log
[17:23] <jam> this would be much less suprising
[17:24] <barry> jam: bing
[17:24] <barry> er, bingo :)
[17:25] <jam> old mac's dog?
[17:26] <barry> jam: :)  ~/.bzr.log on the server was owned by root.  fixing that made the problem go away.  this explains everything, since this is a new-ish server and it explains why all the clients suddenly saw the same thing
[17:26] <jam> barry: of course it is unfortunate that this was so hard to diagnose
[17:26] <jam> #1 we need to fix _open_bzr_log
[17:26] <barry> jam: thanks!  so problem solved, but i wonder if the debugging output couldn't have helped indicate that the message was coming from the server?
[17:26] <jam> to just write to stderr, since we know logging isn't set up yet
[17:27] <barry> jam: are there bugs here i can file or would you like the honors? :)
[17:29] <jam> barry: You can file a bug if you want, I was just going to fix it
[17:29] <jam> It *is* nice to close bugs :)
[17:29] <barry> jam: you kw :)
[17:30] <vila> kw == kilowatt ?
[17:30] <barry> vila: first word: karma
[17:31] <vila> LOL
[17:31] <vila> well, I think the intent here is more to *document*, karma is unfair for jam anyway :-D
[17:32] <barry> :)  but yes +1, especially because my previous google search was unhelpful.  filing bug now
[17:32] <jam> barry: I was thinking keyword myself :)
[17:32] <vila> mostly because lp doesn't take the number of clones jam is using when calculating karma :D
[17:33] <jam> vila: well for a long time lp didn't count code changes as karma
[17:33] <jam> so mine was actually quite low
[17:33] <jam> too many people triaging bugs
[17:33] <jam> so the amount I did, did not amount to much
[17:33] <jam> if you wanted real karma *blueprints* were where it was at
[17:34] <barry> jam: don't i know it!  when i was doing the lp mlist stuff i blueprinted out the wazoo.  lots of yummy karma
[17:35] <vila> which is a bit silly since we don't use blueprints :D
[17:35] <jam> vila: \o/ I somehow managed to have the highest karma of people I can find right now
[17:36] <jam> I don't know how that happened
[17:36] <jam> ah, lots of commits
[17:36] <jam> https://edge.launchpad.net/~jameinel/+karma
[17:36] <jam> 30k karma from "bazaar branches"
[17:36] <barry> jam: bug 503886
[17:36] <jam> I'm certainly a branch whore
[17:36] <barry> and with that, i give you my thanks and take leave for lunch!
[17:37] <jam> barry: eat hearty my friend
[17:37] <barry> :)  bye all
[18:03] <jam> vila: it would appear that merge-proposals are the new karma hotness :)
[18:04] <vila> good move :)
[18:17] <jam> well, if you look at https://edge.launchpad.net/~jameinel/+karma, I have about 10x more karma from branches
[18:17] <jam> though I guess "new branch registered" also appears on the list
[18:17] <jam> and I don't think I'm *shabby* on the bug tracker
[18:17] <vila> jam: you suck at translations though...
[18:17] <vila> ;-P
[18:17] <jam> yeah
[18:18] <jam> which is true enough anyway :)
[19:06] <EdWyse_Mobile> I have to use bzr on Fedora 6 connecting to a newer repository.  The latest fc6 rpm is 0.91.1 but when I attempt to init to the server, I get "Unknown branch format...". If I try to bdist_rpm version 2.0.3 it fails because of: "bzrlib/_annotator_pyx.c:30:27: error: python-compat.h: No such file or directory".
[19:06] <maxb> EdWyse_Mobile: bzr 0.91.1 !? That's unspeakably ancient!
[19:07] <EdWyse_Mobile> Yeah, so is FC6, but I'm stuck with it on this machine. They took a feature I need out of the kernel.
[19:08] <maxb> I'm afraid I know nothing about bdist_rpm, so I would suggest installing bzr 2.0.3 from source to /usr/local
[19:11] <EdWyse_Mobile> Just to be clear, I do mean "python setup.py bdist_rpm"
[19:12] <ronny> EdWyse_Mobile: you lakc the python development packages
[19:12] <EdWyse_Mobile> Oh! That makes sense.
[19:14] <EdWyse_Mobile> Well, made sense but that wasn't it.
[19:35] <jam> EdWyse_Mobile: where are you getting the code from?
[19:35] <jam> I don't see how it would have _annotator_pyx.c but not python-compat.h
[19:36] <jam> EdWyse_Mobile: another option would be to just run from source, which is what I do on an *FC3* machine :)
[19:36] <EdWyse_Mobile> That's what I'm doing for now.
[19:36] <lifeless> moin
[19:37] <jam> hi lifeless
[19:37] <jam> EdWyse_Mobile: looks like I get the same failure, investigating
[19:38] <jam> it seems that bdist_rpm is building in build/temp... but isn't including bzrlib itself
[19:38] <jam> so it probably thinks we should be including "bzrlib/python-compat.h"
[19:40] <jam> EdWyse_Mobile: hmm... bdist_rpm seems to start by hardlinking everything into a new directory
[19:40] <jam> but doesn't seem to include python-compat.h
[19:41] <EdWyse_Mobile> Hmm, sounds like a simple bug.
[19:41] <jam> I don't quite understand how it figures out what files to copy
[19:43] <lifeless> jam: check that sdist includes python-compat.h
[19:44] <jam>  lifeless: the tarball it creates does *not* have python-compat.h, or any of the pyrex generated .c files
[19:46] <lifeless> I'm fiarly sure that they select in common
[19:46] <lifeless> excuse me, more coughing.
[19:46] <jam> lifeless: looks like that is true
[19:48] <jam> looking here for possible answers: http://www.python.org/doc/2.3.5/dist/source-dist.html
[19:48] <jam> It does mention: all C source files mentioned in the ext_modules or   libraries options
[19:49] <jam> however: http://paste.ubuntu.com/352492/ doesn't seem to catch it
[19:53] <jam> this seems to work: http://paste.ubuntu.com/352494/
[19:53] <jam> EdWyse_Mobile: ^^
[19:53] <jam> That will also include the pyrex generated files in the tarball
[19:53] <jam> which is something we would want anyway
[19:56] <jam> oh, and you probably need more for stuff like bzrlib/help-topics, etc
[19:56] <jam> so we probably need a *.txt in there as well
[19:57] <jam> lifeless, jelmer: Any idea why subvertpy debs are in the bzr 2.0/2.0.3 download location?
[19:57] <jam> https://edge.launchpad.net/bzr/2.0/2.0.3/
[19:57] <EdWyse_Mobile> cool, thanks
[19:58] <jam> and bzr_2.0.3-1~bazaar1~hardy_powerpc.changes seems a bit strange to have
[19:58] <jam> it at least looks like someone uploaded to +download instead of to a ppa
[20:01] <lifeless> jam: no idea
[20:01] <lifeless> seems odd
[20:01] <jam> Any way to tell who uploaded them?
[20:01] <lifeless> who uploaded them ?
[20:01] <lifeless> jinx
[20:02] <lifeless> thats a question for #launchpad(-dev)? I think
[20:32] <dutchie> is there a way to make a shelved change dump out the diff saved?
[20:38] <snorkelbuckle> Hi!
[20:38] <GaryvdM> dutchie: maybe bzr unshelve --dry-run
[20:39] <GaryvdM> Hi snorkelbuckle!
[20:39] <dutchie> it just prints out a little summary message, even with -v
[20:39] <snorkelbuckle> New user here, anybody here who can spend 5 minutes to help me with setting up centralized shared repos?  Its installed on linux and I'm having trouble accessing via windows tortoise bazaar.
[20:43] <snorkelbuckle> I did the following, bzr init-repo --no-trees /bzrepos, then from tortoise did and 'Init' no trees to following bzr+ssh://hostname/bzrepos/newproj
[20:43] <snorkelbuckle> now if i check out newproj, I get erro Not a branch
[20:44] <snorkelbuckle> what am I not understanding about setting up new repos?
[20:45] <GaryvdM> snorkelbuckle: are you maybe a user of another vcs?
[20:46] <GaryvdM> snorkelbuckle: If I understand you correctly, you have a branch stored on a linux box, and you want a copy of it on your win box?
[20:47] <snorkelbuckle> GaryvdM: yes, I've used svn, yes I suppose a branc on linux box, but it is empty I only just initizliued it.  So I assume once it is init, then I can check it out to my win box and add files to it
[20:47] <GaryvdM> snorkelbuckle: what url did you use?
[20:48] <snorkelbuckle> GaryvdM: bzr+ssh://myinternalhost.com/bzrepos/myproject
[20:51] <lifeless> snorkelbuckle: in one line you say bzr+ssh://hostname/bzrepos/newproj in another bzr+ssh://myinternalhost.com/bzrepos/myproject
[20:51] <lifeless> snorkelbuckle: the urls will need to be the same :)
[20:51] <snorkelbuckle> lifeless: thanks, first line was generlized, second line is accurate.  :)
[20:52] <snorkelbuckle> okay, now I tink I understand what is wrong...but I don't understand then how I should use bazaar...I think the terminology is different from what I'm used to.
[20:52] <snorkelbuckle> What I did was did bzr init-repo for /repos
[20:53] <snorkelbuckle> and then under /repos, I did also init-repo
[20:53] <snorkelbuckle> for a different dir
[20:53] <snorkelbuckle> so then this is a sub-repos under a repos?  This is allowed?  Thus I don't yet have a branch which I must do with bzr 'init'  as opposed to 'init-repos'?
[20:55] <GaryvdM> snorkelbuckle: http://doc.bazaar.canonical.com/latest/en/user-guide/core_concepts.html will help
[20:57] <snorkelbuckle> GaryvdM: thanks
[20:59] <GaryvdM> btw: I've just changed from Qwerty to dvorak so my typing is painfull slow :-(
[21:02] <snorkelbuckle> GaryvdM: what is the reason you changed?
[21:03] <GaryvdM> hopefully I will become faster in the long run :-)
[21:04] <snorkelbuckle> GaryvdM: thanks for your time in helping me.  I must have missed those reference pages, explains a lot.  I've got things working now.
[21:04] <GaryvdM> Good!
[21:07] <snorkelbuckle> GaryvdM: I guess my main problem was that I had not actually any branches to checkout from the repos, thus the error.  However, I find this a minor problem with tortoise bazaar (maybe there is a way to do it), but there doesn't seem to be a way to create a branch on an empty remote repository.
[21:15] <lifeless> snorkelbuckle: yes repos can be nested but its not what you want
[21:15] <lifeless> snorkelbuckle: you want to init under the first repo
[21:54] <jam> GaryvdM: good luck, I've been there
[21:54] <jam> It took me about 1 month before I was at reasonable speed vs qwerty
[21:54] <jam> I'll note that I don't think I'm faster today than I was w/ qwerty
[21:54] <jam> though the bottleneck is not really my fingers
[21:54] <jam> I *do* feel that there is less motion in my fingers
[21:54] <jam> and I believe poolie has had good results wrt strain
[21:54] <GaryvdM> Hi jam
[21:55] <jam> GaryvdM: I'll also mention that I was decent at switching for a long time, before I started working exclusively on my laptopt
[21:55] <jam> now I can switch somewhat, but ViM is still a real pain in the wrong keyboard
[21:57] <GaryvdM> In the typing tutor, I can do 10 wpm, but when I'm much slower when I've got other things on my mind.
[21:58] <idnar> yeah, I observed about the same; once I was up to speed, I wasn't any faster on dvorak, but I wasn't any slower either, and the strain on my wrists was much less
[21:59] <GaryvdM> I find 'L' to be a bit of a strain.
[22:05] <marsilainen> I would seriously consider switching to dvorak if there were a decent selection of keyboards to buy..
[22:08] <lifeless> marsilainen: any keyboard with homogenous keys
[22:19] <jam> marsilainen: well, it helps you become a better touch typist
[22:19] <jam> lifeless: except the F & J keys have bits on them to guide your fingers
[22:19] <jam> but I did rearrange a keyboard
[22:20] <jam> and just swapped those two keys appropriately so that I still had the dots, and just had 4 keys in the wrong place
[22:20] <jam> well, except for the fact that I made mistakes and never bothered to fix them (V & W, IIRC)
[22:51] <poolie> hello jam, gary
[22:51] <poolie> i never switched the keycaps
[22:52] <poolie> i just learned to do things from the dots on the home row
[22:52] <poolie> that possibly improved my results independently of switching to dvorak
[22:52] <poolie> iow relearning any layout this way may have helped
[22:52] <poolie> i'd like to do a small hack some time that measures errors (backspaces) as a feedback technique
[22:56] <jam> hey poolie
[22:56] <jam> abentley: are you around?
[23:03] <GaryvdM> Hi poolie
[23:03] <poolie> hi, happy new year
[23:03] <poolie> jam, if it's not too late, we could talk
[23:04] <poolie> otherwise i'll set an alarm for earlier tomorrow :)
[23:05] <jam> poolie: I'm heading out the door now
[23:05] <jam> I suppose you could call my cell if you wanted
[23:05] <poolie> nm, if i call you at 2200utc tomorrow would that work?
[23:05] <jam> sure
[23:05] <jam> I've been trying to investigate bug #494269, and our tree root handling just seems ... broken
[23:05] <jam> everywhere
[23:06] <jam> calling "wt.set_root_id(new)"
[23:06] <poolie> hm :/
[23:06] <jam> causes "wt.id2path(new)" to fail
[23:06] <jam> well, wt.id2path(wt.path2id('')) breaks
[23:06] <poolie> with problems in dirstate, or tt,or maybe both?
[23:06] <jam> both
[23:06] <jam> wt.id2path(wt.path2id('')) is a dirstate bug
[23:06] <jam> 'bzr revert' fails
[23:06] <jam> but seems to be a TreeTransform bug
[23:06] <jam> etc,
[23:07] <jam> update/pull use different code paths to achieve 90% the same thing
[23:07] <jam> and update will call set_root_id() if it is None
[23:07] <jam> pull doesn't
[23:07] <jam> etc.
[23:07] <jam> anyway, I'm off for now
[23:58] <igc> morning


[00:03] <brousch> cmaloney: Put your pants back on
[00:03] <cmaloney> you can't make me
[00:04] <rick_h__> shorts ftw
[00:04] <rick_h__> fireplace and steak dinner night wooooo!
[00:05] <cmaloney> Very nice.
[00:05] <cmaloney> How's the weather by you?
[00:05] <cmaloney> We're still getting rain, luckily enough
[00:05] <rick_h__> ugly, but the ice thing hasn't happened
[00:05] <rick_h__> just rain, temp according to the car has been 32-34 all day
[00:06] <cmaloney> That's good
[00:06] <rick_h__> yea, but I tried to go to the grocery store
[00:07] <rick_h__> I deserve a freaking medal imo
[00:07] <cmaloney> I went to Meijer just before noon.
[00:07] <cmaloney> So I can relate
[00:07] <rick_h__> filo dough, sesame seeds, fluten free crackers...imaginary crap no one needs but were on my list for some reason
[00:08] <cmaloney> Um, we need filo dough. :)
[00:08] <rick_h__> it's no where near any doughy stuff in the store
[00:08] <rick_h__> you know how hard/picked over the dough section is?
[00:08] <cmaloney> Nope, it's in the freezer section near the puffed pastry
[00:08] <rick_h__> and busy with everyone
[00:08] <cmaloney> Yeah, I can imagine
[00:08] <rick_h__> right, but puffed pastry is different. I know because I grabbed that first and a text sent me back
[00:09] <rick_h__> anyway, fun stuff
[00:09] <cmaloney> I'm just relaying the message from JoDee.
[00:09] <rick_h__> lol
[00:09] <jrwren> someone is going to make something delicious out of it, and you will get to eat it!
[00:09] <rick_h__> meh, I got chocolate chip cookies and I'm getting a pumpkin pie. I'm set.
[00:10] <rick_h__> oooh, first monitor review http://uk.hardware.info/reviews/5100/dell-ultrasharp-up2414q-review-24-inch-uhd--4k-monitor
[00:10] <rick_h__> of course no hint on how it'll hook up in linux. Much more complicated than I expected it to be overall
[00:10] <jrwren> its not just DL DVI
[00:10] <rick_h__> everyone else staying ice-free?
[00:10] <jrwren> i think I'm ice free here.
[00:11] <rick_h__> jrwren: nope, can't even dvi it
[00:11] <rick_h__> at least I don't think you can
[00:11] <rick_h__> yea, no dvi ports
[00:11] <jrwren> wtf ports does it have?
[00:12] <rick_h__> dp and dp mini and hdmi
[00:12] <rick_h__> though with hdmi it only runs 30hz
[00:12] <rick_h__> so dp 1.2 for me
[03:38] <cmaloney> Finished the last episode of Open Metalcast for 2013
[03:38] <rick_h__> woot!
[03:39] <cmaloney> And it's not a holiday episode. :)
[03:40] <rick_h__> hah!
[03:40] <cmaloney> It's actually an Instrumetalcast
[03:40] <cmaloney> I scheduled it to release on Monday morning, but you can get the files on Archive.org
[03:44] <cmaloney> http://www.reddit.com/r/retrobattlestations/comments/1tfgc6/most_of_my_portable_battlestation_collection/
[03:44] <rick_h__> wow
[03:46] <cmaloney> Sad thing is I have one of those machines. :)
[03:46] <cmaloney> And only one of those machines. :)
[03:48] <cmaloney> If anyone wants to gift me an Osborne 1 I'd be much obliged. :)
[15:10] <cmaloney> Good morning
[15:10] <cmaloney> Hoep you all have power
[15:11] <rick_h__> yep, and the roads weren't as scary as feared
[15:11] <cmaloney> Good deal
[15:11] <rick_h__> though I'm glad no UPS deliveries today
[15:11] <rick_h__> the driveway is a sheet of ice
[15:13] <cmaloney> Yeah, I'll bet
[15:39] <jrwren> and you have power!
[15:39] <jrwren> some of ortonville doesn't, I hear.
[19:32] <cmaloney> Afternoon
[20:37] <cmaloney> http://azac.pl/cobol-on-wheelchair/
[20:47] <waf> i've always felt that the lack of a killer web framework was holding cobol back.
[21:14] <cmaloney> Say no more. Cobol is BACK BAYBEEEEE.


[12:21] <cubo-cube> JackFrost, okay so jpgs instead, should I reupload everything? Or wait until the contest is over and see if my submission get selected.
[12:22] <cubo-cube> I don't know about your preferences, but I don't like duplicates.
[12:48] <bluesabre> jpgs compress better for photos
[12:49] <bluesabre> knome, what would you recommend for replacing or deleting already uploaded submissions?
[17:04] -BottyMcBotFace:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: xfce4-clipman-plugin 1.4.4 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-xfce4-clipman-plugin-1-4-4-released-tp57505.html (by Simon Steinbeiss)
[22:43] <ochosi> bluesabre, JackFrost: i haven't heard from ofourdan in a while, but i have two patches which could/should make it into xubuntu 20.04 ideally, see here:
[22:43] <ochosi> https://bugzilla.xfce.org/show_bug.cgi?id=16382
[22:43] <ochosi> https://bugzilla.xfce.org/show_bug.cgi?id=16381
[22:43] <ochosi> both are sort of cosmetic, but also quite annoying once you notice them
[22:44] <ochosi> the latter one is even a bit misleading and ugly if you ask me
[23:15] <jphilips> Super + D was introduced with 19.10 for show desktop, but it doesnt work for me on my installed 19.10 or 20.04 live session
[23:18] <ali1234> on 20.04 the panel has shadows
[23:18] <jphilips> if i press Super + D in thunar, it acts like if i'm not pressing Super at all and shows 'd' for search
[23:34] <brainwash> jphilips: is it set to super+d?
[23:35] <jphilips> brainwash: yes
[23:36] <brainwash> on my system it is not because I installed it before this change
[23:36] <brainwash> https://git.launchpad.net/xubuntu-default-settings/commit/etc/xdg/xdg-xubuntu/xfce4/xfconf/xfce-perchannel-xml/xfce4-keyboard-shortcuts.xml?id=4f8124a0669462a5ff86017043ab4cc068ae4b1e
[23:53] <jphilips> brainwash: well you can set it in window manager and see if it works for you