[00:00] <lifeless> it will make subunit-ls clearer, so if you get the time to review, assume its gone :)
[00:00] <mwhudson> ronny: have you read "xUnit test patterns"?
[00:01] <lifeless> spiv: stacked [merge] sent
[00:02] <ronny> mwhudson: no
[00:03] <mwhudson> ronny: the first 100 pages or so is well worth reading for provoking thoughts about testing
[00:03] <ronny> hmm, added to my should read list
[00:04] <mwhudson> it's unfortunate that you have to buy the other 700 pages too :)
[00:04] <ronny> ew
[00:18] <edcrypt_> igc: ping
[00:22] <igc> edcrypt_: pong
[00:25] <edcrypt_> igc: hi, I the one who made that bug report about views
[00:25] <edcrypt_> igc: what is the view-aware API to iterate on the WT?
[00:26] <igc> edcrypt_: there probably isn't one ...
[00:26] <igc> I tend to trap most things at the UI layer inside builtins.py ...
[00:27] <igc> so that the list of files is automagically passed to commands without needing to change their internals
[00:27] <igc> edcrypt_: there are exceptions though ...
[00:27] <lifeless> igc: shouldn't it filter at the tree?
[00:27] <igc> diff comes to mind
[00:27] <lifeless> igc: so that plugins work
[00:28] <igc> lifeless:it depends
[00:28] <igc> whether to use a filtered view needs to be considered on a case by case basis
[00:29] <edcrypt_> igc: WorkingTree..inventory.iter_entries_by_dir() gives all files, but probaly I shouldn't be using it
[00:30] <igc> edcrypt_: so if you look at the code for cmd_diff in builtins.py, you'll see it passed apply_view flag down to the next layer
[00:31] <igc> edcrypt_: you certainly can use that API, you'll just need to post filter the results by seeing if the path falls inside the view or not
[00:31] <igc> thst's not hard - see the examples at the top of builtins.py (like internal_files_for_add say)
[00:31] <igc> s/thst/that/
[00:32] <edcrypt_> igc: ok, taking a look, thanks!
[00:32] <igc> np
[00:32] <igc> edcrypt_: any you looking at fixing ls for me? :-)
[00:33] <lifeless> igc: in what cases is the answer 'no' so far?
[00:33] <igc> lifeless: merge, log, info at least
[00:34] <edcrypt_> igc: hehe, maybe, I have just learned hwo to create a plugin!
[00:37] <edcrypt_> igc: _check_path_in_view()
[00:38] <edcrypt_> ops, diff._check_path_in_view()
[00:40] <spiv> lifeless: reviewed, bb:approve
[00:42] <lifeless> woo
[00:42] <igc> edcrypt_: might be good to make that a public function in views.py instead of a private one in diff.py.
[00:47] <edcrypt_> igc: indeed
[00:57] <lifeless> spiv: ok, thats sent.
[01:08] <jelmer> luke-jr, hi
[01:08] <igc> poolie: fyi, here's my plan for today
[01:08] <jelmer> luke-jr, any chance you can comment on bug 326278?
[01:08] <igc> 1. get usertest tweaked with some of the changes on the roadmap
[01:09] <lifeless> jelmer: ping
[01:09] <jelmer> lifeless, pongz0rz
[01:09] <igc> 2. ping you and we'll update orchadas
[01:09] <igc> 3. land content filtering after chatting with you
[01:09]  * igc bbiab - food calling
[01:11] <lifeless> jelmer: could you do a pass over your subunit branches, and submit for merge where relevant
[01:12] <jelmer> lifeless, k
[01:13] <lifeless> thanks
[01:14] <poolie> igc, sounds good
[01:14] <poolie> my laptop won't boot, i'm guessing because of bug 333073 in jaunty :/
[01:14] <poolie> that gave me a bit of a setback
[01:14] <poolie> but let's talk anyhow when you're done
[01:17] <garyvdm> Hi - when I run bzr shelve - I get the following prompt:
[01:17] <garyvdm> Shelve? [yNfq]
[01:18] <garyvdm> yes No f???? q????
[01:18] <garyvdm> Where can I find more info. bzr help shelve does not say anything.
[01:19] <poolie> q is quit
[01:19] <poolie> does ? do anything?
[01:20] <garyvdm> no
[01:20] <garyvdm> no - ? seams to cause no which is the default action - lol
[01:20] <poolie> srsl? :(
[01:21] <mwhudson> f flips the defaults
[01:21] <lifeless> Odd_Bloke: is workng on this I thought
[01:22] <garyvdm> mwhudson - I jest tested that - f seems to do a "full" diff?
[01:23] <mwhudson> oh
[01:23] <mwhudson> i'm wrong then
[01:24] <garyvdm> ok - it easy to figure out - but irritating.
[01:30] <poolie> it should definitely be able to give you help
[01:31] <poolie> igc, back in 5
[01:37] <lifeless> spiv: ok with that sent off I'm looking at the next round trip
[01:42] <lifeless> spiv: another regression - we're not using find_repository to do the iteration for us
[01:42] <lifeless> we're walking up dirs manually
[01:44] <spiv> lifeless: actually, I'm not sure if that ever worked...
[01:44] <spiv> But yes, it'd be good to fix that.
[01:44] <spiv> Also, coffee is good...
[01:44]  * spiv does something about that
[01:44] <lifeless> I'm fairly sure it did at one time ;)
[01:44] <lifeless> but I could be wrong
[01:45] <spiv> Me too :)
[01:51] <jml> new small lp-open patch just sent to mailing list.
[01:52]  * jml doubles as an IRC notification bot.
[01:53] <mwhudson> :)
[02:04] <lifeless> spiv: I want to delete InterPackToRemotePack
[02:09] <poolie> igc, i'm free now if you are
[02:09] <poolie> lifeless: +1 (minus a bit for not being right there in the code atm)
[02:17] <spiv> lifeless: so that was only doing two things
[02:17] <spiv> lifeless: (IIRC).  calling the autopack RPC, and making sure _walk_to_common_revisions walks 50 revs at a time
[02:18] <spiv> lifeless: the streaming push takes care of the former, I think the latter might be taken care of by the InterOtherToRemote?
[02:18] <spiv> lifeless: if so, I don't see any reason to keep it either
[02:21] <lifeless> spiv: yeah
[02:21] <lifeless> spiv: thats why I want to delete it; and am doing so ;)
[02:21] <spiv> Ok.  +1 :)
[02:21] <spiv> I'm glad to see the set of InterRepos shrinking for once :)
[02:22] <lifeless> http://paste.ubuntu.com/121655/
[02:22] <lifeless> I'd like to just toss that at pqm - pass land fail I'll look into it
[02:22] <lifeless> spiv: ^
[02:27] <spiv> lifeless: sure, if it passes, then +1
[02:27] <spiv> lifeless: or rather, bb:approve :)
[02:36] <mwhudson> jml: your blug reports footnote doesn't seem to exist
[02:39] <jml> mwhudson: mea culpa
[02:43] <mwhudson> i think i just made the annotate view in loggerhead twice as fast
[02:44] <lifeless> mwhudson: good
[02:44] <lifeless> :)
[02:44] <mwhudson> by not calling annotate_iter twice!
[02:44]  * mwhudson sighs
[02:46] <lifeless> mwhudson: its amazing how little things can make a difference :)
[02:46] <lifeless> mwhudson: I have a suggestion for you
[02:46]  * mwhudson listens
[02:46] <lifeless> this is for testing
[02:47] <lifeless> create a little delegate branch
[02:47] <lifeless> which logs all the calls made to it
[02:47] <lifeless> and has a repository object it can return which likewise does the same for the branches repository
[02:47] <lifeless> you can do two things with this
[02:47] <lifeless> when asking 'why is X slow' you can see the api calls being made
[02:48] <lifeless> and secondly you can write a test that no more than a certain number of calls/exact calls etc are made
[02:49] <mwhudson> hmm
[02:49] <lifeless> the former is useful for exploring
[02:49] <lifeless> the latter is useful for locking down a behaviour ratchet
[02:51] <mwhudson> certainly, something i've been doing lately is removing the layers between loggerhead and bzrlib
[02:52] <mwhudson> and it was in the process of doing this that i found this problem
[02:58] <lifeless> spiv: I'd like to make RemoteRepository.*write_group* no-ops like knit/weave repositories
[03:00] <spiv> lifeless: the _real_repo would still need to have a write group, though?
[03:00] <lifeless> well
[03:00] <spiv> lifeless: or are we avoiding enough vfs ops now?
[03:01] <lifeless> as a start point we may find points that break
[03:01] <lifeless> at the moment though it and repo.lock_write are triggering _ensure_real
[03:01] <lifeless> actually
[03:01] <lifeless> lock_write doesn't trigger _ensure real
[03:01] <lifeless> but its a noop for pack repos
[03:03]  * spiv nods
[03:04] <lifeless> light weight commits will still need vfs
[03:04] <lifeless> but bound commit shouldn't
[03:05] <lifeless> calls 13 through 18 are RemoteRepository.start_write_group(), in the acceptance test
[03:18] <lifeless> spiv: ok, BranchFormat.network_name next I think
[03:18] <lifeless> spiv: ping
[03:18] <lifeless> bah
[03:18] <lifeless> spm: ping
[03:18] <spm> lifeless: pong
[03:18] <lifeless> spm: I think pqm is hung, can you check please?
[03:18] <spm> sure
[03:23] <jml> did jelmer's clean-tree patch get reviewed?
[03:27] <spm> lifeless: it was wedged pretty good. should be rockin again
[03:27] <lifeless> spm: did you note the cause?
[03:28] <spm> looked like the old email thing; but that didn't fix it. the sendmail was then hanging around as a defunct process. ie still wedged.
[03:28] <lifeless> ok, I'll try the merge again
[03:33] <spm> damn. it's rewedged itself. looks like on the original one too.
[03:34] <igc> poolie: I'm back
[03:34] <lifeless> spm: ok, patch is bad anyhow, so I suggest just removing the request from me and killing the bzr child
[03:35] <lifeless> spm: you shouldn't ever kill the pqm parent when a test is wedged
[03:35] <igc> is it just me or does bazaar-vcs.org seem really slow these last few days?
[03:36] <spm> lifeless: yeah - that was a pebkac. :-( did the chroot kill without a dir specified. clobbered everything :-( x 3
[03:36] <lifeless> spiv: we need a 'refresh your data' api for all repositories
[03:36] <lifeless> spiv: because this streaming push can work for knits, but we can't let it try :>
[05:17] <poolie> igc, hi?
[05:18] <igc> hi polie
[05:18] <igc> poolie:^
[05:19] <igc> poolie: you ready to do this orchadas stuff?
[05:19] <poolie> hey
[05:19] <poolie> i am
[05:19] <poolie> i hit an ubuntu bug 332270 that stopped my laptop booting and messed up my day a bit
[05:20] <igc> poolie: yum
[05:20] <igc> poolie: let's start by having a quick call maybe?
[05:20] <poolie> that's why it's called an alpha
[05:20] <poolie> good idea
[05:20] <poolie> i'll call your home?
[05:21] <igc> sure
[05:22] <jam> lifeless: I have some theoretical reasons why multiparent with xdelta is smaller than gc, care to have a call about it tomorrow?
[05:22] <poolie> hello jam
[05:22] <jam> hi poolie
[05:23] <jam> just heading off to bed after perusing the ~200 emails that came in over the weekend...
[05:23] <lifeless> jam: I'd be delighted
[05:23] <jam> lifeless: k, ping me when you wake up
[05:23] <jam> I'm going to sleep now
[05:35] <lifeless> jam: ciao
[05:36] <lifeless> jam: I'd expect the theoretical reason is deltas composition rather than recipes
[05:36] <lifeless> but see recipes for why gc is fast at extraction
[05:37] <maco> um, bzr just said "bzr: ERROR: exceptions.AttributeError: children" and aborted the commit i told it to do. how do i make it successfully commit?
[05:38] <lifeless> maco: what bzr version?
[05:39] <maco> 1.12
[05:42] <lifeless> maco: uhm
[05:43] <lifeless> maco: is there more in ~/.bzr.log ?
[05:52] <maco> lifeless: it spit out a backtrace
[05:52] <maco> i'll pastebin it
[05:57] <maco_> kernel panicked
[06:02] <maco> http://paste.ubuntu.com/121690/
[06:02] <maco> lifeless: ^
[06:09] <lifeless> maco: can you pastebin the output from 'bzr st' please
[06:09] <lifeless> (parent appears not to be a directory)
[06:10] <maco> just "added: .kde@"
[06:11] <lifeless> so .kde is a symlink
[06:11] <maco> i just made ~/config-backup, cd'd there, and did "bzr init" then tried to do "bzr add ~/.kde/share" and some other directories, but it didn't like that, so i made the symlink
[06:11] <maco> yes
[06:11] <lifeless> ok
[06:12] <lifeless> so we'll make a bug for the error, because it shouldn't be happening; but if you're trying to backup your .kde directory, a symlink to it won't do that - bzr will version the symlink
[06:12] <maco> i didnt give it ~/.kde to version though
[06:12] <edcrypt_> igc: merge request sent (make ls aware of views)
[06:12] <maco> i gave it ~/.kde/share and ~/.kde/Autostart and ~/.kde/env
[06:12] <lifeless> you need to either make ~/.kde a symlink to your bzr tree, or actually bzr init in ~/.kde
[06:13] <lifeless> maco: you did 'ln -s ~/.kde' inside config-backup didn't you?
[06:13] <maco> yes
[06:13] <igc> edcrypt_: thanks!
[06:13] <maco> but then i did bzr add on .kde/share, not on all of .kde
[06:14] <edcrypt_> igc: np
[06:14] <lifeless> maco: right, so I think I know what the bug is
[06:14] <lifeless> maco: however fixing it won't do what you want, so give me a second to record the issue
[06:14] <maco> was trying to get around it giving "NotBranchError: Not a branch: "/home/maco/.kde/share/"." when i did "bzr add ~/.kde/share"
[06:14] <maco> ok
[06:15] <poolie> igc, ok, i got a report with just one tool running
[06:15] <maco> is it not possible to give an absolute path to bzr add?
[06:15] <poolie> now i'll try it with some more though that will be slower
[06:15] <lifeless> maco: no, its not possible
[06:16] <lifeless> maco: bzr requires that all the files it versions are underneath a .bzr directory containing the 'tree' to be versioned
[06:16] <lifeless> maco: roughly, thats where you do 'bzr init'
[06:16] <lifeless> maco: so if you want to version ~/.kde/share, you must have done 'bzr init' in one of: ~/.kde/share, or ~/.kde, or ~
[06:18] <lifeless> maco: I've filed a bug for the specific error you're getting, but the actual fault is in 'bzr add' :(
[06:19] <maco> lifeless: ok thanks. a friend suggested avoiding putting it in ~/.kde in case of the next time i blow away ~.kde but i'll just have to remember to keep a backup of the .bzr that's in there
[06:19] <lifeless> maco: put it in ~/.kde like so:
[06:20] <lifeless> rm -rf ~/config-backup; cd ~/.kde; bzr init; bzr add [things]; bzr commit -m "start versioning ~/.kde"; bzr push ~/config-backup
[06:20] <igc> poolie: cool
[06:20] <lifeless> maco: now config-backup is a backup
[06:20] <maco> ah ok good idea. thanks!
[06:21] <lifeless> my pleasure
[06:30] <poolie> http://benchmark.bazaar-vcs.org/usertest/summary.html
[06:46] <maco> if i do "bzr remove" it doesnt remove the file, right? just stops doing version control on it?
[06:46] <poolie> if you do rm --keep it will do that
[06:49] <maco> or well...how do i tell it to not track anything in share/apps/kmail/*/*? bzr ignore? and will that get rid of its past control of those files or not?
[06:49] <poolie> if you have already added them, and you want to just ignore them in future you need to both remove --keep and also ignore them
[06:51] <poolie> igc, still here?
[06:53] <maco> ok
[06:53] <maco> thanks
[06:53] <igc> poolie: yep
[06:54] <poolie> i'd like to make something that will feed usertest output into rrd
[06:54] <poolie> so we have an over-time plot of results
[06:54] <maco> er, was i supposed to ignore or remove first? bzr diff still shows stuff from those files
[06:54] <lifeless> maco: bzr ignore ./share/apps/kmail/
[06:54] <poolie> i'd probably start with getting the total scenario time for each tool
[06:54] <poolie> and recording that each time we execute
[06:54] <lifeless> maco: ignore and remove
[06:57] <poolie> so firstly ,is this redundant with something you've done
[06:57] <maco> ok thanks
[06:57] <igc> poolie: no, I'm yet to produce rrd friendly output
[06:57] <poolie> bearing in mind it has to run on a dapper machine with no added software
[06:57] <poolie> and secondly, what should i start from?
[06:57] <poolie> oh
[06:58] <poolie> actually for the overall time, now that we're running each test separately, it's obviously easy
[06:58] <poolie> to do it from the driver script
[06:58] <poolie> i'll do that first then see how we go
[06:58] <igc> poolie: ok
[06:58] <igc> poolie: btw, new usertest just pushed with Description column added to the html report
[06:59] <igc> poolie: that will reduce the # of times I need to explain what each task/action does :-)
[06:59] <poolie> scalability :)
[07:00] <igc> rev 151 also fixes the colouring when multiple projects are given in the one html report
[07:00] <igc> i.e. colouring is per project, not just against the first column :-(
[09:10]  * igc dinner
[09:44] <Odd_Bloke> lifeless: I have a branch to fix the prompt up.  I'll send it in now (as the branch it depends on has been merged now).
[10:52] <ronny> yo
[11:01] <Peng_> lifeless: FWIW, I always run latest bzr.dev, and the streaming push work hasn't broken anything for me. I don't use stacking though.
[11:18] <spiv> Peng_: that's good to know.  Does that include using bzr.dev on the server?
[11:34] <Peng_> spiv: Yes.
[11:35] <Peng_> Except for once half an hour ago, where the revisions on the client and server were incompatible, so I had to do one push over sftp.
[12:05] <lifeless> Peng_: thanks
[12:05] <lifeless> Peng_: is it faster?
[12:06] <Peng_> lifeless: Sorry, but I don't really pay attention. It takes more than 1 second, so I always do something else while it runs.
[12:06] <lifeless> Peng_: fair enough
[12:06] <Peng_> I always run it through "time", and yet I never read the results. :P
[12:06] <lifeless> LOL
[12:16] <jelmer> moin lifeless, Peng
[12:19] <ronny> lifeless: are there any plans to support custom objects in the history store at one point?
[12:19] <Peng_> jelmer: Good morning.
[12:20] <lifeless> ronny: no; as we discussed before I think we'd need to see more examples of custom things before being able to design a good reliable & sufficient interface
[12:20] <lifeless> ronny: so its not 'no, never' its 'no, no _plans_ at the moment, open to things as we see people doing it in plugins'
[12:23] <ronny> k
[12:23] <jelmer> lifeless, what happened to the annotated code stuff you were discussing with James in London during the summer?
[12:23] <jelmer> can't remember the exact name you were using
[12:28] <ronny> the main use-cases *i* see is signed tags, code-review, testresults
[12:30] <james_w> jelmer: "marks"?
[12:31] <jelmer> james_w, yeah, that's it
[12:32] <james_w> I don't know if lifeless has done any work on it, I certainly haven't
[12:32] <james_w> I would love to have it though
[12:33] <james_w> the thing that I'm not sure about is how to store the marks
[12:33] <james_w> "file-id hunk-start hunk-end sha-of-hunk" might work I guess
[12:43] <lifeless> jelmer: views
[12:43] <lifeless> jelmer: erm
[12:43] <lifeless> views/filters/tags something like that
[12:43] <lifeless> marks maybe?
[12:43] <lifeless> james_w: yeh I started sketching htat
[12:43] <ronny> hmm
[12:43] <lifeless> haven't gone far; performance is a major issue first
[12:45] <lifeless> ronny: so for all of those, I'd definitely help you get support in the core as hooks, so that plugins can do them
[12:45] <lifeless> and once we see what plugins *do* with those hooks look at the design for core inclusion of extensible things
[12:50] <ronny> lifeless: atm im puting together a nosetest plugin for subunit
[12:51] <james_w> lifeless: if you've committed anything I'd love to take a look
[12:51] <james_w> lifeless: I understand that it's not your first priority
[12:55] <ronny> lifeless: subunit could use a setup.py
[12:55] <lifeless> ronny: yeh, though it builds native C and shell and stuff; setup.py isn't really a good fit there
[12:55] <jelmer> scons isn't either though >-)
[12:56] <ronny> lifeless: at least for the python part
[12:56] <lifeless> jelmer: scons was an awful nightmare that I regret
[12:56] <lifeless> ronny: certainly thats doable yes
[12:56] <lifeless> I think there is a branch
[12:56] <lifeless> ronny: http://www.somethingaboutorange.com/mrl/projects/nose/doc/plugin_interface.html#prepareTestResult
[12:56] <lifeless> prepareTestResult(self, result)
[12:56] <lifeless> seems to be the bit
[12:57] <lifeless> lp:~lifeless/subunit/filter has the latest subunit branch I was tweaking
[12:58] <ronny> would you mind if i would put nosetest support directly into subunit ? its basically just replacing the reporter
[13:15] <lifeless> ronny: I'm not sure what you're asking
[13:15] <lifeless> ronny: but note bug 332770
[13:16] <ronny> lifeless: thats what i do atm
[13:16] <lifeless> which is to say, I'd like it if installing subunit added an option to nose [if nose is installed]
[13:16] <lifeless> I don't want subunit to depend on nose though
[13:16] <lifeless> I consider it a lower level helper
[13:16] <ronny> ok, so separate repo it is
[13:17] <lifeless> ronny: hm? Not sure I follow, however I'm tired :)
[13:17] <lifeless> so - chat with you in ~ 7-8 hours
[13:17] <ronny> k
[13:17] <ronny> cu later
[16:10] <jam> morning vila, I hope you had a good weekend
[16:11] <vila> jam: hehe, hi ! Yes, pretty good, didn't touch a mouse nor a keyboard (didn't happen for a while :)
[16:11] <vila> jam: how was yours ?
[16:11] <jam> jelmer: I'm getting timeouts while trying to access a signature file on your dulwich branch
[16:11] <jam> vila: pretty good
[16:12] <jam> sat was a kids birthday party
[16:12] <jam> so it was fun to see Kareem playing with the neighbor kids
[16:12] <jam> I didn't get back to a comp until late Sunday night as well
[16:12] <jam> jelmer: lp also seems to be having problems with that branch
[16:12] <jelmer> jam: us2 seems to be under heavy load at the moment, one of the admins is looking into it
[16:13] <jam> jelmer: k. It seems funny since everything works until the .six
[16:16] <jam> vila: still looking into the mysql stuff?
[16:16] <vila> jam: on my right screen, yes
[16:17] <vila> jam: trying to find a better ftp test server on the left one
[16:17] <vila> jam: I was so close :-/ And had problems *again* with FtpStatResult and the test suite being too demanding for ftp :-/
[16:17] <Peng_> Hmm, it took 438.396 seconds to pull one revision from subvertpy. bzr-svn is still going. Did my connection hiccup?
[16:18] <vila> jam: the idea was to spend a couple of hours only on it and then address the fact that we can't test under 2.6 anymore until we avoid using medusa there which requires another one
[16:19] <vila> jam: I hate ftp
 that was rude, ftp doen't like me that much
[16:21] <jelmer> Peng_, server is having issues
[16:21] <jam> vila: Would it be easier to just get medusa working with 2.6 ?
[16:21] <Peng_> Oh. Oh! I did read backlog, just not enough to understand it. Alright. :)
[16:23] <vila> jam: no, far harder as the bug is deep down inside asyncore/asynchat or something (I suspect the problem is roughly that somewhere in an iterator str() objects are special-cased and unicode isn't, ugly business), so the idea was to just stop using medusa for >= 2.6 and find another ftp test server
[16:24] <vila> jam: I found one that doesn't require running as root, only to find that it returns an empty list when asked to list a non-existing directory and has no problem giving the *size* of a directory
[16:24] <jam> vila: why would we be using Unicode anywhere...
[16:24] <jam> at the FTP level, everything should be 8-bit strings, (I think)
[16:25] <vila> utf-8 (sorry)
[16:25] <jam> vila: we wouldn't be special casing a utf-8 string
[16:25] <jam> as it is just another 8-bit string
[16:25] <vila> but at some point giving utf-8 means handling unicode (from memory)
[16:25] <vila> jam: I don't remember exactly the problem, certainly it was on server side, and ... well there is little we can do there :(
[16:26] <jam> vila: I don't know the failures, but everything *under* FTPTransport should be 8-bit strings. I suppose if we have a unicode file on disk there may be other issues
[16:26] <jam> vila: does everything fail?
[16:26] <jam> Or is it just a couple tests that we could say "py2.6 + unicode files + medusa is KnownFailure"
[16:26] <jam> vila: I certainly would rather you spending your time on other things :)
[16:27] <vila> under 2.6 with medusa, failures are about utf-8 encoded file names IIRC
[16:27] <jam> vila: exactly, so wrap tests that do exactly that with KnownFailure and get on with your life :)
[16:27] <vila> jam: I know :-/ I hoped to be done with it far quicker and then... well each bug looks like the solution was close :)
[16:28] <eferraiuolo> Can I expect the Mac OS X 10.5 Installer for bzr 1.12 soon?
[16:28] <vila> hmm, not sure we can peak under the cover to realize we are under 2.6 + medusa + whatever, the idea was to shorcut at get_transport_permutations
[16:29] <vila> get_test_permutations I meant
[16:29] <Peng_> eferraiuolo: "tonight (European time)" according to a post on the mailing list :)
[16:30] <eferraiuolo> Peng_: thanks for the info :-)
[16:30] <vila> jam: to be precise, I have a test server that pass the test suite, with a relaxing constraints patch against bzr.dev, so that's not *that* bad :-)
[16:31] <jam> jelmer: I have a trivial patch to 'dulwich' which should help the performance of 'apply_delta'. Care to test it out?
[16:31] <jam> http://paste.ubuntu.com/121930/
[16:32] <vila> jam: on the bbc front all the remaining failures will require a bit of work and I wanted to start with a bzr.dev merge which raise to many conflicts to be solved quickly, so *that* was pushed out of the parrallel activities which are now back to the two mentioned above :)
[16:32] <jam> vila: sure. I'm also submitting the "trailing whitespace" fix
[16:32] <jelmer> jam, Is that against the current trunk? James also submitted a performance improvement yesterday
[16:32] <jam> which is going to be bad for merging into bbc
[16:32] <jam> jelmer: versus 154
[16:32] <jam> it just changes to use a list and append
[16:32] <jam> and then ''.join() at the end
[16:33] <jelmer> jam, ah, cool
[16:33] <jelmer> jam, can you "bzr send" or is it easier if I just pick up from pastebin?
[16:33] <jam> that should avoid O(N^2) performance
[16:33] <jam> I haven't committed, but I can and I'll send it
[16:33] <vila> jam: by the way, if *you* are able to merge bzr.dev cleanly in bbc, just tell me :-)
[16:33] <james_w> nice
[16:34] <james_w> there are probably a couple more places in that file where that approach could be used
[16:34] <jelmer> jam: Please do :-)
[16:34] <jelmer> jam, vila: Also, if you can have a look at my InterBranch patch that would be really helpful for bzr-git..
[16:35]  * jelmer is still wondering what the magic trick is to get a patch reviewed
[16:35] <jam> jelmer: sent
[16:35] <jelmer> jam: Thanks :-)
[16:35] <jam> vila: I'm sure I'm not
[16:35] <jam> I changed some code in fetch
[16:36] <jam> which Robert changed with the network streaming stuff
[16:36] <arshad> hi channel
[16:36] <jam> I added a progress bar
[16:36] <arshad> whats bazaar all about  ??
[16:36] <vila> jam: yeah, so at least you know *one* side of the conflict as opposed to None :-)
[16:37] <jam> jelmer: I think it is beer. And submitting patches that directly effect other people. The problem with InterBranch is that I haven't worked out whether the added complexity is worth the benefit for non-core code. I'll try to give it a look
[16:37] <jam> arshad: freedom :)
ok . . . . . .   but freedom for what ??
[16:38] <james_w> jelmer: I assume that is the cause of "AttributeError: 'module' object has no attribute 'InterBranch'" with a newer bzr-git?
[16:38] <jam> arshad: That was a trivial response. To give you a better one, how much do you *know* so I don't repeat myself
[16:38] <jam> bzr is a version control system
[16:39] <jam> do you need to know the diff from others
[16:39] <jam> what a vcs *is*?
[16:39] <jam> etc
[16:40] <arshad> hope u wont fire me for that
[16:41] <jam> arshad: no firing, just trying to understand what info you really want
[16:42] <jam> vila: yeah, robert refactored a lot of stuff that bbc had hacked to get working :(
[16:42] <jam> So I need to actually understand the new stream code
[16:42] <jam> before we can really adapt it
[16:42] <jam> vila: like understanding how to get chk records as part of the new stream
[16:42] <vila> jam: The good thing is that that should address at least *one* failure :-)
[16:43] <vila> jam: ouch, not an easy bird then :-/
[16:43]  * vila throws some stones at jam to help him :)
[16:43] <arshad> can VCS b made as a career
[16:43] <arshad> ??
[16:43] <jelmer> james_w: yep
[16:43] <jelmer> .
[16:43] <Peng_> Doesn't CPython optimize += on strings with only one reference, making it faster than ''.join()ing a list?
[16:44] <james_w> jelmer: am I better merging that, or going back in time a little bit on bzr-git?
[16:44] <vila> arshad: vcs == version control system, try reading http://bazaar-vcs.org a bit
[16:44] <vila> arshad: you should get many answers there
[16:44] <arshad> where??
[16:45] <jam> vila: so one problem I have with your "knownFailure" change to "autopack_rpc_is_used" test. Is that you don't test anything, in case we accidentaly *fix* that.
[16:45] <jelmer> jam: It's the only way to make "bzr pull" work on remote git repositories since we can't walk the graph of remote git repositories to determine the revno
[16:45] <jelmer> james_w, Better off merging InterBranch, without it you can't pull from remote git branches
[16:46] <vila> jam: that was quite the only possible route at that time as we were testing that the hpss autopack call was in hpss_calls
[16:47] <vila> jam: and that required some InterRepo accepting chks which wasn't the right way
[16:47] <jam> vila: not really
[16:47] <jam> you could have put the knownFailure later
[16:47] <jam> around the actual "x in y" test
[16:47] <jam> anyway, it is fine.
[16:47] <jam> For right now, I'm pulling out your change, because it conflicts with the new streaming RPCs
[16:47] <jam> and I don't know how BBC will interact with that yet
[16:48] <james_w> jelmer: will InterBranch allow things like "missing" against the remote branch? I guess they may have to become a fetch to local then missing operation?
[16:49] <vila> jam: pull out ! pull out ! sounds perfectly right now that the test has changed
[17:00] <jam> vila: dammit.... we have a serious problem
[17:00] <jam> the generic fetching code doesn't really seem to support converting on-the fly
[17:00] <jam> at least not easily
[17:01] <jam> since it expects to be getting a stream
[17:01] <jam> that it can just insert on the other side
[17:01] <jam> and with chk
[17:01] <jam> it has to convert the repos
[17:01] <jam> well, convert the inventories.
[17:01] <jelmer> james_w: It mainly allows for custom implementations of branch-to-branch operations, such as pull
[17:01] <jelmer> james_w: right now bzr-git only overriden update_revisions(), which is the main worker used by pull
[17:02] <jelmer> james_w, but in the end, we would indeed end up with a search_missing_revisions() and that would most likely indeed to a fetch :-/
[17:02] <jelmer> james_w, s/to a/do a/
[17:03] <james_w> yeah, that's a pain
[17:03] <vila> jam: ouch :-/
[17:03] <james_w> jelmer: would it be at all possible to extend git's server to help with this?
[17:04] <james_w> not in terms of would they do it, but in terms of whether git could provide the sort of information that is needed?
[17:04] <jelmer> james_w, it would, though I'm not sure how likely such changes would be accepted upstream
[17:04] <james_w> I guess having it speak the bzr remote protocol would work :-)
[17:04] <jelmer> james_w: :-)
[17:05] <jelmer> james_w, Actually, that has crossed my mind.. the git server John has been working on can provide a "bzr" capability, just like "bzr svn-serve" does
[17:05] <james_w> heh
[17:05] <james_w> jelmer: also, would "bzr format-git-patch" make sense?
[17:06] <james_w> and something to then pull then back in? maybe "bzr patch" is enough
[17:06] <jelmer> james_w, you mean "bzr send --format=git" ? >-) Yes, I think so
[17:06] <james_w> yeah, that too
[17:06] <james_w> :-)
[17:07] <Jc2k> jelmer: i thought about custom extensions to git-serve too :)
[17:07] <james_w> making "format-patch" and alias of "send" might be a good idea
[17:07] <jam> vila: so StreamSink *is* meant to handle some of that, but it only really is defined as handling the case where 1 fulltext == 1 inventory
[17:07] <jam> which is no longer true for bbc
[17:07] <jam> so I have to figure out how to work around it
[17:08] <jam> the stream code seems to think that just "get_bytes_as('fulltext')" would be enough
[17:08] <jam> and, of course, lifeless and spiv are both sleeping right now
[17:08] <jam> I may have to punt... :(
[17:09] <jam> until I can talk to them and see what they were thinking of as a solution for this
[17:10] <Ng> is bzr 1.12's "st" supposed to explode on me?
[17:10] <jelmer> Ng, you may want to update your copy of bzr-loom
[17:10] <vila> Ng: let me guess: it doesn't like 'verbose' and you have installed bzr-loom ? Grr, jelmer is too fast :)
[17:11] <Ng> correct :)
[17:14] <vila> jam: punting sounds the most reasonable thing to do, is StreamSink._extract_and_insert_inventories where the problematic assumption is being made ?
[17:15] <jam> vila: that an inventory is contained within a string
[17:15] <jelmer> james_w, yeah, I agree
[17:15] <jam> the idea is that you can do "read_inventory_from_string()" using the source serializer
[17:15] <jam> the problem is that for chk repos
[17:15] <jam> you can't just have the little bits you need
[17:15] <jam> you have to have all the chk pages
[17:16] <jam> for that inventory
[17:16] <jam> in order to cast up to an Inventory object
[17:16] <jam> that can then be serialized back down into whatever format the target requires
[17:16] <jam> vila: does that make sense?
[17:16] <vila> jam: can't we just transmit the delta and build from that ? Argh, yes, not all formats can build from a delta :-/
[17:17] <jam> vila: so the issue is that "CHKRepo.get_stream()" would want to at best just send the individual pages that changde
[17:17] <jam> changed
[17:17] <jam> but the target repo doesn't have *any* pages
[17:17] <jam> so it wouldn't know how to interpret them
[17:17] <jam> so CHKRepo.get_stream() sort of needs to do the conversion on *its* end
[17:18] <vila> jam: so either the target is chk and we send changed pages (>-/) or better the delta or the target is not and... pfff
[17:18] <jam> The BBC logic just did "for inv in self.source_repo.iter_inventories(revs)"
[17:19] <jam> vila: right, so I can easily figure out what to do when source_format == target_format
[17:19] <jam> However, when source_supports_chks != target.supports_chks
[17:19] <jam> I'm a bit stymied
[17:19] <vila> I can understand that :-/
[17:19] <jam> The code is written such that the *target* does the conversions
[17:19] <jam> But a Pack-0.92 repository isn't going to know what to do with a chk page
[17:20] <jam> So I think we need a get_stream() that can tell the target what format it needs
[17:20] <jam> sorry, tell the *source*
[17:20] <jam> hmm.. maybe I can cheat and try to do that
[17:20] <jam> I just worry that I'm breaking the *spirit* of lifeless & spiv's work
[17:21] <vila> jam: better talk with them then
[17:21] <jam> though I know they wanted to make sure that the streaming code worked with bbc
[17:21] <jam> as part of the "if it doesn't, then we haven't done the right thing"
[17:21] <vila> there is already some XXX in remote.py
[17:22] <vila> so may be we should just don't try to merge yet (and will regret it later :-)
[17:22] <jam> vila: well, the other 3 conflicts were easy to resolve... :)
[17:23] <jam> and if we don't merge revno 4032, when we merge 4033 we're going to have a real pain (it is the whitespace cleanup patch)
[17:23] <vila> jam: hmmm, can you resolve the last one with a hammer maybe ?
[17:23] <jam> it is easy enough to do if you merge just before
[17:23] <jam> because then you know you can revert everything
[17:23] <jam> and do your own whitespace cleanup
[17:24] <jam> vila: yeah, I can always put big XXX and say that robert and andrew need to fix this
[17:24] <jam> :)
[17:24] <vila> jam: if we end up with test_autopack_or_streaming_rpc_is_used_when_using_hpss failing, well that will make 5 failures instead of 4, not a big deal
[17:24] <jam> vila :)
[17:24] <vila> jam: sounds like a good idea, at least they get an almost working bbc
[17:25] <vila> jam: and they may already know that can't work right now
[17:25] <vila> jam: and they may already know that bbc can't work right now
[17:26] <jam> vila: I'll also note that "supports_chk" isn't a sufficient test. As if you have different CHK repos with a different paging structure (different hash, etc)
[17:26] <jam> then the target repo still doesn't understand the source repository
[17:26] <jam> pages
[17:26] <jam> (layered on *top* of the pages is a possible delta format, which could differ but still be understood by both formats)
[17:27] <jam> like gc+chk255 should be able to understand the wire-stream of a chk255 repo
[17:27] <jam> but chk16 != chk255
[17:27] <jam> me == :(
[17:27] <vila> jam: yup, and a delta format may be easier to serialize/deserialize for *future* formats too
[17:28] <jam> vila: I think we are talking different things
[17:28] <jam> logical inventory diff
[17:28] <jam> versus byte-wise diff of chk page
[17:29] <jam> I think defining a "get_stream()" that can return serialized bytes of a logical inventory diff may be the way to go
[17:29] <jam> though possibly slower than a pure chk => chk could be
[17:29] <vila> jam: sorry, I went too fast, but you were already saying the byte-wise diff of chk pages was having problems, so going with a logical inv dif... yes, what you said :)
[17:30] <vila> jam: I'm not sure you can assume that two repos have the needed pages without checking first (and it's true today, I'll be more comfortable if that wasn't required)
[17:30] <vila> jam: I'm not sure you can assume that two repos have the needed pages without checking first (and *if* it's true today, I'll be more comfortable if that wasn't required)
[17:31] <jam> of course, I don't want to have to write a logical diff format + serialized form just to get bbc working
[17:31] <jam> vila: chk pages are the same problem we have today, so I'm not specifically worried
[17:31] <jam> we assume that if you have the inventory at revision X, then you don't need to transmit it
[17:31] <jam> in the same way, you don't need to transmit the chk pages for X
[17:32] <jam> the issue is that if both sides have different chk serializers
[17:32] <jam> the pages for Y don't mean anything to the other side
[17:32] <vila> I think that defining new serialized formats shouldn't be harder than defining a % format
[17:32] <vila> It *is* today but it shouldn't
[17:33] <jam> vila: anytime you work on bytes-on-the-wire or bytes-on-disk it is hard
[17:33] <jam> because you need a whole lot of direct tests
[17:33] <vila> jam: exactly
[17:33] <jam> to make sure that bzr-X.Y can talk to bzr-X.Z
[17:33] <jam> I don't see that going away
[17:34] <vila> I worked in that direction in the transportstats plugin (not the interoperability part, but the easy defined formats)
[17:37] <jam> argh....
[17:37] <vila> jam: but the gap to go there is still rather large :-/
[17:37] <jam> I thought I had a decent workaround
[17:37] <jam> by changing the source to do the reserialization and hand it back
[17:38] <jam> but it seems the Sink always uses the source-serializer to decode the fulltext bytes
[17:38] <jam> (which sort of makes sense, but means I don't have a way to do this yet)
[17:40]  * vila dinner
[17:41] <jam> hmm... it seems that chk_serializer's inherit from the XML serializers (perhaps wrongly, but they do)
[17:41] <jam> which means an ugly-ugly hack is to actually write out a xml5 format inventory to the record stream
[17:45] <vila> jam: will that make it less ugly to use composition instead of inheritance (ignoring it doing that) so that you can provide the right xml serializer ?
[17:46] <jam> vila: so the ugly hack is that we will read in the CHK inventory, bring it up all the way to a full Inventory object in memory
[17:46] <jam> and then convert it to some-semi-random not really used XML representation
[17:46] <jam> and write those bytes out on the wire
[17:47] <jam> I think I can make it work
[17:47] <jam> but it certainly isn't what I would consider the "correct" method
[17:47] <jam> One other possibility, is that get_stream() from a CHK repo
[17:47] <vila> jam: At least you'll have some meat to talk with lifeless and spiv :)
[17:47] <jam> could return *all* the pages
[17:48] <jam> which would mean the target would have enough to work with to do it on its end
[17:48] <jam> but it would have to transmit and buffer all of those pages somewhere
[17:48] <jam> until it got to the inv records
[17:48] <jam> and new what to do with them.
[17:48] <vila> jam: returning all the pages sounds wrong especially considering that you'll certainly ends up transmitting some of them multiple times
[17:48] <jam> vila: you can just transmit the set()
[17:49] <jam> for revisions 10..30 send all referenced chk pages
[17:49] <jelmer> hmm
[17:49] <vila> jam: sounds better
[17:49] <jam> jelmer: ?
[17:49] <jelmer> jam, Trying to figure out what I'm doing wrong benchmarking OOo with bbc and bzr.dev
[17:49] <jam> vila: yeah, I'm still going to let robert and andrew worry about how to semi-optimize transfering between formats
[17:50] <jelmer> I'm seeing a 28x performance gain with bbc
[17:50] <jelmer> which seems a little excessive ;-)
[17:51] <jam> jelmer: not really
[17:51] <jam> it is an O(N^2) versus O(N) sort of change
[17:51] <jam> I don't know *what* you are benchmarking
[17:51] <jelmer> jam, import from OOo-svn into bzr
[17:51] <jam> jelmer: oh sorry, it is a log(N) versus N change
[17:51] <jam> jelmer: so still possible
[17:52] <jam> with bzr.dev
[17:52] <jelmer> bzr.dev gives one revision every 6 or 7 seconds, bbc close to 4 per second
[17:52] <jam> we have to generate an inventory which contains a line for *every* file
[17:52] <jam> with bbc
[17:52] <jam> we only have to update the few pages based on the actual change
[17:52] <jam> O(tree) operation versus O(changes)
[17:53] <jam> jelmer: also the bbc pages aren't delta compressed (yet), which means they are also faster to read, etc.
[17:53] <jam> so *faster* but not *smaller* to store
[17:53] <jam> jelmer: so my initial feeling is that you aren't doing anything wrong
[17:53] <jam> as that is really what bbc is *about(*
[17:54] <jam> I would actually expect the difference to get *more* pronounced as time goes on
[17:54] <jam> as the larger OOo gets, the size(changes) stays relatively constant for most projects
[17:55] <jelmer> right
[17:55] <jam> jelmer: well, at least if you have an optimized Inventory._make_delta() for bzr-svn
[17:55] <jelmer> jam, I do
[17:55] <jelmer> jam: Still surprised it matters this much though
[17:55] <jelmer> jam, Anyhow, I'm not complaining ;-)
[17:56] <jelmer> jam, bbc rocks \o/
[17:57] <jam> jelmer: if you see igc around, I'm sure he'd be interested to hear it
[17:57] <jam> It seems that OOo is looking again at possibly switching to a DVCS
[17:57] <jelmer> jam, This was actually why I was looking into it
[17:57] <jelmer> jam: They were seeing slow imports with bzr.dev
[17:58] <jam> jelmer: yeah, when we imported in the past, it was... 2 weeks to a month? something like that
[17:58] <jam> Also, I wouldn't be surprised if the generic converter is actually *slower* in bzr.dev than it used to be
[17:58] <jam> as it was updated in preparation for bb
[17:58] <jam> bbc
[17:59] <jam> And I believe Ian was looking at fast-import code in the last couple of days
[17:59] <jam> as it had also done some internal hackery for performance that may not be as relevant now
[18:00] <jelmer> based on what I'm seeing now with bzr-svn (4 revs / second) I should be able to import OOo in 20 hours
[18:01] <jam> jelmer: that's a good number
[18:01] <jam> jelmer: is that streaming from their repository? Or do you have an svn dump locally?
[18:01] <jelmer> I have a local dump
[18:02] <jelmer> That's mainly to avoid hammering their server too much though
[18:02] <jelmer> as the process is mainly CPU-bound
[18:06] <jelmer> jam: bzr-svn basically does one "svn log -v" followed by "svn up -rX-1:X" for each revision
[18:07] <jelmer> so while the extra roundtrip-time should have some impact, it shouldn't be significant
[18:07] <jam> jelmer: well, bandwidth and latency
[18:07] <jam> and as you say
[18:07] <jam> if you try multiple times
[18:08] <jam> you only have to have dumped once :)
[18:08] <jam> at 4 revs/sec
[18:08] <jam> latency becomes an issue
[18:08] <jam> 250ms
[18:08] <jam> a latency of 100ms and 2 round trips would cut your conversion speed in half
[18:08] <jam> certainly didn't matter for bzr.dev at 7s/rev
[18:08] <jelmer> jam: Latency to launchpad is 10ms here, not sure how much it is to the ooo svn server
[18:37] <jam> vila: ok, I've hacked it enough that it seems to be working
[18:38] <jam> the RPC tests still fail
[18:38] <jam> though I think we could fix that by allowing chks to be included in the InterPackToRemotePack tests
[18:47]  * ToyKeeper finds it a little odd that two opposite-sounding options are required to produce the desired output...  bzr log --verbose --short
[19:08] <ronny> anyone knows when lifeless will appear?
[19:12] <mthaddon> anyone know what's up with http://benchmark.bazaar-vcs.org/usertest/usertest.log ?
[19:12] <jam> ronny: he usually shows up in about 2 hours
[19:12] <jam> though he almost never actually completely logs off irc
[19:12] <jam> so I'm not sure if something changed
[19:13] <jam> mthaddon: what is the problem?
[19:13] <mthaddon> jam: it seems to be debug output rather than the expected output
[19:13] <ronny> i hacked up a inital nosetest plugin for subunit
[19:14] <mthaddon> jam: either that or the format has changed radically (it's used to generating performance graphs, so I'd need to alter my parser if the format's changed)
[19:18] <jam> mthaddon: poolie or igc would be the ones to ask
[19:18] <jam> If you want, I'll try to mention it when I talk to them later
[19:18] <jam> mthaddon: best guess is that someone forgot a flag when the updated the benchmarks being run
[19:18] <mthaddon> cool, thx - I'll send them an email as well
[19:45]  * jelmer makes a note to buy John beer at the next bzr sprint
[19:46] <jelmer> jam: Thanks for the reviews, it's much appreciated!
[20:37] <glade88> hello. is there a way to make bzr use a network proxy setting?
[20:57] <mwhudson> does nicolas allen irc?
[20:57] <mwhudson> nicholas, sorry
[21:08] <lifeless_> mwhudson: I think so
[21:22] <poolie> jam, hi
[21:22] <Peng_> Do http connections time out...ever?
[21:22] <jam> morning poolie
[21:23] <poolie> Peng_: probably, but i would say not as fast as they should
[21:23] <poolie> they should timeout and retry
[21:23] <poolie> since they're all idempotent
[21:24] <poolie> jam, want to talk?
[21:25] <jam> hey poolie, chatting with robert right now
[21:25] <poolie> ok
[21:26] <poolie> i'll be here all day, ping me if you want a 1:1
[21:27] <james_w> hi poolie
[21:27] <poolie> hello
[21:28] <mwhudson> Peng_: we occasionally had http connections hang for ridiculous amounts of time in the branch puller
[21:29] <poolie> jam, btw not sure if you saw but it looks like rockstar will go to the mysql conf
[21:30] <Peng_> mwhudson: How long?
[21:30] <mwhudson> Peng_: days, iirc
[21:30] <Peng_> Eh. I'm at 12.5 hours so far. That sounds bad.
[21:31] <Peng_> Oh well, I have nothing better to do. :)
[21:32] <mwhudson> well
[21:33] <mwhudson> killing and starting again will probably work...
[21:34] <Peng_> Sure, but how would that be fun?
[21:35] <mwhudson> i'm not going to try to guess what you find fun :)
[21:38]  * mwhudson watches pydoctor trunk process bzrlib
[21:39] <mwhudson> gawd docutils is SO SLOW
[22:23] <lifeless> jam: let me know if you want to continue the compression chat [just skype me]
[22:24] <ronny> lifeless: got an initial nose plugin for subunit wired up, currently it imports the reporter
[22:25] <ronny> lifeless: how about a convention for giving stream output/log lines after the trace?
[22:26] <mwhudson> beuno: hi
[22:26] <lifeless> ronny: How would that map into pyunit [let alone junit etc]
[22:26] <beuno> mwhudson, hiya
[22:27] <mwhudson> beuno: so the masses are complaining about https://bugs.edge.launchpad.net/loggerhead/+bug/253950
[22:27] <ronny> lifeless: ignore unless known otherwhise
[22:27] <lifeless> ronny: no, I mean *where* would that be exposed
[22:28] <ronny> nosetest tracks things like stdin/stderr (and its nice for additional output)
[22:28] <lifeless> ronny: you have a RemoteTestCase which calls result.addFailure(self, RemoteError(self.blah))
[22:28] <mwhudson> beuno: a simple fix is to truncate the list of added/modified/... files when the list gets more than a certain length
[22:28] <lifeless> ronny: ah
[22:28] <lifeless> so; divide and conquer
[22:28] <beuno> mwhudson, sure. Although, to be fair, doing it with ajax should be pretty quick as well.
[22:28] <mwhudson> beuno: yeah, i guess
[22:28] <ronny> currently my initial wire up doesnt handle that tho
[22:29] <mwhudson> maybe i should just try that quickly
[22:29] <lifeless> there are two use cases here - there is 'get nose discovered tests run with output to subunit', and there is 'accept a subunit stream for display with the nose infrastructure'
[22:29] <beuno> mwhudson, and we could potentially avoid getting that information at all unless needed, gaining some performance?
[22:30] <mwhudson> doing it nicely will require some infrastructure hacking i guess
[22:30] <ronny> lifeless: i see 2 possible solutions - mangle it into the trace output, or have a new event
[22:30] <lifeless> In terms of the former, just putting it in the comment area in the result is fine [though if people should be seeing it real time (e.g. a debugger prompt), put it in the stream in realtime.
[22:30] <mwhudson> and some nice gifs
[22:30] <beuno> mwhudson, we have most of that in lazr-js  ;)
[22:30] <mwhudson> i should look at lazr-js i guess!
[22:31] <lifeless> for the latter, I don't think you need to accept any random stream into nose so much as nose generated ones, so as long as you use the same approach for in as for out it should work nicely
[22:31] <lifeless> ronny: yes, I see the same two things; I'm cautious about new events though
[22:31] <mwhudson> argh
[22:31] <mwhudson> when will bzr info lp:lazr-js not say "format: unnamed" ?
[22:32] <lifeless> ronny: particularly things that are tricky to map into python space - like jml's testtools, I want to see what multiple projects are doing before committing to a design
[22:33] <lifeless> mwhudson:
[22:33] <lifeless> Repository branch (format: pack-0.92)
[22:33] <lifeless> I bet its info not doing the right thing with hpss branches; perhaps filing a bug would help.
[22:34] <ronny> lifeless: got a link to jml's testtools?
[22:35] <lifeless> https://edge.launchpad.net/testtools
[22:36] <mwhudson> lifeless: would seem to be https://bugs.edge.launchpad.net/bzr/+bug/196080
[22:37] <lifeless> mwhudson: k
[22:37] <lifeless> thanks
[22:37]  * beuno -> home
[22:37] <beuno> bbiab
[22:37] <mwhudson> beuno: so how do i actually use lazr-js, is there documentation or a quickstart somewhere?
[22:45] <phinze> is there any way to get bzr log to show me only the commits made on this task branch?
[22:47] <ronny> afair bzr log -rsubmit:..
[22:47] <ronny> see bzr help revisionspec
[22:55] <igc> jam: I've been struggling getting a good conversion of mysql and emacs to --development5
[22:55] <igc> emacs fell out with a serializer bug after 10 hours
[22:55] <igc> s/out/over/
[22:56] <igc> mysql completed but then didn't work ...
[22:56] <igc> and I'm yet to track down why cos ...
[22:56] <igc> bzr check isn't fast
[22:57] <igc> jam: I'm wondering if you've had more luck converting these
[22:57] <jam> igc: I have, but I haven't done a full conversion in a while
[22:58] <igc> if so, could I ask for you to tar.gz the converted branches and put them on orcadas?
[22:58] <igc> that's the missing piece for getting meaningful benchmark results
[23:00] <jml> abentley: thanks for the review
[23:00] <abentley> jml: np
[23:09] <thrope> hi - numpy/scipy developers are discussing dvcs ... I pointed out bzr-svn (they were talking about the shortcomings of git-svn)
[23:09] <thrope> http://projects.scipy.org/pipermail/scipy-dev/2009-February/011205.html
[23:10] <thrope> someone asked "can you point us to a public svn repo where non-trivial branching is happening with bzr?" was wondering if anyone (perhaps jelmer ) could point me to this
[23:11] <jelmer> thrope, hi
[23:11] <jelmer> thrope, non-trivial branching?
[23:11] <fullermd> I thought the point of a DVCS was that ALL branching is trivial   ;>
[23:12] <thrope> not sure - thats what the person asked...
[23:12] <thrope> I dont have a lot of experience - but bzrsvn worked well for me and they were complaining about git-svn
[23:13] <thrope> I guess can anyone point to an open source project using bzr-svn 'officially' with a couple of different bzr branches in svn
[23:14] <jelmer> thrope, well, there are some projects that contain roundtripped revisions using bzr-svn
[23:15] <jelmer> thrope: it seems kindof pointless to have official bzr-svn branches though, since the official repo would always be svn, even if some developers are accessing svn using bzr
[23:16] <thrope> right
[23:16] <thrope> just not sure how to respond to the guys question then
[23:17] <jelmer> thrope, if you're looking for example branches in bzr created from svn branches using bzr-svn, see http://bzr-mirror.gnome.org/
[23:19] <thrope> ok thanks
[23:19] <jelmer> thrope: alternatively, I'm interested to hear about svn repositories that don't work in bzr-svn
[23:25]  * igc out for several hours
[23:25] <igc> back later hopefully
[23:30] <lifeless> spiv: so, what shall we do today?
[23:31] <fullermd> The same thing we do every night; try and take over the world.
[23:31] <spiv> lifeless: so I'm currently wikifying my measurements from yesterday
[23:31] <spiv> lifeless: after that I'm happy to head over to Epping
[23:31] <spiv> lifeless: if that suits you?
[23:33] <lifeless> hornsby would be better for us today; if epping is better for you though, that is fine too
[23:33] <spiv> lifeless: that's ok
[23:34] <lifeless> ok, well I'll pick up food and grab a train
[23:37] <lifeless> late morning is ok for you ?
[23:40] <spiv> Sure.


[00:00] <bulletxt|2> thanks sbeattie
[00:00] <sarnold> sbeattie: wow that's cool
[00:00] <wxl> wow i did NOT know about lkddb sbeattie thanks!
[00:00] <bulletxt|2> any way to understand if ubuntu ever backported it to the  3.13, or 3.16 series?  even 3.19 would be fine
[00:00] <sarnold> way easier than hunting through git trees :)
[00:00] <sbeattie> rando googling for the win (TIL also)
[00:00] <wxl> bulletxt|2: why not ask if you can get the kernel that includes the support you're looking for?
[00:01] <bulletxt|2> im on 12.04 and for the moment I cant upgrade
[00:01] <wxl> 12.04 is still supported
[00:01] <bulletxt|2> I cant install 4 series can I ?
[00:01] <sarnold> it'd be best to test on a staging machine before production but I'd expect it to work
[00:02] <bulletxt|2> I tried installing 4.4 but it complains it cant find kmod package
[00:02] <wxl> bulletxt|2: linux-generic-lts-xenial will get you 4.4
[00:02] <bulletxt|2> reallyé
[00:02] <bulletxt|2> ?
[00:02] <bulletxt|2> let me check
[00:02] <wxl> yuup
[00:03] <wxl> were you otherwise trying to compile 4.4 yourself?
[00:03] <sarnold> that's probably only available on 14.04 LTS
[00:03] <wxl> oh derp
[00:03] <wxl> sorry
[00:03] <wxl> i take it back
[00:03] <bulletxt|2> yea
[00:03] <wxl> precise not trusty :(
[00:03] <bulletxt|2> yea :(
[00:03] <sarnold> but it might still be the easiest way to get there
[00:03] <wxl> you can get 3.13 with linux-generic-lts-trusty but that's not 4.1
[00:04] <bulletxt|2> yea, so the question is, does latest 3.13 have backportd that driver? :)
[00:04] <sbeattie> it does not (just checked)
[00:04] <bulletxt|2> :(
[00:04] <bulletxt|2> sbeattie: what about 3.16 or 3.19 ?
[00:04] <wxl> you could request an SRU (yeah, i doubt it)
[00:05] <wxl> or you could just upgrade the version
[00:08] <sbeattie> looks like the 3.19 kernel(vivid/linux-lts-vivid) has it backported; *however* that kernel is not officially supported by the kernel team anymore.
[00:09] <bulletxt|2> 3.19? really? that because I can install this on 12.04  http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19.8-vivid/
[00:10] <bulletxt|2> when was that backported?
[00:10] <bulletxt|2> because this actually is newer, http://kernel.ubuntu.com/~kernel-ppa/mainline/linux-3.19.y.z-review/current/
[00:10] <bulletxt|2> not sure what's the differenfe thoughù
[00:11] <sbeattie> mainline == upstream's 3.19 kernel != the ubuntu kernel team's kernel
[00:11] <bulletxt|2> mm
[00:11] <wxl> i mean if you don't care about it being supported there's quite a few ways you could probably go
[00:12] <bulletxt|2> for example?
[00:12] <wxl> compile it yourself, maybe search for ppas, etc.
[00:14] <bulletxt|2> wxl: intel seems to offer source   https://downloadcenter.intel.com/product/82185/Intel-Ethernet-Connection-I219-LM
[00:14] <bulletxt|2> but I cant even compile that doing "make"
[00:14] <bulletxt|2> not sure what im doing wrong
[00:15] <wxl> heh
[00:16] <wxl> well if i click on linux for OS, it gives me stuff for freebsd :)
[00:16] <bulletxt|2> it says OS linux... not sure what intel is doing on that page..
[00:17] <wxl> https://downloadcenter.intel.com/download/17509/Intel-Network-Adapter-Gigabit-Base-Driver-for-FreeBSD-?product=82185
[00:17] <sbeattie> (For the record, this was the commit in the vivid 3.19 kernel that added support for it https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/commit/drivers/net/ethernet/intel/e1000e/hw.h?id=bb198e17affadccf6273253b295dbf100e367b56 )
[00:17] <bulletxt|2> thanks
[00:17] <sbeattie> (sorry, wrong url, https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/vivid/commit/?id=bb198e17affadccf6273253b295dbf100e367b56 )
[00:18] <bulletxt|2> who knows if the ubuntu kernel ppa team put that too
[00:18] <sbeattie> it's not going to be in the 3.19 mainline kernel
[00:19] <bulletxt|2> yea
[00:19] <sbeattie> also, 12.04 has about 1 more month of maintenance left to it.
[00:19] <bulletxt|2> yea :S
[00:19] <wxl> there's the "connections cd" which is supposedly os independent, but they only list red hat for supported linux systems
[00:20] <bulletxt|2> I could try that
[00:20] <sbeattie> moving to 14.04 and the linux-lts-xenial kernel would get you to a kernel/OS combination that will be maintained for 2 more years.
[00:20] <sbeattie> that will support your hardware.
[00:20] <wxl> oh sorry, that's for FCoE
[00:21] <wxl> given that it's a "CD" that suggests an ISO
[00:21] <wxl> which would make sense for something "OS independent"
[00:24] <bulletxt|2> wxl: so its not ok for me?
[00:24] <bulletxt|2> oh well
[00:24] <bulletxt|2> Ill just try
[00:28] <bulletxt|2> thanks for the moment to everyone!
[00:28] <bulletxt|2> have a nice day
[01:53] <smoser> bdmurray, my cloud-init bug referenced a security bug
[01:53] <smoser> err.. cloud-init upload
[01:54] <smoser> not a private one, a security one. it isn't particularly necessary to be security, but i would have expected that is allowed.
[01:57] <slangasek> smoser, bdmurray: I spoke with jgrimm about this; we do expect that by the time a bugfix is pushed to a public queue, the bug is also public, and the process doesn't really allow for verification of bugs that the scripts can't see
[01:58] <smoser> slangasek, tahts fine. i can just make it public
[01:58] <slangasek> smoser: I understand this bug may or may not be made public, but we expect there to be /a/ public bug for tracking this issue
[01:59] <smoser> thats fine. i didn't realize that.
[01:59] <smoser> bug is set public now
[01:59] <smoser> .
[02:00] <slangasek> ok
[02:00] <smoser> rharper, found an issue so i'm not going to re-upload at the moment :-(
[02:00] <slangasek> well, I was going to rescue it from the rejected queue anyway
[02:00] <slangasek> but if there's a known issue, I won't do that ;)
[02:02] <smoser> slangasek, if you're looking for work, and want to start your reviewing of it, that is perfectly fine
[02:02] <smoser> i dont expect anything other than this one issue to change.
[02:02] <slangasek> smoser: is it fine to accept the current version, or should I wait for the upload?
[02:02] <slangasek> (I started reviewing much earlier)
[02:03] <smoser> don't accept it.
[02:04] <slangasek> ok
[02:05] <slangasek> smoser: this version also includes the ds-identify sleep, which AIUI is to be dropped?
[02:06] <smoser> it doesnt hurt much.
[02:07] <smoser> ie, having that support doesnt cause any real issues. it just wont be used
[02:08] <smoser> slangasek, https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/318975
[02:08] <smoser> that is the one change that i think we will need.
[02:09] <slangasek> smoser: since it's all part of ds-identify which is new in this upload, I'll trust that is the case
[02:10] <smoser> and on that note, /me goes afk.
[02:46] <jgrimm> thanks smoser, hope you are feeling better
[04:13] <tsimonq2> infinity, slangasek: So patch pilot is no longer a thing, or did the calendar move?
[04:55] <slangasek> tsimonq2: I'm not aware of any calendar moving; which one were you looking at?
[04:56] <tsimonq2> slangasek: https://calendar.google.com/calendar/embed?src=6k1e5rq45m1bdqq0n1ge3oqaok%40group.calendar.google.com&ctz=America/Chicago
[04:56] <slangasek> tsimonq2: we probably do have less than perfect coverage on it, however, since the person who managed it is no longer at Canonical
[04:56] <tsimonq2> slangasek: I miss Daniel :(
[04:56] <slangasek> so it's possible no roster was set beyond Feb
[04:56] <tsimonq2> (yes I know who you're talking about :P)
[04:58] <tsimonq2> slangasek: Ok, well I found it very useful to have a person in here who I can ping and ask questions to.
[04:58] <tsimonq2> slangasek: I understand the attendance wasn't good, but the couple of people who did end up doing it were really helpful. ;)
[04:59] <slangasek> tsimonq2: people are not immune to pinging just because their name isn't in the channel topic ;)
[04:59] <slangasek> (but if you ping me now, I'm going to be unhelpful, as I have a one-year-old to go put to bed in the next few minutes)
[05:00] <tsimonq2> slangasek: Sure they aren't, but it's saying, "I am setting aside some time to look at patches and go through the sponsorship queue" - I guess that's more inviting than pinging someone who might be working on something else.
[05:00] <tsimonq2> slangasek: <3
[05:03] <tsimonq2> slangasek: I guess I wanted to ping you and Adam because I was hoping someone could send an email or take the time to fill in for Daniel on managing the Patch Pilot roster (not saying you or Adam should do it, bringing up the usefulness of it).
[05:05]  * tsimonq2 's thoughts are a bit jumbled at the moment, I need some sleep
[05:05] <tsimonq2> But otherwise I just wanted to send a ping :)
[05:05] <tsimonq2> slangasek: Have a good night :)\
[12:24] <bulletxt|2> wxl:         sbeattie:       at the end, what I am attempting now is to compile vanilla 4.4 kernel on ubuntu 12.04 :)
[12:24] <bulletxt|2> following this simple guide http://veithen.github.io/2013/12/19/ubuntu-vanilla-kernel.html
[13:04] <javier4> I'm trying to cross-compile a modified version of the wpa package from amd64 to armhf through sbuild. Every time I make a change to the orig tar or the debian overlay I have to reset the sieze and checksums inside the .dsc file. I need something like this --debbuildopt=--source-option=--nocheck that obviously doesn't work. Anyone?
[14:25] <cjwatson> javier4: in nearly 20 years of Debian-based development I've never had to do this; I am confident you are doing something fundamentally wrong
[14:25] <cjwatson> javier4: you should normally just rebuild the source package using the usual tools, e.g. debuild -S
[14:26] <cjwatson> javier4: do not try to work around .dsc checksum verification; you are on the wrong path
[14:28] <javier4> cjwatson: I have a .dsc, an .orig archive and a debian overlay archive. If I made a change inside one of the two, how can I build without changing the checksums? I normally use
[14:28] <javier4> sbuild -A -d vivid-amd64-armhf --host armhf wpa_2.3-1+deb8u4.dsc
[14:30] <cjwatson> javier4: you should not be editing any of those by hand; you edit the unpacked tree and then use debuild -S to construct a new source package
[14:30] <cjwatson> javier4: all of the files you listed are output files, and editing them directly is a mistake
[14:32] <javier4> should I pass to sbuild the unpacked source tree instead of the .dsc as argument?
[14:33] <cjwatson> you can do that if you like, but you don't have to.  rebuilding the .dsc etc. using debuild -S will work fine (that's what I normally do)
[14:33] <cjwatson> but whatever you do, do *not* hack about with the .debian.tar.* (or .diff.gz) directly, that's a mistake
[14:34] <javier4> cjwatson: debuild will work even for croos-compile?
[14:35] <cjwatson> the .orig.tar.* should come unmodified from upstream and any time it changes then its version number (and hence file name) should also change; the .debian.tar.* and the .dsc are *outputs* of the process of building the source package and are not to be edited manually
[14:35] <cjwatson> javier4: debuild -S means "build a source package", and it is irrelevant whether you're later going to be cross-compiling that source package
[14:36] <cjwatson> debuild without -S would be a binary package build, and is not what I am suggesting
[14:39] <javier4> cjwatson: If I understood: 1) create the debian source tree (orig+overlay unpacked) 2)apply my changes to the tree 3) recreate a new overlay and a new .dsc with debuild -S 4) use these two new files together with the original .orig file to build my package
[14:39] <javier4> right?
[14:43] <cjwatson> javier4: roughly, yes
[14:44] <cjwatson> javier4: use dpkg-source -x foo.dsc to unpack the source tree
[14:45] <javier4> cjwatson: yes I already did it that way. Thanks a lot. :-)
[14:48] <javier4> Another question: I don't wanna lose the edits I already made inside the archives. Could I dpkg-source -x my custom-archives, then substitute the my-custom-.orig with the original one, to make debuild -S put all my editings inside the new overlay that it will create?
[14:48] <cjwatson> you are getting yourself into a dreadful tangle
[14:49] <cjwatson> why were you editing the orig in the first place?
[14:51] <cjwatson> so yes, you probably can do something along those lines, but it sounds like you should take backup copies of everything before going any further
[14:52] <javier4> It's complicated: I have a mediatek-customized wpa source in an android tree. I'm trying to port UbuntuTouch, but it seems that the vanilla wpa doesn't work. Then I'm trying to build the customized version and install it inside the rootfs of Ubuntu Touch.
[14:52] <cjwatson> depending on the source format, you may find that debuild -S makes you transform your changes into patches
[14:52] <cjwatson> but cross that bridge if you come to it
[16:22] <javier4> @cjwatson unfortunately my try failed. It seems that debuild -S tries to apply the patches on the orig.tar.gz (that I substituted with the original one) instead of using the already extracted&patched tree.
[16:22] <udevbot> Error: "cjwatson" is not a valid command.
[16:22] <javier4> cjwatson unfortunately my try failed. It seems that debuild -S tries to apply the patches on the orig.tar.gz (that I substituted with the original one) instead of using the already extracted&patched tree.
[16:26] <cjwatson> javier4: Yes, that's how it works.  It's trying to build a source package based on the given orig and the given source tree.
[16:27] <cjwatson> javier4: I'm afraid I can't help you further right now, though.  I suggest doing some reading - there are lots of manual pages and such describing how the source format works.
[16:34] <tsimonq2> javier4: Did you get it working?
[17:35] <javier4> tsimonq2: Hi Simon. Still learning some man-pages. Perhaps the --no-pre-clean flag dor dpkg-buildpackage could help?
[17:36] <tsimonq2> I'm unsure. What are you attempting at this point?
[17:41] <javier4> Build a deb-source directly from a debian tree instead than from an .orig archive.
[18:07] <tsimonq2> javier4: Like cjwatson said, you should probably use a clean orig tarball and just use debian/patches for any needed modifications.
[18:07] <tsimonq2> javier4: My favorite guide on this: https://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
[18:07] <tsimonq2> javier4: I'd save whatever changes you had and just use uscan to get a new tarball
[18:08] <tsimonq2> javier4: Then like I said, use debian/patches and try it
[18:08] <tsimonq2> javier4: You can also just cd into the source dir and build it directly from there with sbuild -d CHROOTNAME
[18:12] <javier4> too much work. I'm doing this just as a try that I'm not sure will fix my ubuntu touch problem.  No possibilities of making just a diff from origin to mediatek-wpa and make a single commit?
[18:44] <tsimonq2> javier4: Well you can just quilt add everything then apply the diff and you're good
[18:44] <tsimonq2> javier4: So yeah you can do it all in one patch if you want


[16:32] <tsimonq2> ogra_: is there a more up-to-date release of Snappy that I can download? Maybe 15.10 or Xenial? The tutorial just says 15.04
[16:32] <ogra_> you can use rolling (xenial based)  when you build your own image with ubuntu-device-flash
[16:33] <tsimonq2> ogra_: how?
[16:34] <tsimonq2> ogra_: and isn't there just an equivelent to do-release-upgrade in snappy?
[16:34] <ogra_> updates are installed automatically when new images are released by default
[16:35] <ogra_> (you can turn that off with "snappy config ubuntu-core" if you do not want that)
[16:35] <tsimonq2> oh, so could I just do snappy update and it will automatically be rolling then?
[16:35] <ogra_> but they will only remain within the channel you originally instaleld
[16:35] <ogra_> no
[16:35] <ogra_> if you use a 15.04 image it will auto-update if there i a new 15..04
[16:35] <ogra_> you wont be able to switch over to the rolling channel
[16:36] <ogra_> (thins might change once we dropped all of system-image)
[16:37] <tsimonq2> ogra_: so there is NO way whatsoever to switch the channel? No sources.list change?
[16:37] <ogra_> not currently, no
[16:37] <tsimonq2> oh, ok
[16:37] <ogra_> as i said, that will likely change once we dropped system-image
[16:37] <tsimonq2> ogra_: is there a download link for a rolling amd64 image?
[16:37] <ogra_> no, there is no such thing, you have to create one yourself
[16:37] <ogra_>  sudo ubuntu-device-flash core --channel=edge --oem=generic-amd64 -o test.img rolling
[16:38] <ogra_> that should get you one
[16:38] <ogra_> (probably add --install=webdm)
[16:38] <ogra_> (and --enable-ssh)
[16:40] <Guest74213> tsimonq2, tsimonq2 it doesn't work on xenial, try on 14.04 Determining oem configuration
[16:40] <Guest74213> generic-amd64 failed to install: snappy package not found
[16:40] <tsimonq2> Guest74213: I just did sudo apt -y install snappy
[16:41] <tsimonq2> oh...but one removes the other
[16:41] <Guest74213> :>]
[16:41] <tsimonq2> ogra_! what packages do I need installed for this? I am running xenial
[16:41] <ogra_> just ubuntu-device-flash should be enough ... it should pull the needed dependencies
[16:41] <Guest74213> ogra_, it doesn't work on xenial
[16:42] <tsimonq2> ogra_: this is what I am getting: generic-amd64 failed to install: snappy package not found
[16:42] <Guest74213> yes, me 2
[16:42] <ogra_> try adding https://launchpad.net/~snappy-dev/+archive/ubuntu/image
[16:42] <tsimonq2> ok, trying now
[16:43] <ogra_> seems the last snappy upload FTBFS
[16:43] <ogra_> so it might be uninstallable atm
[16:43] <ogra_> (xenial is a devel release after all :P )
[16:44] <tsimonq2> ogra_: what do I have to do after the ppa? the package is already installed
[16:45] <Guest74213> The following packages will be upgraded:
[16:45] <Guest74213>   golang-snappy-dev ubuntu-snappy-cli
[16:46] <Guest74213> Warning: The home dir /nonexistent you specified can't be accessed: No such file or directory
[16:46] <Guest74213> The system user `snappypkg' already exists.  Exiting.
[16:46] <Guest74213> and the same error
[16:46] <tsimonq2> it went fine for me...
[16:46] <Guest74213> oh
[16:46] <Guest74213> so can you make the image now?
[16:46] <tsimonq2> nope
[16:47] <tsimonq2> still the same error
[16:47] <Guest74213> yeah :'(
[16:47] <tsimonq2> I'm wondering if I should just pull up a 14.04 VM and build it there, then transfer it over
[16:47] <tsimonq2> (to the host system)
[16:47]  * tsimonq2 trys that
[16:49] <Guest74213> tsimonq2, after that try to install this snap https://uappexplorer.com/app/classic.mvo
[16:50] <Guest74213> tsimonq2, https://uappexplorer.com/app/classic.mvo
[16:50] <Guest74213> sorry
[16:50] <Guest74213> tsimonq2, https://lists.ubuntu.com/archives/snappy-devel/2015-November/001290.html
[16:50] <tsimonq2> well stahp, let me get it installed first jeez us
[16:58] <Guest74213> :D
[16:58] <Guest74213> by all
[16:58] <tsimonq2> I have the Lubuntu 14.04.3 VM ready
[16:58] <tsimonq2> so what do I install?
[17:05] <ogra_> you enable the above PPA and install ubuntu-device-flash
[17:08]  * tsimonq2 met dependency errors and got frustrated, so he is going to give in to just using 15.04 for now
[17:33] <tsimonq2> ogra_: looking to build a snap for irssi, is it easy enough to just port it, or do I have to tweak it a lot?
[17:33] <tsimonq2> ogra_: and what do I do abou dependencies?
[17:33] <tsimonq2> *about
[17:34] <ogra_> create a snapcraft file, it will care for the deps any everything
[17:34] <tsimonq2> ok
[17:35] <ogra_> (for that you want to install snapcraft indeed ... there is some PPA for it too)
[17:40] <tsimonq2> already installed
[17:46] <tsimonq2> ogra_: following https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/, running "snapcraft" in my irssi directory that I created with my snapcraft.yaml file just outputs that I am missing the parts property, but it isn't listed on that link. What's the reason?
[17:46] <ogra_> dunno, someone didnt update the docs yet  ?
[17:47] <tsimonq2> oh
[17:47] <ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files
[17:47] <ogra_> take a look at that snapcraft.yaml
[17:48] <ogra_> at the bottom you see the packages it is supposed to install
[17:48] <ogra_> so create your own parts block :)
[17:48]  * tsimonq2 already found it here: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
[17:48] <tsimonq2> but thanks :)
[17:49] <tsimonq2> so I just need to list ALL of the dependencies?
[17:59] <tsimonq2> ogra_: ok, so irssi is on Github and requires some dependencies, is there any way that I could just clone it from Github, then add/edit some config files, and it will work?
[18:00] <tsimonq2> ogra_: or will it require a complete rewrite?
[18:18] <ogra_> tsimonq2, i think thats easy, but i have never done it ... my packages usually just use debs from the archive
[18:18] <ogra_> you dont need to llist any dependencies
[18:18] <tsimonq2> ogra_: well irssi IS in the repos, so I COULD do THAT too
[18:19] <ogra_> see my file above ... it onnly defines bip and openssl
[18:19] <ogra_> deps are pulled automatically into the snap
[18:20] <tsimonq2> oh cool


[05:01] <MauroGaspari[m]> <OvenWerks "Mauro Gaspari: yeah, the user si"> Hopefully pipewire will make things a bit easier?
[05:02] <OvenWerks> probably not
[05:03] <OvenWerks> at least I think not if it can still truely be a JACK replacement
 *summons Eickmeyer for reasons*
 @teward001 [*summons Eickmeyer for reasons*], Yeeeees?????
[05:09]  * OvenWerks hears creaking and moaning in there somewhere...
[05:12] <Eickmeyer[m]> OvenWerks: Cracking, yes. Moaning, not so much.
 @Eickmeyer [Yeeeees?????], well (1) i'm drunk and (2) i'm wondering if there was anything else you still needed uploaded while i'm awake
 because i can't sleep xD
 @teward001 [well (1) i'm drunk and (2) i'm wondering if there was anything else you still ne …], Well, I don't really have anything at the moment. I did upload my first package as a MOTU the other day, and it was accepted. No questions were asked, probably the cleanest, simplest package I've ever uploaded, and it wasn't even Studio rela
[05:15] <studiobot> ted.
 was it an SRU?  :P
 usually bugfixes are easier to get in :P
 until freeze anyways
 It was an entirely NEW package.


[15:48] <avc> exit
[15:48] <avc> quit
[15:48] <avc> \exit
[15:48] <avc> \quit
[22:50] <autumna> hi dool7
[22:55] <dool7> hi. someone recommended i come to this channel if I'm interested in helping with the Ubuntu Studio project
[22:57] <zequence> dool7: Just keep logged in, and in touch. Or, present yourself on our devel mail list. May take a while before someone answers.
[22:57] <autumna> welcome, but yes, what zequence said
[22:58] <zequence> Night everyone!
[22:58] <autumna> gnight


[03:39] <daftykins> yigal is totally timewasting and giving bad advice in #ubuntu
[08:07] <valorie> hi folks, since adding some new Kubuntu Council members, we opened the #kubuntu-council channel
[08:09] <valorie> how do I get that logged by the official logging bot?
[08:09] <valorie> or should I take this to the irc council?
[08:12] <Flannel> valorie: I believe it's still an email to rt at ubuntu
[08:13] <valorie> rt?
[08:13] <valorie> that's the sysadmins, correct?
[08:13] <k1l_> its the admins from canonical that manage the logbot
[08:14] <valorie> ah, got it
[08:26] <k1l_> done
[08:27] <valorie> and sent, thank you
[08:29] <bazhang> that insane rants for $500
[08:29] <bazhang> and was
 eldariond: better ask in ##chat
[11:15] <bazhang> wut wut
[12:01] <ikonia> hello ahoneybun
[12:01] <ahoneybun> hey ikonia
[12:02] <ikonia> what's up ? how can we help you tody ?
[12:02] <ikonia> today too
[13:09] <c0m0> Hi, my user name is c0m0 and I has been banned from #irc chanel and I would like to know the reason
[13:10] <c0m0> I never have been banned from any irc channel and I have this problem only in #ubuntu chanel
[13:14] <ikonia> c0m0: hi there
[13:14] <ikonia> so you're currently banned in #ubuntu right ?
[13:14] <c0m0> ikonia: yes, but I don't know why
[13:15] <ikonia> lets see if we can find out
[13:15] <c0m0> When I use /join #ubuntu I see "Cannot join #ubuntu (You are banned)."
[13:15] <ikonia> I see why
[13:16] <ikonia> can you give me a moment to look into it please
[13:16] <ikonia> c0m0: that should be resolved for you now
[13:16] <ikonia> apologies for that - it was a false positive for you
[13:17] <ikonia> c0m0: do you want to try to join #ubuntu now ?
[13:17] <c0m0> ikonia: yes, I like to see the post in ubuntu chanel
[13:18] <ikonia> try to join now and it should work
[13:18] <ikonia> great, you're in, I see you
[13:18] <c0m0> ikonia: thanks Now it works
[13:18] <ikonia> no problem, apologies for the problem
[13:18] <c0m0> ikonia: what was the false positive?
[13:19] <ikonia> there had been trouble makers from your ISP - your IP was caught in a ban
[13:19] <ikonia> that simple really
[13:19] <c0m0> ikonia: thanks for your help
[13:19] <ikonia> no problem
[13:24] <ikonia> c0m0: if you don't need anything else can you /part this channel please
[13:26] <ikonia> ahoneybun: do you need anything from this channel ?
[14:25] <DJones> ikonia: It was f0urq that returned, drone +q'd them, then they left
[14:25] <ikonia> ah
[15:27] <Pici> bazhang: fyi, I had a issue with tachibana yesterday, ended up with a kick warning and then they went silent shortly after joining and not getting an answer.
 i would be installing cisco packet tracer
[15:28] <bazhang> what ever for pici????
[15:28] <k1l> the one claiming he got down syndrom while insulting others yesterday
[15:28] <bazhang> !unfair
[15:28] <bazhang> @random chu emacs HURD
[15:28] <bazhang> oh yeah
[15:29] <k1l> hihi, the bot seems to have a hurd random generator ;p
[15:29] <bazhang> lies!
[15:29] <bazhang> bots got a truthy thing goin on
[15:33] <ikonia> Pici: was that the guy who threatened to rip your ears off ?
[15:33] <ikonia> I enjoyed him
[15:34] <Pici> ikonia: nah, this is some other guy.
[15:34] <ikonia> oh, I enjoyed him
[15:34] <genii> Hehe, the ear-ripper troll
[16:00] <phunyguy> laaa laa laa ear the ripper...   *cowbell* *cowbell* *cowbell* *cowbell* *cowbell* *cowbell*
[21:48] <valorie> ah, ahoneybun was here because he's now on the KC, and thus an op on #kubuntu and #kubuntu-devel
[21:49] <valorie> or supposed to be....
[21:50] <Unit193> I don't see the flags.
[21:53] <yofel> how are those even updated? We might've forgotten do some some step for that
[21:53] <yofel> or who is supposed to update them?
[21:55] <k1l> J.Riddell got founder flags, so he is the one with the most access
[21:56] <yofel> do the launchpad teams have an effect?
[21:57] <k1l> but Jussi01, ScottK, yofel, valorie, shadeslayer got all access too (kcouncil flagset). and the irccouncil got access too.
[21:57] <yofel> hm, that list is outdated
[21:57] <k1l> yofel: no. someone named above needs to sort the flags here on freenode.
[21:57] <valorie> very much so
[21:58] <yofel> how does one add/remove said kcouncil flagset for people?
[22:01] <k1l> i am looking for a guide i have in mind but just cant find it on the interwebs
[22:01] <yofel> thanks
[22:02] <Unit193> yofel: /msg chanserv help flags
[22:02] <Unit193> or /msg chanserv help access
[22:02] <k1l> there seem to be clever templates set already. so i would use them
[22:03] <k1l> /msg chanserv help templates
[22:03] <Unit193> yofel: Also, usually the LP teams are supposed to match the channels.
[22:03] <k1l> yeah, but there is not automatic sync between LP and freenode
[22:03] <Unit193> I know.
[22:03] <Unit193> k1l: Also, that's why I linked to 'access', for the templates.
[22:04] <Unit193> /msg ChanServ ACCESS #kubuntu ADD user57 kcouncil  for example.
[22:04] <yofel> ahh, thanks. I'll try it
[22:12] <yofel> ACL updated to match the current council, thanks for the help
[22:13] <Unit193> yofel: You'll want to make sure your folks are logged in too, ahoney wasn't.
[22:14] <yofel> isn't it enough if they're registered?
[22:15] <Unit193> Why would it be?  It's the same for forums, can't post under your username if you aren't logged in.
[22:15] <yofel> good point