[07:42] <vila> hello jelmer , hello all
[07:47] <fullermd> Shoot, I'm demoted to 'all'?   :(
[07:53] <vila> hehe, you were part of all in 'hi all' already :) Since you ask me to introduce some variety I do my best at a time where my caffeine / blood ratio is still low...
[07:54] <fullermd> There are many problems in the world caused by having too much blood in one's coffeestream...
[07:55] <fullermd> Still, it's not THAT hard to rig up an IV, really.
[07:55] <vila> 4 ?
[07:56] <fullermd> As in 'intravenous'.
[07:56] <vila> ha, IntraVenous ?
[07:56] <vila> :)
[07:56] <jam> morning vila
[07:56] <vila> hey jam !
[07:57] <vila> jam: so, about your config need,
[07:57] <vila> nothing forbids getting the option value once and pass it down to your objects
[07:57] <jelmer_> 'morning vila :)
[07:58] <vila> (if you're still worried about accessing the *file*)
[07:58] <jelmer_> hi fullermd, Riddell_
[07:59] <vila> jelmer_: nice shot, the avatar (Ridell no _) died ;)
[08:00] <jelmer_> :)
[08:03] <jam> vila: so I don't know if you noticed what I said, which is that one of the ways GroupCompress objects are created is from _LazyContentManager, which can be instantiated by a NetworkRecordStream. None of which is directly coupled to a Repository.
[08:03] <jam> anyway, I think I can make it work
[08:04] <jam> Right now, I'm working on actually implementing the functionality *based* on the config item, so I have some time to think about it still
[08:04] <vila> jam: there are two cases there I think
[08:04] <vila> if it's connected to the repo, get it from there
[08:04] <vila> if it's not there are again two cases :)
[08:04] <vila> if it should end up in a repo, you probably know it ahead, so connect it
[08:05] <vila> otherwise, either fallback to the global config or use a default value
[08:23] <poolie> hi everyone
[08:24] <vila> fullermd: he really meant fullermd *and* everyone ;)
[08:24] <vila> hey poolie
[08:25] <fullermd> Oh good.  My ego was in danger of shrinking for a minute there.  And then what would hold up the clouds?
[08:26] <vila> Herakles ?
[08:27] <fullermd> Pfft.  Pretender.
[08:28] <jam> vila: I'm pretty sure Atlas was the one holding up the world, Herakles was just a strong-man
[08:30] <vila> jam: indeed, but Atlas asked Herakles to replace him for a while (and went party-ing for an unreasonable period and then Herakles wasn't wery happy about that...)
[08:30] <jam> was he a waskaly wabbit?
[08:30] <jam> :)
[08:38] <fullermd> Well, Atlas managed to get whole lines of gym equipment named after him, so by some measures he come out ahead, anyway...
[08:39] <bignose> and some pretty awesome books.
[08:40] <bignose> and a now-defunct rocket launcher program.
[08:40] <fullermd> Yeah.  And what did Heracles get?  A crappy TV show...
[08:40] <fullermd> It just doesn't pay to hold planets for your friends.
[08:41] <bignose> sage advice, I'm sure that will save people some time.
[08:41] <fullermd> 's why I share my genius like this.  I'm a giver.
[08:42] <vila> yeah, once again competition is bitten by collaboration ;)
[08:45] <fullermd> Good choice for a Greek day, as I'm already sitting here listening to _Atalanta_   :p
[08:52] <vila> :)
[09:20] <vila> jam: quick check about our locking model:
[09:21] <vila> branches/wt are write-locked for the duration of the whole operation but repos are only write-locked around the pack-names modifications
[09:21] <vila> correct ?
[09:21] <vila> operation == bzr command
[09:22] <vila> well ~=, you see what I mean or feel free to be more precise ;)
[09:22] <jam> vila: physically locked, yes
[09:22] <vila> is there some hidden meaning to physically I may be missing ?
[09:22] <jam> so when you do Object.lock_write(), Branches and WT change the state on disk
[09:22] <jam> Repository does not
[09:22] <vila> yup
[09:23] <jam> Repository only holds the on-disk lock for the time to update pack-names
[09:23] <vila> my question was: only one operation can get the lock
[09:23] <jam> vila: right. It doesn't make sense to allow 2 people to push to a branch concurrently, since both would want to change the branch poitner.
[09:23] <vila> sure
[09:24] <jam> arguably some branch operations could be done in parallel, but it was never worth doing
[09:24] <jam> (like setting a branch.conf entry vs updating branch's tip pointer)
[09:24] <vila> what I'm after is: can I rely on the object lock to assume that the corresponding config file doesn't need an additional lock
[09:24] <vila> this works for branch/wt but is still unclear for repos
[09:25] <jam> vila: doesn't work for repos, but they don't currently have a config
[09:25] <vila> indeed ;)
[09:25] <jam> also, we don't *want* to block Repo for config settings (most likely)
[09:25]  * vila nods
[09:25] <jam> we *want* repo to be multi-writer as much as possible
[09:25]  * vila nods
[09:25] <jam> so that you can have 100 branches that get updates without blocking the repository
[09:25] <jam> I don't know how that works with config
[09:25] <vila> well
[09:26] <vila> there is no repo option today
[09:26] <vila> so there is no repo option that a bzr operation want to set
[09:27] <vila> but we can imagine repo options that could be set directly via bzr config or by editing the file
[09:28] <vila> so as long as the config file is never left in an inconsistent state by bzr itself, we always get a valid config file leaving only the issue that bzr can get an out-of-date option value (which is acceptable)
[09:29] <vila> neglecting user errors while editing the file that is (which is addressed differently anyway)
[10:44] <jelmer> spiv, hi
[10:49] <spiv> jelmer: hola
[10:49] <jelmer> spiv: I'm looking at adding a limit argument to Branch.fetch but I'm wondering what the most appropriate way is to do so
[10:49] <jelmer> spiv, in particular, would it be better to pass the limit argument down as part of the fetch_spec or rather as a separate argument down to InterRepository.fetch() ?
[10:50] <spiv> Hmm, limit meaning what here?
[10:51] <spiv> If it means "no more than N ancestors of these tips", then I think that's a kind of fetch_spec.
[10:51] <jelmer> yep, just a rough way of limiting the data transferred
[10:52] <jam> hey spiv, on late?
[10:52] <spiv> (If you don't mind walking the history up front you can already do that via an appropriate SearchResult fetch_spec)
[10:52] <spiv> jam: yeah, a bit.  V just went to bed.
[10:52] <spiv> Snoring like a proverbial baby :)
[10:52] <jelmer> :)
[10:52] <jelmer> spiv, that makes sense, I'll add it to the fetch_spec. Thanks :)
[10:53] <spiv> jelmer: so basically yes, I think this is something fetch_spec ought to do
[10:54] <spiv> I have a ugly patch atm that adds a new fetch spec (to make "bzr branch --stacked" from remote when it's about to build a working tree) much better.
[10:55] <spiv> Transfers 1/3 the bytes in 1/2 the round-trips.
[10:56] <spiv> So I'm definitely in favour of adding fetch_specs :)
[10:56] <jelmer> that sounds nice :)
[10:57] <spiv> Basically it's a fetch spec for "the whole revision, i.e. inventory and all referenced texts (and chks)", which is the data that has to be retrieved to build a working tree if you have no data to start with.
[10:58] <spiv> We really should make get_stream_for_missing_keys not need VFS calls though
[10:58] <spiv> (Possibly in part by sending more of those keys in the stream in the first place!)
[11:13] <chriscauser> Hello everyone
[11:13] <chriscauser> I'm having a spot of bother with my bzr-svn
[11:13] <chriscauser> I'm 2.4 daily on ubuntu and when I push I get this
[11:13] <chriscauser> http://paste.ubuntu.com/606456/
[11:13] <jelmer> chriscauser, hi
[11:14] <chriscauser> It worked yesterday so I suspect it may have something to do with the update I installed this morning
[11:15] <jelmer> chriscauser, what sort of bzr / bzr-svn are you running?
[11:16] <chriscauser> jelmer: Sorry, I thought it was in the crash report. bzr is 2.4.0dev3
[11:16] <chriscauser> bzr-svn is 1.1.0~bzr3688~ppa376~lucid1
[11:17] <jelmer> chriscauser, you need a newer version of bzr-svn too if you're running a bzr snapshot
[11:17] <jelmer> are you running both from the daily PPA?
[11:17] <chriscauser> yes
[11:18] <chriscauser> As far as I'm aware, there's nothing out of the ordinary on this box
[11:18] <chriscauser> (other than a daily PPA ;) )
[11:20] <jelmer> looks like the bzr-svn package in the PPA needs fixing
[11:21] <chriscauser> jelmer: Thanks
[11:27] <jelmer> chriscauser, should be fixed now, but it'll take up to 24 hours for the package to rebuilt
[11:27] <jelmer> *rebuild
[11:27] <chriscauser> jelmer: Thanks a lot. What would you recommend I do in the meantime (
[11:28] <chriscauser> pin the version or download the tar?)
[11:28] <chriscauser> or just sit and wait :)
[11:28] <chriscauser> ?
[11:28] <jelmer> chriscauser: there is no tarball to download, as you're running a nightly build :)
[11:29] <jelmer> chriscauser: you can grab lp:bzr-svn though
[11:29] <chriscauser> jelmer: Duh, now why didn't I think of that!
[11:30] <jelmer> spiv: still there?
[11:30] <jelmer> spiv: I'm trying to figure out how to integrate this with SearchResult
[11:31] <spiv> jelmer: I probably wouldn't change SearchResult.  This sounds like it'd be a new search or search result.
[11:34] <jelmer> spiv: Where would you put it instead, FetchSpecFactory.make_fetch_spec() ?
[11:36] <jam> jelmer: the other thing to consider between you and spiv, is how "wide" the result should be
[11:36] <chriscauser> jelmer: Thank you so much. The latest revision works absolutely fine now.
[11:37] <jam> specifically, for "shallow" branches, you want to have all texts, even if they aren't part of the delta for a given rev
[11:37] <jelmer> chriscauser: np, thanks for making me aware it's broken
[11:37] <jam> however, for regular fetch + some ancestors, do you want all texts or not?
[11:37] <jelmer> jam: The use case for this is the incremental fetches that Launchpad does for imports (but would also apply for mirrors)
[11:38] <jam> jelmer: how is that different from just requesting a fetch at N and reporting back that you have N-1000 ?
[11:38] <jam> (though it sounds like you don't want the 'fully-wide' content)
[11:39] <jelmer> jam: we want more than just the mainline so N-1000 is too rough
[11:39] <jam> jelmer: but don't you have text discovery already?
[11:39] <jelmer> jam: also, it's imposibble to determine what N-1000 is for e.g. Git or Mercurial repositories
[11:39] <jam> _walk_to_to_common_revisions
[11:39] <jam> sort of thing
[11:40] <jelmer> jam: that's server driven
[11:40] <jam> jelmer: I don't understand why you want N - (100 old ancestors) without wanting evertyhing you don't have
[11:41] <jelmer> jam: I do want everything I don't have, I just don't want all of it now
[11:41] <jam> jelmer: but surely you want older stuff first
[11:41] <jelmer> jam: ah, yes
[11:41] <jelmer> jam: of course
[11:41] <jam> jelmer: the search you were proposing was "give me the newest 100 revisions" not "give me the oldest 100 revisions that I don't have"
[11:42] <jam> I understand why you want the latter, but that isn't easily constructed from a tip
[11:42] <jam> also, how would you pass that to something like git ?
[11:42] <jam> I thought it could only fetch everything from the tips it has
[11:42] <jam> (it reports to you)
[11:42] <spiv> jelmer: Perhaps make_fetch_spec() would sometimes use this new fetch spec, but that seems like a largely orthogonal issue
[11:43] <jelmer> jam: yes, it can only give you everything but bzr-git can limit the amount it fetches to the bzr repository
[11:43] <jam> jelmer: by staging it?
[11:44] <jelmer> jam: importing the git pack file to bzr is fairly slow (getting better, but not ideal yet)
[11:44] <jelmer> jam: refetching the pack each time at the moment
[11:44] <jam> jelmer: so it gets the full ancestry stream, and then strips it?
[11:44] <jelmer> yeah
[11:44] <spiv> jelmer: AIUI the issue you're tackling is you have some code that would like to call "source.fetch(fetch_spec=<something>)", and needs to be able to have a <something> that means "limited to <some limit>"
[11:44] <jelmer> jam: It's not ideal, but this is what already happens on the Launchpad importds atm
[11:45] <spiv> jelmer: so the questions are a) what object is <something>, and b) how do you make one?
[11:45] <jam> jelmer: what *I* would like to see, even for bzr-core, is the ability for a fetch stream to say "you should have a complete snapshot up to rev X, feel free to commit it"
[11:46] <jam> we can already interleave Revisions then inventories, then texts, then send more revisions (IIRC)
[11:46] <jam> it would be nice to have revs, invs, texts, COMMIT, revs, invs, texts
[11:46] <jam> that would also allow resumable "bzr branch"
[11:46] <jelmer> jam: that'd be nice
[11:47] <jam> and possibly make it cheaper to compute fetch streams
[11:47] <spiv> jelmer: one approach is "class MostRecentNRevsNotAlreadyInTarget(AbstractSearch): def __init__(self, n, target_repo): …" that just does a regular breadth-first walk in its .execute() and so returns a regular SearchResult
[11:47] <jam> in that the streaming code could find what needs to be sent, but then break it up to commitable chunks
[11:47] <jam> and then it doesn't have to look at all 5Million chk pages across all 100k revisions
[11:47] <jelmer> jam: it's different from this though - the fetch limit goal is mainly there to avoid resource issues
[11:47] <spiv> jelmer: another approach is define a new SearchResult (rather than a new Search), along the lines of PendingAncestryResult
[11:48] <jam> spiv: jelmer and I just realized that he wants OldestNRevsNotAlreadyInTarget()
[11:48] <jam> which is quite different
[11:48] <jelmer> spiv: Sorry for being vague - I'm after the oldest revs rather than the newest
[11:48] <jelmer> or what jam said :)
[11:48] <spiv> jelmer: ah, interesting.
[11:49] <spiv> I could imagine something like OldestNRevsOfPendingAncestryResult
[11:50] <spiv> Where you specify not just the heads you want, but the heads you've already got
[11:50] <spiv> Normally we don't like calculating heads for the target because it's not cheap
[11:51] <spiv> But if you've just grabbed a OldestNRevsOfPendingAncestryResult stream you can keep track of the heads so far as you receive them.
[11:52] <jelmer> spiv, ah, hmm
[11:52] <jam> spiv: true, and you could also use an existing branch target as a Head to seed
[11:52] <spiv> It's a bit rough on the stream source (i.e. the server), it will have to keep walking back from the current tip all the way back to your heads each round.
[11:52] <jam> right now fetch is missing Branch <=> Branch info
[11:52] <jam> as it tends to just be done at the Repo level. I would *like* to at least hint at target heads.
[11:52] <spiv> But that's perhaps just the price someone has to pay for breaking the work up into chunks.
[11:52] <jam> Though we'de need to do something with that.
[11:53] <spiv> Yeah, having more info about the target heads available there would be good.
[11:55] <jelmer> lunchtime here, I'll have a closer look at it this afternoon
[13:00] <mrevell> Hello/nick mrevell-lunch
[13:01] <mrevell> Oops
[15:09] <bugreporter> hi everybody
[15:10] <bugreporter> any experts here ?
[15:10] <bugreporter> qor non-experts ?
[15:11] <bugreporter> wel ...
[15:11] <bugreporter> i'd like to know what "pending merge tips" are
[15:12] <bugreporter> i believe the reason why they are in my directory is that .......
[15:13] <bugreporter> the directory is a checkout from a local branch which is a "branch" of a public branch
[15:13] <bugreporter> and i wanted to merge the branch updates with my local changes but accidentally did a pull
[15:14] <bugreporter> now my locally commited changes disappeared from the log but they are still in the files
[15:15] <bugreporter> bzr diff shows all of them in one diff ...
[15:15] <bugreporter> ... bzr status -v shows all the commit messages
[15:15] <bugreporter> now another more important question:
[15:21] <vila> ...
[15:21] <vila> his commits are still there but he is not anymore so he can't know...
[15:24] <vila> bugreport: were you called bugreporter a few minutes ago
[15:24] <vila> ?
[15:24] <bugreport> ... all   ...    dädädä  ...
[15:24] <bugreport> yes
[15:24] <bugreport> .... merge tips
[15:24] <bugreport> sorry
[15:25] <bugreport> do you know anything about merge tips, villa
[15:25] <bugreport> ?
[15:25] <vila> (more personalized nicks are available and easier to recognize ;)
[15:25] <vila> yes
[15:26] <vila> when you do a merge, 'bzr status' reports the tip of the branch you merged so you can keep track of where you are
[15:26] <vila> you triggered a merge when you did the pull in your checkout
[15:26] <bugreport> "the tip of the branch I merged " ... yes ...
[15:27] <bugreport> what i fail to understand is why my commits are not in bzr log output
[15:27] <vila> so your previous commits were merged, you still need to commit to finish the merge
[15:27] <vila> because they are pending
[15:28] <bugreport> aaaah ... ok ... but ...
[15:28] <vila> they will appear after you commit
[15:28] <vila> well,
[15:28] <bugreport> now when i do a merge, they will be "condensed" ...
[15:28] <vila> no
[15:28] <vila> or
[15:28] <bugreport> no ? .....
[15:28] <vila> well, really no
[15:28] <vila> but by default bzr log will only report the merge
[15:29] <vila> do 'bzr log --include-merges' to see them
[15:29] <bugreport> and where will the commit message of the merge commit show up and where the others ...
[15:29] <bugreport> thanks
[15:29] <bugreport> ok ... think i just got the answer from you
[15:29] <vila> there all there, one level down
[15:29] <vila> they are all...
[15:30] <bugreport> have to read about include-merges ...
[15:30] <vila> yeah, try 'bzr log --help'
[15:31] <bugreport> ~ shows all revisions, also those not in the mainline ...
[15:31] <bugreport> which means bzr pull also made the "remote" the mainline ...
[15:31] <bugreport> sort of
[15:31] <bugreport> can i make my local changes "mainline" again ?
[15:32] <bugreport> (and how ?)
[15:32] <vila> if you're sharing the remote branch with others, you don't want to do that
[15:32] <bugreport> i don't have  write access to remote
[15:32] <vila> well, unless you can convince them that's you're the boss and they just have to listen ;)
[15:33] <bugreport> am just trying to get my local branch ready to publish on launchpad
[15:33] <bugreport> remote is on savannah.gnu.org
[15:33] <bugreport> i think i could publish my stuff on launchpad ... ? can i ?
[15:33] <vila> sure
[15:34] <bugreport> :-) you have any suggestions on how i should proceed with that from here ...
[15:35] <vila> hmm
[15:35] <bugreport> i would finally do something like "bzr push lp:~bugreport-mailinator/grub/sector-ranges" ... or can i just publish to "+junk" ??
[15:35] <vila> better to publish in the project namespace
[15:36] <vila> if only because you will be able to do a merge proposal against the project trunk
[15:36] <vila> hmm
[15:36] <bugreport> do have write access there (default / without any further actions ...
[15:36] <vila> as long as savannah and lp agree about what the trunk is
[15:36] <bugreport> i thought it's savannah but am not sure ...
[15:37] <bugreport> they differ quiet a bit ... anyway ... in terms of bzr commands ... how to get my local changes branch to be "mainline" again here on my laptop ?
[15:38] <vila> https://code.launchpad.net/~vcs-imports/grub/main seems to say that it's a mirror from gnu.org so that should be in sync
[15:38] <vila> back to your goal:
[15:38] <vila> you can:
[15:39] <bugreport> (by "differ" i mean, there are commits inn launchpad/ubuntu which are not in the trunk on savannah )
[15:40] <vila> if you commit now, that will create a revisions whose parents will be (savanah tip, your last commit)
[15:40] <vila> what you want is (your last commit, savannah tip)
[15:40] <bugreport> exactly ....  got me
[15:40] <vila> hmm,
[15:40] <bugreport> :-) difficult enough ?
[15:41] <vila> the shortest way that comes to mind is to recreate a branch with a tip at your last commit
[15:41] <vila> and merge savannah branch there, commit and you'll get the right pattern
[15:41] <vila> now, to get back your tip...
[15:42] <vila> you can just commit and see what revno you get there :)
[15:42] <vila> there are other ways but this one is the simplest for you I think
[15:42] <bugreport> hmm...
[15:42] <bugreport> lets commit ...
[15:43] <bugreport> it's +1 from before ...
[15:43] <bugreport> so savannah-trunk+1
[15:43] <vila> look at 'bzr log --include-merges' now
[15:44] <bugreport> +10 from my old tip
[15:44] <vila> yup, commit always create a +1 revno by definition
[15:44] <vila> forget about the numbering of your old tip, you broke it
[15:44] <bugreport> old tip commitsss all have the same revno
[15:44] <bugreport> :-)
[15:45] <vila> they shouldn't, are you sure you used --include-merges ?
[15:45] <vila> if in doubt, just pastebin the output
[15:45] <vila> !paste
[15:46] <bugreport> all right ... but i can switch branches and have the old commits seperate ... ? (if not it doesn matter much ... nothing interresting in the commit messages ... all just "wip" but out of interrest ...
[15:46] <bugreport> http://paste.ubuntu.com/606520/
[15:47] <vila> yes you can (unless I totally misunderstood what happened)
[15:47] <vila> right, so they don't have the same revno: 3245.1.1 is different from 3245.1.2
[15:47] <bugreport> :-) didn't read the output before ...
[15:47] <vila> to get back your old branch just do:
[15:48] <vila> bzr branch . -r3245.1.27 ../my-dear-old-branch
[15:49] <vila> and, yeah, I'm sure the people you'll share this branch with will be more than happy to find commit messages providing a bit more info than wip ;-D
[15:49] <bugreport> cool ... wroked
[15:50] <bugreport> i have to write some ... and condense some commits ... make around 5-10 out of those ...
[15:50] <bugreport> :-) ... you helped me a lot already ! thank you! ..
[15:51] <bugreport> .. anyway if you know how to write nice commit messages onto those changes and reorganize them ... ??
[15:51] <bugreport> "git rebase -i" ...
[15:52] <vila> haaaaa... that's why it's so popular !
[15:52] <bugreport> very likely
[15:52] <vila> there is 'bzr shelve --interactive' I think
[15:53] <bugreport> ok ... sounds good
[15:53] <bugreport> not in my version though ...
[15:54] <bugreport> (natty 2.3.1)
[15:54] <vila> but shelve works for uncommitted changes, so you'll have to get them back first
[15:54] <bugreport> (at leas not in help output ...
[15:54] <vila> err, wth
[15:54] <bugreport> :-) pull ?
[15:56] <vila> hmm, no cherry pick instead probably
[15:57] <vila> i.e. start with a branch from savannah and there do:
[15:57] <bugreport> googling for "git rebase bzr" leads me to a plugin ... bzr-rewrite"
[15:57] <vila> yup, but I don't think there is an --interactive option there, does it ?
[15:58] <bugreport> http://marcin.juszkiewicz.com.pl/2010/10/06/bazaar-what-is-wrong-with-it/
[15:58] <bugreport> no idea ...
[15:58] <jelmer> --interactive is imho not really appropriate on the rebase command, as it's a general way to reshape the revision graph
[15:58] <vila> bzr merge ../my-dear-old-branch -r<first-rev>..<last-interesting-rev>
[15:58] <bugreport> go ahead with the cherry-pick solution ... sounds reasonable
[15:58] <jelmer> I'm happy to have another command in bzr-rewrite that does a similar thing though
[15:59] <vila> jelmer: Did I dream the shelve --interactive ?
[15:59] <awilkins> vila, shelve is interactive by default, no?
[16:00] <vila> bugreport: bzr diff will show your changes, bzr st will allow you to verify that there is no pending merges, you're just getting the changes without tracking the history
[16:00] <vila> awilkins: dunno, I always use --all
[16:00] <vila> awilkins: because I can't use the interactive mode under emacs (where I have alternative workflows that work better for me)
[16:01] <vila> bugreport: so once you have the uncommitted changes, try 'bzr shelve' and follow the prompts ;)
[16:02] <jelmer> vila: there is a bzr-interactive plugin that allows interactive shelving I think
[16:02] <bugreport> i was about to check out ("merge") a fresh savannah trunk and the do "bzr merge ../my-dear-old-branch -r<first-rev>..<last-interesting-rev>" repetingly ... ??
[16:02] <vila> jelmer: haaaa, thanks, bugreport ^
[16:03] <vila> bugreport: you create a branch once, you repeat the merge ; hack;shelve;commit;unshelve;
[16:03] <bugreport> ups --- i meant ("branch") of course ...
[16:05] <jelmer> vila: it does a completely different thing from "git rebase -i" though
[16:07] <vila> bugreport: branch and checkout are two different things but if the checkout led you to the trap, you may prefer branch and come back to checkout later (bzr reconfigure can help switch from one to the other)
[16:07] <bugreport> well ... i will approach the task later on  ....
[16:08] <bugreport> i branched / not chekout actually ...
[16:08] <bugreport> i was just not aware that pull would do a different kind of merge then merge ...
[16:08] <vila> bugreport: or you may just push your branch to lp, not everybody cares about the intermediate commits
[16:09] <vila> bugreport: pull should warn you to use merge if it can't pull in a branch
[16:09] <bugreport> yea ...
[16:09] <vila> bugreport: checkouts are different
[16:09] <bugreport> ok - have to go - see you ...
[16:09] <bugreport> and thanks again
[16:09] <vila> bugreport: they are targeted at people used to the centralized workflow where the local changes don't show up on the mainline
[16:10] <bugreport> hmmmm ....
[16:10] <bugreport> i kind of dont like that "compatibility" in bzr
[16:10] <vila> bugreport: just use plain branches then
[16:11]  * awilkins likes "lightweight" checkouts used to approximate gits co-located branches thing
[16:11] <vila> bugreport: I suspect you *did* use a checkout to end up in this "mess"
[16:11] <vila> awilkins: please :) Don't add confusion ;)
[16:11] <bugreport> distriibuted is a new paradigm which is not really hard to get and you should switch when using a dscm
[16:12] <vila> bugreport: not everybody has the luxury to do that
[16:12] <vila> bugreport: *I* never use checkouts, but I don't forbid others to ;)
[16:12] <bugreport> i have a shared repo on top and "savanna-trunk" and "my-branch" inside ...
[16:12] <vila> bugreport: perfect setup :0
[16:12] <bugreport> shared repo created with "bzr init-something ..."
[16:13] <vila> init-repo
[16:13] <bugreport> :-) good to know it's approved
[16:13] <vila> hehe
[16:13] <bugreport> cu then ... bye
[16:13] <vila> we want to make it easier to get it as the default one
[16:13] <vila> cu
[17:12] <chriscauser_> Hello all again. Sorry to pester (and I hope this is a quick one) but I don't know how to use bzr+svn with keyring auth for http simple. Is there a verbose flag that would tell me what it's trying on the auth front?
[17:13] <jelmer> chriscauser_, hi
[17:13] <jelmer> chriscauser_, GNOME keyring?>
[17:13] <chriscauser_> jelmer: yes indeed.
[17:14] <jelmer> chriscauser_, bzr can only use existing keyring credentials, it won't add new credentials to keyrings at the moment
[17:15] <chriscauser_> jelmer: Ah, this might be it. It seems to checkout the repo just fine in svn though.
[17:15] <chriscauser_> (as in I have put the credentials in the keyring already by doing an svn checkout)
[17:16] <jelmer> chriscauser_: it should in any case prompt you, even if it can't already find the crednetials
[17:16] <jelmer> also, I can't spell
[17:18] <chriscauser_> jelmer: don't worry. I'm explaining it very badly. My problem is more of an annoyance than anything else. Any remote  operation requires me to enter a password. svn checkout works fine because the pw is cached in the keyring. Is there a way of getting the same behaviour?
[17:18] <chriscauser_> jelmer: It used to work when I had the pw stored in plaintext in ~/.subversion (obviously not ideal)
[17:19] <jelmer> chriscauser_: I'm not sure
[17:19] <jelmer> chriscauser_: If you can use svn with the keyring credentials then that obviously means that the credentials are there and valid
[17:19] <jelmer> so I'm not sure why the keyring integration in bzr-gtk is not working properly
[17:20] <chriscauser_> jelmer: Is there a debug that I can run?
[17:20] <jelmer> chriscauser_, it's been a while since I've worked on the keyring stuff
[17:20] <jelmer> chriscauser_, I'd recommend adding some pdb statements in the code in bzr-gtk to see what entry it is looking at
[17:20] <jelmer> and then comparing that with what the gnome-keyring-manager thinks is present
[17:23] <chriscauser_> jelmer: OK. I'll get back to you on this.
[17:53] <chriscauser_> jelmer: I think I have it. svn seems to be storing the credentials in the keychain differently to how bzr-svn is expecting to read it.
[17:53] <chriscauser_> I have got it working, and can give you a patch if you want
[17:53] <chriscauser_> The only problem is I don't know if it is because subversion has changed the way it stores things (I'm on Lucid) so I may break things for other people
[17:56] <Buttons840> i have *.pyc in my ignore file, but pyc files still show in subdirectories?
[17:56] <Buttons840> do i do */*.pyc or something?
[17:57] <jelmer> chriscauser_: I don't think it has - a patch would be great :)
[17:58] <Buttons840> is bzr written entirely in python?
[18:02] <chriscauser_> jelmer: I'm forking bzr-svn and will create a merge proposal for you if that's OK with you.
[18:02] <jelmer> chriscauser_: You mean bzr-gtk?
[18:02] <jelmer> Buttons840: Do you mean whether "bzr status" shows them?
[18:03] <chriscauser_> jelmer: Yes, you're clearly psychic because you understand what I mean, not what I write :)
[18:04] <jelmer> chriscauser_: :)
[18:07] <Buttons840> jelmer: yes, but i solved it, i put "**/*.pyc" in .bzrignore
[18:15] <vila> Buttons840: that;s weird because  I have '*.py[co]' in my ~/.bazaar/ignore and I *never* see any .pyc...
[18:16] <chriscauser_> Buttons840: I may be corrected on this but if these pyc files are already versioned, they will continue to be after the .bzrignore file has them included. Are these files versioned?
[18:17] <jelmer> chriscauser_: yeah, that's correct
[18:19] <chriscauser_> jelmer: I'm hitting a brick road with this patch. I think the problem is that the changes I make will stop auth for bzr over https. As I can tell, there is no way that bzr-gtk can see if the auth request is for an svn repo or a bzr one :$
[18:19] <chriscauser_> cd
[18:20] <chriscauser_> Duh, wrong window
[18:20] <jelmer> chriscauser_: should it have to know whether it is for a svn or a bzr repository?
[18:20] <jelmer> chriscauser_: Can you perhaps show the patch so far?
[18:21] <chriscauser_> jelmer: No, I think that's the problem. bzr (I assume because I have no way of testing it) stores creds in a particular format. svn stores it in another.
[18:22] <jelmer> chriscauser_: In what way are they different?
[18:22] <jelmer> I think it might be reasonable to adjust the way in which bzr-gtk retrieves the credentials if that matches something that is more commonly used
[18:22] <jelmer> I doubt there are a lot of people actually using it yet (since we don't actively store credentials), and the bug you've hit is something that more people have complained about
[18:23] <chriscauser_> lp:~chy-causer/bzr-gtk/fix-svn-keyring
[18:25] <jelmer> hmm, it stores domain as realm?
[18:26] <jelmer> the other way around I mean
[18:26] <chriscauser_> indeed
[18:26] <jelmer> I wonder what things like epiphany use
[18:28] <chriscauser_> jelmer: That would be interesting.
[18:29] <jelmer> chriscauser_: http://live.gnome.org/GnomeKeyring/StoringPasswords
[18:29] <jelmer> chriscauser_: So, according to the documentation "domain" is actually the appropriate thing to use
[18:30] <jelmer> chriscauser_: So we should probably be setting that unconditionally, rather than special casing http/https
[18:30] <chriscauser_> jelmer: Very interesting!
[18:32] <chriscauser_> jelmer: So you would have to check if the scheme were http(s) though to remove the protocol and server attributes (which aren't in the keyring)
[18:35] <chriscauser_> jelmer: Hmm. grepping the codebase makes me think there is no way of setting keyring keys, so a merge proposal wouldn't be too disastrous
[18:40] <chriscauser_> jelmer: I've updated the code so now all requests will have the 'domain' key
[18:41] <jelmer> chriscauser_: cool, I'll have a look
[18:44] <jelmer> chriscauser_: Does it still work if you also set protocol and server?
[18:44] <chriscauser_> jelmer: Unfortunately not. I got a gnomekeyring.NoMatchError, because those keys aren't specified by svn
[18:44] <jelmer> Hmm, that's a bit annoying
[18:45] <chriscauser_> This was what was making me uneasy: there's potential here to stomp all over people who are using bzr over http
[18:45] <chriscauser_> without svn
[18:45] <jelmer> chriscauser_, I don't think there are a lot of those to be honest
[18:45] <jelmer> chriscauser_: either way, perhaps we should consider trying multiple combinations
[18:46] <chriscauser_> jelmer: I think you may be right.
[18:46] <chriscauser_> jelmer: yes, I don't think this code is in any way thoroughly tested. The only problem is that my testbed is a little limited.
[18:46] <chriscauser_> jelmer: especially since almost everything I do uses ssh keys
[18:51] <chriscauser_> Right, I'm off now. jelmer: thank you for all your help.
[18:52] <jelmer> chriscauser_: Any chance you can create a MP for your branch?
[18:53] <jelmer> chriscauser_: Even if it's not perfect (yet), it should help us remember to get this code in.
[18:53] <chriscauser_> jelmer: Absolutely.
[18:53] <jelmer> chriscauser_: Thanks :)
[18:57] <chriscauser_> jelmer: https://code.launchpad.net/~chy-causer/bzr-gtk/fix-svn-keyring/+merge/60817
[19:03] <chriscauser_> jelmer: Well, anyway hope that helps. See you!
[19:10] <screen-dsuch> Hm, whom to let know that http://wiki.bazaar.canonical.com/BzrPlugins links to http://doc.bazaar.canonical.com/plugins/en/rebase-plugin.html which 404s?
[19:12] <screen-dsuch> ah alright http://wiki.bazaar.canonical.com/JelmerVernooij
[19:25] <hfitzgerald> hey, sorry if this question has been asked to death. I've got a bunch of configuration files that I dont want to track the changes to, but that I do want to be included in checkouts/uploads. Whats the best way to accomplish this?
[19:35] <jam> hfitzgerald: the method I've seen work the best is to version a template version, and ignore the real version
[19:35] <jam> so foo.conf.template gets version controlled
[19:35] <jam> and people do cp foo.conf.template foo.conf to actually use it.
[19:39] <hfitzgerald> ahhh
[19:39] <hfitzgerald> thanks jam, that makes sense
[19:39] <fullermd> (and ignore foo.conf)
[19:40] <fullermd> A common setup in my projects is that my code tries to load something like foo.conf, and if it's not there, falls back to foo.conf.default.  Then I can version control .default, and most of the time that's fine.  But if I ever need local changes, I can make the foo.conf in that particular copy.
[19:43] <idnar> so I'm busy making some changes in a feature branch, and I decide that some changes I just made really belong in their own branch; what's the easiest way to "extract" them?
[19:43] <idnar> something with bzr shelve?
[19:43] <fullermd> Just made as in "haven't committed yet"?
[19:44] <LeoNerd> shelve is for saving-and-reverting changes, so they no longer appear for now.
[19:44] <LeoNerd> So you can unshelve them again later
[19:44] <idnar> fullermd: I have committed them
[19:44] <fullermd> Ah.  Well, I'd try cherrypicking the rev then.
[19:44] <idnar> the branch hasn't been published anywhere, though, so I don't mind a solution that involves revision surgery or whatever
[19:45] <fullermd> (then either uncomitt'ing it away and merging the new 'authoritative' version in, or just ignoring it and letting the merge at the end deal with it)
[19:46] <idnar> what I was thinking of doing is branching a copy of the branch, uncommitting everything, shelving the changes I want, reverting the rest, unshelve/commit, and then replaying the original branch on top of the new one
[19:47] <idnar> er, I think I mean rebasing, not replaying
[19:47] <fullermd> If you've got multiple revs on both sides, it may be worth investigating the rewrite plugin.
[19:47]  * fullermd doesn't really know any details on that side of things.
[20:17] <idnar> bleh, shelve can't split hunks
[20:21]  * vila split hunks in diff-mode
[20:22] <fullermd> Well, that doesn't mean you have to talk about it in public...   ew.
[20:22] <vila> but I'm ~80% sure someone said it was able to split hunks with <insert the plugin I can't remember here>
[20:22] <vila> s/it was/*he* was/ grr
[20:24] <vila> fullermd: yeah, I almost used the . o O () syntax
[20:24] <vila> fullermd: I'm still allowed to *think* in public right ?
[20:25] <fullermd> I'm not sure you're even allowed to think in private   :p
[20:26] <vila> hmpf
[20:31] <lifeless> vila: vimdiff thingy
[20:41] <vila> idnar: looks like I wasn't mad after all: https://code.launchpad.net/~abentley/bzr/shelve-editor/+merge/13819
[20:41] <abentley> vila: that functionality's part of bzr nowadays.
[20:42] <vila> abentley: exactly :)
[20:42] <vila> abentley: how come it's not mentioned in the help ?
[20:42] <idnar> not in the bzr I have here, apparently :/
[20:42] <abentley> idnar: have you configured a change_editor?
[20:42] <vila> abentley: and does it require a special setup to become apparent ?
[20:43] <idnar> oh, right; probably not
[20:43] <abentley> vila: yes, it does.  'e' isn't provided if you haven't configured a change_editor.
[20:43] <idnar> bingo
[20:43] <vila> abentley: thanks, I vaguely remembered something. Now I won't forget (hopefully).
[20:43] <idnar> oh, but that's rather confusing; if you push "?" at the interactive prompt, there's no mention of the e and f commands
[20:44] <idnar> *of the e command
[20:44] <idnar> anyhow, cool, that should do the trick
[20:44] <idnar> I see it's mentioned in the help for "bzr shelve", I guess I should pay more attention to what I'm reading
[20:44] <vila> idnar: file a bug, this should at least be better documented
[20:45] <vila> AAAARGH, I can't read !!!
[20:45] <idnar> heh heh
[20:45] <idnar> at least I'm not the only one ;)
[20:46] <vila> I searched for it right there a couple of hours ago :-(
[20:46] <abentley> vila, idnar: we could list 'e' all the time, and then error when no change_editor is configured.
[20:48] <vila> abentley: that may have helped idnar , I can't be cured ;)
[20:48] <idnar> yeah, that would be nice
[20:48] <idnar> the "?" display should also be fixed
[20:48] <idnar> (I would file a bug, but I'm currently on an extremely thin internet pipe)
[20:51] <vila> bug #781871
[20:53] <vila> Argh, test suite broken for 2.3.2 :-(
[20:53] <vila> FAILED (errors=1093, skipped=2312, expected failures=35)
[20:54] <vila> poolie: ping
[20:55] <vila> bug #760435 needs to be backported
[20:55] <vila> to the 2.3 series
[20:56] <abentley> idnar: You can file bugs by email: https://help.launchpad.net/Bugs/EmailInterface
[20:57] <idnar> abentley: gpg-signing mail from gmail is tedious :(
[20:58] <idnar> (and it's not an @gmail.com address, so DKIM doesn't work either)
[20:58] <abentley> idnar: surprised gmail is tolerable over a thin pipe.
[20:59] <vila> gmail provides pop3/imap access and forwarding no ?
[20:59] <idnar> it's surprisingly workable as long as you don't have to actually load all the UI elements over the thin pipe, and I already had it open in my browser...
[21:00] <idnar> but I'm mostly reading my email at the moment via the Android client, which is pretty light on bandwidth
[21:00] <abentley> vila: why does that bug need to be backported?
[21:01] <vila> abentley: our SRU process requires the test suite to succeed
[21:01] <idnar> vila: yeah, and SMTP, but I don't actually have any of that set up in a mail client
[21:01] <abentley> vila: So you're saying that bzrtools 2.3 fails the test suite with bzr 2.3?
[21:02] <vila> abentley: no idea, I'm cutting 2.3.2 and testing bzr only
[21:02] <idnar> vila: I'm currently limping along on the trickle of 3G/HSDPA bandwidth I can get on my phone, since my fixed-line connection is down, so this isn't the normal situation for me
[21:02] <vila> idnar: np, I filed the bug already anyway ;)
[21:03] <vila> abentley: and of course pqm happily succeeded since it's python2.6 there :-(
[21:04] <idnar> vila: :)
[21:04] <vila> idnar: bug #781871


[02:41] <pace_t_zulu> hey guys
[02:41] <pace_t_zulu> is it true there is a kernel freeze tomorrow?
[02:42] <crimsun> yes, but in effect it's already in place
[02:50] <pace_t_zulu> crimsun, are you aware of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/535297 ?
[02:50] <ubot3> Malone bug 535297 in linux "BUG: unable to handle kernel NULL pointer dereference at<PHONE_NUMBER>000028" [High,Confirmed]
[02:51] <pace_t_zulu> Malone?
[03:48] <EruditeHermit> hello, can anyone help me with this error?
[03:48] <EruditeHermit> http://pastebin.com/Hnriax64
[04:09] <EruditeHermit> apparently its a bug with kernel package
[04:21] <netritious> Hi, is it possible to obtain the linux-headers packages for kernel version 2.6.32-15 ? They appear to be unavailable in the repository, but they are needed to workaround an issue a few are having with 2.6.32-16 and VBox.
[13:23] <apw> pace_t_zulu, Malone is the name of the launchpad software
[13:24] <apw> pace_t_zulu, ubot3 can translate other bug numbers scemes like CVE numbers and so prefixes its results with where it found things
[13:39] <pace_t_zulu> apw: thank you
[13:45] <smb> cking, So what other things. beside suspend resume can cause a tsc warp`
[13:45] <smb> ?
[13:45] <cking> smb, not sure what triggers it, but I've seen it on Atoms - you sometimes see TSC warp warnings.
[13:47]  * cking tries to think back 12+ months ago when he observed TSC issues on a N270.. hrm.. bit fuzzy
[13:47] <smb> Are those the that messages with -<huge number> marking tsc unstable?
[13:47] <cking> no - just small warping
[13:48] <cking> big warp only observed when coming out of S3
[13:48] <smb> Cause there is also the "Marking TSC unstable due to halts in idle", but probably thats the clocksource framework and not the things you looked at
[13:48] <apw> smb, the "two ack rule" things count as having two acks if they are sent by a core-committer and acked by one other ... right?
[13:49] <smb> apw, Usually not later. For now we could go with it
[13:49] <apw> rtg i've pushed qcm-msm branch into linux-meta ... you'll have to upload it the first time i guess
[13:50] <smb> apw, Thats why I usually pester two of you guys when I got a patch. :)
[13:50] <tgardner> apw, k
[13:50]  * apw pesters smb to look at tgardner's patch
[13:50] <apw> tgardner, i'll get the other one done now
[13:50] <cking> smb, if I recall, it's most probably an unstable TSC as reported by arch/x86/kernel/tsc.c
[13:50] <tgardner> apw, the patch for -virtual ?
[13:51] <smb> cking, Oh, so warp not only means warping around to 0 but also going faster forward or even back?
[13:51] <smb> apw, tgardner was busy which one
[13:51] <apw> tgardner, yeah am getting smb to review that
[13:52] <cking> warp to zero --> wrapping,  warping where TSC seems to jump back/forwards in a manner that's not expected
[13:53] <tgardner> cking, do you suppose that happens when ACPI is reefing on C states as well as S states?
[13:54] <cking> tgardner, can't say for sure, but it may be possible for C states too to affect it
[13:54] <tgardner> cking, that would make TSC well nigh unusable
[13:55]  * cking agrees
[13:55] <smb> It seems to be clear that tsc can halt in C states
[13:56] <cking> smb, have we any evidence of that - perhaps we need to get a script that tests for this
[13:56] <smb> cking, So that my problem. I havn't looked for some time but I thought that tsc is usually replaced by hpet for timer events
[13:57] <cking> smb, maybe so, but TSC does seem to be used for udelay by default if I understand the code correctly
[13:58] <smb> Right, probably we look/think of different usages
[13:59] <cking> ..hopefully not missing any out
[13:59] <smb> One thing is the clockevents framework for the monotonic and also the waking up/timer events (unfortunately its quite some time I looked at that code)
[14:01] <cking> if the only good reason for using the TSC is lower-latency in udelay then maybe an alternative mechanism in udelay can be used and we ditch the TSC
[14:11] <Q-FUNK> smb: it seems that AMD decided to get involved and contact the FIC engineering team themselves to solve bug #396286.
[14:11] <ubot3> Malone bug 396286 in linux "[Geode LX] [ION603] 2.6.31-generic: kernel panic near the end of initramfs" [High,In progress] https://launchpad.net/bugs/396286
[14:11] <Q-FUNK> one thing I'm wondering:  what tools do we have to probe the BIOS and print the manufacturer and build date, etc.?
[14:12] <smb> Q-FUNK, sudo dmidecode
[14:12] <smb> It would be nice to have someone look at that with some low lever hw information
[14:12] <smb> Cause it looks like from a sw point of view I don't get farther
[14:15] <Q-FUNK> smb: I suspected as much. Thanks for trying.
[14:16] <smb> Q-FUNK, I hope at least the information we have can help there
[14:16] <Q-FUNK> at least, the good news is that AMD considers what's left of the Geode market to be wrothy of salvaging enough to contact FIC themselves.
[14:16] <Q-FUNK> hopefully, yes
[14:17] <Q-FUNK> and it indeed seems that otavio was correct when he said that none of his other Geode hardware showed the symptoms.
[14:19] <Q-FUNK> the program manager for AMD's embedded chips appologized on behalf of AMD, especially for the downfall of laying off Jordan Crouse, back then, and for having momentarily left Geode support in Linux and X.org in limbo.
[14:20] <Q-FUNK> they now have one guy in US and a whole team in Taiwan working on both issues.
[14:20] <smb> sweet
[14:20] <Q-FUNK> they're barely coming up to speed on the basics of e.g. using git, but I have a feeling that it's only a question of time before things fall back into place.
[14:21] <Q-FUNK> my only worry is whether any of those issues will be fixed on time for Lucid's release or not.
[14:21] <Q-FUNK> I'd rather avoid the situation we had with the X driver on Hardy having to be resucitated after Hardy was released, but well...
[14:23] <smb> It would have to be really fast to hit Lucid release. On the (maybe not  completely satisfying) side at least LTS gets a few point updates which rebuilds cd's
[14:24] <apw> smb, in the first bit of good news of the day ... i plugged and external monitor into my lucid box and it didn't GPU hang on me ... so we do have the fixes :)  you are on there now
[14:24] <smb> apw, \o/
[14:24] <Q-FUNK> \o/
[14:25] <apw> actually i've missed having IRC always visible
[14:25] <apw> amitk, in mutt-patched how often do the stats on the left update ?
[14:25] <Q-FUNK> apw: you position your IRC app in the second display?
[14:26] <apw> Q-FUNK, i have today ... its 'only' 1280x1024 so too small for working on
[14:26] <amitk> apw: you mean the unread count?
[14:26] <apw> amitk, yeah the numbers over there
[14:27] <amitk> apw: only when I move my 'cursor'
[14:27] <amitk> or open another mail folder
[14:27] <apw> as in C-n C-p in that left panel
[14:27] <amitk> right
[14:27] <apw> cool better than not seeing them
[14:27] <amitk> you don't see them?
[14:28] <Q-FUNK> apw: I wonder if I can do the same on this laptop running -intel.  when I'm at home, I'd love to slide specific apps on a separate display.
[14:28] <apw> no i do, i mean them updating only when i take action is better than not seeing them at all as i was without -patched
[14:28] <apw> Q-FUNK, works for me, this is a laptop.  added external, ran xrandr, and poop my desktop got wider
[14:29] <Q-FUNK> apw: interesting.  do you get separate desktops or just one large virtual desktop area?
[14:29] <apw> in the bad old days i used the 'tiny' laptop screen for irc et al and my 'huge' monitor for work ... but now my internal is bigger ...
[14:29] <apw> all one desktop you can have windows spanning the break
[14:30] <Q-FUNK> hm.  ok. any way to have separate desktops, like in the old days?
[14:30] <Q-FUNK> IIRC with xineramara we had separate desktops.
[14:31] <apw> its not the default, i am sure its possible somehow, you'd have to ask on #u-x
[14:31] <apw> as this is what i wanted, i am not moaning
[14:33] <Q-FUNK> :)
[14:33] <Q-FUNK> hm.  due to the timezone difference, my e-mail exchanges with AMD Taiwan are pracically real-time.  pity their firewall prevents them from using IRC.
[14:42]  * apw reboots to test a kernle
[15:03] <tgardner> apw, strange install problem on Karmic when installing a Lucid kernel: 'linux-image-2.6.32-16-server depends on binutils (>= 2.20.1)'
[15:04]  * apw blinks
[15:04] <tgardner> its not like we're still doing dynamic linking
[15:05] <apw> tgardner, /me investigates
[15:06] <apw> tgardner, is that a binary from the archive or one you made
[15:06] <tgardner> apw, from my archive mirror
[15:06] <smb> apw, Could that be because of linux-tools?
[15:06] <tgardner> linux-image-2.6.32-16-server_2.6.32-16.25_amd64.deb
[15:07] <tgardner> smb, linux-tools is a 'suggests'
[15:07] <apw> smb, linux ... what he said
[15:07] <apw> tgardner, i don't have that dep on a local build
[15:08] <smb> apw, In one of my past attempts I was unable to install the kernel image without linux-tools
[15:08] <apw> tgardner, can you less the package and paste your Depends: line
[15:08] <apw> smb, yeah it changed
[15:08] <tgardner> apw, Depends: binutils (>= 2.20.1), binutils (<< 2.20.2), libc6 (>= 2.8), libelf1 (>= 0.131), initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.3-pre11-4ubuntu3), wireless-crda
[15:09] <tgardner> its gotta be from ${misc:Depends}, ${shlibs:Depends}
[15:09] <apw> wtf ? _two_ binutil depends
[15:09] <apw> tgardner, which is the problem one ?
[15:09] <tgardner> pretty tight constraints :)
[15:10]  * apw wonders why i have none on my local builds ... arrrg
[15:10] <tgardner> binutils (>= 2.20.1)
[15:11] <tgardner> we kind of have to figure this out lest it raise hell with the kernel backports
[15:11] <apw> well actually i suspect if you build it in a karmic chroot it'll be fine
[15:12] <tgardner> apw, ok I'll do that
[15:12] <tgardner> which is really the right solution anyway
[15:12] <apw> yeah we would be building them there .. but why do we have such tight contraints from that
[15:13] <tgardner> apw, I think its coming from the wildcard dependencies. I'll have to read up on them
[15:14] <tgardner> apw, while we're at it, we should reexamine the 'Provides:' boilerplate. most of that stuff is no longer accurate.
[15:16] <apw> tgardner, annoyingly for the linu-image package i put both those general defs together so we cannot tell by the position of the deps if some is from one or the other
[15:16] <apw> but i suspect it is cause of the perf binary in there, it is tying us to the current binutils version
[15:16] <apw> tgardner, i am starting to think it needs to come out into its own package
[15:17] <tgardner> apw, right, but as you've pointed out the backports will get build in a Karmic environment anyways
[15:17] <apw> into linux-tools flavour package
[15:17] <apw> yeah. makes testing kernels on the wrong series a lot harder though
[15:17] <tgardner> indeed
[15:17] <apw> to it might make sense to pull it out to its own package
[15:17] <apw> i will have a look how horrid that would be
[15:18] <tgardner> yeah, its not like there is any real binutils dependency, is there? initrams doesn't use it, right?
[15:18] <apw> nope ... its just cause of the binary i am sure ... perf
[15:19] <apw> i'll pull it out and see if the deps get better
[15:19] <apw> tgardner, what is a bit whack is my local builds have different deps:
[15:19] <apw>  Depends: libc6 (>= 2.8), libelf1 (>= 0.131), initramfs-tools (>= 0.36ubuntu6), coreutils | fileutils (>= 4.0), module-init-tools (>= 3.3-pre11-4ubuntu3), wireless-crda
[15:20] <apw> they would preclude install on karmic too, but they arn't the same which is most wack
[15:20] <tgardner> why is the buildd different?
[15:20] <tgardner> apw, could be we're just tilting at a windmill here
[15:21] <apw> yeah i am not sure
[15:21] <apw> i guess i need to review that chroot and rebuild it
[15:22] <apw> i'll go split it out and we can see how it looks
[15:23] <apw> it didn't seem sensible to have a separate package for one bin kernel version locked, but these deps will hurt our testing and so its prolly worth the pain
[15:24] <tgardner> apw, yeah, but linux-tools doesn't have an ABI so how will you keep perf in sync?
[15:24] <apw> linux-tools is the binary independant bits
[15:24] <tgardner> oh, you mean a separate package just for perf?
[15:24] <apw> we'd ahve to have a kernel matches binary package for the tool  linnux-tools-15-generic, move linux-tools to linux-tools-common
[15:25] <apw> and have a linux-tools meta package
[15:25] <apw> yeah thats the proposal.  i thought i'd try it and see how vile it was
[15:25] <tgardner> what a pain in the ass
[15:25] <apw> yeah... it probabally would have been the 'right' way to do it, we were lazy and it bites us on the ass
[15:44] <manjo> apw, smb brb
[16:10] <tgardner> apw, so, a Lucid kernel installs better when built under Karmic
[16:10] <apw> good
[16:10] <tgardner> now lets see if it withstands a stress pass
[21:48] <cnd> apw: you remember anything that went in -16 that would cause bug 536858?
[21:48] <ubot3> Malone bug 536858 in linux "USB-Audio devices do not show up as input devices" [Low,Invalid] https://launchpad.net/bugs/536858
[21:51] <cnd> apw: nm, reporter invalidated the bug
[23:12] <Ng> are we aware of any virtio problems in lucid atm? I've been trying to install the alpha 3 iso image inside a virtio kvm on my lucid laptop and it gets to the package installation bit and ends up IO erroring itself read-only
[23:14] <daftykins> hi all, please excuse the newbie question... will Lucid be sticking with the 2.6.31 kernel through release and further?
[23:15] <RAOF> No; it will be sticking with the 2.6.32 kernel though.  There are plans to pull newer kernels in post-release, but I don't know details of that.
[23:16] <daftykins> ah yes my bad, typo/memory failure :) ah ok, thanks very much :)