[12:51] <Fotis__> Hello to everyone
[12:52] <Fotis__> Is there anyone ever occupied with hardware?
[12:53] <Fotis__> I need a little help with some details
[12:56] <zequence> Fotis__: I posted a link to you yesterday
[12:56] <zequence> Fotis__: https://help.ubuntu.com/community/UbuntuStudio/SupportedHardware
[12:57] <Fotis__> thanks a lot I will check it right now
[13:09] <Fotis__> I used Ubuntu and Blender din't work cause of my intel 3000 gpu.
[13:10] <Fotis__> After research I realise that for best results in graphics and video is better to have a better cpu and gpu that I have
[13:11] <Fotis__> So I decided to make a high end computer and I also decided to use ubuntu studio instead of ubuntu
[13:12] <cub> Fotis__, if you only will do graphics you really don't get any performance advantages by running Ubuntu Studio
[13:12] <cub> except that xfce is lighter than unity
[13:13] <cub> and of course Ubuntu Studio looks more awesome. ;)
[13:14] <Fotis__> Ubuntu studio is a complete preinstalled ubuntu with useful apps and prettier than unity UI right?
[13:15] <cub> yes, but everything is available in any of the *buntu releases
[13:15] <Fotis__> Sure
[13:18] <Fotis__> Ubuntu is the base but the studio version is a full container for every user
[13:18] <Fotis__> I spent a lot of time to find the whole package for myself
[13:19] <Fotis__> Ubuntu studio is ready
[13:19] <cub> that is the goal
[13:19] <Fotis__> I would like to participate in studio devel
[13:21] <cub> We have a lot of testing coming up for 14.04. :) https://wiki.ubuntu.com/UbuntuStudio/JoinTheTeam
[13:25] <Fotis__> How exactly this testing works?
[13:25] <Fotis__> is it supported for intel hd3000?
[13:27] <zequence> Inte writes their own open source drivers for Linux, so in theory, they should have the best support for their GPUs
[13:27] <zequence> Intel*
[13:35] <Fotis__> Which high end GPU should I purchase (I hope the question is not out of topic)
[13:36] <zequence> Fotis__: We don't really have a clue. Intel is generally well supported. You could check out the Ubuntu verified page
[13:36] <zequence> And, the specs for system76 computers, who only sell Ubuntu machines
[13:36] <zequence> https://www.system76.com/
[13:37] <zequence> http://www.ubuntu.com/certification/
[13:41] <cub> Fotis__, you can learn more about testing on http://iso.qa.ubuntu.com/
[13:47] <Fotis__> What is the name of the UI of ubuntu studio?


[07:53] <dholbach> good morning
[11:36] <trinikrono> good morning from ubunut-tt
[11:37] <trinikrono> *ubuntu-tt
[11:39] <dholbach> hi trinikrono
[11:42] <trinikrono> i like the changes you guys made to loco.ubuntu.com


[00:17] <NoCode> fossfreedom: tbh, this is how I've always set up my system. But this install seems to be different/changed. I'll ask elsewhere.
[04:03] <NoCode> Okay, I've found that the session manager isn't hooking into PAM properly. In Budgie, ulimit -l" suggests 64. While I've set it to unlimited. I've logged into virtual console to get "ulimit -d" which suggests unlimited. How can I fix this issue?
[04:09] <NoCode> Does Budgie use Lightdm as default?
[06:38] <deepak_hp> Hello
[07:56] <Cl4ra-fr> Hello everyone
[07:57] <Cl4ra-fr> I just installed ubuntu budgie, it's great, but i have a problem :(
[07:58] <Cl4ra-fr> I installed gnome-boxes in order to have some VMs but i can't manage to make my mouse and keyboard work inside of these VM
[12:56] <NoCode> Still having issues even try to see if gdm would fix the issue
[12:56] <NoCode> trying*
[12:57] <NoCode> I'm memlock'd to 64 in Budgie. But virtual console I am at unlimited.
[13:29] <NoCode> So instead of /etc/pam.d/common-session, I put session required pam_limits.so in /etc/pam.d/systemd-user. memlock has changed from 64 to unlimited. Hopefully that's the proper way to fix it.
[16:16] <fossfreedom> NoCode, yes - the greeter is a lightdm greeter called "slick greeter"
[16:16] <fossfreedom> the session manager is gnome-session
[20:39] <dlaube_de> is there any reason for network manager being a dependency for budgie-desktop?
[20:40] <dlaube_de> i feel like even the minimal package has too many dependencies that are not required
[22:57] <fossfreedom> dlaube_de, that is an upstream issue - the network applet is specifically coded to display in the system tray.  It isnt optional in its current coded form.
[23:32] <NoCode> I'm glad with all the changes I had to endow the last day, everything has worked well. No meltdown yet.
[23:33] <fossfreedom> sounds like good news NoCode
[23:34] <NoCode> I hope so
[23:34] <NoCode> fossfreedom: That PAM change in systemd-user, does that sound right?
[23:35] <fossfreedom> sorry - I'm not an SME in this area so cannot say if its correct or not correct.
[23:35] <NoCode> ah ok


[00:00] <GaryvdM> mbt: I'm busy for a fix for that bug (https://code.launchpad.net/~garyvdm/bzr/bug492116-ls-file/+merge/45679)
[00:01] <mbt> Oh!
[00:01] <mbt> I'll mark my bug a dup
[00:01] <mbt> *dupe
[00:02] <vila> GaryvdM: hawk eyes you have :)
[00:02] <mbt> GaryvdM, thanks!
[00:03] <jml> spiv: has it landed yet?
[00:03] <vila> GaryvdM: the issue is that there is some weird interaction with hudson, so for the time being I keep them blacklisted
[00:03] <vila> GaryvdM: I know "some" people are still running them so I'm not worried about regression there :)
[00:03] <vila> GaryvdM: especially since they cover a developer feature :D
[00:03] <mbt> zyga, am breaking for dinner; will be back in a bit.  if you need to get a hold of me my email and jabber info is on my LP profile
[00:04] <vila> GaryvdM: oh, and by the way, these tests are disabled for *all* platforms, not only windows
[00:04] <GaryvdM> vila: oh!
[00:05] <GaryvdM> vila: I also had problems with them in the past. So I'm also running with ""-x TestBreakin"
[00:05] <vila> GaryvdM: you shouldn't !
[00:05] <vila> :-D
[00:06] <vila> I rely on *you* :)
[00:06] <GaryvdM> ok
[00:06]  * GaryvdM restarts tests.
[00:08] <GaryvdM> vila: btw - this is on windows, with the standalone install.
[00:11] <GaryvdM> vila: I
[00:11] <GaryvdM> vila: It hangs on "blackbox.test_breakin.TestBreakin.test_breakin_harderbreakin_harder"
[00:12] <vila> GaryvdM: hmm :-/
[00:12] <vila> GaryvdM: file a bug or is there one already for that ?
[00:12] <vila> GaryvdM: and ping jam :)
[00:14] <GaryvdM> vila: ok
[00:14] <GaryvdM> I'll do that tomorrow. Good night.
[00:18] <zyga> mbt: okay
[00:18] <zyga> mbt: I got first _very_ rough version that talks with remote daemon
[00:19] <zyga> mbt: I only route the info() request this way
[00:19] <zyga> but it works
[01:22] <mbt> zyga, I am back.
[01:25] <exarkun> What is the "submit branch" (in particular in comparison to the "parent" branch)?
[01:25] <zyga> mbt: great
[01:25] <zyga> mbt: I'll commit and push my stuf
[01:25] <zyga> mbt: it's not much
[01:25] <mbt> exarkun, It is the branch used for the "bzr send" command
[01:26] <exarkun> weuoook
[01:26] <mbt> exarkun, you can specify the parent branch as :parent
[01:26] <mbt> exarkun, e.g., bzr send :parent
[01:27] <zyga> mbt: pushed
[01:27] <zyga> mbt: check it out
[01:27] <zyga> mbt: it's nice, I'm working on more
[01:28] <exarkun> mbt: okay thanks
[01:28] <mbt> zyga, sure thing, one second
[01:28] <mbt> zyga, what's the link to the branch?
[01:29] <mbt> oh nvm, I can pull can't I.
[01:29] <zyga> lp:~zkrynicki/+junk/redmine-bzr
[01:29] <zyga> :-)
[01:29] <zyga> right
[01:29] <fullermd> I think submit is also used as a default for merge.
[01:31] <zyga> mbt: the adapter hardcodes the location of the rpc server
[01:31] <mbt> zyga, looking now,
[01:32] <zyga> mbt: eventually you will be able to talk to the server entirely so the url/root url will no longer be meaningful and the branch server can be all that you specify
[01:32] <zyga> mbt: with my branch you can also see all the merges
[01:32] <zyga> mbt: but there are some bugs so if you find something broken leave me a note
[01:32] <zyga> mbt: if you compare my adapter to yours you'll see I removed some if's
[01:34] <mbt> zyga, what's the change to config/environment.rb for?
[01:34] <zyga> uh
[01:34] <zyga> random junk, sorry
[01:34] <zyga> it's 2AM
[01:35] <mbt> lol okiedokey just making sure 'cuz I was all like "interrobang"
[01:35] <zyga> uncomited and pushed again
[01:36] <zyga> with --overwrite
[01:38] <mbt> Ah, I see how this works
[01:38] <zyga> it's just a start, but we can manage everything this way
[01:38] <zyga> the server has to be moved to initialize
[01:39] <zyga> but I'm already dying here, I'll hit the bed soon
[01:39] <mbt> What's going to manage the lifecycle for the bridge process?  Or can Redmine be setup to start it up when it's persistent Rails process is started?
[01:39] <zyga> mbt: it's a separate topic, IMHO it can be done in several ways that will make it not a problem in practice
[01:39] <zyga> mbt: such as xml-rpc hosted inside apache
[01:39] <zyga> mbt: or just plain deployed as a separate service alongside
[01:40] <zyga> mbt: redmine does not need to care about this, all you give it is xmlrpc url
[01:40] <mbt> zyga, well, it should be able to, lest people have to do extra work when setting up for Bazaar repositories anyway
[01:41] <mbt> But yes, later
[01:41] <zyga> mbt: you don't have to setup lp.net to use lp.net url with redmine
[01:41] <zyga> it think it's out of scope
[01:41] <mbt> I'm just thinking in terms of expectations.  All other SCMs work out of the box with no additional effort, so this should, too.
[01:42] <zyga> well that's true
[01:42] <zyga> mbt: we might setup something that will work like that
[01:42] <zyga> mbt: one thing I would look at is performance
[01:42] <zyga> mbt: if it's faster than everyone else
[01:42] <zyga> that's a plus :-)
[01:43] <mbt> zyga, True.  It does look like, though, the way this XML-RPC thing works, it'd be entirely possible to choose a front-end (e.g., also support command line invocation)
[01:43] <mbt> right
[01:43] <mbt> ?
[01:43] <zyga> mbt: I only worry that setting up stuff like that is flaky
[01:44] <zyga> mbt: stuff like the helper dying
[01:44] <mbt> No more flakey than shelling out 10 times per page view to determine if the current revision is the latest one
[01:44] <zyga> etc
[01:44] <mbt> lol
[01:44] <zyga> it's part of the system services to oversee this
[01:44] <zyga> putting it inside redmine will only be more broken
[01:44] <zyga> right but this is about fixing things
[01:44] <zyga> personally
[01:44] <zyga> apache + xmlrpc server is probably most resiliant method
[01:45] <zyga> but we'll need to check how all those read locks behave
[01:45] <zyga> I'm really curious how lp.net does this
[01:45] <mbt> Hrm.
[01:45] <zyga> running loggerhead _AND_ allowing you to push all the time
[01:45] <mbt> I'm sure that "buy-in" will be better if it can be done as an either/or
[01:45] <zyga> unless they mirror the branch you push to scratch space to run loggerhead from
[01:45] <mbt> zyga, probably doesn't hold the locks any longer than necessary
[01:45] <mbt> or that.
[01:46] <zyga> mbt: I never saw it hold any locks and loggerhead can take a while to run
[01:46] <zyga> mbt: setting up redmine is ~10 minutes if you follow the docs
[01:46] <zyga> mbt: I'd add +2 minutes to setup the service for bzr
[01:46] <zyga> but in a way that will recover, not just running it like that from the comand line
[01:46] <zyga> that can be done after it works
[01:46] <mbt> Well, one could use dæmontools or Upstart
[01:47] <zyga> mbt: yeah there are lots of options
[01:47] <mbt> But not every server is going to have the ability to do that either
[01:47] <zyga> apache is the logical choice if you already run it
[01:47] <zyga> to run what?
[01:47] <zyga> why not? managed crippled hosting with rails?
[01:47] <mbt> A server where you can deploy rails apps, might not permit ssh access or the ability to run any (other) persistent processes
[01:49] <zyga> mbt: perhaps, but personally I dont find this that important, if you already host your code somewhere else you might as well host it using public services, setting up a django app on google app engine that will do this is trivial and will not require anything fancy
[01:49] <zyga> (perhaps apart making sure that the app can actually talk to the repository)
[01:49] <zyga> mbt: so for the moment, let's fix the adapter, figure out how to make people deoploy it later
[01:49] <mbt> Indeed.
[01:49] <mbt> :)
[01:50] <zyga> mbt: another thing, it can run on _separate_ sever
[01:50] <mbt> Well, go ahead and head to bed, and I'll work on this for a while, maybe see if I can get feature-parity tonight
[01:50] <mbt> zyga, Indeed
[01:50] <zyga> mbt: usually you do have bzr+ssh to get the code in the first place
[01:50] <zyga> mbt: thanks, I'll talk to you tomorrow
[01:50] <zyga> mbt: btw, I'm +1GMT, you?
[01:50] <mbt> zyga, sure thing.  Thanks!
[01:50] <mbt> zyga, -0500
[01:51] <zyga> okay, see you tomorrow
[01:51] <mbt> So noon there is several hours before I wake up here :)
[01:51] <mbt> zyga, yep, night
[10:45] <sender> I am on revision 10. I bzr rm'd a file on revision 4. How do I get that file back?
[10:45] <sender> Thanks :)
[10:45] <bob2> bzr cat -r3 xxx > xxxx
[10:45] <sender> bob2: thanks, will try now
[10:47] <sender> bob2: great, never knew about bzr cat. brilliant.
[10:47] <mgz> you'll not get any blame like that, no?
[10:47] <bob2> note: bzr will have no idea what you did
[10:47] <bob2> mgz: right
[10:47] <sender> true
[10:47] <soren> You can revert the file back to r3.
[10:47] <mgz> `bzr merge -r4..3 xxx` any better?
[10:47] <soren> That way, bzr will know it's the same file.
[10:48] <bob2> mgz: oh, didn't think of that
[10:48] <sender> i've tried that too, bzr revert -r3 robots.txt - didnt do anything
[10:48] <mgz> I'm not certain it's any better, but might be.
[10:49] <soren> Works for me.
[10:49] <soren> Just tested it.
[10:49] <awilkins> jelmer, Do you know the evolution codebase well, or do you just keep a PPA of it?
[13:21] <mgedmin> bzr branch lp:ubuntu/$suite/$package rules!
[13:57] <Odd_Bloke> I want the contents a particular revision of a bzr branch (I'm packaging, I don't care about history whatsoever).  Currently I'm doing 'bzr co -r ... <branch>'.  This is slow.  Is there a better way?
[13:57] <Odd_Bloke> In fact, can I use 'bzr export' on the remote branch?
[14:03] <Lo-lan-do> You probably can, yes.
[14:06] <Odd_Bloke> Hmm, that causes problems.
[14:06] <Odd_Bloke> In that previously I had a local copy that I could use for looking up revnos (for example).
[14:06] <Odd_Bloke> Whereas now I'm using the remote one, which could change between my export and my revno lookup.
[14:07] <Odd_Bloke> Is there any way I can get a lightweight checkout of a particular revision?
[14:09] <Lo-lan-do> You could use a revid, which isn't going to change.
[14:09] <awilkins> Odd_Bloke, What about export
[14:09] <awilkins> bzr export -r URL
[14:09] <awilkins> oops
[14:09] <awilkins> bzr export -r revid URL
[14:10] <awilkins> No checkout, no baggage, just the files
[14:10] <awilkins> Oops, didn't read all the scrollback
[14:10] <Odd_Bloke> awilkins: :)
[14:11] <Odd_Bloke> Added complication: I'm exporting by tag but need to look up the revision.
[14:13] <Odd_Bloke> Ah, and 'bzr revno' won't let me specify a revision.
[14:13] <awilkins> Odd_Bloke, You can use revno or revision-info with the --tree argument on a lightweight checkout to get the revision of the current tree
[14:14] <awilkins> (knew it was supported because qlog does it)
[14:14] <Odd_Bloke> awilkins: But I don't think I can create a lightweight checkout of anything but the head of a branch.
[14:15] <awilkins> Odd_Bloke, So you can do a checkout --lightweight -r tag:WIBBLE
[14:15] <awilkins> Odd_Bloke, Just performed a lw checkout of a 2 revision branch at r1
[14:15] <awilkins> bzr revno --tree  # returns 1 as expected
[14:18] <Odd_Bloke> awilkins: Victory!  Thanks. :)
[15:57] <maxb> Yikes. This morning, I thought, "I'll just see if bug 705279 is reproducible"
[15:58] <maxb> It's been running for hours, is half way through, and has transferred 3.3GB
[16:19] <awilkins> maxb, Is the vcs import of the chromium sources an old-style or new style one, I wonder
[16:19] <awilkins> maxb, The newer ones use bzr-svn, the older ones use some other thing that isn't interoperable with it
[16:20] <maxb> It's the new kind
[16:20] <maxb> cscvs is hellspawn
[16:21] <awilkins> I suppose I might have guessed that 'coz Jelmer created it...
[17:47] <jelmer> awilkins: hi
[17:47] <jelmer> awilkins: I know the evolution-mapi source code a bit, not familiar with the core
[17:49] <SpamapS> if I do 'bzr commit -x debian' .. the debian dir should be totally ignored right?
[17:50] <james_w`> SpamapS, yes
[17:50] <SpamapS> hrm.. not happening. :(
[17:50] <SpamapS> actually...
[17:50] <james_w`> SpamapS, you are seeing it in the diff if you "bzr diff -c -1" after the commit?
[17:50] <SpamapS> it shows in the modified list if I specify no message..
[17:50] <SpamapS> but it is not actually committed
[17:50] <james_w`> yeah
[17:50] <SpamapS> DOH
[17:51]  * SpamapS looks for the surely already open bug report to +1
[17:51] <awilkins> jelmer, Ah, it's more the evolution-exchange stuff I was interested in ; our Exchange server is trapped behind one of these cookie redirectors so I was wondering how hard it would be to implement the same sort of solution described here  ; http://blogs.interknowlogy.com/timmccarthy/archive/2006/08/05/3659.aspx
[17:51] <james_w`> bug 552805
[17:51] <SpamapS> james_w`: I'm not sure what to make of the fact that you know the bug # by heart ;)
[17:52] <james_w`> SpamapS, only google knows that
[18:20] <glyph> possibly this should not be an internal error: http://buildbot.twistedmatrix.com/builders/debian64-py2.4-select/builds/894/steps/bzr/logs/stdio
[18:22] <spiv> glyph: I agree.  jelmer?
[18:23] <spiv> glyph: jelmer says that may already be fixed in current bzr-svn
[18:23] <spiv> glyph: inspection of the code suggests yes
[18:25] <spiv> glyph: interactive testing however suggests no!
[18:25] <spiv> glyph: investigations continue
[18:26] <spiv> (Apparently this is not ERR_UNKNOWN_HOSTNAME?)
[18:39] <glyph> spiv: I don't know man, I don't even work here
[18:43] <mbt> Dumb question, I can't find this in the docs it seems: given a branch and a file_id, how do I get the last revision that modified the file_id?
[19:04] <GaryvdM> jelmer: please can I ask you do advise me on bug 704840
[19:04] <GaryvdM> I posted a question in the bug.
[19:08] <vila> GaryvdM: thanks for the installers !
[19:09] <GaryvdM> vila: It's a pleasure :-)
[19:12] <GaryvdM> vila: I got the test suit to finish for the first time (with the standalone installer.) I had to exclude a bunch of https that were causing the test suit to fail.
[19:12] <GaryvdM> s/fail/hang/
[19:12] <vila> GaryvdM: fail
[19:13] <vila> GaryvdM: grr, file a bug with as much relevant  -s xxx you can think of and I'll try to give you more instrucitions
[19:13] <vila> to better localize the problem
[19:14] <GaryvdM> Ok will do. I'm going to slowly work at.
[19:43] <vila> GaryvdM: by the way, 2.2.3 in the pipe... :)
[19:44] <GaryvdM> vila: Ok
[19:45] <jelmer> GaryvdM: hmm
[19:45] <jelmer> GaryvdM: I think we should fix the bzr-svn config
[19:46] <jelmer> GaryvdM: but I'm also a bit surprised by the actual implementation in bzr.dev
[19:46] <GaryvdM> jelmer: ok
[19:49] <GaryvdM> I battling to grok the "increasing the python requirement " thread in ml. Where any decisions made?
[19:50] <jelmer> I'm not sure, I had the same problem :-)
[19:50] <spiv> GaryvdM: "stick with 2.4 for now" is the short answer
[19:51] <GaryvdM> spiv: Thanks
[19:51] <spiv> GaryvdM: with some interest in playing with 2to3 etc sometime soon to see how hard it would be to run on 3.x
[19:55] <mythril> how do I eliminate a specific revision?
[19:58]  * mbt 's ears perk up
[19:59] <mbt> Python 3.x?  Yes?  Yes?  :)
[20:00] <spiv> mbt: I wouldn't hold your breath...
[20:01] <mbt> lol, yeah, that seems to be the general consensus in most major python systems
[20:03] <mbt> spiv, You wouldn't know how to answer my ? from earlier, would ya?  I'm still stuck; I seem to be barking up all the wrong trees
[20:04] <mbt> ha, ha, that was an awful pun
[20:05] <GaryvdM> mythril: if there are no revisions after the revision you want to eliminate, then you can do a bzr uncommit
[20:06] <mbt> mythril, Do you need to eliminate it from the history, or would reverting it be sufficient?
[20:06] <GaryvdM> mythril: if there are revisions after, you could do a reverse cherry pick to revert the changes made by that revision, but the revision would still be in the history..
[20:08] <mbt> Should be possible also, in theory, to make a new branch, then on the old one, uncommit repeatedly to back way up, and then merge from the new branch as a cherry pick.  Then only the dead revision has to be pruned, right?
[20:16] <jam> mbt: this is also something that bzr-rewrite was developed to help with
[20:16] <jam> I don't know the specific invocations, though
[20:16] <jam> (something like "bzr rebase")
[20:16] <jam> but there have been complaints that rebase doesn't work very well with a single branch, etc.
[20:24] <GaryvdM> mbt: re you question about getting the revision that last modified a file
[20:24] <GaryvdM> If you get the inventory item for the file, you can call item.revision to get the revid.
[20:25] <GaryvdM> You will then need to get a revno for the revid.
[20:27] <mbt> I _think_ I found a way, using iter_entries_by_dir from RevisionTree
[20:27] <GaryvdM> I'm not sure how you are iterating the files, and hence what is the easiest for you to get the inventory item
[20:27] <GaryvdM> That will do.
[20:28] <GaryvdM> mbt: shout if you need help to go from a revid to a revno
[20:29] <mbt> GaryvdM, That I think I have; but whether or not the way I am doing things is going to be efficient is yet to be determined.
[20:29] <GaryvdM> mbt: is this for a web server?
[20:30] <mbt> Yeah, I'm workign on getting Redmine (a Ruby on Rails application) to try to support shared bzr repositories.
[20:31] <mbt> But the way that the bzr command line tool works, and the way that Redmine works, well, they don't have the same conceptual model of things.
[20:32] <mbt> Unless I am missing something in bzr or bzrlib, without a branch context a lot of operations are impossible.  But Redmine does not give you the branch context if you tell it that the revision system supports branches; instead it treats branches as a reference to a revision number (as if it were a tag in reality), and path information won't include the branch in that instance.
[20:33] <mbt> So instead, I'm trying to use the approach that it uses for subversion, which is to pass the repository as the URL; the URL may or may not be a branch, and if it is not a standalone branch, then the branch will have to be found from the relative path information
[20:33] <mbt> That seems to be working, but then I am left with breaking apart the branch information to find the relative path for the directory being browsed
[20:34] <mbt> And the odd thing is that since that comes from the RevisionTree, which comes from the repository, I can get a whole tree, but then I have to get into the branch context again to map the revision IDs to branch-local revision numbers.
[20:34] <mbt> What I am trying to figure out now is the most direct way of finding a path in the revision tree
[20:36] <GaryvdM> mbt: Ah - the api is like that, because the calculation of revision numbers is dependent on knowing branch tip
[20:36] <mbt> I get the why, but I don't understand why Redmine doesn't pass (branch, rel_path) to the VCS
[20:37] <mbt> That would make live a lot easier, and would make the bridge between bzr and Redmine a lot less ugy
[20:37] <mbt> *ugly
[20:37] <GaryvdM> I see
[20:37] <GaryvdM> if you can guess the branch tip, and are willing to go down a api level, you could calculate the revnumbers with out a branch ref
[20:37] <mbt> Only other thing is: can I get a path without kicking off the generator? Something like revisiontree.get_file_inventory(file_id) some how or another?
[20:38] <mbt> Oh?
[20:39] <mbt> (Or for that matter, just get the inventory for the root directory of a working tree, since the inventory apparently has references to all of its children)
[20:39] <GaryvdM> Yes
[20:42] <mbt> I see get_root_id in revisiontree, but I don't see a way to get its inventory without a generator somewhere.  For that matter, I'm not even sure that I'm hunting in the right place in the API
[20:43] <GaryvdM> revision_tree.inventory[file_id]
[20:46] <mbt> Oh?
[20:47] <mbt> Oh, well, sheesh.
[20:48] <mbt> Why didn't I see that like three hours ago lol
[20:48] <GaryvdM> I'm not sure if that is abusing the api a bit. Maybe one of the core devs can comment on that.
[20:48] <mbt> I don't know but it eliminates a function or two from my own code
[20:48] <mbt> so that isn't bad
[20:57] <zyga-efika> mbt: hi
[20:57] <zyga-efika> mbt: I'm still busy today but I looked at your changes
[20:57] <zyga-efika> mbt: I'll try to rewrite the single-branch model first
[20:57] <zyga-efika> mbt: and see how that works
[20:57] <zyga-efika> mbt: but it seems this will work
[20:58] <mbt> zyga-efika, I am looking at single branch ATM but I think it will transparently work for both.
[20:59] <mbt> I can commit my WIP in a sec
[20:59] <mbt> I have a very unhappy Entries list lol
[20:59] <zyga-efika> unhappy?
[20:59] <mbt> It loads without crashing, but with empty fields
[21:00] <mbt> it's what I'm working on right this sec
[21:00] <mbt> it's up
[21:01] <mbt> I think it's unhappy because I have not yet taught it fetch_changesets
[21:01] <mbt> which is I think what I need to do next
[21:13] <zyga-efika> mbt: I'm still occupied with my daily job, I need to finish some of the stuff in my backlog
[21:13] <mbt> zyga-efika, no biggie
[21:14] <mbt> am going to bind my branch so i don't forget to push
[21:15] <zyga-efika> mbt: thanks
[21:16] <mbt> zyga-efika, np... thank you
[21:28] <GaryvdM> abentley: I can't see 1.1 in lp:bzr-pipeline. Maybe you forgot to push?
[21:29] <poolie> thanks for the windows builds gary
[21:30] <GaryvdM> Hi poolie.  np :-)
[21:31] <GaryvdM> poolie: it feels good to be able to get back in to the swing of things :-)
[21:31] <poolie> it's great to have you back
[21:32] <abentley> GaryvdM, the 1.1 release is on the stable branch, not the trunk.
[21:33] <GaryvdM> abentley: oh - ok
[22:04] <lifeless> mkanat: hi
[22:04] <mkanat> Hey lifeless.
[22:05] <lifeless> I was talking to poolie
[22:05] <lifeless> about loggerhead & branches and launchpad
[22:05] <lifeless> uhm
[22:05] <lifeless> so you know that we've reorged the Launchpad team, right ?
[22:05] <mkanat> lifeless: Don't know anything about it, no.
[22:05] <lifeless> ah
[22:06] <lifeless> so http://blog.launchpad.net/general/changing-how-we-track-launchpads-bugs-questions-and-blueprints references a mail from me
[22:06] <mkanat> lifeless: Okay. But that wouldn't apply to loggerhead, since it's a separate product that's used elsewhere in addition to being used by LP.
[22:07] <mkanat> (Much like bzr itself wouldn't become part of launchpad.)
[22:07] <lifeless> thats true
[22:07] <lifeless> what is concretely means is that we're less siloed
[22:08] <lifeless> so we are more likely to fix things that are important rather than things that are important in one area
[22:08] <mkanat> lifeless: Although I'd think that it will also mean that your design will become more haphazard in the individual pieces, if the same people aren't always working on them. But that's more of a side note.
[22:08] <mkanat> Perhaps though the overall design will become more cohesive. Hard to say.
[22:09] <lifeless> one way to find out :)
[22:09] <lifeless> also its kindof my job, and jml's job to keep the technical and user stories cohesive
[22:09] <mkanat> lifeless: Sure, I just would be concerned that this will shift *all* design work onto you.
[22:10] <mkanat> Instead of allowing you to have sub-designers for the individual pieces.
[22:10] <lifeless> mkanat: nah, I chase after rather than being a bottleneck
[22:10] <lifeless> I like being able to sleep
[22:10] <mkanat> lifeless: Haha. :-)
[22:10] <lifeless> anyhow
[22:11] <lifeless> so - I'm worried that with the separate trunk + for-lp branch that we'll end up diverging, if trunk stays unsuitable for lp for extended periods
[22:11] <mkanat> lifeless: Oh, that is a temporary situation.
[22:11] <lifeless> and AIUI you may be spending less (no?) time on loggerhead
[22:12] <lifeless> what are your medium term plans vis-a-vis loggerhead?
[22:12] <mkanat> lifeless: Whether or not I'll still be working on loggerhead depends on administrative details at Canonical, so it's hard to say.
[22:12] <mkanat> lifeless: The only thing I'll be able to complete in the time that Canonical has currently allotted is bug 567729.
[22:13] <lifeless> mkanat: will this leave trunk unsuitable for lp ?
[22:13] <lifeless> or is it currently suitable?
[22:13] <mkanat> lifeless: It will leave trunk unsuitable. I had a plan to make trunk suitable for LP, but it was not approved.
[22:14] <mkanat> lifeless: The disapproval was not technical, it had to do with contracting.
[22:14] <lifeless> ok, I'll talk with poolie and flacoste about that
[22:14] <GaryvdM> Hi jam.
[22:14] <lifeless> how much work has landed since the point it became unsuitable?
[22:15] <mkanat> lifeless: Well, I can't be sure that history_db itself is unsuitable.
[22:15] <mkanat> lifeless: But /raw/ is definitely not suitable.
[22:15] <mkanat> lifeless: Although we could just hack out /raw/ easily, for LP.
[22:15] <mkanat> s/unsuitable/suitable/
[22:15] <GaryvdM> jam: I'm running into a bzr bug when building the win installer. The bzr on the ec2 instance is quite old.
[22:15] <lifeless> poolie: btw, that all pages cachable thing isn't useful for lp
[22:16] <poolie> oh, because?
[22:16] <lifeless> poolie: we can just tell squid to do that in ~2 minutes
[22:16] <poolie> ah, true
[22:16] <GaryvdM> jam: Admin is needed to install a new version. Please could you do that for me.
[22:16] <mkanat> lifeless: BTW, the CSS for loggerhead on LP seems to be wrong.
[22:17] <mkanat> lifeless: This page, for example, does not have the right CSS: http://bazaar.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/annotate/head:/.bzrignore
[22:17] <lifeless> the raw controller has a knob overriding it though?
[22:18] <mkanat> lifeless: It doesn't, but it would just involve commenting out a few lines.
[22:18] <lifeless> ok
[22:18] <mkanat> lifeless: The only think LP needs for it to work properly is the token thing, because of the private branches.
[22:19] <mkanat> lifeless: I'd be totally thrilled to do the work to make trunk stable and on LP though.
[22:20] <lifeless> :)
[22:20] <poolie> jam, GaryvdM, i'd like to sometime migrate the windows vm to use an ebs-based root partition
[22:20] <poolie> then it'll be easier to save the state
[22:21] <poolie> lifeless, will you comment on that squid bug or shall i?
[22:23] <lifeless> I will
[22:23] <GaryvdM> poolie: I'm only using the ec2 instance for 2.2 builds. For 2.3, I'm hoping I'll be able to get a 64 bit build done, so I'm using a local 64bit vm.
[22:24] <poolie> ah, ok
[22:27] <GaryvdM> poolie: having my own local vm allows me freedom to changes things, but I guess it's not good if I need to hand over to someone else.
[22:28] <mkanat> lifeless, jam: Is there some plan for how storing and updating history_db would work for LP?
[22:29] <jam> mkanat: hand-wavingly every project would get its own sqlite db file
[22:29] <jam> which gets updated on demand
[22:29] <jam> and we would pre-seed projects like emacs
[22:29] <mkanat> jam: Okay. Does history_db do incremental updates now?
[22:29] <jam> always has
[22:30] <mkanat> jam: Okay, cool. I thought so, just wanted to check.
[22:30] <jam> just that the *first* update is faster if you do it manually
[22:30]  * mkanat nods.
[22:30] <jam> plus, it means that someone hitting the website isn't the one waiting for it to complete
[22:30] <mkanat> Yeah, for sure.
[22:31] <mkanat> In an ideal world we'd update it asynchronously every time somebody changed the tip.
[22:31] <jam> mkanat: it actually wouldn't be a lot of overhead from that, at least my timings showed it to be quite feasible to run it as a post-commit hook in bzr
[22:31] <mkanat> jam: That'd be great if we could do that. Would require instrumentation and changes on codehosting, of course.
[22:32] <jam> at least once it has the first 100k revisions completed :)
[22:32] <mkanat> Right. :-)
[22:32] <jam> mkanat: yeah, some sort of job-task that triggers when a branch is updated
[22:32]  * mkanat nods.
[22:32] <jam> we already have the branch scanner which does similar work
[22:33] <jam> and we've been talking a bit about changing some of the postgres tables to use the history-db-like layout
[22:33] <jam> since BranchRevision currently is something like 0.5Billion rows
[22:33] <mkanat> Wow.
[22:34] <jam> anyway, when we poke at that, loggerhead could just use the production tables (possibly via an intermediate db, rather than the actual live one, etc)
[22:34] <jam> abentley: didn't you write up a LEP on this?
[22:35] <mkanat> Right. That'd be even simpler if we had history_db use an ORM.
[22:36] <abentley> jam, not quite a LEP, but: https://dev.launchpad.net/Code/BranchRevisions
[22:36] <jam> abentley: thanks. I wanted to point mkanat at the idea that we were looking at that sort of thing.
[22:36] <jam> mkanat: well, it is pretty generic sql, using python dbapi2
[22:36] <jam> so you could do it to pretty much any SQL backend
[22:36] <mkanat> jam: True.
[22:37] <jam> some of the create syntax is sqlite specific
[22:37] <mkanat> abentley: I wonder about the "use loggerhead" proposal, there. It's possible we could make it fast enough.
[22:37] <jam> (PRIMARY KEY AUTOINCREMENT vs using SERIAL in postgres)
[22:38] <abentley> mkanat, it's not a complete solution.
[22:38] <mkanat> abentley: Okay. Because you need to JOIN that table against other things in SQL?
[22:40] <mkanat> jam: Yeah, this would seem like a good reason to abstract history-db out into a plugin, again, reading this BranchRevisions proposal.
[22:40] <GaryvdM> jam: Thanks - the upgrade fixed the bug.
[22:40] <jam> mkanat: it is a plugin
[22:40] <abentley> mkanat, it would not address "Finding the most relevant branch for any given revision" "Allocating revision karma" or "Merge detection in the scanner "
[22:40] <jam> we pulled it into loggerhead to avoid having a weird plugin dependency
[22:41] <mkanat> jam: Ahhh.
[22:41] <jam> for people that want an easy way to set up loggerhead
[22:43] <jam> the history is synced up, though, so loggerhead can merge updates from the plugin, and you can cherrypick loggerhead changes back to the plugin
[22:43] <mkanat> jam: Oh, okay. Are there changes that I should pull in, now?
[22:45] <jam> mkanat: nothing I know of
[22:45] <mkanat> jam: Okay.
[22:48] <lifeless> mkanat: ok, I has spoken with poolie and flacoste
[22:48] <lifeless> mkanat: what we propose to do is:
[22:48] <Erimos_Wolf> Hi at all, i have a question considering the behavior of the bazaar plugin for eclipse. Iam not sure if this is the right channel
[22:48] <lifeless>  - push the history-db & raw stuff to a experimental/future branch and push stable to trunk
[22:49] <lifeless>  - have the launchpad team adopt the loggerhead project, so we'll do bug triage & code review
[22:49] <GaryvdM> Erimos_Wolf: ask away
[22:49] <lifeless> mkanat: does that sound sensible to you?
[22:50] <mkanat> lifeless: Ah, that doesn't quite make sense.
[22:50] <mkanat> lifeless: history_db is already on trunk.
[22:50] <mkanat> lifeless: As is raw.
[22:50] <mkanat> lifeless: stable is well behind trunk.
[22:51] <mkanat> lifeless: Pushing stable to trunk wouldn't make any sense.
[22:51] <Erimos_Wolf> I followed the instructions and installed bazaar on my local machine. In eclipse i have under Project->Team all bazaar instructions. But when i try to commit it says every time "nothing to commit". A look at the bazaar explorer says different. There i can commit. Is this normal?
[22:52] <mkanat> lifeless: trunk is the experimental and future branch.
[22:52] <mkanat> lifeless: The launchpad branch of loggerhead has many important things from trunk that aren't on stable.
[22:52] <lifeless> mkanat: yes, thats my understanding; we want to get trunk stabilised and this seems the most robust way to do it
[22:52] <jam> mkanat: he wants to turn that around
[22:52] <jam> make trunk stable
[22:52] <jam> and start and experimental branch
[22:52] <jam> by "resetting" trunk
[22:52] <mkanat> lifeless: Right, I want to make trunk stable as well.
[22:53] <mkanat> jam: I'm not sure that makes sense at this point.
[22:53] <mkanat> Why not just do the work to stabilize what's on trunk now?
[22:53] <mkanat> It would be a few weeks of work at the most, I think.
[22:54] <mkanat> lifeless: Also, I'm not sure that having only the launchpad team work on loggerhead will be the best for the non-launchpad users of loggerhead.
[22:55] <GaryvdM> Erimos_Wolf: I guess that's not normal. verterok?
[22:55] <mkanat> lifeless, jam: Also, it's not possible to extract the unstable parts of trunk, for the most part--they involved a lot of refactoring and then what comes after is built on that refactoring.
[22:56] <mkanat> It would probably be almost as much work to "reset" trunk as it would to actually make trunk stable.
[22:58] <lifeless> sorry, local interrupt
[22:58] <Erimos_Wolf> is there a log file to digg through?
[22:58] <lifeless> mkanat: so the bzr team is focusing on udd
[22:58] <GaryvdM> Erimos_Wolf: ~/.bzr.log
[22:59] <GaryvdM> My Document\.bzr.log on windows
[23:02] <lifeless> mkanat: which means that AFAIK there isn't anyone really worrying about loggerhead atm except you
[23:03] <mkanat> lifeless: Yeah, although that's been true for about a year now.
[23:03] <lifeless> right
[23:03] <lifeless> launchpad has a vested interest in loggerhead being a solid component, and we're decent folk - we like reusable modules and components
[23:04] <mkanat> lifeless: Yeah, I agree. I just want to be sure that the user experience or configuration experience doesn't degrade for people who aren't LP.
[23:04] <lifeless> I am pretty sure it won't
[23:04] <jam> mkanat: I think Peng is a good test subject
[23:04] <jam> :)
[23:04] <mkanat> jam: Okay. :-)
[23:04] <lifeless> I doubt it will improve without someone interesting it making that *better* stepping up
[23:04] <Erimos_Wolf> I think the plugin doesnt call bazaar in any way. It just reacts with this message. The log shows only the last actions take from the explorer.
[23:04] <lifeless> Peng: yo, around?
[23:04] <lifeless> mkanat: now, for the question of code stabilisation
[23:04] <lifeless> mkanat: you're saying there are three branches?
[23:04] <lifeless> trunk, stable and lp ?
[23:05] <mkanat> lifeless: More or less, yeah.
[23:05] <lifeless> ok
[23:05] <lifeless> so, I think that I'm proposing
[23:05] <lifeless> future, trunk and lp
[23:05] <mkanat> lifeless: That was something we were forced to do because of my limited time.
[23:05] <mkanat> lifeless: Honestly, I think that's just a non-standard terminology change.
[23:05] <mkanat> lifeless: "trunk" should mean "future".
[23:05] <mkanat> lifeless: I don't see the advantage we'd get from renaming it.
[23:06] <mkanat> lifeless: The solution I'd prefer to see is that trunk become stable, then branches for 1.19, and then 1.19 and trunk are both maintained.
[23:06] <mkanat> lifeless: And from that point forward, trunk releases frequently in new stable releases.
[23:06] <lifeless> so, because of limited resources
[23:07] <lifeless> I'd rather not maintain multiple branches
[23:07] <mkanat> lifeless: There are just as many branches as in your solution. In fact, there is one less.
[23:07] <lifeless> in particular, having patches build on history db when its not production ready (whatever that means) is a bit counter productive - we'll end up being essentially forked, which is undesirable
[23:08] <lifeless> mkanat: going forward, after future is integrated, it could be deleted.
[23:08] <lifeless> mkanat: in my proposal
[23:08] <mkanat> lifeless: Oh, that's what I'm talking about doing in any case.
[23:08] <lifeless> I don't have an answer for how future would get integrated
[23:08] <lifeless> so we'd just have trunk and lp
[23:08] <lifeless> with trunk always stable
[23:08] <mkanat> lifeless: Well....
[23:08] <mkanat> lifeless: I think it would be better to have trunk and stable, and lp just runs stable.
[23:09] <mkanat> Or trunk and "current stable branch".
[23:09] <lifeless> what advantage does an unstable trunk offer?
[23:09] <mkanat> lifeless: This is stuff I've already planned out in detail with poolie, quite a bit.
[23:09] <mkanat> lifeless: The advantage is in a stable branch, not in the trunk.
[23:10] <mkanat> lifeless: And I'm sure you already know the advantages of a stable branch, and me explaining them to you would be redundant.
[23:10] <Erimos_Wolf> no ideas?
[23:11] <mkanat> Erimos_Wolf: You might want to ask whoever maintains the Eclipse Bzr integration.
[23:11] <mkanat> Erimos_Wolf: bzr does keep a ~/.bzr.log
[23:11] <Erimos_Wolf> ok, thank you
[23:12] <GaryvdM> Erimos_Wolf: bzr-eclipse is maintained by verterok.
[23:13] <GaryvdM> Erimos_Wolf: bzr-eclipse is probably looking in the wrong directory.
[23:14] <GaryvdM> That might show up in the log if you look at the paths
[23:14] <Erimos_Wolf> the directory for the bzr exe is setup
[23:15] <Erimos_Wolf> I "shared" the project like the tutorial says.
[23:16] <GaryvdM> Erimos_Wolf: maybe you have to add files before you can commit them in bzr-eclipse?
[23:16] <Erimos_Wolf> There was already a "hello world" code
[23:18] <Erimos_Wolf> if i do any changes, the plugin doesnt recognize them. Although the "history" is written correctly
[23:18] <mkanat> lifeless: FWIW, stabilization of trunk would probably just involve some refactoring, writing some tests, and doing some tests to show that everything will work at LP scale.
[23:18] <mkanat> lifeless: "writing some tests" is the longest part of that, probably.
[23:20] <Erimos_Wolf> looks like verterok is not availible, idle for almost 3 hours
[23:36] <GaryvdM> vila: 2.2.3 windows installers are done.
[23:37] <vila> GaryvdM: hmpf ! This time you beat the osx packagers :D
[23:37] <vila> GaryvdM: nice work !
[23:37] <GaryvdM> :)
[23:37] <dOxxx> there was a 2.2.3 release? doh
[23:37] <vila> dOxxx: :D
[23:37] <dOxxx> bah, you cheated. you posted while I was at work. :P
[23:38] <vila> dOxxx: by the way, I'll be on the move tomorrow so I may not be able to build the 10.5 one before.... some days :)
[23:38] <dOxxx> vila: just fixing up the release notes and what's new for my mergetools mp
[23:38] <vila> dOxxx: ok
[23:38] <dOxxx> vila: hmm ok
[23:38] <dOxxx> vila: I think the 10.5 audience is smaller so it's probably not such a bad thing if it's delayed a few days
[23:39] <vila> dOxxx: hmm, but you pushed that already no ?
[23:39] <vila> dOxxx: and as long as it's available when we *announce* (instead of freeze), that's good enough
[23:39] <dOxxx> vila: pushed release notes and then noticed in the diff that I forgot to move what's new
[23:39] <vila> dOxxx: ha, ok
[23:39] <dOxxx> vila: also rewording it a bit
[23:40] <dOxxx> pipeline is cool :)
[23:40] <GaryvdM> dOxxx: Do you think you patch will land in bzr before 2.3 final. If so, I'll push to get the qbzr side in to.
[23:40] <dOxxx> although the handling of conflicts could be a little better. It would be nice if it could pre-populate the commit message, so I would just have to fix the conflicts and commit.
[23:40] <dOxxx> GaryvdM: I doubt it. I'm moving my release notes to 2.4.
[23:41] <GaryvdM> dOxxx: ok
[23:41] <dOxxx> GaryvdM: unless vila has a sudden change of heart ;)
[23:42] <GaryvdM> I've fallen a bit behind on email, so I'm not sure what the status is.
[23:42] <vila> GaryvdM, dOxxx : hehe, let's make it rock in 2.4 instead of trying to shoehorn it in 2.3 :)
[23:42] <dOxxx> yeah
[23:43] <vila> dOxxx: my heart is behind the efforts there, I can assure you
[23:43] <dOxxx> vila: oh for sure, otherwise you wouldn't have stuck with it for so long :)
[23:43] <dOxxx> vila has been slowly weeding the Java OOP out of my mp ;)
[23:48] <dOxxx> vila: okay, all set for review :)
[23:48] <GaryvdM> jam: Do we have any documentation on how to do a bundle of  desolation?
[23:49] <vila> dOxxx: ok, I'll try to review it now (~20 left), if I fail to do that... that will be tomorrow only :-/
[23:49] <jam> GaryvdM: I don't think it is explicitly documented. It is go to the AWS console, and tell it to create a bundle, when that finishes, tell it to create an AMI
[23:49] <dOxxx> vila: sure, no problem. thanks :)
[23:49] <jam> GaryvdM: there *is* doc/developers/ec2.txt
[23:49] <GaryvdM> I tried but I'm getting: NoSuchBucket(404)- The specified bucket does not exist
[23:49] <jam> GaryvdM: what S3 bucket are you trying to bundle into?
[23:50] <jam> do you want me to do it?
[23:50] <GaryvdM> jam: I entered desolation-20110121 for the bucket name. Do I have to create it first?
[23:51] <GaryvdM> jam: I would like to learn.
[23:51] <jam> GaryvdM: no, but you need to set the bucket to ec2.bazaar-vcs.org
[23:51] <GaryvdM> ok let me try that.
[23:51] <vila> dOxxx: approved, well done, I'll pqm it
[23:51] <dOxxx> vila: yay!
[23:51] <jam> GaryvdM: from the web console
[23:51] <jam> right click on the instance
[23:52] <jam> say "bundle"
[23:52] <jam> then S3 bucket name is ec2.bazaar-vcs.org
[23:52] <jam> the S3 Key Name is desolation-20110121
[23:52] <GaryvdM> Ok - and then shut down from rdc
[23:52] <jam> GaryvdM: the bundle request should handle the shutdown
[23:52] <jam> so you don't have to do it manually
[23:53] <jam> (It didn't always work for me from ElasticFox, but it has always worked from the web console for me)
[23:53] <jam> by having "bundle" do it, it will also bring it back up when the bundling is finished, I think
[23:54] <GaryvdM> Ok - so I have to remember to come back and shut it down.
[23:55] <GaryvdM> jam: thanks - it's working now.
[23:55] <jam> GaryvdM: right 3% is the "it isn't shut down yet" but it should progress from there
[23:57] <GaryvdM> Ok - I better go. They lock the gates for the office park at 2am . I might come on line at home.


[04:18] -NickServ(NickServ@services.)- This nickname is owned by someone else
[04:18] -NickServ(NickServ@services.)- If this is your nickname, type /msg NickServ IDENTIFY <password>
[04:18] -ChanServ(ChanServ@services.)- [#ubuntu]  Welcome to #ubuntu! Please read the channel topic and consider spending some time on the FAQ mentioned there
[04:18] -ChanServ(ChanServ@services.)- You do not have channel operator access to [#ubuntu-boot]
[04:18] -ChanServ(ChanServ@services.)- You do not have channel operator access to [#ubuntu-freshers]


[07:14] <soee> good morning
[08:45] <lordievader> Good morning.
[10:04] <_Groo_> good morning
[10:08] <Riddell> hola
[10:09] <apachelogger> yo
[10:09] <apachelogger> neon ppas are no more
[10:10] <tsdgeos> Riddell: you guys planning to update artikulate at any point?
[10:22] <_Groo_> life on the cutting edge is always fun
[10:22] <_Groo_> since kwin didnt compile for amd64, im back to unity :D
[10:23] <_Groo_> i was about to test the new telepathy :( bummer
[10:26] <Riddell> tsdgeos: it's waiting on some dep isn't it?
[10:27] <tsdgeos> i do not know, just asking
[10:28] <Riddell> tsdgeos: oh it was waiting on qt-gstreamer I think which I've now updated so groovy I can sort that in vivid
[10:28] <Riddell> but I had to remove kamoso to make way for it
[10:42] <sgclark> morning
[10:43] <Riddell> hola scarletta
[10:43] <Riddell> tsdgeos: did d_ed send you something for security-preannounce?
[10:43] <Riddell> tsdgeos: oh never mind just found it in my e-mail
[10:45] <Riddell> sgclark: we should work out when and what we're doing for UOS
[10:45] <Riddell> Sick_Rimmit: want to help out too?
[10:46] <sgclark> Riddell: yeah we should
[10:46] <soee> Riddell: ktp-* in staging are all fine ?
[10:46] <Sick_Rimmit> Yes provided the timings work with me, I could do something simple on KDE Activities, or anything else you think
[10:47] <sgclark> Sick_Rimmit: you up for another package?
[10:47] <Sick_Rimmit> sgclark: Yes,but not quite yet, I have libkpeople to update for Utopic, just a few fixes there
[10:48] <Riddell> soee: you tell me, it needs tested :)
[10:49] <Riddell> Sick_Rimmit: libkpeople has a utopic build in staging https://launchpad.net/~kubuntu-ppa/+archive/ubuntu/staging/+packages
[10:49] <_Groo_> soee: i was about to test it when i lost kwin :(
[10:49] <Riddell> although it needs testing
[10:50] <sgclark> Riddell: I will work on k3b today as I promised valorie I would do it yesterday, I can find another package for Sick_Rimmit when he is ready :)
[10:50] <_Groo_> im waiting for the kubuntu-ci to do is thing so i can get back to my bleeding edge beloved kde
[10:50] <Sick_Rimmit> Riddell: I got some issues from you, which I thought needed fixing, is that no so
[10:50] <soee> ill try to do an upgrade than
[10:52] <sgclark> Riddell: also I think you need to fix you script, ECM was missed again yesterday lol
[10:53] <Riddell> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=kubuntu-packaging  grantlee (twice), digikam, gtk2-engines-oxygen (and gtk3 I guess), phonon. take your pick :)
[10:53] <Riddell> sgclark: well spotted on there, my bad indeed
[10:56] <soee> Riddell: http://paste.ubuntu.com/8834058/
[10:57] <soee> oh wait it should be dist-upgrade (full-upgrade) isnt it ?
[10:58] <Riddell> soee: yep  apt full-upgrade
[11:00] <Riddell> sgclark, Sick_Rimmit: I can do a session this evening, tomorrow evening I'm out
[11:00] <soee> Riddell: kpeople fails http://paste.ubuntu.com/8834085/
[11:00] <Riddell> sgclark, Sick_Rimmit: does 18:00UTC work?
[11:00] <Riddell> soee: ooh interesting
[11:01] <Riddell> soee:   dpkg --force-overwrite /var/cache/apt/archives/kde-telepathy-kpeople_0.9.0-0ubuntu1~ubuntu14.10~ppa2_amd64.deb  should fix it, does that show any more overlapping files?
[11:01] <Riddell> s/fix/workaround/
[11:01] <kubotu> Riddell meant: "soee:   dpkg --force-overwrite /var/cache/apt/archives/kde-telepathy-kpeople_0.9.0-0ubuntu1~ubuntu14.10~ppa2_amd64.deb  should workaround it, does that show any more overlapping files?"
[11:01] <sgclark> Riddell: umm you are out for my devel tests????
[11:01] <Riddell> sgclark: when is that?
[11:01]  * sgclark cries
[11:02] <Riddell> sgclark: there's nothing on the schedule! http://summit.ubuntu.com/uos-1411/2014-11-13/
[11:03] <soee> Riddell: http://paste.ubuntu.com/8834131/
[11:03] <sgclark> Riddell: tomorrow is my kubuntu-devel test . the summit is on the 13th no?
[11:03]  * sgclark is confused
[11:03] <soee> brb in 30 min
[11:04] <Riddell> sgclark: it's today, tomorrow and friday.  but there's nothing on any schedule
[11:05] <sgclark> what?!?! they gave me 2 days to set it up??
[11:05] <sgclark> that is not cool
[11:06] <Riddell> sgclark: oh hang on...
[11:06] <Riddell> sgclark: the dates changed, my calendar is all wrong!
[11:06] <sgclark> Riddell:
[11:06] <sgclark> Starts: Wed, 12 Nov 2014 14:00:00 UTC
[11:06] <sgclark> Ends: Fri, 14 Nov 2014 19:55:00 UTC
[11:06] <sgclark> hah
[11:07] <Riddell> and just to confuse me the schedule has today's date and not the date of the day it's showing on it http://summit.ubuntu.com/uos-1411/2014-11-13/
[11:07] <sgclark> but on a serious note.. you marked available for my tests and I am not going to do it without you there... are you now not available tomorrow?
[11:08] <Riddell> sgclark: what time did you decide on?
[11:08] <Riddell> I did say to a friend yesterday I'd go out for a cycle ride tomorrow evening
[11:09] <sgclark> Riddell:
[11:09] <sgclark> By Popular demand the meeting will take place Thursday 9:00 PM UTC
[11:09] <sgclark> 1:00PM(my time)
[11:09] <sgclark> as sent to the devel list..
[11:09] <Riddell> which seems to be at 19:00UTC
[11:10] <Riddell> right so I need to work out if it'll get back before 21:00UTC
[11:10] <Riddell> but that's my problem not yours :)
[11:10] <sgclark> well yes it is. I wnt you there
[11:11] <Riddell> worry not, I'll work it out
[11:11] <sgclark> your my confidence haha
[11:11] <sgclark> thanks
[11:12] <Riddell> but same thing next week, I'm busy thursday from 17:00UTC but free wednesday and friday any time
[11:13] <sgclark> Ok, Sick_Rimmit which is better for you Wed or Fri for the summit? and I need you LP id to add you to the blueprint
[11:24] <Sick_Rimmit> sgclark: Prefer Weds
[11:24] <sgclark> ok. LP name?
[11:25] <sgclark> launchpad id
[11:26] <sgclark> Sick_Rimmit: ^
[11:27] <Sick_Rimmit> sgclark: LP is rick-timmis
[11:34] <sgclark> Riddell: does this fall under users or community? (UOS)
[11:37] <Riddell> sgclark: um, I've no idea what the difference is
[11:38] <sgclark> hah me either
[11:39] <apachelogger> sgclark: shadeslayer wants to talk about kci he said
[11:39] <sgclark> ?
[11:39] <sgclark> at UOS?
[11:39] <shadeslayer> what no
[11:39] <shadeslayer> apachelogger is supposed to talk about KCI
[11:40] <shadeslayer> actually
[11:40] <shadeslayer> let me schedule that session for you
[11:40] <sgclark> KCI?
[11:40] <shadeslayer> http://kci.pangea.pub/
[11:40] <shadeslayer> the thing that's all red
[11:41] <sgclark> oh our ci system, gosh I need more coffee
[11:41] <Riddell> dunno if it's worth having more than one session for Kubuntu
[11:41] <Riddell> I don't know if there's an audience for these or not
[11:42] <apachelogger> no one reads my mails, so shadeslayer might as well do a session :P
[11:42] <sgclark> umm
[11:42] <shadeslayer> I do read your emails
[11:42] <sgclark> I do too
[11:42]  * sgclark looks
[11:42]  * shadeslayer just doesn't have anything to say
[11:42] <_Groo_> and all the girls say im pretty fly.. for a wifi!!! best SSID EVER!
[11:43] <_Groo_> ppl at work are very creative :P
[11:43]  * apachelogger doesn't get it
[11:43]  * sgclark doesn't either
[11:45] <Riddell> that is amusing
[11:45] <Riddell> it's a pun or play on words on a song
[11:46] <sgclark> apachelogger: I cannot find any mails from you in regards to kci and uos. But I really think it would fit in our plasma5 session as we use it for plasma5
[11:58] <Riddell> sgclark: yep book them both in to present a bit on the same session
[11:58] <sgclark> ok
[12:00] <sgclark> apachelogger: shadeslayer: Is Wed (next week) ok for both of you for UOS
[12:01] <shadeslayer> I'm not talking about KCI
[12:01] <shadeslayer> since I know very little about it :P
[12:01]  * sgclark sighs
[12:01] <shadeslayer> Harald is
[12:09] <soee> back, Riddell so any thoughts @ http://paste.ubuntu.com/8834131/ ?
[12:11] <Riddell> soee: should be fine,  then  apt -f install  to tidy up
[12:12] <Riddell> soee: but actually I uploaded a fix
[12:12] <Riddell> so you can just apt update and full-upgrade again
[12:20] <soee> Riddell: ok seems to work just fine now, thanks :)
[12:22] <Riddell> soee: yay, what did you do?
[12:23] <soee> Riddell: just update & full-upgrade again
[12:24] <soee> so the fix you uploaded solved teh issue
[12:26] <Riddell> awooga
[12:26] <BluesKaj> Hiyas all
[12:26] <Riddell> soee: now does it all run and enable you to chit chat?
[12:26] <soee> Riddell: brb have to reboot
[12:33] <soee> hmm i did configured google talk account in kde-telepathy but there was a typo in email, now i don't know how to change the conmfiguraion, i have no menu panel in the window
[12:36] <Riddell> soee: icon on toolbar right -> Instant messenger setttings
[12:39] <_Groo_> soee: or use gnome empathy to change it... they share the config
[12:40] <_Groo_> what is the cicle window for kubuntu-ci? i cant use kde today because kwin package didnt compile cleanly :(
[12:42] <soee> Riddell: the scroll right arrow ?
[12:43] <soee> it is inactive, i can't do nothing with it
[12:48] <santa_> yofel: thank you very much again for pointing me to the status page code, I have modified it a bit for siduction's kdenext
[12:49] <santa_> I have been dreaming for a while to finally get something like that
[12:49] <santa_> http://gpul.grupos.udc.es/kdenext_status/
[13:04]  * Riddell publishes http://www.kubuntu.org/news/kde-telepathy-0.9
[13:11]  * sgclark shares
[13:16] <soee> sgclark: do you have ktp installed ?
[13:16] <sgclark> nah, not much of a chatter haha
[13:20] <sgclark> soee: why? does it need testing or something?
[13:30] <_Groo_> soee: i do, i just need kwin now :D
[13:31] <_Groo_> soee: more seriously what do you need?
[13:37] <apachelogger> does anyone fancy packaging something from scratch?
[13:38] <sgclark> apachelogger: depnds how fast you need it done, I have a rather huge to-do list already
[13:38] <Riddell> apachelogger: Sick_Rimmit needs stuff to get his claws into
[13:39] <Sick_Rimmit> apachelogger: Sure, but not immediately as I'm at work.
[13:39] <apachelogger> Sick_Rimmit: http://quickgit.kde.org/?p=libkeduvocdocument.git
[13:40] <apachelogger> not super urgent
[13:40] <Riddell> apachelogger: what's that for?
[13:41] <Riddell> does it have a releae?
[13:41] <apachelogger> going to be released in the 14.12 apps release
[13:41] <apachelogger> needed for kanagram, khangman and parley
[13:42] <soee> sgclark: _Groo_i would liek to know how to open app settings :)
[13:42] <apachelogger> apparently it was split out of libkdeedu somehow, so maybe one could salvage packaging from there, although doing it from scratch likely would be faster
[13:45] <soee> gusy this is all i have when i open it: http://wstaw.org/w/31KB/
[13:47] <soee> lol :)
[13:48] <soee> this is some kind of bug, the Right icon does not work, but if i resize widnow, i can see the icon to open menu ...
[13:48] <Riddell> mitya57: qt4-x11 uploaded
[13:51] <soee> ok i have it working now :)
[14:05] <BluesKaj> how is plasma 5/kf5 behaving these days soee?
[14:05] <soee> BluesKaj: no changes for me - works fine as always :) Plasma 5.1.1 should be released soonish
[14:06] <BluesKaj> ok soee, thanks
[14:37] <Quintasan> Riddell: Is there any list of stuff to be merged in universe?
[14:38] <Riddell> Quintasan: why yes :) https://merges.ubuntu.com/universe.html
[14:39] <Quintasan> Oh.
[14:39] <Quintasan> I though we have some Kubuntu specific list
[14:40] <Riddell> Quintasan: just search for everything that says Riddell and do that first :)
[14:40] <Quintasan> Mmkay.
[14:41] <Riddell> gosh a good chunk of that list is kubuntu staff
[14:41] <Riddell> stuff
[14:41] <Riddell> I wonder if that's a good sign or not
[14:41] <Riddell> I woudn't bother with anything in KDE SC, we'll do that when KDE Appliacations gets released
[14:44] <soee> Riddell: and when the release og KDE Applications is planed ?
[14:46] <Riddell> soee: beta 1 tagging today says https://techbase.kde.org/Schedules/Applications/14.12_Release_Schedule
[14:50] <Quintasan> Riddell: Can you add me to 15.04 board?
[14:50] <soee> :O
[14:51] <Riddell> Quintasan: done! welcome home Quintasan
[14:51] <Quintasan> Splendid
[14:54] <Quintasan> wow
[14:54] <Quintasan> neat
[14:55] <Quintasan> I really need to start hanging around here more
[15:04] <Riddell> we're cooler than a cafe con heilio
[15:29] <Riddell> hola bukai
[15:31] <bukai> Riddell: ping
[15:32] <Riddell> bukai: you pung?
[15:32] <Riddell> Quintasan: gtk2-engines-oxygen is also a new upstream release as well as a merge
[15:32] <Riddell> Quintasan: bug 1385316
[15:32] <Quintasan> Yeah, I realised that.
[15:32] <Riddell> Quintasan: oh also you could look into if we should build it with the gtk dependency for the test app
[15:33] <Riddell> Quintasan: we ship gtk on the images now so there's probably no reason why not
[15:33] <Riddell> and of course there's the gtk3 version of the same
[15:33] <bukai> Riddell: yes, How will i get the images? shall I send a mail to kubuntu-devel?
[15:34] <Quintasan> Riddell: What is the test app?
[15:34] <shadeslayer> Riddell: python -m SimpleHTTPServer
[15:35] <Riddell> shadeslayer: <IP_ADDRESS>:8000
[15:36] <Riddell> Quintasan: it's a gtk binary that you can run from the kcm to show the settings you have set
[15:37] <Riddell> Quintasan: I disabled it because I didn't want gtk on the cdimages but we have that anyway so I guess there's no point in being so pure for no gain
[15:37] <Riddell> Quintasan: it should just be a settings in debian/rules
[15:39] <shadeslayer> Riddell: dcmd cp path/to/*/*.changes upload/
[15:39] <shadeslayer> and then make the upload dir available via python
[15:41] <Riddell> shadeslayer: <IP_ADDRESS>:8000 up
[15:51] <Riddell> bukai_: images of what?
[15:53] <bukai_> Riddell: the blog images. BTW I came across this webpage recently , http://www.gewest13.nl/nl/home , Is this theme better than the previous one?
[15:54] <Riddell> bukai_: well we don't have blog images, that's the issue I was pointing out, they'd need to be made
[15:55] <Riddell> http://www.gewest13.nl/nl/werk also looks very bling
[15:55] <Riddell> interesting how the first use of <video> I see in the wild is as background images
[15:57] <Riddell> bukai_: well yes that design also looks good and I guess lets you have 1 most important message rather than lots of messages on your other design
[15:57] <Riddell> bug again same issue of finding or making nice artwork
[15:58] <sgclark> I don't think we could come up with that many images lol
[16:00] <bukai_> sgclark: You can give any image to resemble your blog.
[16:00] <Riddell> lots of new plasma 5 bits in here! https://launchpad.net/ubuntu/vivid/+queue
[16:01] <sgclark> nice
[16:02] <Quintasan> Riddell: Alright, let me look into it.
[16:02] <bukai_> Riddell: I find this theme more applicable for us compared to the last one as the content is not too much and it's static as you mentioned earlier.
[16:05] <Riddell> bukai_: yes i agree
[16:05] <sgclark> it would be ok if we had images for every blog post , but we don't
[16:05] <Riddell> bukai_: worth checking how it looks in rekonq and konqueror, would be a bit embarracing to have a website that doesn't work on KDE's browsers
[16:05] <sgclark> I don't see how it would fit for us, but that is my opinion
[16:06] <Quintasan> hm
[16:06] <Quintasan> The only thing in rules is -DDEBIAN_NO_DEMOS=1 but I do not think this is the switch we want so I guess it's enabled
[16:07] <Quintasan> I kept Noskcaj's Fix dh_shlibdeps to exclude libgtk2.0-0 from Depends change but that's all
[16:08] <Riddell> Quintasan: yes that's the switch we want
[16:09] <Quintasan> Right.
[16:10] <Riddell> Quintasan: hmm actually maybe it's not
[16:11] <Quintasan> If there is any binary then we'd probably have to get rid of the shlibs magic as well.
[16:11] <Quintasan> Lemme test build it
[16:11] <Riddell> Quintasan: I know, I'm thinking of the wrong package
[16:11] <Riddell> I'm thinking of kde-config-gtk-style
[16:12] <Riddell> which interacts with this but isn't the same thing
[16:16] <mitya57> Riddell, thanks, and armhf build (mostly) finished (though with lots of warnings about<EMAIL_ADDRESS>[16:16] <Riddell> and I say aeabi_atexit back to armhf
[16:18] <bukai_> Riddell: konqueror is not supporting the video aspect. We can you a slider instead. Apart from that it's  working fine.
[16:24] <Riddell> bukai_: lovely
[16:28] <Quintasan> pbuilder y u no preload eatmydata
[16:29] <Riddell> ?
[16:29] <Riddell> dunno what eatmydata is but it doesn't sound like something I want to load
[16:29] <sgclark> lol
[16:29] <Quintasan> Riddell: a library that disables fsync and friends
[16:30] <Quintasan> I used it in my pbuilders so it installs stuff faster
[16:31] <Quintasan> ...
[16:32] <Quintasan> They removed the so in newer version
[16:32] <debfx> Quintasan: echo 'force-unsafe-io' > /etc/dpkg/dpkg.cfg.d/unsafe-io
[16:32] <debfx> should do the same
[16:33] <Quintasan> debfx: I'd disables it for dpkg only, disabling it chroot wide should be faster theoretically.
[16:33] <Quintasan> Not that I'm going to benchmark this
[16:34] <debfx> I doubt anything in a typical build will call fsync, testsuites maybe
[16:37] <Quintasan> eh, there are more problems getting it to work now than forcing unsafe-io
[17:16] <Quintasan> Riddell: gtk2-engines-oxygen 1.4.6 uploaded
[17:18] <Riddell> Quintasan: awooga!
[17:19] <Quintasan> This UDD stuff is neat but I'm still not sure if I'm doing it right
[17:19] <Riddell> oh I don't use UDD
[17:19]  * Quintasan decided to look for new tools before doing stuff how he used to.
[17:19] <Riddell> full sources in packaging branches seems nuts to me
[17:20] <Quintasan> I'm still not sure what the hell am I supposed to do with the final commit
[17:20] <Quintasan> Should I push it or upload the changes or wtf
[17:24] <Riddell> you need to upload, you can push if you want
[17:24] <Quintasan> Hmm.
[17:24] <Quintasan> I'll just upload.
[17:47] <Quintasan> Riddell: To get package from -proposed to vivid one still has to have archive admin accept it or there are some tests done and it's accepted automagically?
[17:49] <Riddell> Quintasan: it compiles then if it installs everywhere it installed before it gets accepted magically
[17:49] <Quintasan> Splendid.
[17:49] <Riddell> check http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html if it doesn't get accepted
[17:49]  * Quintasan gets onto something else.
[17:49] <Riddell> although that's hard to read, but the reasons are that it failes on an arch it succeeded before, it doesn't install or some autopkgtests fail
[17:50] <Riddell> autopkgtest being a newish way to add automated tests to applications
[17:50] <Riddell> to packages rather
[17:50] <Riddell> Quintasan: now you're back you should come to Munich later in the month
[17:51] <Quintasan> Riddell: Well, I'm not back per se but I'm finally having some free time
[17:51] <Quintasan> I just need to shake some people off my back.
[17:51] <Riddell> :)
[17:53] <Quintasan> If I get this PHP and ASP.NET crap done I should have Thursdays and Fridays free.
[18:08] <Riddell> groovy, plasma 5 and KDE SC 4.14.2 and KF 5.4.0 well on their way
[18:08] <Riddell> KF 5.4 still needs some poking in ninjas
[18:09] <Riddell> KDE Applications 14.12 beta due by tomorrow
[18:09] <Riddell> and I've to tag Plasma 5.1.1
[18:10] <Riddell> lovely, time to wander off for the day
[18:10] <shadeslayer> Riddell: cya
[18:11]  * shadeslayer bangs head against sbuild meanwhile
[19:40] <murthy> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1389847