[04:57] <sergio-br2> hi
[07:00] <dholbach> good morning
[08:09] <ochosi> Rhonda: hey! any reason why wily isn't showing up on packages.ubuntu.com yet?
[08:11] <Rhonda> ochosi: because I was too lazy to do it yet. :)
[08:12] <ochosi> alrighty :)
[08:17] <Rhonda> btw., the wiki doesn't mention wily in the Releases page
[08:18] <Rhonda> meh, it does, I'm blind :)
[08:19] <Rhonda> I guess I'll remove utopic already.
[08:22] <Laney> utopic's still alive
[08:22] <Rhonda> For less than two more months?
[08:23] <Laney> it's your call but I bet people still use it for that
[08:23] <Rhonda> Ok.  But lucid gets removed. :)
[08:24] <Laney> what's the config like?
[08:24] <Laney> could you script it to be generated from $(ubuntu-distro-info --supported) or something?
[08:25] <Rhonda> I guess so.  There is also this metainfo website that the information could get pulled from I guess.  We had that discussion in Debian context recently where that one was mentioned.
[08:25] <Rhonda> I have this workplan for debcamp to work on the packages code so maybe I get something done at that time.
[19:59] <jimcornette> Hello there, I am making a simple c++ console application with Qt.  I have compiled it and it runs fine.  But when I try to build it with sbuild it errors out saying that there is no QCoreApplication  even though I have added widgets and core and network to my .pro file and also to d/control any idea what is going on ?
[20:00] <jimcornette> it is a simple avahi register.  so it is a simple console application.
[20:03] <jimcornette> My debian/control and debian/rules files    http://paste.ubuntu.com/11527486/


[01:41] <dcoles> Hello again. Here's an interesting issue - if I have svn cache.tdb files in my .cache/bazaar/svn directory I can't use bzr-git.
[01:42] <dcoles> The quick fix is to just blow away the .cache/bazaar/svn directory, but I'm still trying to work out why bzr-git was the thing affected (since bzr-svn and normal svn work fine)
[01:42] <lifeless> thats odd :)
[01:44] <dcoles> I'm wondering if it's some sort of auto-probe like the transports do. My work has a weird certificate config that means I can only use svn+https because https straight will explode.
[01:44] <dcoles> "Initialising Subversion metadata cache in /home/dcoles/.cache/bazaar/svn/a64d3506-044a-4e67-9bab-d6d69bd6860d."
[01:44] <dcoles> Hm. It's a git checkout...
[01:45] <dcoles> Though ffmpeg was being dual-hosted with svn.
[01:51] <lifeless> heh
[02:05] <spiv> dcoles: I suppose as a workaround you could set BZR_DISABLE_PLUGINS=svn when working with that location
[02:07] <dcoles> spiv: Well the weird thing is that if I do a new checkout of the ffmpeg trunk with git then it works
[02:07] <dcoles> Looks like for some reason it the first repo was missing .git/branches and thus caused bzr-git to assume it was not a repository
[02:09] <dcoles> (Which then caused a whole bunch of other behavior in bzr-svn like trying to look at all the svn repos it had cached)
[08:33]  * jelmer waves
[09:04] <jam> morning jelmer, you're up early :)
[10:47] <poolie> hi jam, jelmer, vila
[10:48]  * jelmer waves
[10:48] <jam> hi poolie
[10:50] <poolie> hi jelmer
[10:50] <poolie> i'm out in the atrium space
[11:06] <rom1> hi all
[11:07] <rom1> Is there somethong to configure in qbzr so that the user defined bugtrackers are displayed in qlog tree tags ?
[11:13] <luks> rom1: unfortunatelly, no
[11:14] <luks> rom1: there is a currently a hard-coded list of URL pattenrs in the source
[11:14] <luks> http://bazaar.launchpad.net/~qbzr-dev/qbzr/trunk2a/view/head:/lib/bugs.py
[11:22] <spiv> luks: huh
[11:22] <spiv> luks: seems like that should be using bzrlib.bugtracker.tracker_registry somehow
[11:23] <spiv> luks: (maybe some helper APIs need to be added to bzrlib?)
[11:30] <luks> spiv: that doesn't really work
[11:30] <luks> spiv: because bzr stores only the full URL
[11:30] <luks> spiv: but not a way to get the ID from it
[11:30] <Kamping_Kaiser> can bzr be made to print out the current revno before updating if i involve 'bzr pull'?
[11:31] <spiv> luks: right, so we probably should extend the APIs there to allow that.
[11:31] <spiv> luks: it would be useful for more than just qbzr :)
[11:31] <luks> spiv: well, it's not possible without changing the format
[11:32] <luks> spiv: because bug tracker configuration is stored in the user's configuration file
[11:32] <luks> so I get an arbitrary URL, I don't know what the user that committed it had configured as a bug tracker
[11:33] <luks> this would be a nice use case for versioned properties, IMO
[11:34] <spiv> luks: sure, but you can use the current user's config as a likely reasonable approximation
[11:34] <spiv> (I agree we could store more structured data in the properties)
[11:34] <mbp_> o/ spiv
[11:35] <mbp_> thanks for all the reviews
[11:35] <spiv> Hi mbp, just having a quick bike shed before dinner :)
[11:46] <mbp_> heh
[11:46] <mbp_> i bet people can really bikeshed on your dinner too
[11:46] <mbp_> hm
[11:46] <poolie> that's better
[11:47] <poolie> that's good news fram maritza
[13:06] <rom1> Thx luks
[14:06] <poolie> jam, vila, hi?
[14:06] <jam> hi poolie
[14:06] <poolie> can you join #ubuntu-uds-arany
[14:06] <poolie> we're just going to talk about bfbip
[15:50] <santagada> why does bzr diff tries to go to launchpad to search for differences? I would like to do a local diff only
[15:58] <jam> santagada: if you are using a lightweight checkout, the data isn't stored locally to diff against
[15:58] <jam> if you're not, then I don't see why it would be connecting to launchpad
[15:58] <santagada> jam: stacked means lightweight?
[15:58] <jam> santagada: no
[15:59] <santagada> then no
[15:59] <jam> but stacked may-or-may-not have the data locally
[15:59] <santagada> I have huge checkouts
[15:59] <jam> since stacked inherently stores some comment remotely
[15:59] <jam> content
[15:59] <santagada> at least the latest version should be here
[15:59] <santagada> I'm doing a simple bzr diff <file>
[16:00] <santagada> without any parameters, so I can't think of any for that it would have to look on the internet to do it
[16:00] <santagada> s/for/form
[16:00] <santagada> because it should at least have the revision I'm on
[16:02] <maxb> Not if you are using a lightweight checkout
[16:03] <santagada> why would I want such a lightweight checkout? I'm going to find the command I did to checkout stuff, but I remember it was huge and slow
[16:03] <maxb> Run 'bzr info' and tell us the first line
[16:04] <santagada> bzr info is kinda slow also
[16:04] <maxb> Actually, pastebin all of 'bzr info's output
[16:04] <santagada> https://gist.github.com/6440ba487ad80f038ece
[16:04] <maxb> Oh, OK, your local branch is stacked on the remote launchpad branch
[16:05] <maxb> i.e. bzr is configured to not store locally any revisions which are present in the remote branch
[16:05] <jam> maxb: he's using "bzr branch --stacked" which may or may not have local content. I'm guessing at the least, we are always opening the stacked-on location just as part of opening the branch.
[16:05] <maxb> Seems likely
[16:05] <jam> by default we *don't* have the tip revision at the time of branching, because that is in the stacked location (and by default we have nothing in a stacked branch that is in the stacked-on location)
[16:05] <jam> after a commit, we *should* have some of the data locally
[16:05] <jam> (the newly committed stuff)
[16:06] <santagada> "bzr branch --stacked" was what I used
[16:06] <jam> but I'm guessing we would still connect to the stacked-on location (because Branch.open() opens fallbacks)
[16:07] <santagada> there is no point of downloading the whole repo at x revision and not keep at least the tip
[16:07] <santagada> so I downloaded tons of megabytes from launchpad, suffered thru it and I don't have the tip to do a diff :)
[16:08] <santagada> I'm not mad, but it doesn't make much sense to me
[16:09] <santagada> is there a way to get at least the tip?
[16:13] <jam> santagada: its something we want to support (bzr branch --shallow), but it isn't in the immediate plans. It is something that is rated moderately high for stuff like UDD development
[16:13] <jam> so I would guess it would be implemented in the next few months.
[16:13] <jam> it isn't trivial to create in the current model, since as I said, we default to not storing data that is already present
[16:14] <jam> mostly because '--stacked' was an answer for pushing stuff up to Launchpad, where you *don't* upload a whole set of contents.
[16:18] <poolie> hey jam, thanks for joining in
[16:33] <santagada> jam: so I should just download the whole repo