[00:01] <poolie> jam, hi
[00:02] <poolie> and lifeless
[00:03] <poolie> jam, want to talk?
[00:04] <jam> isn't it standup time?
[00:16] <spiv> https://bugs.edge.launchpad.net/bzr/+bug/230902
[00:26] <lifeless> spiv: un
[00:27] <lifeless> spiv: fun
[00:27] <poolie> jam, nicely done with setup.py, but it should be in news too
[00:33] <spiv> jam: I just realised there's a problem with my batching patch; mail sent.
[00:47] <lifeless> spiv: btw I think your batching should apply to all repos
[00:47] <lifeless> spiv: there is no reason to special case it for remote
[00:47] <lifeless> IMNSHO
[00:53] <spiv> lifeless: Hmm.
[00:53] <spiv> lifeless: I think it would penalise plain pack repos.
[00:54] <lifeless> spiv: index lookups for 5 keys are more efficient than 5 lookups for 1 key
[00:54] <lifeless> spiv: with both GI and BTGI
[00:54] <spiv> lifeless: e.g. if there's only one new revision, then asking about 50 revisions will cause extra work for no benefit.  And doing it one-by-one with plain packs isn't so bad because it's filling the caches of the indexes AIUI.
[00:55] <spiv> What's GI/BTGI?
[00:55] <lifeless> spiv: tell you what; test it :)
[00:55] <lifeless> graphindex btreegraphindex
[00:55] <spiv> Ah ok.
[01:00] <lifeless> kiko: why have you moved the download instructions lower on the front page?
[01:00] <lifeless> kiko: they used to be lower and we moved them to the top based on feedback from users of the web site
[01:01] <kiko> lifeless, because I had to scroll to read what it was.
[01:02] <lifeless> kiko: yes, thats the tradeoff we made
[01:03] <kiko> a bad one. but it's fixed now.
[01:03] <lifeless> kiko: another one, and this one matters more, is why you've just moved the toc to the bottom of the workflows page
[01:03] <lifeless> its entirely useless there
[01:03] <kiko-zzz> lifeless, yeah, maybe we should just remove that ToC entirely, I'm not sure
[01:03] <lifeless> kiko-zzz: its a long page, I think it needs a toc
[01:03] <kiko-zzz> yeah.. ok
[01:04] <kiko-zzz> I wish we could at least float the damn toc or something
[01:04] <kiko-zzz> but it would fight with the sidebar
[01:04] <lifeless> just put it under the intro
[01:04] <lifeless> right before solo
[01:06] <kiko-zzz> that page is a bit of a mess
[01:12] <lifeless> thanks for putting the toc back
[01:12] <kiko-zzz> the images should be like 1/3rd of the size
[01:12] <kiko-zzz> maybe tomorrow
[01:12] <lifeless> I'm not sure the welcome page is better; but I let others worry about that
[01:12] <kiko-zzz> I'm absolutely sure it's better, luckily
[01:12] <kiko-zzz> man who do I have to kill to get some food in this office
[01:13] <lifeless> kiko-zzz: you just reminded very strongly of linus
[01:14] <lifeless> absolute confidence, and yet, still wrong
[01:14] <kiko-zzz> at least I get it done
[01:14] <kiko-zzz> now get out of my way :)
[01:16] <jml> lifeless: for a minute there I was thinking you meant the Peanuts character.
[01:16] <lifeless> jml: perhaps I was
[01:17] <jml> lifeless: it doesn't gel.
[01:17] <lifeless> jml: ah, then perhaps I wasn't
[01:20] <poolie> kiko-zzz, maybe we should really split the wiki from the web site
[01:20] <poolie> it's hard to make it look slick in moin
[01:21] <kiko-zzz> yeah, it's an idea. for now I think it's okay but it needs a facelift for december
[01:21] <kiko-zzz> maybe just a moin facelift, but maybe something more nicer
[01:21] <lifeless> what happens in december?
[01:22] <poolie> the end of the year :)
[01:22] <kiko-zzz> xmas
[01:22] <kiko-zzz> gifts
[01:22] <kiko-zzz> vacations
[01:22] <kiko-zzz> god's last 3 gifts to mankind
[01:22] <poolie> 'myrrh... how nice!'
[01:23] <poolie> makes a change from socks
[01:24] <poolie> lifeless, more seriously i think kiko was wanting us to have something exciting and public happen before then
[01:24] <poolie> repostiory stuff will be exciting, but maybe not ready for wide use
[01:25] <markh> "tests suite passes on all major platforms" would possibly qualify as exciting and public :)
[01:27] <poolie> that is pretty exciting
[01:27] <poolie> is that true on windows at the moment, or not quite?
[01:27] <markh> will be exciting :)  No movement on the LockContentionErrors AFAIK
[01:28] <markh> I need guidance on how to handle them before I can progress on it
[01:28] <markh> s/handle/silence/whatever/
[01:29] <lifeless> implement dirstatev2, new tree format, then silence the existing one
[01:30] <lifeless> or v4 or whatever the signature would reach
[01:30] <poolie> someone else had a problem with file locking on a mac the other day
[01:30] <markh> oh, I didn't think it was *that* easy! ;)
[01:30] <poolie> eventually we need to get away from that
[01:30] <lifeless> well I mailed the list with a proposal
[01:30] <poolie> not to say we can't take a smaller step first
[01:30] <lifeless> the responses seemed to vary
[01:30] <markh> tests are too noisy on windows so regressions will not be noticed.  Silencing the test noise is IMO more important than fixing the implementation
[01:31] <markh> and presumably easier
[01:32] <poolie> markh, did you get my pm?
[01:32] <lifeless> markh: given that tests fail because of the implementation, I really can't agree
[01:33] <markh> lifeless: my concern is that regressions completely unrelated to the *known* problem of locks will be hit
[01:34] <markh> and experience shows that *has* happened in the past - regression have been introduced that the tests *did* see, but got lost in the noise
[01:34] <markh> that IMO is worse than what we already know is bad about locks on windows
[01:34] <lifeless> markh: selftest -v | grep 'FAILURE|ERROR'
[01:35] <lifeless> markh: then do that and diff, if there are + lines, its new failures
[01:35] <markh> lifeless: who are you saying should do that regularly?
[01:35] <markh> it wasn't me that introduced the regressions I'm talking about
[01:35] <lifeless> whoever is doing release related stuff on windows; before the release
[01:36] <markh> well - the end result is we end up in a catch 22 - wont fix tests until we fix the impl, impl is very hard to fix, especially on windows, as tests are too noisy to see what regressions you introduced :)
[01:36] <markh> but - I'm not interested in arguing this
[01:36] <markh> I just suggested it might be good public info to work towards and announce
[01:36] <markh> take it or leave it :)
[01:37] <markh> I'm interested in helping fix tests - but have no time to help with a dirstate impl
[01:41] <lifeless> markh: I don't get the catch-22, but perhaps I just have a different understanding on how the tests fit together
[01:43] <markh> lifeless: i think if the situation was reversed, and we had massive linux test failures due to an implementation problem, I doubt your solutions would fly - either the "live with it or provide a new impl" position or the "live with it and use grep to detect regressions" position.
[01:44] <poolie> hm
[01:45]  * jml emulates looms with branches
[01:45] <poolie> > Silencing the test noise is IMO more important than fixing the implementation
[01:45] <poolie> i mostly agree, getting to a known reliable state is a good first step
[01:46] <markh> We *know* all about the lock problems.  We *don't* know about new regressions
[01:46] <poolie> right
[01:46] <markh> bbiab
[01:47] <lifeless> markh: actually, I use the diff approach when I'm dealing with horribly broken branches, which happen when I do some of the heavy lifting I do regularly
[01:47] <lifeless> markh: if I was a windows dev, I would be hacking on the tweaked implementation at top speed because that would permanently fix this issue
[01:48] <lifeless> markh: but I'm not a windows dev, so even if wrote a new impl for you (which really is quite small, ~500 lines totall diff I think) I couldn't be sure it had fixed things for windows
[01:49] <lifeless> markh: you seem to feel I'm not helping, so I'll drop it
[01:49] <lifeless> poolie: silencing the test noise doesn't get us a known reliable state
[01:52] <poolie> ok i'm going to look at this usertest thing with spiv
[02:06] <lifeless> I thought someone wrote a stats gatherer that determines by annotate the contributors to the code base
[02:06] <lifeless> (rather than commit cout, which is... crude)
[02:12] <spiv> lifeless: maybe abentley did?
[02:18] <jml> ooh, fancy: "You can restore the old tip by running:..."
[03:16] <lifeless> poolie: bzr 1.8. branch created
[04:08] <teratorn> anyone alive that knows about bzr-svn internals? got a bug that I wouldn't mind talking about: https://bugs.launchpad.net/bzr/+bug/277369
[04:08] <jelmer> teratorn, Yeah, I just closed that one, it's already fixed
[04:08] <teratorn> jelmer: oh wow that rocks
[04:08] <teratorn> jelmer: in trunk?
[04:09] <jelmer> teratorn, Not exactly sure what version, 0.4.13 for sur ehas the fix
[04:09] <teratorn> oh, heh. well I just commented on the bug after having upgraded to the latest release
[04:10] <poolie> nicely done
[04:10] <teratorn> I mean, it still crashes :)
[04:12] <jelmer> teratorn, You'll probably have to repush the other revisions as well
[04:12] <jelmer> teratorn, since the error would actually be in there
[04:13] <teratorn> jelmer: hmm, how would I do that?
[04:15] <jelmer> teratorn, the easiest way is to remove the revisions manually from svn
[04:16] <jelmer> teratorn, that requires administration access to it though
[04:16]  * jelmer gets some sleep
[04:16] <teratorn> I didn't even know that was possible, with SVN
[05:15] <abentley> spiv: wisnae me.
[06:30] <gimmal> hey folks. having trouble installing bzr-xmloutput plugin. 'bzr plugins' gives me this: Unable to load plugin 'xmloutput' from '/usr/lib/python2.4/site-packages/bzrlib/plugins' # so how do I find out why it can't load the thing?
[06:31] <gimmal> fwiw, it's being installed for sake of bzr + eclipse eclipse plugin
[06:31] <markh> gimmal: check out .bzr.log - executing 'bzr version' will tell you where it is
[06:32] <gimmal> ok. thank you
[06:32] <markh> probably in ~
[06:32] <gimmal> yeah
[06:33] <gimmal> hey do y'all have a minute to look at a paste? I'm no python student as of yet ... heh
[06:33] <gimmal> it boils down to this in the traceback: TypeError: __init__() got an unexpected keyword argument 'short_name'
[06:34] <gimmal> which is in the traceback, listed after this: File "/usr/lib/python2.4/site-packages/bzrlib/plugins/xmloutput/__init__.py", line 108, in cmd_xmlstatus
[06:34] <gimmal>     short_name='V'), # any ideas?
[06:34] <gimmal> bzr version mismatch?
[06:35] <markh> that would be my guess
[06:35] <gimmal> ok; could be simple to fix, thanks
[06:38] <gimmal> simple, muahahah ... so i just start virtualbox, copy my /etc/apt/soruces.list to a vfat partition, move my hdd to the gateway laptop (where bzr is, and where eclipse is installed), then use gnome-terminal via an xming (xserver for vista) session ... update the apt repo on that comp, install the bzr deb from backports.org, then start eclipse (via gnome-terminal via xming) again ... pretty simple, yeah, just involving a lot of steps...
[06:38] <gimmal> the hdd is a portable, duhuhuhehe
[06:40] <gimmal> if only virtualbox was booting the virtual deb image ... it's some kind of ext2 fs support in the windows env...
[06:41] <gimmal> woo success ... weird wait preiod after plugging in the hdd
[06:59] <vila> hi all
[07:24] <gimmal> well thanks for the help
[07:41] <loswillios> hey
[07:42] <loswillios> I have a little problem here, bzr pull tells me to do 'bzr upgrade' to get better performance but 'bzr upgrade' says format 1 is already at the most recent format.
[07:42] <loswillios> anyway to solve that, or workaround the message?
[08:01] <jml> loswillios: perhaps it's the remote branch that needs to be upgraded?
[08:03] <bob2> it may say that if it is an old rich-root format
[08:11] <loswillios> hm.. I guess I should do a clean check out
[08:15] <loswillios> jml: seems like it: even 'bzr get http://bazaar.launchpad.net/~team-mms/mms/1.1.0 mms-1.1.0' says "Format <RepositoryFormatKnit1> for http://bazaar.launchpad.net/%7Eteam-mms/mms/1.1.0/.bzr/ is deprecated - please use 'bzr upgrade' to get better performance"
[08:16] <jml> loswillios: so, if you want to work around it, you need to upgrade that branch.
[08:16] <jml> loswillios: which is only something you can do if you are a member of ~team-mms
[08:17] <loswillios> I'll poke the author, thanks
[10:04] <_raz_> Does someone know a solution for the push/branch issue for ftp in version 1.7 (https://bugs.launchpad.net/bzr/+bug/259855)?
[10:05] <_raz_> looking at the 1.7 bzrdir code, the patch for it is already in, but does not resolve that issue - at least not for me
[10:08] <_raz_> looking at the push result on the server, the .bzr directory and all subdirectories miss a g+x in contrast to the old behaviour
[10:10] <_raz_> files accordingly lack g+r and so on
[10:12] <_raz_> though this only seems to affect anything directly under .bzr, not under the directories within it
[10:26] <kiorky> Uhm is that normal ,that with pyrex, i can not run 'easy_install bzr' (i go into sandbox violation)
[10:52] <lifeless> kiorky: no idea, we generally recommend people use packages
[10:52] <lifeless> kiorky: we have binaries for windows, macos X and most linux distros have current packages
[11:02] <poolie> night all
[13:09] <rocky> does bzr 1.7 run on py2.6 ?
[13:09] <fullermd> I don't think so.
[13:09] <fullermd> vila is doing some work on that.
[13:10] <vila> bzr.dev should, but since 2.6final is not yet out, take it with a grain of salt...
[13:15] <rocky> vila: 2.6 final is out =P
[13:15] <rocky> jelmer: any release of bzr-svn supporting bzr 1.7 yet? or still use the 0.4 branch?
[13:15] <vila> oops, since when ?
[13:16] <jelmer> rocky, 0.4.13
[13:16] <rocky> vila: lol, you must not read much python blogs ... it was released yesterday i think, i read about 50 blog posts about it ;)
[13:16] <rocky> jelmer: awesome, thanks
[13:16] <rocky> will test it out
[13:16] <fullermd> vila: See what you miss when you sleep?   :p
[13:17] <vila> rocky: anyway, you're welcome to test it and report any problems, but the test suite is passing (modulo a very minor/cosmetic error)
[13:17] <vila> fullermd: damn, I knew it !
[13:18] <vila> fullermd: I'm still wondering when *you* sleep though :)
[13:23] <fullermd> I'll get all the sleep I need when I'm dead   ;)
[13:24] <jelmer> hmm, no python 2.6 in debian yet :-(
[13:24] <fullermd> Debian?  Do they even know there's a python 2.4 yet?
[13:28] <rocky> lol
[13:28]  * rocky just finished building python2.6 on his ubuntu
[13:42] <rocky> jelmer: when i "bzr co https://dev.serverzen.com/svn/cluemapper/ClueMapper/trunk ClueMapper-trunk" (you can do this too, it's an anonymous svn repo) at around rev 82 it slows down *big* time ... bzr 1.7.1 + bzr-svn 0.4.13 + svn 1.5.1
[13:44] <jelmer> rocky, svn rev 82?
[13:44] <rocky> i guess, i'm watching the status bar
[13:44] <rocky> it gets to 82/156 and slows down (it's at 87 right now)
[13:46]  * rocky integrates cluemapper svn repo into jelmer's bzr-svn test cycles ... :)
[15:06] <Leonidas> is it possible to manipulate a bzr branch without having a working tree?
[15:07] <fullermd> Depends on what manipulation you want to perform.
[15:07] <Odd_Bloke> Leonidas: It depends what you mean by 'manip... yeah.
[15:07] <Leonidas> jelmer: python 2.6 is probably not going into debian anytime soon - freeze.
[15:07] <Leonidas> fullermd: add files, commit stuff.
[15:08] <Odd_Bloke> Leonidas: It could go into experimental.
[15:08] <Odd_Bloke> Oh, wait, it'd be a separate package, it could go into unstable. >.<
[15:08] <fullermd> Well, no, since that would be manipulating a working tree.
[15:08] <Leonidas> Odd_Bloke: yeah, thats possible
[15:08] <jelmer> Leonidas, I run experimental
[15:08] <Leonidas> fullermd: ok, thanks.
[15:08]  * Leonidas runs testing and stable and backports important stuff.
[15:08] <fullermd> (of course, if you dug into bzrlib, you could pretend to have a working tree in some ways, but then you sorta HAVE a WT)
[15:09] <Leonidas> (but as long as there are no packages, there's nothing to backport)
[15:09] <Leonidas> fullermd: no, thats too problematic, I'll just make me a working tree.
[15:27] <LarstiQ> Leonidas: those kinds of things are what a working tree is for, so no :)
[15:27] <LarstiQ> Leonidas: but you need not have a working tree _on disk_, you can use a memory backed tree.
[16:10] <abentley> Leonidas: You need a working tree to *commit*, but if you prefer, you can create a Tree and a Revision, and install those.
[16:33] <Leonidas> Is there a low-level commit? I have a list of files which changed and want to commit them without creating files in the working tree.
[17:03] <Leonidas> I'm trying to understand bzrlib.commit.Commit.commit() - where does it gather the changes to the WorkingTree?
[17:07] <jpe> Is bzr ls --non-recursive http://url supposed to work?
[18:06] <chadmiller> Hi all.  One of my co-workers is using a SVN tree converted to BZR.  In merging one tree to another, bzr complained that the files inside src/ were versioned but src itself was not.  It moved src to src.moved, and added the merging files as src/... .  I thought we worked around it by collating them with "find -exec mv" .  Now, when he's finished merging files, "bzr commit" looks like it's removing all files.  All his source files are "unknown" and "removed
[18:06] <chadmiller> " at the same time.  What can he do?
[18:07] <AmanicA> Leonidas: I think its in  self.builder = self.branch.get_commit_builder(self.parents, ..
[18:09] <Leonidas> AmanicA: yeah, I'm now currently trying to overwrite stuff in the Commit class. Fiddling with the builder was a bit too complicated.
[18:09] <AmanicA> yes
[18:09] <AmanicA> I saw its a bit complicate
[18:09] <AmanicA> d
[18:10] <LarstiQ> chadmiller: that sounds confusing
[18:11] <chadmiller> Well, we certainly are.
[18:11] <AmanicA> chadmille: it sounds like the src dir was added in 2 different branches (thus 2 different file ids)
[18:11] <chadmiller> -ed.  not -ing.
[18:11] <chadmiller> AmanicA: I thought so.  He insists it wasn't.  The latest-common-ancestor has it, he says.
[18:12] <fullermd> Well, leaving aside the "how did you get src moved in the first place", if you find -exec mv'd all the files, as far as bzr is concerned they ARE removed...
[18:13] <chadmiller> We didn't "bzr rm" them or anything.
[18:13] <fullermd> But they're not where it expects them.
[18:14] <chadmiller> fullermd: So, it expect them in "src.moved"?
[18:14] <chadmiller> Which we then "bzr mv" to "src"?
[18:15] <fullermd> Sure.  That's where it put them.  I don't think your description works; the files can't be versioned while src/ is not, but if src (in the branch you merged) isn't the same as src (in your branch), you'd expect yours to end up in src.moved, and everything cascades from there.
[18:15] <chadmiller> Okay.  I'll try that.
[18:15] <fullermd> Mass moved like that tend to lead to wackiness down the line though.  I'd start with investigating why the src/'s are distinct.
[18:17] <chadmiller> "Conflict because src is not versioned, but has versioned children.  Versioned directory."
[18:18] <fullermd> That sounds like src was removed on the other branch.
[18:18] <fullermd> If it were then re-add'd (instead of revert'd back into existence), that would explain why it's considered different.
[18:18] <chadmiller> fullermd: Occam's razor says it is a svn conversion bug.
[18:18] <fullermd> Likely.
[18:19] <fullermd> So, the thing to decide is, which of the src/'s is more likely to be used going forward, and which exists in other branches you may want to merge in the future, etc.
[18:19] <fullermd> Then you can decide which to keep.
[18:19] <chadmiller> "bzr: ERROR: Could not move src.moved => src: src is already versioned."
[18:21] <chadmiller> I'm having him "bzr mv src src.old", then "bzr mv src.moved src"
[18:24] <LarstiQ> that error I'd expect when he did "bzr mv src.moved src"
[18:24] <LarstiQ> without the .old step in between
[18:26] <Leonidas> AmanicA: right, bzr seems to have no memoery-API, this looks like it's goingt to be painful
[18:27] <LarstiQ> what?
[18:29] <LarstiQ> Leonidas: did you see what abentley said? And look at how bzr-svn does things?
[18:29] <Leonidas> LarstiQ: no, sorry - my bouncer has no backlog.
[18:31] <Leonidas> This is a bit of a problem, I have to reconfigure it some day. or find one which is not crappy
[18:40] <abentley> Leonidas: You need a working tree to *commit*, but if you prefer, you can create a Tree and a Revision, and install those using install_revision.
[18:42] <Leonidas> abentley: ah. This sounds easier.
[18:46] <Leonidas> install_revision(repository, rev, revision_tree)
[18:47] <Leonidas> So after I installed the revision, I have to link it to the branch.
[18:48] <abentley> Leonidas: Yes; Branch.set_last_revision_info
[18:50] <Leonidas> very nice, trying this.
[18:52] <chadmiller> Back next week.
[18:52] <fullermd> Oh, surely there aren't THAT many files to move   :p
[18:53] <chadmiller> ideas to<EMAIL_ADDRESS>please.
[19:07] <Leonidas> I'm getting "Revision is not compatible with KnitPackRepository" when adding an empty revision (that is, it only has a revid)
[19:43] <Arjen> How do I determine the commit in which a file was introduced?
[19:49] <Verterok> Arjen: bzr log -l 1 --forward <the_file>
[19:54] <loxs> hello, I can't find any documentation on how to setup a "smart server". could anyone help me please?
[19:55] <beuno> loxs, all you need is to have bzr installed on the remote server
[19:55] <beuno> and for clients to use bzr+ssh
[19:56] <loxs> you mean sftp?
[19:56] <beuno> no, I really mean bzr+ssh
[19:56] <loxs> because for this I don't need bzr installed on the remote server
[19:56] <beuno> right
[19:56] <loxs> hm, then could you please explain what do you mean by bzr+ssh
[19:57] <beuno> for bzr+ssh you do, because it uses the remote bzr installation to, well, be smart  :)
[19:57] <beuno> loxs, sure
[19:57] <beuno> you would do:  bzr branch bzr+ssh://user@host/path/to/branch
[19:57] <beuno> instead of: bzr branch sftp://...
[19:57] <loxs> ahamz... that sounds nice
[19:58] <loxs> and how do you manage permissions? on filesystem level?
[19:58] <beuno> yeap
[19:58] <beuno> since you're using ssh, whatever that user has read/write access to
[19:59] <loxs> I want to allow my developers commit to their own branches, but disallow them to commit to trunk. But for them to be able to commit to their branches, they need to have a write access to the .bzr in the main repository directory... is it safe?
[20:00] <beuno> loxs, they can have their own branches in their home dir
[20:01] <Leonidas> I need some help on this code: http://paste.pocoo.org/show/86963/
[20:01] <loxs> hm, right... I can't stop thinking in svn terms... thanks for opening my eyes :)
[20:02] <Leonidas> I'm currently missing two things: 1) how to generate a revid 2) how to get the proper revno
[20:02] <beuno> loxs, :)
[20:10] <Verterok> Leonidas: I known nothing about commit internals, but it seems that rev_id id returned by the commit_builder
[20:12] <Verterok> beuno: hi
[20:12] <Leonidas> Verterok: yeah, me too. but CommitBuilder does not generate it, it gets it as an argument on instantiation
[20:12] <beuno> Verterok, ho
[20:14] <Verterok> Leonidas: it's an argument of Commit
[20:14] <Verterok> Leonidas: from the docstring: "        :param rev_id: If set, use this as the new revision id.
[20:14] <Verterok>             Useful for test or import commands that need to tightly
[20:14] <Verterok>             If null (default), a time/random revision id is generated."
[20:14] <Verterok>             control what revisions are assigned.  If you duplicate
[20:14] <Verterok>             a revision id that exists elsewhere it is your own fault.
[20:15] <Verterok> apologize the big paste
[20:16] <Leonidas> Verterok: I know, but I don't understand where it is being generated.
[20:17] <Leonidas> Verterok: rev_id is None by default
[20:17] <Leonidas> Verterok: self.rev_id is set to None in commit()
[20:17] <Leonidas> but I'm missing the part where it gets generated
[20:18] <Verterok> Leonidas: I think this should clarify that :) "If null (default), a time/random revision id is generated."
[20:18] <Leonidas> the builder returns an id, so I suspect it generates it.
[20:19] <Leonidas> Verterok: but where is the part where it gets generated in the code?
[20:20] <Verterok> Leonidas: I assume in the Commit builder, beacuse if it's null, it returns a generated rev_id
[20:21] <Leonidas> Verterok: repository.CommitBuilder.commit() only returns the rev_id that was passed to its constructor
[20:22] <Verterok> mmm...maybe we are missing something :p
[20:24] <Leonidas> Verterok: yeah, I feel stupid/blind ;)
[20:25] <Verterok> Leonidas: don't feel alone :)
[20:35] <jam> Leonidas, Verterok: In CommitBuilder there is _generate_revision_if_needed which calls _gen_revision_id
[20:35] <jam> which is used if you don't supply a revision_id
[20:36] <jam> and _generate_if_needed is called as part of CommitBuilder.__init__
[20:37] <Verterok> jam: thanks!
[20:37] <LaserJock> quick question, is it possible to change the committer's email address in the log?
[20:37] <LaserJock> would rebase do that?
[20:38] <beuno> LaserJock, you could do it with rebase, but it would break compatibility with anyone else who branched
[20:38] <Leonidas> jam: thanks, gen_revision_id was what I was looking for.
[20:38] <jam> LaserJock: it would be possible to do so during rebase, I don't think it specifically supportsr it
[20:38] <jam> beuno: that's what rebase *does* anyway :)
[20:38] <LaserJock> beuno: I don't care about anybody else ;-)
[20:38] <Leonidas> jam: can you also tell me how to get the right revno?
[20:38] <beuno> LaserJock, life's so much easier that way  :p
[20:39] <jam> Leonidas: "right revno"? in what context
[20:39] <LaserJock> beuno: I don't do anything people care about anyway :-)
[20:39] <beuno> jam, you may be the right person to answer this. How can I find out what revno a revid is part of?
[20:39] <jam> "is part of" ?
[20:39] <LaserJock> ok, so related question, is it possible to have multiple email addresses in bzr?
[20:39] <jam> you mean when it was merged?
[20:40] <beuno> jam, it's merged into that revno, yes
[20:40] <jam> LaserJock: you can generally set a email address per branch
[20:40] <jam> beuno: "bzr log" ?
[20:40] <LaserJock> jam: ah, excellent
[20:40] <jam> "bzr log -r revid:XXX..-1"
[20:40] <beuno> jam, right. Now, let's say I need to do that through python
[20:40] <jam> beuno: you could use the output of 'bzrlib.tsort.merge_sort()'
[20:40] <jam> it is what 'bzr log file' now does
[20:40] <beuno> "here's a revid, give me the mainine revno it belogs to"
[20:40] <jam> you can see the code in log.py
[20:41]  * beuno looks
[20:42] <jam> around line 603
[20:42] <Leonidas> jam: In this context: http://paste.pocoo.org/show/86963/
[20:42] <Leonidas> jam: line 1 is already replaced with something that is not static anymore
[20:43] <jam> Leonidas: so for the "set_last_revision_info()" call?
[20:43] <jam> and you aren't doing this as a commit on something else
[20:43] <jam> which you know the revno?
[20:44] <jam> I can give you a way, but some are easier/faster than others
[20:44] <jam> for example, if you know the revno, parent_id for the parent of this commit, then it is just revno+1
[20:44] <Leonidas> jam: well, I commit this on something else.
[20:44] <jam> otherwise there is bzrlib.repository.get_graph().find_distance_from_null()
[20:45] <jam> you can look at bzrlib/graph.py find_distance_from_null
[20:45] <jam> to figure out what to pass it
[20:45] <jam> generally you'll want to give it a hint about some other revision
[20:45] <Leonidas> jam: actually I am now writing a converter from hg to bzr and constucting changesets.
[20:48] <LaserJock> hmm, I must be doing something wrong, rebase isn't working
[20:49] <beuno> jam, so I would sort the graph, and then iterate over it, until scheduled_nodes[-1][1] < merge_depth ?
[20:49] <LaserJock> there's gotta be a simple way to do this. I just want to change my email address on a branch that only has 3 revisions
[20:50] <Leonidas> jam: isn't revno+1 a bit too easy? The revno is this number that bzr log outputs, right? But then the revno can look something like 34.1.3 etc.
[20:54] <abentley> Leonidas: A commit can never produce a dotted revno, by definition.  revno + 1 is exactly what commit does.
[20:56] <Leonidas> abentley: ok, fine. Then I can just take the last revno and add 1.
[20:57] <LaserJock> rebase just says there aren't any revisions to rebase :(
[20:57] <abentley> Leonidas: As long as the previous revision is the lefthand parent of the new revision.  (Otherwise, you're not simulating commit.)
[21:11] <LaserJock> ok, let's try this a different way. How do I go back to a previous revision?
[21:12] <LaserJock> do I have to branch each revision separately?
[21:15] <LarstiQ> LaserJock: that depends on what you mean with "go back to"
[21:15] <LaserJock> ok, I just want to go through these 3 revisions and make a new branch from them
[21:16] <LaserJock> so I was thinking if I can get back to revision 1, then copy that over and commit, then go to revision 2, copy and commit, then same for revision 3
[21:18] <LaserJock> but I don't exactly know how to go back in history
[21:22] <LarstiQ> LaserJock: that sounds like what rebase does, sort of
[21:23] <LarstiQ> LaserJock: unless you want to use those 3 actual revisions
[21:23] <LaserJock> well, I couldn't get rebase to work
[21:23] <LaserJock> it just said there was nothing to rebase
[21:33] <LaserJock> perhaps it's because I'm trying to rebase a whole branch
[21:33] <LaserJock> man, this is really frustrating
[21:34] <james_w> LaserJock: how are you running rebase?
[21:35] <LaserJock> well, I've tries several things
[21:35] <LaserJock> just plain bzr rebase
[21:35] <james_w> also, it will still leave the original email adress as author I believe
[21:35] <LaserJock> bah
[21:35] <LaserJock> I also tried --onto and -r to see what that'd do
[21:35] <james_w> I'd try "bzr-fast-export", edit the output, then "bzr fast-import"
[21:35] <LaserJock> oh, good idea
[21:36] <james_w> for rebase I'd guess rebase on to an empty branch would be what you want
[21:36] <LaserJock> I couldn't
[21:36] <LaserJock> it said that there was no history
[21:36] <james_w> ah, ok
[21:37] <LaserJock> I know it's not exactly bzr-specific but I can't  believe how hard it is just to change the email address
[21:38] <james_w> well, it's designed to have immutable history
[21:39] <LaserJock> right, which I suppose works, except when you want to change history
[21:39] <LaserJock> :-)
[21:48] <LaserJock> james_w: well, I ended just doing bzr export into 3 directories then cp the files in an commit
[22:25] <Arjen> I can't get the bzr search plugin to accept multi-word multi-word strings to search for
[22:29] <tacone> how space efficent bzr is for binary files ?
[22:30] <tacone> let's say pictures (which normally doesn't get modified, just added or removed)
[23:51] <GPHemsley> jam: Version number for 1.7.1 still says 1.7.1-rc1 (or something else with "rc" in it; I didn't look closely) in some parts of the Mac installer/upgrader


[07:17] <c2tarun> need help with bug 777973 I couldn't understand the last comment, Can anyone please explain?
[07:17] <ubot4> Launchpad bug 777973 in asciijump (Ubuntu) "Merge asciijump 1.0.2~beta-4 (universe) from Debian unstable (main) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/777973
[11:14] <hramrach_> Hello
[11:14] <hramrach_> How od I report bugs with Ubuntu mirrors?
[11:16] <hramrach_> The page at https://help.ubuntu.com/community/ReportingBugs which you get by trying to report an Ubuntu bug advises to run apport or whatever but you dan't need that for Ubuntu mirror bug and there is no way to actually report a bug
[11:16] <yofel> I'm not sure either, someone in #ubuntu-mirrors shoudl know
[11:17] <yofel> *should know
[11:31] <jfi> Hello, is it allowed for an upstream author to directly flag a bug as 'confirmed' in order to speedup the resolution?
[11:32] <jfi> it concerns this packaging "bug": bug #778415
[11:32] <ubot4> Launchpad bug 778415 in psensor (Ubuntu) "Missing Nvidia and Application Indicator support (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/778415
[11:36] <micahg> jfi: you just need to make sure there's a valid e-maill address in the changelog and subscribe ubuntu-sponsors, you can set it to confirmed at that point yourself to show it's ready for sponsorship
[11:37] <micahg> jfi: also, get rid of the extra newline at the end of debian/control
[11:38] <jfi> micahg, argh yes, the new changelog is wrong, I am going to fix it
[11:38] <jfi> micahg, thx for the information
[11:44] <jfi> micahg, fixed: https://launchpadlibrarian.net/71191903/778415.debdiff
[11:46] <micahg> jfi: you might want to say why you're adding that in the changelog
[11:47] <micahg> jfi: and this should probably move to #ubuntu-devel :)
[11:49] <jfi> jfi: ok, I will explanation in changelog. Sorry to be out of topic on this channel.
[13:48] <jtaylor> is pull-lp-source in natty broken?
[13:48] <jtaylor> e.g. pull-lp-source meld
[13:48] <jtaylor> some json decode error
[13:49] <micahg> jtaylor: wfm
[13:49] <jtaylor> ?
[13:49] <jtaylor> micahg: I'm not familiar with that abreviation
[13:50] <yofel> works for me too
[13:50] <jtaylor> ah
[13:50] <jtaylor> must be something local then
[13:51] <jtaylor> weird it works in oneirc which has the same version
[13:58] <jtaylor> hm the lpcache is somehow tainted, anyone know how to reset it?
[14:07] <jtaylor> found it: rm -rf $HOME.launchpadlib/
[14:09] <xieyi> I find a problem of rekonq 0.7.0 with kubuntu 11.04. When I download a file, a dialog ask for location to save the file. If I change the location the whole browser freazes. I think it may be a bug.
[14:11] <xieyi> rekonq alway prompt a dialog saying rekonq requires an additional plugin to decode this file The following plugin is required:text/html when I use the google translator
[15:28] <pcanham> Hi, could anyone help point me in the direction of any documents on how to debug shutdown issues, seeing on a Sony Vaio that you cant reboot or shutdown, screen shows just the background and this is it
[15:28] <pcanham> dmesg,message,syslog,kern.log showing no useful information either
[15:33] <micahg> pcanham: https://wiki.ubuntu.com/Kernel/Debugging/Symptom
[15:35] <pcanham> thanks micahg will go though this and hopefully get some info together
[18:42] <tetsuo55> Is anyone working on the wifi regression(s) in 11.04?
[18:42] <tetsuo55> seems to span over several brands of wifi cards, so it appears to be the network manager or something
[18:43] <tetsuo55> symtoms are: Signal generally weaker than with 10.10/windows and once it drops below a certain level, it will start dropping so many packadges that at some point it completely loses the connection
[18:43] <tetsuo55> in these same locations 10.10/windows will stay connected at good speeds for days
[18:44] <tetsuo55> my wireshark logs on 11.04 look more black than green
[18:44] <tetsuo55> :(
[18:48] <hggdh> tetsuo55: please open a bug on it -- do not assume that this is generic; may be related to a specific wireless card/brand/firmware level
[18:49] <hggdh> tetsuo55: for example, my wireless works perfectly
[18:49] <EvilUrsinha> tetsuo55, and mine doesn't because of an specific driver change I know it's a regression for that hardware (there's an open bug for that)
[18:53] <hggdh> EvilUrsinha: Evil?
[18:53] <EvilUrsinha> hggdh, just for today :)
[18:53] <hggdh> heh
[19:22] <JoshuaL> Is bug #778653 an unity bug or should it be marked as affecting Ayatana Design?
[19:22] <ubot4> Launchpad bug 778653 in unity (Ubuntu) "Fullscreen firefox and xchat conflicts (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/778653
[19:26] <tetsuo55> Ursinha-lunch: what hardware do you have?
[19:26] <tetsuo55> hggdh: do you have a strong or weak signal? the bug only plays out when the signal is weak
[19:27] <tetsuo55> hggdh:  my wireless works fine too, if i stay in my office, but as soon as i walk to the other room, it starts acting up
[19:28] <tetsuo55> also what is the best way to open a bug so my hardware gets added to it?
[19:29] <yofel> file it with 'ubuntu-bug linux'
[19:29] <tetsuo55> there are so many open bugs for the 11.04 wifi regression that i'm not sure which one is like mine
[19:29] <tetsuo55> but that wont add hardware specs will it?
[19:29] <yofel> no one is, the kernel team wants seperate reports for everyone
[19:29] <tetsuo55> don't i need to use apport for it
[19:29] <yofel> ubuntu-bug *is* apport
[19:30] <tetsuo55> oh
[19:30] <tetsuo55> ok so i run that from terminal
[19:30] <yofel> well, you can use apport-bug too, ubuntu-bug is an alias for that
[19:30] <tetsuo55> running
[19:34] <tetsuo55> might as well keep going
[19:34] <tetsuo55> how should i report that " when switching from just the laptop screen, to just the external monitor, the extra resolution will be black, and alghough the mouse will go over it, the windows hide under it
[19:35] <tetsuo55> ok reported wifi regression here https://bugs.launchpad.net/ubuntu/+source/linux/+bug/778671
[19:35] <ubot4> Launchpad bug 778671 in linux (Ubuntu) "Connection times out when WIFI signal is weak, regression from 10.10 to 11.04 (affects: 1) (heat: 6)" [Undecided,New]
[19:38] <tetsuo55> i also have a crash bugs with unity that dont trigger apport
[19:40] <yofel> do you have apport actually enabled?
[19:45] <tetsuo55> yes
[19:45] <tetsuo55> i changed the line from 0 to 1
[19:51] <tetsuo55> and it catches other crashes like flash player
[19:52] <tetsuo55> doublechecked, its set to 1
[19:53] <JoshuaL> Is bug #778653 an unity bug or should it be marked as affecting Ayatana Design?
[19:53] <ubot4> Launchpad bug 778653 in unity (Ubuntu) "Fullscreen firefox and xchat conflicts (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/778653
[19:57] <JoshuaL> tetsuo55, yofel that bugs looks like a duplicate of bug 776834 or am i mistakena?
[19:57] <ubot4> Launchpad bug 776834 in linux (Ubuntu) "Natty drops wifi if signal not four bars (affects: 2) (heat: 3264)" [Undecided,New] https://launchpad.net/bugs/776834
[19:57] <yofel> *that* is for the kernel team to decide
[19:57] <JoshuaL> ok
[19:58] <yofel> they don't like you adding infors to a bug unless you have the *exact* same hardware, firmware revision on the chips, bios rev, etc.
[19:58] <yofel> s/infors/infos/
[19:58] <JoshuaL> yofel, ok thanks :)
[20:20] <EvilUrsinha> tetsuo55, I have an eeepc with something that I have to check now :)
[20:22] <EvilUrsinha> tetsuo55, it's rt2860pci
[20:33] <ikt> where would be best to file a feature request for ubuntu to include the ability to downgrade an install?
[20:34] <hggdh> ikt: downgrade in what sense -- version, or package?
[20:34] <ikt> complete version
[20:34] <ikt> for example from 11.04 to 10.10
[20:35] <ikt> I mean an ideal state would be in a VM with snapshotting
[20:35] <ikt> but by itself it sounds fairly impossible
[20:36] <ikt> it would require backing up the entire computer maybe to a single tar? and then if you went back unrolling it out
[20:36] <hggdh> indeed... I am not sure this is generically possible. You cannot really tar up the whole install and then untar it -- it would conflict with the currently-running system, and all bets are then off
[20:37] <tetsuo55> EvilUrsinha: ok different from mine
[20:37] <hggdh> this is doable with an overlay filesystem
[20:38] <ikt> https://bugs.launchpad.net/ubuntu/+bug/775317
[20:38] <ubot4> Launchpad bug 775317 in ubuntu "Cannot down grade away from natty (affects: 1) (heat: 8)" [Undecided,New]
[20:38] <ikt> I can't think where to put :s
[20:38] <hggdh> ikt: perhaps http://brainstorm.ubuntu.com/
[20:39] <ikt> ah yes, good idea
[20:43] <yofel> well, this *is* already planned
[20:43] <yofel> not before btrfs becomes stable though
[20:45] <hggdh> I did not know it was already planned
[20:45] <hggdh> good to know, though :-)
[20:45] <yofel> well, not sure about full upgrade backups, but I know people talked about this during natty
[20:45] <yofel> natty's ubiquity already makes a root and home subvolume if you install on btrfs which you need for upgrade snapthots
[20:46] <arand> yofel: Is it planned as in has a blueprint, or as in "hey, that'd be cool if someone does it.."
[20:47] <yofel> arand: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-foundations-n-btrfs-support there are items for apt snapshotting
[20:47] <arand> yofel: Actually, maverick's layout would work as well for snapshotting, though the ability to roll back / without doing the same with your home has its perks ;)
[20:48] <yofel> well, true, that's why we have a seperate root subvolume now
[20:48] <yofel> ikt: ^
[20:50] <ikt> nice :D
[22:23] <caudex> System - Prefs - Keyboard won't reset to defaults Apply-System-Wide (meerkat on tpad t-42) any ideas?
[23:29] <txomon> hello, I just discovered a kernel bug, that was a minor problem before, how was the command for kernel bugs ubuntu-bug ...
[23:30] <yofel> ubuntu-bug linux
[23:30] <txomon> oki
[23:33] <txomon> yofel, how can I mark it as a previously fixed bug?
[23:34] <yofel> txomon: use a regression tag https://wiki.ubuntu.com/Bugs/Tags#Regression%20specific
[23:35] <txomon> and which one should I use for kernel one?
[23:35] <txomon> regression-update?
[23:36] <yofel> when was the last time it worked?
[23:37] <yofel> regression-release would be: worked in maverick, broke in natty. -updates is worked in natty and an update broke it, -proposed is for testing packages from <release>-proposed
[23:38] <txomon> oki
[23:38] <txomon> ty


[01:32] <thomi> RAOF: I'm having problems building glmark2 in a chroot - it complains about not being able to find the 'gl' package - that should be provided by libgl1-mesa, right?
[01:33] <RAOF> thomi: Which mesa are you using? There was a version of mesa in the PPA which was broken. You need libgl1-mesa-dev installed.
[01:34] <RAOF> thomi: (It's been brought to my attention that not everyone knows about apt-file - if this describes you, then ‘apt-file search gl.pc’ will tell you what package contains gl.pc)
[01:34] <thomi> RAOF: that's what it's installing...
[01:35] <thomi> RAOF: I wonder if you could scan over this? http://pastebin.ubuntu.com/5669187/
[01:37] <thomi> I'll try and get that waf log
[01:37] <RAOF> You might need the newer mesa - I take it the PPA hasn't yet managed to build the mesa branch?
[01:38] <thomi> no, I think Martin sent you an email about that?
[01:40] <thomi> RAOF: I tell a lie - I built and pushed it manually last week
[01:40] <thomi> so there's a a mesa package in the PPA from 28/03
[01:52] <RAOF> thomi: Oh, right. It just doesn't have the version I expected
[01:52] <RAOF> Hm
[01:52] <thomi> RAOF: it's using the version I built last Friday
[01:53] <RAOF> Yeah. I just expected that to be called +mir3
[02:01] <thomi> RAOF: so it turns out that gl.pc exists in the chroot
[02:02] <RAOF> thomi: Are you able to get /tmp/buildd/glmark2-2012.08+266+13/build/config.log ?
[02:02] <thomi> RAOF: yeah, just figured out what the issues is:
[02:02] <thomi> it needs the xcb-dri2 package
[02:02] <thomi> which isn't a build-dep
[02:02] <thomi> :-/
[02:02] <RAOF> Hm. That would be a bug in libgl1-mesa-dev, then.
[02:03] <RAOF> A development package should always depend on all the other development packages required to use it.
[02:04] <thomi> want me to file a bug?
[02:26] <RAOF> thomi: Yeah, thanks. It's probably only a problem in the Mir mesa package so far, though.
[02:29] <RAOF> Bah! GCC's libstdc++ doesn't implement list.erase(const_iterator it) as specified by C++11.
[02:49] <duflu> RAOF: It does implement that erase. I have used it for years. You mean the version that returns an iterator? That one is uncommon
[02:50] <RAOF> duflu: Hm. My g++ failed to find it, and http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 suggests that it's not implemented.
[02:50] <RAOF> duflu: Perhaps you're thinking of list.erase(iterator it)?
[02:53] <duflu> RAOF: Maybe
[02:54] <duflu> Though it would make sense to use a non-const iterator, kinda
[02:54] <RAOF> Yeah, kinda. C++11 standard says it takes a const_iterator, though.
[02:55] <RAOF> (As does list.insert(const_iterator it))
[02:55] <RAOF> Which also makes sense, as they don't modify any list elements.
[02:56]  * RAOF wonders whether the valgrind tests _really_ need to take 7 minutes
[03:02] <robert_ancell> racarr, hey, got an input question. How do I intercept alt+ctrl+Fn in the current server? Is that possible?
[03:05] <RAOF> I'm unsure...
[03:06] <RAOF> duflu: When you throw() in the edge-types merge proposal, is that caught somewhere sane?
[03:07] <duflu> RAOF: Yeah it's caught well below that. In an existing location at above the frontend. I forget where. The tests cover it
[03:08] <RAOF> Cool. That merge looks reasonable to me, then.
[03:09] <duflu> RAOF: It's usually a good indicator of efficiency, how well your code runs under valgrind. Valgrind is a good analog of a "slow machine" which we should be able to support. So yeah, 7 minutes is way too much
[03:11] <duflu> Valgrind, particularly, shows you where your code is CPU-bound.
[03:12] <smspillaz> RAOF: duflu the only reason why those valgrind tests would take 7 minutes is because you have to set up and tear down valgrind all the time
[03:13] <smspillaz> code under valgrind is supposed to run about 5x slower in the best case
[03:14] <RAOF> Doesn't valgrind interact poorly with highly threaded code, too?
[03:18] <smspillaz> *shrug* maybe
[03:18] <smspillaz> but I know that tests taking forever under valgrind is likely to be a direct product of the valgrind startup cost
[03:18] <smspillaz> considering the fact that your unit tests probably run in half a second and your integration tests maybe run in 20 seconds tops
[03:19] <smspillaz> add n * valgrind startup and it gets expensive fast
[03:20] <duflu> 5x slower would be fine. But the several orders of magnitude we see, not so fine
[03:21] <smspillaz> I've been thinking recently the maybe the best way to do the tests is to create static libraries linked to libgtest with all of your tests and then link them together into a single binary for each main () that you wish to provide (eg gtest_main, xorg_gtest_main etc)
[03:21] <smspillaz> if you want to valgrind / callgrind / whatever your tests, it means that you only need to run valgrind once per binary as opposed to once per test
[03:22]  * smspillaz has been working on a little thing that would effectively do just that
[03:23] <duflu> Ooh, sorry. Yes. Valgrind startup is an artificially slow bottleneck. We should ideally not be starting new processes all the time
[03:23] <smspillaz> yeah
[03:24] <smspillaz> its my one gripe with ctest's ExperimentalMemCheck target
[03:24] <robert_ancell> RAOF, you should probably approve your use-dma-buf MP - it's marked as needs fixing by you
[03:24] <RAOF> robert_ancell: No-one else has reviewed it.
[03:24] <RAOF> Oh, ahem.
[03:26] <duflu> smspillaz: I still intend on resolving that Compiz branch madness when didrocks says I can
[03:26] <duflu> Last I checked, the diff was small
[03:26] <smspillaz> duflu: didn't didrocks say you could ?
[03:26] <duflu> smspillaz: He said wait a little
[03:26] <smspillaz> I'm pretty sure you got the "go for it" like a month ago now :p
[03:26] <duflu> He was "busy"
[03:27] <RAOF> robert_ancell: And to answer your question, no, I don't think you can get alt+ctrl+Fn in the X server.
[03:27] <duflu> It's ridiculous because the diff was only 160 lines when I last checked
[03:27] <smspillaz> duflu: why would there be a diff for changing a branch name ?
[03:27] <RAOF> robert_ancell: Except it just occurs to me that this is not what you were actually asking :)
[03:27] <robert_ancell> RAOF, in X? I mean intercept it inside /usr/bin/mir
[03:28] <duflu> smspillaz: You need to merge the "raring" and "0.9.9" branches first. They differ
[03:28] <smspillaz> oh right. I believe that was intentional
[03:28] <robert_ancell> RAOF, I was trying to work out why I wasn't getting the VT signal on my VT branch, then I realized that of course nothing would be grabbing the key combination
[03:28] <smspillaz> the diff is much larger now
[03:28] <duflu> Awesome-bloody-tastic
[03:28]  * duflu -> coffee
[03:28] <smspillaz> duflu: the "raring" branch was basically the great-distro-strategy to cut off myself and mc-return so they could cherry pick everything
[03:29] <smspillaz> because you know
[03:29] <smspillaz> cherry picking always results in more stable code
[03:29] <robert_ancell> duflu, can you see if https://code.launchpad.net/~robert-ancell/mir/frontend-class-renaming/+merge/156430 seems like an improvement to you?
[03:29] <smspillaz> I don't understand it when people think they know better than the maintainers ...
[03:30] <RAOF> Because the common case is that we _do_ know better than the maintainers :)
[03:30] <bschaefer> smspillaz, welll we are suppose to fix that raring branch, as it was a mistake from what I understand...
[03:30] <RAOF> (Because we often have significantly different goals to the maintainers)
[03:30] <smspillaz> RAOF: sure, you have different goals
[03:31] <smspillaz> my point is that cherry-picking tends to do more harm than good, especially the kind of cherry picking focused on "lets get the fix without the refactoring"
[03:31] <smspillaz> unless you have a very detailed knowledge of that codebase to understand why that might be a good idea
[03:32] <duflu> bschaefer, smspillaz: Yeah no need for anyone to get angry or worry about it. We have consensus that it should and will be resolved
[03:32] <smspillaz> I'm not angry at all :)
[03:33] <bschaefer> duflu, yeah, its on the heap, but someone has to do it, and Ill be poking around to see what needs to be done soon ...
[03:33] <duflu> bschaefer: I'll do it as soon as didrocks says I can. In fact, I might do the parts that don't interfere with anyone's work soon
[03:34] <bschaefer> duflu, well its always nice to learn :), I just got caught up with that 100 scopes thing last week and didn't get around to it
[03:34]  * bschaefer thinks its green lighted atm
[03:35] <duflu> smspillaz: Also, it's not about who knows best or being picked on. It's a matter of we should have branched earlier to give distro stabilization time and you somewhere to land new stuff without worrying distro
[03:35] <duflu> bschaefer: It was agreed by everyone but didrocks explicitly asked me to wait
[03:35] <smspillaz> duflu: I wasn't interested in landing anything new that wasn't going to affect distro
[03:36] <smspillaz> why would I work on a dead end?
[03:36] <bschaefer> duflu, oo, didn't know that, I can poke him tomorrow morning as well about it :)
[03:36] <bschaefer> smspillaz, to learn!
[03:36] <smspillaz> I have other projects where I can do that
[03:36] <duflu> smspillaz: That dead end is the only complete and functional desktop we have for now. It's no dead end (yet)
[03:36] <bschaefer> smspillaz, very much so :)
[03:37] <smspillaz> *shrug* if distro wanted to branch early ... they really could have just asked
[03:37] <smspillaz> that being said, they've already done it
[03:37] <duflu> Yeah, just /wrong/
[03:37] <duflu> Never mind. I'll fix it
[03:38] <smspillaz> and needless to say, upstreams should be following the freeze process anyways
[03:38] <smspillaz> so there shouldn't even be a need for a branch
[03:39] <duflu> robert_ancell: Looks like some things I was thinking about. Will get to it
[03:39] <robert_ancell> duflu, ta
[04:24] <RAOF> Urgh. Git's UI is a fractal of horibleness.
[06:37] <RAOF> When can I stop caring about Quantal?
[06:40] <duflu> RAOF: When you absolutely have to...
[06:40] <duflu> RAOF: Or after I upgrade my desktop ;)
[07:29] <tvoss> alf_, ping
[07:39] <alf_> tvoss: pong
[07:39] <tvoss> alf_, did you see thomi's mail to mir-devel? Is the branch he is looking at the current one?
[07:42] <alf_> tvoss: hmm, I thought I pushed the right branch, trying to push again...
[07:42] <tvoss> alf_, ack
[08:15] <alan_g> tvoss: ping
[08:32] <tvoss> alan_g, pong
[09:54] <tvoss> alan_g, no invite arriving in my inbox
[09:56] <alan_g> tvoss: looking...
[09:56] <alan_g> tvoss: ... - it says you've been invited.  It is a library in development and will be used by a *future* version of unity.
[12:11] <arsson> no but i'm exited and anxious
[14:19] <racarr> Morning
[14:20] <alan_g> racarr: afternoon
[14:21] <racarr> alf_: Re: enable-inprocess-egl
[14:22] <racarr> did you apply the mesa patch mentioned in the comments for the branch
[14:22] <racarr> err
[14:22] <racarr> this patch is incorrect
[14:23] <alf_> racarr: I didn't apply it
[14:25] <racarr> alf_: Posted a new one
[14:25] <racarr> it's necessary otherwise the
[14:25] <racarr> DRM EGL backend conflicts with the mir one
[14:27] <alf_> racarr: thanks, I will try it out
[14:36] <racarr> alan_g: Left some comments on receive-input-in-client (+ updates)
[14:37] <alan_g> racarr: will look...
[14:56] <alf_> racarr: It doesn't seem mir_toolkit/mesa/native_display.h is installed by make install
[15:00] <dharmaone> missed the session :( this might have been answered already - will existing ubuntu apps work on new versions of ubuntu that use QT and mir - or will they have to be rewritten?
[15:02] <tvoss> dharmaone, depends on the toolkit support for Mir, but in general: you don't need to rewrite your app to run against Mir
[15:02] <tvoss> dharmaone, I think the session was recorded and you can watch it on youtube
[15:03] <kdub> morning folks, status, began working on our own framebuffer native window for android
[15:03] <dharmaone> ok :) what about current apps that are not written with QT - will they have to be rewritten? (not really mir related)
[15:04] <tvoss> dharmaone, again, toolkit dependent, but in general no :) the point is that an app hardly ever should know about the underlying display server
[15:05] <alf_> status: reviewing, bug fixing, thinking about main loop
[15:05] <tvoss> dharmaone, there might be some apps that are tightly coupled to X for one or the other reason. Those will be supported by an in-session, on-demand rootless X server that talks to Mir (much like in OS X)
[15:06] <tvoss> dharmaone, http://youtube.com/ubuntuonair
[15:07] <racarr> status: Made some updates to branches. Did some review
[15:07] <racarr> worked on new version of qtubuntu and ubuntu-platform-api-mirclient yesterday and produced some working code
[15:08] <racarr> going to go through and see if there is anything else I need to do right now and if not work on those some more
[15:08] <racarr> (goal: Qt backend against Mir with input:))
[15:12] <racarr> Anybody need some help or review or anything?
[15:19] <alan_g> racarr: quick hangout?
[15:21] <racarr> alan_g: Sure
[15:21] <racarr> gcalling you
[15:22] <racarr> alan_g: I can hear you just a sec
[15:45] <racarr> tvoss: Made some comments on QtUbuntu stuff and input/platform-api, etc here https://bugs.launchpad.net/mir/+bug/1163393
[15:45] <racarr> (we talked about this briefly in the past and you said you would think about it :))
[15:46] <racarr> talked about using this approach of abstraction through the platform api
[15:46] <tvoss> racarr, will look into it, thanks for the pointer
[15:52] <kdub> alf_, updated hwc-integration :)
[15:52] <kdub>  sorry to be a bother about it :P
[15:57] <alf_> kdub: no worries, unfortunately I found a couple of naming nitpicks (see comment), but I will pre-approve to unblock you since I don't have anything else
[15:58] <kdub> alf_, thanks, will take care of those
[16:25] <racarr> going to make android input stack compile in clang
[16:25] <racarr> many of the more confusing errors seem to be about the boost asio based looper which we are dropping anyway :)
[16:27] <racarr> /home/augustwest/src/mir/mir/fix-input-build-clang/cmake/src/mir/mir_discover_gtest_tests.cpp:(.text+0x12b3): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
[16:27] <racarr> infinite erros around this line now...
[16:27] <racarr> libandroidinput.so actually links :)
[16:29] <racarr> ok er building clang from trunk doesn't work either for me
[16:29] <racarr> -DCMAKE_CXX_COMPILER=/usr/bin/clang -DCMAKE_C_COMPILER=/usr/bin/clang -DMIR_DISABLE_INPUT=true
[16:29] <racarr> how should it work?
[16:29] <racarr> How can I see the options that the jenkins clang build uses?
[16:33] <racarr> MIR_DISABLE_INPUT=true does not seem to be the same as MIR_DISABLE_INPUT=ON but both will stop libandroidinput.so from building ;)
[16:35] <racarr> oh maybe that wasn't it. Looks like clang behaves differently invoked as clang++
[16:40] <mpt> tvoss, hi. The phone calls for "Accessibility controls for visually impaired". So for starters, I'm thinking of speccing an "Invert black and white" setting. Does that sound feasible for Mir on the phone?
[16:41] <racarr> alan_g: https://code.launchpad.net/~robertcarr/mir/fix-input-build-clang/+merge/156634
[16:41] <racarr> It turns out it was trivial :)
[16:41] <racarr> I mean unit-tests fails but it builds!
[16:41] <racarr> and I think unit-tests failed anyway
[16:42] <mpt> tvoss, i.e. composit (composite?) such that for every pixel, the value is reversed, while the hue and shade stay the same.
[16:42] <mpt> (Compose!)
[16:43] <tvoss> mpt, hey there :) I think it's better if you check with kgunn and robert_ancell on Mir specifics, but in general, I think it should be possible to apply a custom shader to the final composited image that inverts colors
[16:43] <mpt> ok
[16:43] <kdub> mpt, right. mir can do it, its more a matter of feature scheduling as to when
[16:43] <mpt> kgunn, what do you think? ^^^^
[16:44] <kdub> although mpt, contributions are welcome :)
[16:44] <mpt> kdub, the contribution I am instructed to make is to design the settings :-P
[16:45] <alan_g> racarr: do you understand the need for "mt::" in tests/integration-tests/input/android/test_android_input_manager.cpp? The rest looks obvious
[16:45] <kdub> mpt haha, just trying to remind the rest of the channel that we are open :)
[16:46] <mpt> kdub, fair enough. I've had good, though unpredictable, results from publishing UI designs for wishlist features.
[16:47] <kgunn> mpt: i'd say let's capture it in a bp...
[16:47] <kdub> mpt, yeah... i can see that they would be tricky to convey widely
[16:47] <mpt> hmm
[16:48] <kgunn> mpt: is this a "just capture it" query....or is there a pressing thought behind it
[16:49] <mpt> kgunn, the comically misnamed "Unity API" team has the job of implementing settings UI. So in designing that UI, I need to find out which settings are likely to actually exist. Bad to have UI for a setting without the setting, and (to a lesser extent) vice versa.
[16:49] <kgunn> mpt: :) sure
[16:51] <racarr> alan_g: Yes the namespace {}
[16:51] <mpt> kgunn, excuse the ignorant question, but is display brightness handled by the display server, or is that at a lower level?
[16:51] <racarr> makes it a seperate instantiation of the function for each
[16:51] <racarr> include
[16:51] <racarr> so the functions become "unused"
[16:51] <racarr> which is an error with our clang settings
[16:52] <racarr> well they become unused by people who include mock_event_filter but don't use the matcher
[16:52] <racarr> translation units blablablabla
[16:52] <racarr> :p
[16:52] <alan_g> racarr: Great
[16:52] <kgunn> mpt: great question actually....brightness for sure will have a low level element to it...but the question is, should mir abstract that sort of thing away
[16:53] <kgunn> tvoss: ^   my gut says...probably a server side shell interaction w mir?
[16:54] <tvoss> kgunn, I think it's partly a setting but there needs to be a post-process step for the compositor ... at least htat's my gut feeling
[16:55] <mpt> The only reason I ask is to know whether it should be in the same blueprint
[16:56] <racarr> alan_g: Fixed the whitespace here too https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 (r619 will take a sec to refresh)
[17:03] <alan_g> racarr: seems like a conflict now. But I'll change my vote anyway
[17:03] <kgunn> tvoss: post process for brightness?...hmmm, i suppose you could have both true hw (backlight) brightness & sw (backlight compensation)
[17:03] <kgunn> mpt: i'll capture both
[17:04] <racarr> alan_g: Thanks :) fixing conflict now
[17:04] <kdub> racarr, fix-input-build-clang reminded me that if we need to disable input, we could do that via a server config
[17:05] <kdub> still trying to get rid of compile options :)
[17:05] <racarr> kdub: That's the goal for fix-input-build-clang!
[17:05] <racarr> will propose a branch to disable MIR_DISABLE_INPUT later today
[17:06] <kdub> racarr, great :)
[17:08] <tvoss> kgunn, hmmm, I was more or less thinking about color inversion
[17:08] <racarr> alan_g|life: Have a good evening :)
[17:09] <kgunn> tvoss: just to make sure we're talking about the right things...mpt had 2 distinct questions...
[17:09] <kgunn> 1 about color saturation (like an effect)
[17:09] <kgunn> 1 about brightness
[17:10] <racarr> I think, from the perspective of what we can do, we can say that we can apply any sort of shader effect to any subset of the scene graph (including the final image)
[17:10] <racarr> but it doesn't necesssarily mean postprocessing
[17:10] <racarr> for example, color inversion, should likely be done in the first rendering pass, rather than say rendering to an FBO and postprocessing
[17:11] <racarr> oh just saw the original question now
[17:11] <kgunn> racarr: well....maybe, it might actually be cheaper to post process (depending on # of layers etc)
[17:11] <racarr> is it feasible for mir on the phone
[17:11] <racarr> Sure!
[17:11] <racarr> kgunn: No. You always have to render each visible thing once
[17:12] <racarr> so the question is, do I render it once directly onscreen with a shader to invert the colors
[17:12] <kgunn> racarr: dirty region tracking?
[17:12] <kgunn> racarr: i was thinking setting changed...you got lots of surfaces
[17:12] <racarr> or render it offscreen, then take the final composited image and render it with a shader to invert the colors
[17:12] <kgunn> racarr: but those surfaces might be visually static
[17:13] <racarr> oh maybe, that's true when the setting
[17:13] <racarr> changes
[17:13] <racarr> we don't want to be rendering offscreen for postprocessing in anticipation of settings changing though
[17:14] <kgunn> racarr: no not at all
[17:14] <racarr> if we already are rendering offscreen though! the effect probably should be postprocessing
[17:14] <kgunn> racarr: keep it all dynamic....but build it in such a way you could "postproc" conceptually
[17:14] <racarr> Mm
[17:15] <kgunn> racarr: and...i consider semico hw goodies as postproc conceptually
[17:15] <kgunn> e.g. they might give you a slick way to do this to the fb
[17:15] <kgunn> for cheao
[17:15] <kgunn> oops/cheao/cheap
[17:15] <racarr> mm
[17:15] <racarr> some are.
[17:16] <racarr> I think of the line where postprocessing begins as when the fragment shader emits a fragment
[17:16] <racarr> but who knows why :) thats just something I made up
[17:16] <racarr> XD
[17:16] <kdub> kgunn, i think there are, but they'd have to move to support it in hwc if they want it
[17:16] <kgunn> kdub: yep
[17:17] <kgunn> kdub: racarr ....for sure, either gles or hwc would be the postproc houses....and no we shouldn't build ineffeciency in just in case of a potential savings, but we shouldn't prevent using something cool either, e.g. keep it dynamic (not just flexible)
[17:17] <racarr> I understand :)
[17:18] <racarr> mpt: It's interesting to think about what to support perhaps besides
[17:18] <racarr> inversion...I know it's not unheard of for windows/osx users (and some people through a compiz plugin)
[17:18] <racarr> to use a few other kind of color filters for various forms of color blindness
[17:19] <racarr> or i.e. I remember someone in the compiz forums ages ago worked in astronomy of some such and requested a red light only filter (to not affect his night vision as strongly)
[17:19] <racarr> ...apparently I am in full on attention-deficit-mode this morning. *runs around*
[17:25] <kgunn> mpt: racarr this was a good topic....made me think about backlight compensation....a very big deal in mobile
[17:27]  * kdub thinks we could root ID out of mc::BufferSwapper
[17:28] <kdub> with the post processing effects, i think its safer to rely on gles for them primarily, and then build it dynamic enough that we can use either gles or a special route
[17:28] <kdub> with alpha being the quintessential effect with 'special routes'
[17:29] <kgunn> kdub...ack...gles is the fundamental functional baseline, makes sense
[17:30] <tvoss> kgunn, ah, for brightness, it's a system/shell setting
[17:31] <racarr> kdub: I feel like I flipped back and forth maybe on whether rooting ID out sounded like a good idea
[17:31] <racarr> but it sounds good today!
[17:32] <kdub> racarr, we did, i remember the situation pointedly :) the last thing that I remember was that the interface was something to fix later
[17:33] <kdub> and my android server window work is making me rethink the interface a bit
[17:33] <kdub> i'll mp separately so it can get a thorough review though, once thats done
[17:33] <racarr> ok
[17:33] <racarr> kdub: Is resizing still in your head?
[17:34] <kdub> it is! i was just going to suggest a blueprint related to it to kgunn actually
[17:39] <kgunn> kdub: like a new one....or just add to an existing...i was going to put a couple of bullets in mir-converged
[17:43] <kdub> kgunn, i prefer new blueprints with 2-4 day long task segments... makes me feel like i'm reporting enough :) resizing will be a multiple-landings-required sort of task
[17:48] <racarr> kdub: Oh great :)
[17:53] <kgunn> kdub: what a good title? supposing its more than just resizing?....i need to check the other bp's as we might have had this already
[17:54] <racarr> early morning -> early lunch bbs
[19:08] <thomi> morning
[19:12] <UbuPhillup__> thomi: hi
[19:12] <racarr|lunch> Morning thomi
[19:15] <thomi> hey everyone, what's up?
[19:26] <racarr> Man I love lunch
[19:29] <kgunn> kdub: sorry if you answered...my network has been blinking today
[19:30] <kgunn> kdub: but what would be a good title for the resize work?
[19:30] <kgunn> meaning, does it cover rescale? surface moves etc ?
[19:30] <kdub> kgunn, hmm.. maybe something like
[19:33] <kdub> "fixed client buffer resize" where fixed is added to emphasize that we resize buffers to a known size
[19:33] <kdub> and provide feedback much like we do now with the box outline of the size the client will be resized to
[19:35] <kgunn> kdub: so is it more like resize to a phys dev/screen? rather than an app-window resize ?
[19:35] <kdub> kgunn, no, we're talking client resize
[19:37] <kgunn> kdub: got it, sorry, to keep digging...what about rotate? & moves? or are those seperate topics
[19:38] <kdub> kgunn, its something a bit down the road
[19:38] <kdub> but i consider those separate topics
[19:38] <kdub> my fbnativewindow work led me to want to refactor a funky interface we have
[19:39] <kdub> and i'm refactoring in a way that is friendly to the future of mir resizing client buffers
[19:39] <thomi> woooo! got glmark2 running on mir :)
[19:42] <thomi> hmmm, either my brain is broken, or some of these tests aren't too happy on mir
[19:43] <kgunn> thomi: what are you running them on ? hw wise?
[19:44] <thomi> it's the QA testing laptop, which has 4GB ram, and an intel graphics chipset... when glmark2 finishes I can get the exact specs
[19:45] <thomi> it's an "Intel Ivybridge mobile" - whatever that means
[19:46] <kdub> racarr, quick review when you have a chance? https://code.launchpad.net/~kdub/mir/fix-hwc-test/+merge/156669
[19:47]  * thomi needs more coffee, brb
[19:54] <racarr> kdub: Will soon :) Just finishing up some refactoring on inprocess-egl
[20:05] <racarr> kdub: +1
[20:08] <kdub> racarr, thx
[20:09] <kgunn> robert_ancell: morning
[20:10] <robert_ancell> kgunn, hello
[20:10] <kgunn> robert_ancell: we had a couple of interesting topics...
[20:11] <kgunn> mpt pointed out a feature to have settings (as in system) to put your composed fb in a "color mode"
[20:11] <kgunn> think saturation or sepia or some such
[20:11] <kgunn> then we started talking brightness....which lead to a discussion on hw vs sw, and fb post processing
[20:11] <kgunn> at any rate...i added about 4 work items to mir-converged
[20:12] <kgunn> altho conceivably we'll need brightness control on phones
[20:12] <robert_ancell> kgunn, ok cool. What's the use case for the "colour mode"?
[20:13] <kgunn> robert_ancell: visually impaired
[20:13] <kgunn> so like black / white invert
[20:14] <kgunn> or no blue/grey combos
[20:14] <kgunn> red/green
[20:14] <robert_ancell> kgunn, ah. Traditionally that's been done via themes - is a global method considered better?
[20:14] <kgunn> color blindness
[20:14] <kgunn> global - i guess so, that way nothing gets thru
[20:14] <racarr> kdub: I can't crosscompile anymore because the chroot creator can't find a package for libhybris
[20:14] <racarr> where am I supposed to be getting it from?
[20:14] <kgunn> you have a more uniform experience
[20:15] <robert_ancell> yeah, sounds like the easiest method.
[20:15] <kdub> racarr, the phablet-ppa . i sent out the line in the email about the hybris update
[20:15] <kgunn> then kdub & i have been talking about addressing client resize....
[20:16] <kgunn> i thot we already had that in a bp (was just looking now)
[20:16] <kgunn> if not, he was wanting to tackle...anativewindow stuff allowed him to potentially refactor for resize in mind
[20:16] <kgunn> (but i wondered if duflu might have had it on his plate?)
[20:16] <racarr> kdub: Got it :)
[20:16] <robert_ancell> kgunn, should be in mir-converged I think. I think we decided it wasn't needed on a phone
[20:18] <kdub> i guess mir-converged is what i meant by 'down the road' earlier
[20:18] <kgunn> kdub: and yes, it is in there
[20:19] <kgunn> kdub: robert_ancell ...will we really not need it for phone ?
[20:19] <kgunn> i suppose any resize due to a ui animation/transition would be hidden from client
[20:19] <robert_ancell> kgunn, In San Mateo we couldn't come up with a case where it was required, but we should revisit that if we can think of one
[20:19] <kdub> i agree with robert_ancell that its probably not critical for phone for a while
[20:20] <robert_ancell> kgunn, kdub, I think it is a good target of opportunity to implement early if there's no higher priority work
[20:20] <kgunn> kdub: is there a convenience factor to it for you....e.g. you're mucking around it, may as well address it?
[20:20] <kgunn> robert_ancell: kdub is so awseome he completed the nexus4 bp :)
[20:21] <kdub> kgunn, not really, i'll just leave the door open for resize in what i'm doing now
[20:21] <robert_ancell> kdub, \o/
[20:22] <kdub> yay :) i'll try to make a video for our weekly email
[20:22] <kgunn> kdub: cool!
[20:23] <kdub> robert_ancell, kgunn, in mir-converged, can I assign 'window resizing' and 'mir on mir' to myself?
[20:23] <kgunn> kdub: if you're feeling froggy :)
[20:24] <robert_ancell> kdub, absolutely
[20:24] <kgunn> racarr: so i was thinking (danger)...
[20:25] <kgunn> if you get qt backend w. input working...could we sloppily put unity next on it?
[20:25] <kgunn> maybe a trimmed version
[20:31] <racarr> well thats the plan eventually but this is out of process Qt
[20:31] <racarr> in process Qt is working too but no
[20:31] <racarr> in process Qt with input yet (thats kind of nextish after all the existing stuff lands...i.e. thursday?)
[20:31] <racarr> Then there is the branch for running the unity stuff out of proces that kevin did
[20:31] <kdub> which is just client side qt
[20:31] <racarr> mm
[20:32] <racarr> using
[20:32] <racarr> Well using all the phablet input stuff
[20:32] <racarr> not the mir stuff
[21:15] <racarr> kdub: https://code.launchpad.net/~robertcarr/mir/remove-mir-disable-input/+merge/156696 exists :)
[21:15] <racarr> kdub: Want to talk about prepare-for-inprocess-egl soon?
[21:15] <racarr> hoping for RAOF to show up
[21:15] <racarr> RAOF: Ping?
[21:15] <racarr> err by prepare-for-inprocess-egl I mean
[21:16] <racarr> enable-inprocess-egl
[21:16] <racarr> flashbacks
[21:20] <racarr> kdub: Pushed changes to prepare-for-inprocess-egl to use Platform as you suggest
[21:28] <kdub> racarr, cool
[21:31] <racarr> kdub: Do you have an idea of how hard it will be to implement for android/a plan? Should I start thinking about it
[21:31] <racarr> branch as it stands returns (EGLNativeDisplayType)0 ;)
[21:31] <racarr> oh I guess
[21:32] <racarr> the native display is the same on android EGL_DEFAULT_DISPLAY
[21:32] <racarr> but a native window abstraction is needed.
[21:43] <kdub> racarr, that's sort of what i'm getting into place now with the framebuffer native type
[21:53] <racarr> ohhhh
[22:25] <kgunn> robert_ancell: btw...https://blueprints.launchpad.net/ubuntu/+spec/mir-beyond-converged
[22:25] <kgunn> for stuff that's fringe
[22:25] <robert_ancell> kgunn, awesome
[22:25] <robert_ancell> kgunn, check out that dependency tree :)
[22:26] <kgunn> borg like
[22:32] <RAOF> racarr: Pong!
[22:34] <racarr> brb being non violently mugged by the garage door repairmen
[22:41] <racarr> ok
[22:43] <racarr> RAOF: Two things I was pinging you abobut actually! need another round of review on receive-input-in-client
[22:44] <racarr> and enable-inprocess-egl should be almost ready to land so I wanted some feedback on the mesa changes
[22:44] <racarr> and perhaps to land them in sync
[22:45] <RAOF> racarr: What are the mesa changes needed to land enable-inprocess-egl?
[22:45] <RAOF> I thought we'd already landed them?
[22:46] <racarr> RAOF: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888/comments/342488
[22:46] <racarr> err that patch is slightly backwards due to git failure the - if (mir_connection_is_valid
[22:46] <racarr> is against the wrong branch
[22:47] <racarr> we had landed that as the client library function, mir_egl_native_display_is_valid but then
[22:47] <racarr> that needs an inserver implementation too and I wasn't sure about
[22:47] <racarr> implementing client library symbols in the server
[22:47] <racarr> so there is that
[22:47] <racarr> then the second two bits are about letting mesa load multiple instances of the dri2 driver
[22:47] <racarr> for multiple platforms
[22:47] <racarr> shockingly it seems to work
[22:49] <RAOF> We've already landed that change, haven't we?
[22:49] <racarr> I don't think so
[22:49] <racarr> unless
[22:49] <racarr> nope doesn't look like it
[22:51] <RAOF> Ah, right. We've got *some* of that landed.
[22:59] <racarr> I blogged a blog about what I have been doing lately in mir: http://racarr.me/wordpress/?p=17
[22:59] <racarr> probably uninteresting to mir team members :p


[23:48] <chacha> where can i buy and sell???
[23:48] <LjL> chacha: .....?
[23:48] <ron2> this is sort of a weird question, but is there a command that tells what shell is currently running?
[23:48] <chacha> where can i buy and sell???
[23:48] <xplo> ActionParsnip, because i am a kinda good mirc coder, and i just jumped on ubuntu, i need to learn xchat pearl coding
[23:48] <ionicz> where do i get compiz?
[23:48] <chacha> yah
[23:48] <ActionParsnip> xplo: bitchx allows scripting
[23:48] <KrispyKreme_> sudo apt-get install compiz
[23:48] <LjL> ionicz: it's installed by default.
[23:49] <ron2> xplo, mirc is scripting.
[23:49] <mrwes> b00m!
[23:49] <test_> How much software does wine support?
[23:49] <ionicz> ohh
[23:49] <LjL> !compiz | ionicz
[23:49] <Myrtti> ActionParsnip: bitchx isn't supported anymore
[23:49] <ActionParsnip> test_: theres a db of wine compatible apps at winehq
[23:49] <mrwes> why not run ircii :)
[23:49] <Myrtti> ActionParsnip: not in ubuntu atleast
[23:49] <ActionParsnip> Myrtti: wow, i feel old now
[23:49] <ron2> ircii is awesome
[23:49] <ron2> i started out on that
[23:49] <]{53> iocicz - go to System -> Preferences  -> Appearance. Then go to the Visual Effects tab.
[23:49] <Myrtti> I've used irssi since 2002
[23:49] <test_> thanks, how is the performance in 3D?
[23:49] <ron2> i'd use irssi if i knew a bit of perl
[23:50] <rockyrock> i have problem but i don't know what causes the problem! My problem is that sometimes when i open a website, firefox gets so slow and something looks eating my processor! I dunno if that problem from my Graphics card. What do suggest guys?
[23:50] <]{53> test_: good if you have a 3D card, but bad in a VM.
[23:50] <mrwes> ircii and lynx :) both rox
[23:50] <mrwes> heh
[23:50] <chacha> ljl
[23:50] <chacha> ljl
[23:50] <chacha> where can i buy and sell???
[23:50] <FloodBot3> chacha: Please don't flood, use http://paste.ubuntu.com to paste, don't use Enter as punctuation.
[23:50] <node357> my 8.10 install has been stuck on "scanning the mirror" for about 30 minutes :(
[23:50] <ron2> nobody knows if there's a command that tells what the current shell running is?
[23:50] <Myrtti> chacha: buy and sell *WHAT*
[23:50] <test_> I know, I try enabling the 'special effects', but it never works..
[23:50] <]{53> chacha - you are going to have to explain further......
[23:50] <mrwes> kb00m!
[23:51] <]{53> test_: This might not work in a VM.
[23:51] <node357> ron2, try ps
[23:51] <mrwes> kb that ass will ya
[23:51] <ron2> what??? ps? you've gotta be kidding me
[23:51] <toastedmilk> what's the default gconf-editor value for an ipod mount?
[23:51] <LjL> ron2: in bash, "echo $SHELL" works, not sure if it's very universal though
[23:51] <LjL> mrwes: that's completely unwarranted.
[23:51] <test_> Yes, even with guest additions installed.
[23:51] <ron2> yeah env. vars aren't always gauranteed standard
[23:51] <ron2> I need something fairly standard
[23:51] <test_> maybe if I give it more RAM/GRAM
[23:51] <toastedmilk> what's the default gconf-editor value for an ipod mount?
[23:52] <ron2> ok, neither is any other linux program i suppose.
[23:52] <LoveGuru> Hi, There is one Conf file I just want to Get All uncomment lines from that file? can i?
[23:52] <]{53> test_: you need a 3d card to run compiz. the vm cards are not 3d.
[23:52] <ron2> yeah vmware like emulates graphics, you dont get hardware acceleration as far as i can tell
[23:52] <p1mps> any1 got to work aircrack & bcm4312 chipset?
[23:52] <imachine> LjL, magic
[23:52] <ron2> dunno about other vms
[23:52] <test_> So what's the best distro to learn unix?
[23:52] <imachine> LjL, I feel like I'm on windows :-P
[23:52] <p1mps> ubuntu :P
[23:53] <snuitje> freebsd :P
[23:53] <LoveGuru> test_: Ubuntu
[23:53] <]{53> test_: Ubuntu of course.
[23:53] <toastedmilk> what's the default gconf-editor value for an ipod mount?
[23:53] <ron2> yeah, i'd say ubuntu
[23:53] <LoveGuru> guD start/practice
[23:53] <node357> my 8.10 install has been stuck on "scanning the mirror" for about 30 minutes :(
[23:53] <toastedmilk> test_, ubuntu's pretty solid for learning unix
[23:53] <imachine> LjL, I went Programs/Accessories/Passwords and encryption keys
[23:53] <snuitje> mac os x is a certified unix
[23:53] <toastedmilk> what's the default gconf-editor value for an ipod mount?
[23:53] <Brandano> test_: try asking in #gentoo ... :)
[23:53] <imachine> LjL, in there, edit/preferences
[23:53] <]{53> test_: next step is install it on a reall hd so you can force yourself to 'get used to it'.
[23:53] <mezquitale> test_ try ubuntu, its one of the best, ubuntu or SuSE, i started out with SuSE and moved to ubuntu, ubuntu is much faster and more stable
[23:53] <ron2> Not saying ubuntu because this is #ubuntu either.
[23:53] <imachine> LjL, removed the key base named 'login'
[23:54] <node357> my 8.10 install has been stuck on "scanning the mirror" for about 30 minutes :(
[23:54] <imachine> LjL, it got recreated on next login.
[23:54] <imachine> LjL, now all works fine :)
[23:54] <test_> but those come with gnome/kde, whereas most of unix stuff is done via command line/terminal
[23:54] <]{53> test_: everyone uses ubuntu. ;)
[23:54]  * Brandano bets the #gentoo people won't say gentoo
[23:54] <ron2> node357: try again?
[23:54] <ActionParsnip> test_: to learn unix, i'd say gentoo
[23:54] <imachine> LjL, I could file a bug.
[23:54] <toastedmilk> what's the default gconf-editor value for an ipod mount?
[23:54]  * ]{53 slaps ActionParsnip
[23:54] <mrwes> I remember trying to get X working in slack like 10 years ago...now that was fun!
[23:54] <LoveGuru> Hi, There is one Conf file there is alot commented/uncommented lines on it. I just want to Get All uncommented lines from that file? can i?
[23:54] <Brandano> ActionParsnip: it's also really good to learn how to properly rip your hair out, though
[23:54] <ActionParsnip> ]{53: what, its a good distro
[23:54] <ron2> I've used everything under the sun at some point practically
[23:54] <rockyrock> has anybody understood my problem???
[23:54] <test_> I tried gentoo in vm too
[23:55] <imachine> LjL, do you know tho what in the system got changed through that gui app? So that I'd know what to file a bug agains?
[23:55] <ActionParsnip> Brandano: teaches you a lot
[23:55] <ron2> even things made by sun!
[23:55] <]{53> I agree to REALLY learn you need to start with Linux From Scratch. LOL
[23:55] <Brandano> on the plus side, it's the most optimized among the "high feature" distros
[23:55] <mrwes> gotta compile a couple of kernels to really get into it
[23:55] <]{53> Or Gentoo.
[23:55] <mrwes> heh
[23:55] <ActionParsnip> ]{53: start from stage3 and you have half the battle completed
[23:55] <snuitje> http://funroll-loops.info/
[23:55] <node357> my 8.10 install has been stuck on "scanning the mirror" for about 30 minutes :(
[23:55] <imachine> to learn UNIX, I'd recommend Digital UNIX
[23:55] <ron2> I haven't used gentoo though, so I can't comment on that
[23:55] <imachine> or NetBSD.
[23:55] <imachine> w00t
[23:55] <imachine> gentoo is too new
[23:55] <imachine> ;)
[23:55] <FloodBot3> imachine: Please don't flood, use http://paste.ubuntu.com to paste, don't use Enter as punctuation.
[23:56] <snuitje> hehe try a unix pdp-11 :)
[23:56] <]{53> gentoo is the new slackware.
[23:56] <ron2> gentoo is just something i haven't used
[23:56] <imachine> ]{53, lol I should hang you for that
[23:56] <snuitje> some guy in australia still has one
[23:56] <test_> they say AIX is the most powerful for enterprise, ubuntu for desktop and suse for business, what do you guys think?
[23:56] <imachine> tho I admit, I went slackware -> fbsd -> gento
[23:56] <ActionParsnip> node357: i'd restart the install and unplug the network from your system
[23:56] <]{53> imachine: LOL!
[23:56] <ron2> suse is okay too actually, i guess
[23:56] <toastedmilk> I'm trying to use my ipod with songbird, and I get error message 'Cannot Mount Volume : The volume uses the / file system which is not supported by your system.'  What does this mean?
[23:56] <ron2> or used to be
[23:56] <ron2> I used that for a little while
[23:56] <node357> okay ActionParsnip thanks
[23:56] <node357> wish me luck
[23:56] <mrwes> imachine, yah I remember running Walnut Creek
[23:56] <imachine> I support ubuntu where I can.
[23:56] <Dante123> hi all, trying to run an app that I think was first developed for kde under gnome (in ubuntu) the program starts and i see a logo...but then never loads...i get the following error:  http://pastebin.ca/1268047
[23:57] <LjL> !offtopic | imachine mrwes
[23:57] <imachine> on servers, with uSERS, I recommend debian.
[23:57] <ActionParsnip> imachine: me too, im fairly regular in here :D
[23:57] <LjL> imachine: honestly no and i didn't find anything in gconf either
[23:57] <toastedmilk> I'm trying to use my ipod with songbird, and I get error message 'Cannot Mount Volume : The volume uses the / file system which is not supported by your system.'  What does this mean?
[23:57] <nickrud_> LoveGuru, grep -vP '^[ \t]*(#|$)' should do it I think
[23:57] <imachine> LjL, hey, I said I *suport* ubuntu! :-P
[23:57] <ActionParsnip> imachine: on servers I'd use smoe cli based distro
[23:57] <imachine> double p
[23:58] <imachine> ActionParsnip, on servers with Users I'd use FreeBSD or NetBSD.
[23:58] <Brandano> ubottu: !info chroot
[23:58] <imachine> :-P
[23:58] <imachine> but enough ofg that !
[23:58] <Brandano> yay!
[23:58] <ActionParsnip> toastedmilk: is it in disk mode? does it show up in sudo fdisk -l ?
[23:58] <imachine> before they kill me for offtopic ;]
[23:58] <Dante123> hi all, trying to run an app that I think was first developed for kde under gnome (in ubuntu) the program starts and i see a logo...but then never loads...i get the following error:  http://pastebin.ca/1268047
[23:58] <Brandano> ubottu: !info dchroot
[23:58] <mrwes> !info kernel
[23:58] <Brandano> ubottu knows everything, but has no links to howto's
[23:58] <imachine> lols :)
[23:58] <mrwes> heh
[23:58] <mezquitale> if you install 8.10, can you still choose to use 8.04 kernel when you boot up??
[23:58] <imachine> intrepid don't run on kernel
[23:58] <imachine> ;]
[23:58] <test_> Do you have any suggestions for books on unix?
[23:58] <LjL> !info linux
[23:59] <LjL> !fishing
[23:59] <imachine> ok anyway
[23:59] <LoveGuru> Hi, There is one Conf file there is alot commented/uncommented lines on it. I just want to Get All uncommented lines from that file? can i?
[23:59] <imachine> I'm off to my warm home.
[23:59] <imachine> this machine works fine.
[23:59] <imachine> lates!
[23:59] <nickrud_> LoveGuru, grep -vP '^[ \t]*(#|$)' should do it I think
[23:59] <mrwes> l8r
[23:59] <imachine> and thanks for teh support.
[23:59] <gnutron> test_: Think Unix, by Jon Lasser is a good book.
[23:59] <mcphail> test_: these questions would be better asked in #ubuntu-offtopic
[23:59] <snuitje> test_: can you read ebdic on paper tape?
[23:59] <Brandano> thanks LjL
[23:59] <toastedmilk> ActionParsnip, http://pastebin.com/d2f5376af
[23:59] <LoveGuru> nickrud_ thanks let me try
[23:59] <Paddy_EIRE> imachine, that'll be $250


[11:41] <rick_h> morning
[11:43] <_stink__> yo
[13:01] <cmaloney> morning
[17:25] <cmaloney> "The Secret Service was already initialized"
[17:25] <cmaloney> messages from gnome-keyring-daemon
[17:49] <greg-g> cmaloney: you hope
[17:51] <cmaloney> Yeah, when people are out to get you paranoia is just good thinking.
[17:55]  * greg-g adjusts his tinfoil hat
[18:03]  * cmaloney gets out the slinkys to help augment the radio signals away from his head.
[18:04] <rick_h> I got one for michael for christmas last year
[18:04] <cmaloney> a tinfoil hat?
[18:04] <rick_h> it lasted two days before michael kinked it beyond use
[18:04] <rick_h> slinky
[18:04] <cmaloney> Thought you needed to be at least 10 to get one of those proper
[18:04] <cmaloney> rick_h: Yeah, I think the half-life of a slinky is directly proportional to how much it's played with
[18:07] <cmaloney> but it's cool that they're made in Canton MI
[18:07] <greg-g> yeah, ours lasted a little while, but I was anal about it. Semi fixed it a couple times, now it just sits in the random toy bin unused :(
[18:07] <cmaloney> :(
[18:07] <cmaloney> It's a strange-ass toy to be sure
[18:08] <cmaloney> "hey kids, here's a coil of metal"
[18:10] <rick_h> heh, well the first time you show them how it does stairs they're amazed
[18:10] <rick_h> 20min later it's wrapped around them as a giant form of jewelry and the untangling commences
[18:11] <rick_h> then you get where dad is into his 3rd hour trying to restore it at $4.99 for the toy he's currently earning about $2/hr of labor
[18:12] <rick_h> greg-g: how goes the van shopping?
[18:12] <_stink__> whenever i tried to demo the slinky on the stairs it didn't work
[18:13] <cmaloney> _stink__: Yeah, it doesn't work well on USA stairs
[18:13] <cmaloney> I think they changed stairs in newer homes to be wider
[18:13] <cmaloney> as opposed to the death-traps of older homes
[18:13] <cmaloney> rick_h: Hah
[18:13] <rick_h> greg-g: van porn https://www.youtube.com/playlist?list=PLWysv3wFKyy6D8gj8lWmAuB7B--nAeSOT makes me want to get a van to tow with, well kinda
[18:13] <rick_h> lol
[18:14] <rick_h> "new updated modern slinky for fat stairs"
[18:14] <cmaloney> rick_h: How many vehicles are you allowed in Clarkston before they send you to Hazel Park? :)
[18:14] <rick_h> cmaloney: we've only got 2!
[18:14] <rick_h> I WANT a wrangler, and a van, and a...
[18:15] <rick_h> but contrary to my wife, I don't find a way to get EVERYTHING I want :P
[18:15] <cmaloney> Just "mostly". ;)
[18:15] <rick_h> I mean if anyone wants to send one of these my way I won't complain https://www.santacruzbicycles.com/en-US/bronson
[18:19] <brousch> We're looking at new houses and went through a 100+ year old home. My wife was afraid of the stairs
[18:22] <jrwren> turnover is a good way you can have every vehicle you want, just not all at the same time.
[18:24] <jrwren> if anyone wants to send me one of these, or even just lend... I'll praise ya! http://surlybikes.com/bikes/wednesday
[18:24] <rick_h> jrwren: doesn't Tim roll with one of those?
[18:25] <rick_h> jrwren: saw a guy on a nice fat bike last night. Crazy thinking of cranking those wheels round and round
[18:25] <jrwren> rick_h: Tim has a fat tire for sure. I'm not sure if it is surly or not.
[18:26] <jrwren> yeah... I finally realized, since I ride mostly for the exercise, no reason not to go for steel frame and fat tire :)
[18:26] <rick_h> jrwren: I'm pretty sure it's a surly, just not sure which one
[18:26] <rick_h> jrwren: <3 and with tires like that it's like having a suspension
[18:26] <rick_h> it's why folks are <3'ing 27.5+ these days
[18:26] <jrwren> yup
[18:26] <rick_h> most common review comment is "feels like the bike has more travel than it does"
[18:28] <jrwren> and in surly case its important cuz they don't have suspension
[18:28] <rick_h> yea
[20:09] <cmaloney> Suspensions are for people without butts
[20:09] <cmaloney> gotta feel every pebble on that road.
[20:12] <jrwren> OUCH
[20:14] <cmaloney> ;)
[20:19] <greg-g> "alex is 8 and he's going in the baby pool" OH at home
[20:28] <cmaloney> Big day


[05:14] -queuebot:#ubuntu-release- New binary: node-date-time [amd64] (bionic-proposed/none) [2.1.0-1] (no packageset)
[05:15] -queuebot:#ubuntu-release- New binary: node-rollup-plugin-buble [amd64] (bionic-proposed/none) [0.15.0-1] (no packageset)
[09:51] <rbasak> ddstreet: IIRC I rejected dpkg once due to lack of bug reference in the changelog. I'm not sure if that was your one.
[11:11] -queuebot:#ubuntu-release- New binary: jquery-caret.js [amd64] (bionic-proposed/none) [0.3.1+dfsg.1-2] (no packageset)
[13:32] -queuebot:#ubuntu-release- New sync: nx-libs (bionic-proposed/primary) [2:<IP_ADDRESS>-4]
[13:32] -queuebot:#ubuntu-release- New: accepted nx-libs [sync] (bionic-proposed) [2:<IP_ADDRESS>-4]
[13:33] -queuebot:#ubuntu-release- New: accepted jquery-caret.js [amd64] (bionic-proposed) [0.3.1+dfsg.1-2]
[13:34] -queuebot:#ubuntu-release- New: accepted node-date-time [amd64] (bionic-proposed) [2.1.0-1]
[13:34] -queuebot:#ubuntu-release- New: accepted node-rollup-plugin-buble [amd64] (bionic-proposed) [0.15.0-1]
[13:34] -queuebot:#ubuntu-release- New: accepted node-npm-bundled [amd64] (bionic-proposed) [1.0.3-1]
[13:34] -queuebot:#ubuntu-release- New: accepted vmdb2 [amd64] (bionic-proposed) [0.12-1]
[13:38] -queuebot:#ubuntu-release- New binary: nx-libs [s390x] (bionic-proposed/none) [2:<IP_ADDRESS>-4] (no packageset)
[13:40] -queuebot:#ubuntu-release- New binary: nx-libs [amd64] (bionic-proposed/none) [2:<IP_ADDRESS>-4] (no packageset)
[13:43] -queuebot:#ubuntu-release- New binary: nx-libs [i386] (bionic-proposed/none) [2:<IP_ADDRESS>-4] (no packageset)
[13:44] -queuebot:#ubuntu-release- New binary: nx-libs [ppc64el] (bionic-proposed/none) [2:<IP_ADDRESS>-4] (no packageset)
[13:48] -queuebot:#ubuntu-release- New binary: nx-libs [arm64] (bionic-proposed/none) [2:<IP_ADDRESS>-4] (no packageset)
[13:57] -queuebot:#ubuntu-release- New binary: nx-libs [armhf] (bionic-proposed/universe) [2:<IP_ADDRESS>-4] (no packageset)
[16:26] -queuebot:#ubuntu-release- New: accepted nx-libs [amd64] (bionic-proposed) [2:<IP_ADDRESS>-4]
[16:26] -queuebot:#ubuntu-release- New: accepted nx-libs [armhf] (bionic-proposed) [2:<IP_ADDRESS>-4]
[16:26] -queuebot:#ubuntu-release- New: accepted nx-libs [ppc64el] (bionic-proposed) [2:<IP_ADDRESS>-4]
[16:26] -queuebot:#ubuntu-release- New: accepted nx-libs [arm64] (bionic-proposed) [2:<IP_ADDRESS>-4]
[16:26] -queuebot:#ubuntu-release- New: accepted nx-libs [s390x] (bionic-proposed) [2:<IP_ADDRESS>-4]
[16:26] -queuebot:#ubuntu-release- New: accepted nx-libs [i386] (bionic-proposed) [2:<IP_ADDRESS>-4]
[17:16] -queuebot:#ubuntu-release- New binary: ruby-hamlit [ppc64el] (bionic-proposed/none) [2.8.7-2] (no packageset)
[17:19] -queuebot:#ubuntu-release- New binary: ruby-hamlit [s390x] (bionic-proposed/none) [2.8.7-2] (no packageset)
[17:22] -queuebot:#ubuntu-release- New binary: ruby-hamlit [amd64] (bionic-proposed/universe) [2.8.7-2] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: ruby-hamlit [arm64] (bionic-proposed/universe) [2.8.7-2] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: ruby-hamlit [i386] (bionic-proposed/universe) [2.8.7-2] (no packageset)
[17:24] -queuebot:#ubuntu-release- New binary: ruby-hamlit [armhf] (bionic-proposed/universe) [2.8.7-2] (no packageset)
[21:21] -queuebot:#ubuntu-release- New: accepted ruby-hamlit [amd64] (bionic-proposed) [2.8.7-2]
[21:21] -queuebot:#ubuntu-release- New: accepted ruby-hamlit [armhf] (bionic-proposed) [2.8.7-2]
[21:22] -queuebot:#ubuntu-release- New: accepted ruby-hamlit [ppc64el] (bionic-proposed) [2.8.7-2]
[21:22] -queuebot:#ubuntu-release- New: accepted ruby-hamlit [arm64] (bionic-proposed) [2.8.7-2]
[21:22] -queuebot:#ubuntu-release- New: accepted ruby-hamlit [s390x] (bionic-proposed) [2.8.7-2]
[21:22] -queuebot:#ubuntu-release- New: accepted ruby-hamlit [i386] (bionic-proposed) [2.8.7-2]
[21:57] <xnox> infinity, slangasek: i think src:systemd should ship "dummy" transitional packages initscripts & upstart, which are full of rm_conffile
[21:57] <xnox> or maybe not src:upstart, but like something call "upgrade purger"
[21:57] <xnox> or maybe not src:upstart, but like something called "upgrade purger"
[21:58] <slangasek> xnox: I would not object to such dummy packages to handle the upgrade cleanup
[21:58] <xnox> to clean up, after packages that are removed from the archive, but had coffiles, xenial->bionic.
[21:58] <slangasek> xnox: it's "cleaner" than doing it in the release upgrader; but I'm fine with that also
[21:59] <xnox> and we may assemble them in a single source package, and generate the right binary names, with the right versions, etc.
[22:12] <slangasek> Laney: s390x autopkgtest queue is underperforming; I haven't looked into it yet https://cloud.kpi.canonical.com/dashboard/db/ubuntu-foundations?panelId=19&fullscreen&orgId=1&from=1519291919551&to=1519594805472
[22:13] <slangasek> infinity: ^^ need more glibc uploads, that's a great dataset for assessing the autopkgtest throughput
[22:14] <jbicha> slangasek: could you look into LP: #1718529 when you have a chance to try to unblock NM & ppp ?
[22:14] <ubot5`> Launchpad bug 1718529 in fso-gsmd (Ubuntu) "Please remove fso* packages from Ubuntu" [Undecided,New] https://launchpad.net/bugs/1718529
[22:15] <slangasek> jbicha: sure; do you want to trade me for analysis / fixing of the glibc-triggered autopkgtest regressions, which is what I was going to be working on? :)
[22:15] <infinity> There aren't many, thankfully.
[22:15] <jbicha> cough, cough, cough
[22:15] <slangasek> astroscrappy is almost certainly badtest, I just hadn't figured out what that means yet
[22:15] <infinity> Waking up to the sea of green was a pleasant surprise.
[22:16] <infinity> slangasek: That string doesn't appear in astrocrappy's source, so I assume it's a dep that hates life.
[22:16] <infinity> But that's as far as I dug before reminding myself it's a weekend.
[22:18] <jbicha> I thought you guys were making up the name of that package…
[22:18] <slangasek> I remembered the s
[22:18] <slangasek> infinity ... refactored it
[22:18] <slangasek> I assume astroscrappy is an add-on package for astroscooby
[22:19] <jbicha> "Optimized Cosmic Ray Annihilation in Python 3"
[22:20] <jbicha> oh, the github acronym is better "Speedy Cosmic Ray Annihilation Package in Python"
[22:23] <xnox> slangasek, what about nvidia-304? it's blocking my xorg upgrade fix.... https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-304/+bug/1748000 or should i be working with the kernel team to fix it, because hwe & xenial still probably needs to ship nvidia 304?!
[22:23] <ubot5`> Ubuntu bug 1748000 in nvidia-graphics-drivers-304 (Ubuntu) "Remove from the archive: this legacy driver is unmaintained upstream" [Critical,Triaged]
[22:24] <jbicha> xnox: I'm hoping the mesa/nvidia transition finishes on Monday, not sure how much it's related to your bug
[22:28] <slangasek> xnox: ok, that one I'll trade you for the libunistring-triggered regression in tracker, which looks like it might be a difficult-to-bisect gnulib problem ;)
[22:29] <xnox> slangasek, this is not how the scrub poker is supposed to work!
[22:29] <xnox> *scrum
[22:29]  * jbicha folds
[22:30]  * xnox ponders if we can make an Agile method based on the Risk strategy board game of diplomacy, conflict and conquest
[22:32] <slangasek> xnox: I think you care about tracker, libunistring is tied to libcurl4
[22:32] <xnox> sigh
[22:37] <slangasek> xnox: speaking of which, we've got Debian maintainer ack, I think we should proceed with that upload at least
[22:37] <xnox> slangasek, yes, my plan was to kick it off on Monday.
[22:37] <slangasek> ok
[22:38] <xnox> slangasek, it will need new queue processing, so will not upload no change rebuilds. Unless I do the doko hack of the .dsc
[22:38] <xnox> to include extra build-depends on libcurl-dev (>= bla)
[22:38] <slangasek> ick no :)
[23:11] <acheronuk> slangasek: can the ppc64el and s390x tests on parley be ignored please? http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html#parley
[23:12] <acheronuk> as it no longer builds on those architectures
[23:15] <acheronuk> ^^^ not urgent :)