[02:07] <detrate> ScottL: http://www.xonotic.org/blog/ << I created this over the weekend
[02:24] <ScottL> detrate, did you create the whole thing or just the blog part?
[02:24] <ScottL> it looks good though :)
[02:25] <ScottL> i like how the social media is off the side and not taking up valuable real estate
[02:30] <detrate> the entire site
[02:31] <detrate> with [some] integration to the forums
[02:31] <detrate> it will evolve and connect more in time
[02:31] <detrate> but it's integrated with the main social media sites and has great SEO / easy to use backend
[02:32] <detrate> it's going to serve well to communicate information about the project, both giving and reciving.  I want to do the same for ubuntu studio :)
[02:57] <ScottL> that would be absolutely awesome!
[04:34] <ScottL> detrate, i've been thinking that a introductory video of ubuntu studio is really needed for the new website home page
[04:35] <ScottL> i'm not good at making movies, but maybe we can find someone...maybe i'll find time to post at ubuntu forums about it
[04:35] <detrate> that's a good idea
[04:36] <detrate> usually, name, video, tag line, mission statement and screenshots are good for the front page
[04:36] <detrate> and share icons, newsletter
[04:37] <ScottL> i really am pretty excited about all this, we are really making some significant progress (in a holistic sense)
[04:37] <ScottL> you with the website, knocking out some bugs, dealing with jack<->pulseaudio
[04:38] <ScottL> oh, jack in the main
[04:38] <detrate> yeah, organization in key
[04:38] <detrate> is*
[04:38] <ScottL> if we could get someone who knows art to knock up a new theme, icon set, etc, that'd be ace
[04:39] <ScottL> it would be great if cory could come back...at least as art lead
[04:39] <detrate> I can do dark themes but I request the inclusion of gnome-color chooser
[04:39] <ScottL> i don't even know what gnome-color chooser is   :0   LOL
[04:40] <ScottL> is it the one where you pick something and it tells you which color it is?
[04:41] <ScottL> a theme around heavy metal music would be my personal inclination, not with pictures of rock'n roll peoples, just that kind of colors, theme
[04:41] <detrate> gnome-color-chooser is an advanced color schemer for gnome
[04:41] <ScottL> i thought about redoing the 'human' icon set, but make it dark with some ubuntu studio blue and call it 'dead human' icon set :)
[04:41] <detrate> http://gnomecc.sourceforge.net/
[04:42] <detrate> gnome-colors man
[04:42] <detrate> that's where the sweetness is at
[04:42] <detrate> http://gnome-look.org/content/show.php/gnome-colors?content=82562
[04:42] <ScottL> it is in the repos yet?
[04:42] <detrate> which?
[04:42] <detrate> I'm talking about two things
[04:42] <detrate> gnome-color-chooser, yes
[04:43] <detrate> gnome-colors... (icon set) not sure
[04:44] <ScottL> gnome-color-chooser
[04:45] <ScottL> sorry, saw the answer after i typed the question
[04:46] <ScottL> adding gnome-color-chooser would be easy, just add it to the seeds :)
[04:48] <ScottL> oh vey, i'm tired, got up way too early and did way too much outside with the kids today, off to bed for me
[04:48] <ScottL> g'night detrate
[05:16] <stochastic> detrate, you still around?
[05:22] <stochastic> detrate, I'd love to really discuss the website with you.  I've already approached the server admins at canonical and learnt very much about what will and won't work (i.e. what's worth our time, and what's not) on a web revamp.  Let's talk.
[05:26] <detrate> I'm heading to sleep but can you give me a summary?
[05:26] <detrate> will they allow wordpress?
[05:41] <stochastic> detrate, maybe but the system is currently running on drupal and ALL underlying changes (i.e. non-cosmetic) will need to be audited and approved by the security council
[05:42] <stochastic> I'm familiar enough with drupal that I don't think switching to wordpress is needed or worth it
[05:43] <stochastic> I'm happy to help enough that it shouldn't be needed
[05:44] <stochastic> p.s. poke me with my name next time and I'll respond faster
[12:58] <quadrispro> ScottL, ping
[13:14] <scott-work> quadripspro: once the maverick alpha iso is released and i test lv2rack/zynjacku i was going to mark the zynjacku/lv2jack bug as 'fix released'
[13:15] <scott-work> and thanks for archiving the REVU for zynjacku, i was wondering how to do that but was deferring it until maverick alpha iso as well
[13:20] <scott-work> quadrispro: way to go on lv2vocoder, i might have to grab the deb or source from debian and try this out on my testing parition :)
[13:21] <quadrispro> good :)
[13:21] <quadrispro> scott-work, could you help improving lv2vocoder description?
[13:21] <scott-work> seriously, i'm doing a ubuntu studio presentation this weekend and lv2vocoder could make a *HUGE* impact along with rakarrack
[13:21] <quadrispro> sure, vocoders always have great impacts :)
[13:22] <scott-work> quadrispro: absolutely, it probably will be in a few days though as i have several things in my queue that are "almost" finished and i really want to clear them off my todo list
[13:22] <quadrispro> scott-work, take your time, do you already have an account on alioth?
[13:23] <scott-work> no, that's further down on my list :)
[13:23] <quadrispro> scott-work, please get one, so would be able to do lots of cool things :)
[13:24] <quadrispro> like becoming a member of debian multimedia
[13:24] <quadrispro> pushing to git repo etc
[13:24] <quadrispro> :)
[13:24] <scott-work> i like cool things :)  i will do it
[13:25] <scott-work> i find that i manage things better if i keep a list and more or less follow it, because if not i forget things or skip things and then never come back to them
[13:25] <scott-work> and if it's worth putting on the list then i feel like it's worth doing :P
[13:25] <scott-work> but, i'm really about to clear several items off during this week
[13:26] <quadrispro> scott-work, I tried many times to maintain a kind of TODO list, but I always lost them :/
[13:27] <quadrispro> scott-work, BTW, maverick will be a release with a lot of great multimedia-related stuff
[13:27] <scott-work> quadrispro: i have also bookmarked both of the links you gave us earlier about debian multimedia and the launchpad team, i really do plan on joining :)
[13:27] <quadrispro> I'm happy to hear that :)
[13:27] <scott-work> quadrispro: i hope so (greate multimedia-related stuff) and i hope it works well
[13:27] <quadrispro> yes, indeed we need a lot of testing
[13:28] <quadrispro> more stuff = more testing
[13:28] <scott-work> quadrispro: i've been meaning to ask, for the lv2 stuff, are you using that matrix to keep up with what you are doing?
[13:28] <scott-work> what i mean is, is that the best place to find out what is working or already in debian?
[13:29] <quadrispro> scott-work, for now I'm using that matrix and (again, for now) is not a wrong place.
[13:30] <scott-work> good :)
[13:30] <scott-work> i wanted to have an idea for moderating the menu entries in ubuntustudio-menu
[13:31] <quadrispro> maybe in the future, when lv2 plugins number raises, we would need to find a better platform
[13:31] <scott-work> because of the sub-menu all the new applications will be under 'sound & video' originally instead of 'audio production'
[13:31] <quadrispro> mmm
[13:32] <scott-work> i've talked a little with persia about it before, he seemed to be against making gross changes to the menus that create a bigger delta from the desktop standards
[13:33] <scott-work> the freedesktop standards seem to be tailored for a generic desktop, and more than a little unwieldy for a multimedia distro
[13:33] <quadrispro> yes, but there are a lot of sub-categories..
[13:35] <quadrispro> I know the standards but I don't know much about how to manage this kind of things...
[13:35] <scott-work> also, we may need to prod some people in REVU (or possibly out of REVU) to get the packages falktx submitted pushed through and into the repositories
[13:36] <quadrispro> can you mail me the URL?  I have to leave now
[13:36] <scott-work> re: standards and menu - i *think* persia's main complaint was that the standards exist and should be used OR fix the standards, don't just jimmy around and hack a solution rather than fix the problem
[13:36] <scott-work> certainly
[13:37] <scott-work> do you have a preferred email quadrispro , i can get several from your wiki pages
[13:38] <quadrispro> scott-work, LOL you're right
[13:38] <quadrispro> i have too many mail address
[13:38] <scott-work> is gmail account okay?
[13:38] <quadrispro> but let's use my *new* mail address
[13:38] <quadrispro><EMAIL_ADDRESS>[13:38] <scott-work> oooohhhh, sweet!   i'm jealous :)
[13:39] <quadrispro> scott-work, please don't use gmail address, I've set some rules based on the recipient address
[13:39] <quadrispro> scott-work, eh eh eh, fresh DD, just from yesterday
[13:39] <scott-work> CONGRATULATIONS!  that is uber sweet
[13:39] <quadrispro> :)
[13:40] <quadrispro> scott-work, leaving, see you later! :)
[13:40] <scott-work> bye, email sent also
[14:16] <scott-work> in opensourcemusicians we were discussing setting up jack and a thought occured to me
[14:16] <scott-work> the standard setting that come in jack with a new isntall is pretty cappy, even for onboard audio
[14:17] <scott-work> i wonder if we could change those settings to something a little more "sane"
[14:17] <scott-work> this might cover a lot of the "it should work out of the box" complaints
[14:55] <falktx> howdy all!
[15:30] <scott-work> hi falktx  :)
[15:30] <falktx> hi scott
[16:02] <rlameiro> scott-work: do you have the link for the LAC talks video/audio?
[16:03] <scott-work> rlameiro: http://lac.linuxaudio.org/2010/recordings/day1_1400_Pro_Audio_is_Easy_Consumer_Audio_is_Hard.ogv
[16:04] <scott-work> that is what i had, you can probably get some other stuff from there as well :)
[16:05] <rlameiro> thanks scott-work
[16:06] <rlameiro> scott-work: i set the !571368 to invalid
[16:09] <rlameiro> !571368
[16:10] <rlameiro> bug  !571368
[18:14] <scott-work> #571368
[18:14] <scott-work> bug #571368
[18:14] <scott-work> rlameiro: yeah, i saw that, it looks like it was as i suggested earlier in the bug
[18:15] <scott-work> it actually turned out pretty good because he was sort of arrogant about his bug and i wanted to show him it wasn't ubuntu studio so it forced me to actually use Rosegarden for the first time
[18:15] <scott-work> now i want to use it more :)
[18:26] <falktx> scott-work: ardour 2.8.8 is out
[18:27] <falktx> scott-work: is the mute patch there?
[18:27] <falktx> scott-work: or you don't know?
[18:27] <scott-work> ohhh, i don't know, i'll have to look :)
[18:28] <falktx> scott-work: did you create a bug inthe ardour tracker?
[18:28] <scott-work> there was one already there...hold on, i can get it quick
[18:28] <scott-work> http://tracker.ardour.org/view.php?id=2832
[18:29] <scott-work> looks like rlameiro posted there as well
[18:30] <falktx> i'm not sure if the patch get applied
[18:33] <scott-work> reading the release notes it doesn't look it falktx
[18:33] <falktx> then we'll  have to patch it again
[18:33] <falktx> i'll be back tomorrow
[18:33] <falktx> see ya!
[19:36] <detrate-> yeah... so sans wordpress... I don't really have a drop in solution for you guys
[19:36] <detrate-> my friend is still working on a design
[19:36] <detrate-> which I can slice and pass off to someone else more familiar with drupal
[19:36] <detrate-> but I do not have the time to dedicate to building a drupal site from the ground up
[19:37] <detrate-> especially with tight restrictions coming from the top


[00:25] <poolie> hi all
[00:25] <mgz> hey poolie.
[00:30] <poolie> hi there
[00:31] <poolie> i'm working a bit today on a plan to bring bzr-colo into core
[00:34] <jelmer> 'morning spiv, poolie
[00:34] <jelmer> 'evening maxb, mgz
[00:34]  * jelmer wonders what part of the day fullermd is in
[00:34] <mgz> jelmer, have you filed a bug against launchpad yet to enable projects to remove certain states from the drop down box yet? :)
[00:35] <jelmer> mgz: I think it'd be closed as "Won't Fix" :)
[00:36] <poolie> hi jelmer
[00:36] <poolie> mgz: certain bug states?
[00:36] <poolie> which ones do you want to remove?
[00:37]  * fullermd doesn't know himself anymore   :|
[00:37] <mgz> poolie: I'm winding jelmer up a little, he's forgotten bzr doesn't use 'Triaged' a few times. :)
[00:43] <mgz> okay, now I need sleep.
[00:51] <poolie> ah
[00:51] <poolie> in that particular case i think we'd be better off removing triaged altogether
[00:53] <maxb> On the other hand, the distinction between confirmed and triaged is rather vital if a project wants to separate user confirmations and "has had developer attention"
[01:00] <aroman> how can bzr have a conflict with a file that doesn't exist?
[01:04] <mwhudson> if you delete a file, and the branch you merge from changes it, that sounds like a conflict to me
[01:06] <poolie> that's right
[04:43] <leo2007> If I have 2 commits in my local bzr branch and the parent has new commits, what happens if I do a 'bzr up'?
[04:44] <spiv> The 2 local commits become a pending merge.
[04:44] <spiv> Which you then need to commit.
[04:48] <poolie> hi spiv
[04:48] <poolie> spiv, have you used bzr-colo yet?
[04:50] <leo2007> spiv: thanks.
[04:51] <leo2007> why 'bzr up' always report I am up-to-date when in fact there are 9 new commits from parent?
[04:56] <poolie> leo2007, if it's a separate branch you may need to pull or merge them.
[04:59] <spiv> poolie: no, I haven't
[05:01] <leo2007> poolie: pull says conflicts. But merge will not place my local revs on top of the remote parents, right?
[05:01] <poolie> leo2007, are these separate branches, or is your local branch a checkout of trunk?
[05:02] <poolie> spiv, how do you manage your branches?
[05:02] <poolie> just separate trees within a shared repo?
[05:02] <leo2007> poolie: a checkout.
[05:04] <poolie> leo2007, what does 'bzr info' show?
[05:05] <leo2007> poolie: http://paste.pocoo.org/show/lGSnxK33ZSi6vAKxlWmq
[05:05] <poolie> when you say '9 new commits from parent' where do you see that? by separately running 'bzr log' on the parent?
[05:06] <leo2007> poolie: from 'bzr missing'
[05:06] <poolie> leo2007, this looks like just a regular standalone branch then
[05:06] <poolie> you're trying to bring the latest stuff from trunk into your branch, and then continue with development of your branch?
[05:07] <leo2007> yeah, and my branch has two commits.
[05:07] <leo2007> two extra*
[05:08] <poolie> ok, so you should probably just merge trunk
[05:08] <poolie> your own revisions will still be visible in history, but they won't be on top of it
[05:08] <spiv> poolie: yes, exactly that layout
[05:08] <poolie> if you want to rewrite history so it looks like they were done after what is now on trunk, use bzr-rewrite
[05:09] <leo2007> poolie: I also need to push my commits to trunk at some time later.
[05:10] <poolie> ok
[05:10] <poolie> but not right now?
[05:24] <leo2007> poolie: no, not right now.
[05:25] <leo2007> I basically want to pull from upstream compile and submit my commits.
[05:25] <leo2007> I am familiar with git but not bzr.
[05:25] <poolie> spiv, when you get a chance could you install it and have a play
[05:26] <poolie> leo2007, ok, the typical bzr thing would just be to merge from trunk, resolve any conflicts, compile and test, then send up your changes
[05:26] <leo2007> would that mean my branch having different history than upstream?
[05:27] <poolie> well, your branch is going to show you did some work, then you merged trunk and resolved conflicts
[05:27] <poolie> which is accuarte
[05:27] <poolie> when trunk merges from you, all the history will be accurate
[05:28] <leo2007> Is it possible to push an individual commit to upstream? In my case, I have two new commits locally, one is more mature and the other is waiting for confirmation before submitting.
[05:30] <poolie> when you say 'push' do you mean actual bzr push direct into trunk?
[05:30] <poolie> do you have access to write to trunk?
[05:30] <poolie> or just to submit for someone else to review?
[05:31] <leo2007> poolie: I have write access.
[05:34] <lifeless> spiv: hi, re bug 739144 - making it critical is fine; please don't set to confirmed though - if you've triaged it, set it to triaged.
[05:36] <poolie> leo2007, perhaps the cleanest/easiest thing is to make a new branch off trunk to integrate your work
[05:37] <poolie> do a 'bzr merge -r whatever' from your branch into that
[05:37] <poolie> then push that back up
[05:38] <leo2007> poolie: is it possible to export a commit to a file which I can then put back in easily? something like git format-patch and am?
[05:39] <leo2007> I am thinking since I have only two commits for now. I could save them to a file and drop them in my local branch. Sync my branch and put them back.
[05:39] <poolie> 'bzr send -o FILE'
[05:39] <leo2007> that would appear solve all my questions.
[05:40] <poolie> or perhaps 'bzr shelve' is a better idea
[05:40] <poolie> or, if you have only two, just uncommit, shelve, pull, then unshelve
[05:45] <leo2007> poolie: bzr: ERROR: Operation denied because it would change the main history, which is not permitted by the append_revisions_only setting on branch "/Users/Shared/sources/EmacsBZR/trunk/".
[05:46] <spiv> lifeless: ah, ok.  Thanks for the correction.
[05:49] <poolie> leo2007, ok, in that case you will need to make a new checkout of trunk trunk, merge your work, then commit
[05:50] <lifeless> spiv: you may not have read https://dev.launchpad.net/BugTriage in a while - its been refreshed
[05:52] <spiv> lifeless: I haven't read it in detail, no, although I did skim it to check that I wasn't being too outrageous in choosing Critical
[05:53] <spiv> lifeless: I just didn't think at all about Confirmed vs. Triaged because I'm totally out of the habit of ever considering Triaged :)
[05:53] <lifeless> :)
[05:53] <spiv> jelmer of course is having the opposite problem these days :)
[05:55] <leo2007> poolie: I changed branch.conf and go ahead with uncommit.
[05:55] <poolie> just curious, what change did you make?
[05:56] <leo2007> poolie: append_revisions_only = False
[05:56] <poolie> lifeless, how about you, did you ever use bzr-colo
[05:56] <poolie> oh, for the real emacs trunk?
[05:56] <poolie> that might make other people unhappy
[05:56] <leo2007> poolie: my branch
[06:06] <leo2007> poolie: could you recommend some good docs for using bzr?
[06:06] <poolie> well, mostly the current version under doc.bazaar.canonical.com
[06:06] <poolie> i know emacs also have some special conventions that i think are on their wiki
[06:07] <poolie> i would also really recommend using bzr-colo with bzr
[06:07] <poolie> from
[06:07] <poolie> http://doc.bazaar.canonical.com/plugins/en/colo-plugin.html
[06:11] <wgrant> spiv: :(
[06:11] <leo2007> ok, i'll take a look after reading http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html
[06:11] <leo2007> poolie: thanks for your help.
[06:11] <wgrant> spiv: Processing that same email locally works fine.;
[06:13] <spiv> wgrant: whee
[06:14] <wgrant> spiv: So I wonder if an MTA ate it... or something.
[06:15] <wgrant> I guess we should check that jam's copy is intact.
[06:16] <spiv> wgrant: yeah, that's a good idea
[06:16] <wgrant> If it's intact, we might need to go through MTA logs and find where the size drops...
[06:17] <lifeless> poolie: no, I have used looms, and pipelines, and for non-distro work I just use a lightweight checkout of branches in a shared treeless repo
[06:19] <poolie> ok
[06:19] <poolie> you might like to try this as an alternative to the latter
[06:20] <poolie> i would appreciate your feedback if you do so
[06:20] <lifeless> it will be a bit tricky right now -  my lp dev environment is down to 200MB free :( (and my host os 2GB free :( :( )
[06:20] <lifeless> I need to get a larger SSD
[06:21] <lifeless> I've been looking at getting a larger desktop box in fact - but the price for ones with 48GB of memory is ridiculous ;)
[06:21] <poolie> hm, it shouldn't use any more space than what you do now
[06:22] <wgrant> poolie: Is colo fairly usable these days?
[06:22] <poolie> it might take more than 200MB to convert into it
[06:22] <poolie> i think it's really good
[06:22] <wgrant> I haven't tried it since the week it was announced.
[06:22] <poolie> i'm just drafting a mail proposing we should bless it as the standard way to use bzr
[06:22] <poolie> and ship it by default etc
[06:22] <stylesen> poolie: ping
[06:22] <wgrant> IIRC the main problem I had with it was shelf.
[06:22] <poolie> it gives people a less manual way to set up the single-tree multiple brancehs thing
[06:22] <poolie> hi stylesen
[06:23] <stylesen> poolie: Hi poolie, would like to have a private chat with you!
[06:23] <lifeless> poolie: yeah, converting is what I was thinking might be an issue
[06:23] <poolie> sure, see pm
[06:23] <poolie> lifeless, i think the default conversion does copy all your histoyr
[06:23] <poolie> this could be optimized of course
[06:25] <poolie> for the common case of turning a repo + branches into a colo workspace, just moving the directories ought to be enough
[06:25] <poolie> lifeless, i just bought a 750GB magnetic disk to go into my laptop base
[06:25] <poolie> to store (my own) photos
[06:26] <poolie> lifeless, it's kind of ironic that you just converted me to the convenience of not having separate laptops/desktop machines :)
[06:27] <lifeless> poolie: nice!
[06:27] <lifeless> poolie: thats in an expansion bay, or the main unit?
[06:28] <poolie> in the sata bay of the ultrabase
[06:28] <poolie> the base does work pretty well for using it as a desktop replacement
[06:30] <lifeless> ah, nice.
[06:31] <lifeless> poolie: I'm finding my biggest limit is RAM
[06:31] <lifeless> the disk is a bit annoying, but I can juggle tolerably (though 128GB is quite constraining)
[06:31] <lifeless> but I can barely use all 4 cores with 8GB
[06:32] <poolie> i probably will ssh into my desktop box again if i'm doing something on lp and don't anticipate travelling soon
[06:32] <poolie> it seems like i touch dkim infrequently enough that every time i do, i spend 30 mins trying to get all the dependencies going again :/
[06:32] <lifeless> poolie: so if I do get a new desktop, I'll setup testr to run tests on the desktop from my laptop
[06:32] <wgrant> lifeless: Are new ThinkPad motherboards still limited to 8GB? :/
[06:33] <lifeless> probably set that up locally too so that I edit in a local vim session, and the lp-dev VM runs the tests
[06:33] <lifeless> wgrant: the W something or other can do (IIRC) 12
[06:33] <lifeless> wgrant: need 4GB for a lp test run end to end last time I tried to put a figure on it
[06:34] <lifeless> wgrant: (4GB in a VM)
[06:34] <lifeless> wgrant: so to parallelise robustly-before-we-fix-the-test-suite, I'm thinking we want 4GB*cores.
[06:34] <wgrant> lifeless: It's a lot less if you run i386.
[06:34] <lifeless> wgrant: but then I'd be running i386.
[06:35] <wgrant> In the VM :)
[06:35] <wgrant> How do I grab a remote branch into an existing colo workspace?
[06:35] <lifeless> I
[06:36] <lifeless> I'd expect 'make a branch, pull --overwrite'
[06:36] <wgrant> 'bzr branch lp:launchpad colo:devel' seems to work.
[06:37] <poolie> or bzr colo-fetch lp:launchpad
[06:37] <wgrant> colo-fetch says it creates a new workspace.
[06:37] <poolie> sorry, i misread
[06:38] <poolie> yes, i think your command is correct then
[06:38] <wgrant> Thanks.
[06:46] <wgrant> :(
[06:47] <wgrant> I wish bzr switch had an option to shelve changes into the branch or something.
[06:47] <poolie> wgrant, that was just requested
[06:47] <poolie> it shouldn't be too hard to add
[06:47] <wgrant> poolie: Except that shelves are in the WT, right?
[06:48] <spiv> wgrant: right
[06:48] <wgrant> :(
[06:48] <wgrant> Hmm.
[06:49] <wgrant> I guess it's useful to have them visible in all, but it would be nice if I could tell where each shelf came from.
[06:49] <wgrant> Since I use shelve a *lot*.
[06:49] <spiv> wgrant: hmm!
[06:50] <wgrant> (and I just about never give a message... perhaps I should)
[06:50] <spiv> wgrant: bzr-colo could perhaps auto-fill the --message option of 'bzr shelve' with the branch nick?
[06:50] <wgrant> Right.
[06:50] <wgrant> That would help.
[06:51] <poolie> wgrant, well, what i meant is that it seems like it would be a small code change to put them in the branch dir
[06:52] <poolie> giving better identities would be good
[06:52] <poolie> i'd like if they showed a diff stat or a snippet of the change more easily
[07:19] <vila> hi all !
[07:34] <poolie> hi vila
[07:36] <vila> poolie: hey !
[07:40] <poolie> hi vila
[07:40] <poolie> vila, did you try bzr-colo yet?
[07:41] <poolie> s//at all?
[07:41] <vila> not at all
[07:42] <vila> I still favor using a different working tree for each branch and looms for more involved feature dev
[07:43] <vila> I also use bound branches for specific needs (so multiple working trees but on different hosts)
[07:48] <poolie> ok
[07:48] <poolie> rfc sent
[07:55] <poolie> vila, like multiple machines all on the same network, bound to branches on one of them?
[07:55] <poolie> for fixing failures inside vms, or something?
[07:56] <vila> well, the branches are called my/setup and my/admin and they centralize/share all tweaks/setups I do on all my hosts
[07:56] <vila> that includes VMs
[07:59] <vila> but I still haven't a good story for fixing failures in VMs, partly because I keep encountering corruptions due to hard crashes and partly because I don't want to put valid auth tokens in VMs
[07:59] <vila> (thought I cheat a bit with the later ;)
[08:00] <vila> I work around corruptions by using mounted file systems for most of the VMs
[08:00] <vila> I'd prefer a bzr-based workflow but each time I need it, I'm already in bugfix mode and procrastinate
[08:01] <vila> s/proca*/punt/
[08:01] <vila> urg, one more random kill of a VM as a write this :(
[08:02] <vila> hmm, death may be more appropriate in fact, *2* VMs died (out of 3 running) and only the 3rd one should have shut down...
[08:03] <poolie> wow
[08:03] <poolie> died in the vm infrastructure, or in the guest os?
[08:03] <vila> the vm just vanished
[08:03] <vila> n ologs, no core, no nothing
[08:04] <poolie> this is with virtualbox?
[08:04] <vila> most annoying "babune" bug for months, no idea how to progress, last attempt was configuring core dumps but none ever appeared
[08:05] <vila> yup, and vbox is my first suspect, I keep hoping that the next version will address the issue :-/
[08:05] <poolie> maybe some of these things could run under kvm, vmware desktop, or something else?
[08:05] <vila> I chatted in #vbox several times but no one has any idea about what is going on nor how to collect useful infos to help debug it
[08:07] <vila> and since most of the time it happens during my sleep it's very hard to even caracterize it (hence my kill/death remark above)
[08:32] <magcius> gah
[08:32] <magcius> This is the most annoying thing.
[08:52] <fullermd> vila: Really, it's your own fault for sleeping   :p
[08:53] <vila> aaaaaaah, of course !
[09:19] <poolie> hi vila,
[09:19] <poolie> would you like a quick chat
[09:21] <vila> sure
[10:14] <leo2007> how to show what's in a commit?
[10:14] <jelmer> leo2007: do you mean the tree contents, the changes in that commit, the commit message / committer information?
[10:15] <leo2007> the diff, the message, etc
[10:15] <jelmer> leo2007: bzr log -p -rREV
[10:17] <leo2007> thanks.
[12:05] <spiv> jam1: LP appears to have mangled an email I sent to it: https://launchpad.net/bugs/739144.  You were CC'd, did you receive it intact?
[12:06] <spiv> jam1: probably best to reply on the bug, it's zzz time here :)
[12:06] <jam1> spiv: I got the email in-tact
[12:06] <jam1> and broken from lp
[12:08] <spiv> jam: I'm not sure if I feel relieved to hear that or not!
[12:08] <jam> spiv: sleep well. But yes, you sent the email correctly to me, LP messed something up
[12:08] <jam> or LP's mailhost did :)
[12:54] <Sp4rKy> hi
[12:54] <Sp4rKy> I get an error when trying bzr update :
[12:54] <Sp4rKy> bzr: ERROR: exceptions.UnicodeEncodeError: 'ascii' codec can't encode character u'\xe8' in position 85: ordinal not in range(128)
[12:56] <CaMason> hi guys. In our current team workflow, we occasionally have a 'merge session' where we merge in all changes prior to a release. After that, I get the team to `bzr pull` from the master branch, so we're all now working from the same code
[12:56] <CaMason> is that last bit sensible?
[12:57] <CaMason> it seems to work OK, as all team members then get everyone elses changes in their own branches
[12:57] <maxb> Sp4rKy: See if there is a traceback in ~/.bzr.log, and pastebin it
[12:59] <jelmer> CaMason: that seems perfectly sensible
[13:01] <Sp4rKy> maxb: http://paste.dunnewind.net/show/eVa29Aq8XkZ8ySIA0Xrt/
[13:03] <mgz> Sp4rKy: set you LANG/LC_ALL env vars to something sensible.
[13:03] <mgz> *your
[13:20] <maxb> Sp4rKy: to expand slightly on mgz's answer - you're trying to check out code with non-ascii file names. To do this, you need to be configured to use a locale which uses a character encoding which can represent them, so that Bazaar knows how to write the filenames to disk
[13:21] <maxb> Nowadays, everyone ought to be using a utf8 locale, really
[13:21] <Sp4rKy> maxb: in fact I am using utf-8 locale
[13:21] <Sp4rKy> but for some strange reason puppet (I manage the bzr repo with it) reset it ;)
[13:22] <Sp4rKy> so nothing bzr-related I think
[13:22] <maxb> line 56 of your pastebin says you are not
[13:26] <Sp4rKy> I am :)
[13:26] <Sp4rKy> but puppet reset it
[13:31] <santagada> is there any benchmarks comparing bzr 2.1+ to mercurial and git?
[13:32] <santagada> I've only seem really old ones and people told me bzr improved a lot in the 2.x line
[13:36] <jelmer> santagada: I haven't seen any recent benchmarks
[13:51] <jam> jelmer: care to finish your review of https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994
[13:51] <jam> ?
[13:52] <jelmer> jam: Sure
[14:25] <CaMason> what's the easiest way to output all files that have changed between revisions? Sometimes we get a customer that needs a 'patch', and we want to send only the PHP files that have changed
[14:26] <jam> CaMason: "bzr status -r X..Y" ?
[14:27] <CaMason> we might be talking a few hundred files :) Any way to `bzr cat` based on the revisions?
[14:27] <CaMason> if not, I could set up a script
[14:27] <jam> CaMason: so you want the complete contents of all files that changed recently (that end in .php)?
[14:27] <CaMason> between specified revisions, yes
[14:28] <jam> CaMason: "bzr status --short" is quite scriptable
[14:28] <jam> my 'cut' experience is limited
[14:28] <jam> but
[14:28] <CaMason> ah, hadn't seen that :D
[14:28] <jam> bzr status --short -r X..Y | grep ".*\.php"
[14:29] <jam> gets you a sart
[14:29] <jam> start
[14:29] <jam> I would use sed to get just the filenames, but that's because I don't know cut
[14:31] <CaMason> no sweat, that output is great, I'll get that scripted
[14:31] <CaMason> thanks
[14:33] <CaMason> bzr st --short -r last:4 | cut -c 5-
[14:35] <jam> CaMason: still need 'grep .php'
[14:35] <jam> but yeah
[14:36] <jam> bzr st --short -r last:4 | cut -c 5- | grep '.php' | xargs -n1 bzr cat -r -1
[14:36] <CaMason> ah that's no bother, I actually want all files. I just said 'php' so people didn't worry about a build script :P
[14:37] <jam> CaMason: though you could probably just pass the list to tar so that it will include only those files in a tarball
[14:41] <CaMason> `bzr st --short -r last:4 | cut -c 5- | xargs zip ../patch.zip` worked great
[14:41] <CaMason> its for windows clients unfortunately :)
[14:47] <jam> jelmer, vila: ping about https://code.launchpad.net/~jameinel/bzr/2.4-cheaper-iter-entries-by-dir/+merge/53994
[14:49] <vila> ubot5: where do you find a bug 2 ?
[14:49]  * mgz eyes ubot5 suspiciously
[14:50] <vila> mgz: ;)
[14:50] <jam> mgz: it *really* likes bug 2
[14:51] <jam> mgz: currently reviewing  https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130
[14:51] <jam> why do you return the Error class rather than just raising it?
[14:51] <mgz> okay, someone just borked poor ubotu5.
[14:51] <vila> gee, unplug that bot !
[14:52] <jam> mgz: at least it didn't mention "that bug" again
[14:52] <mgz> jam: I don't really like helpers appearing in the stack, and to raise I need to return object from the cdef anyway
[14:52] <jam> mgz: well,there are other ways, and you don't have to explicitly list object (it is the default if you say nothing)
[14:53] <mgz> so it's either helper than raises or returns None, or returns exception instances
[14:53] <jam> cdef foo() returns None
[14:53] <jam> same as regular python
[14:53] <vila> jam: oh, and pong https://code.launchpad.net/~vila/udd/735477-kill-harder/+merge/53837 ;)
[14:54] <mgz> I picked the way that gave me a shorter path in the common case, and one less level of stack when something goes wrong. but I'm open to all suggestions of this kind, made various stylistic judgement calls.
[14:54] <jam> vila: you didn't respond to my comment on that proposal
[14:55] <jam> I don't usually like hard-coded constants in the middle of code, can you bring it to a module/class level constant?
[14:55] <vila> jam: it wasn't related to the proposal but to another script :)
[14:55] <jam> otherwise seems good to me
[14:55] <jam> vila: though isn't that script broken by any grace period that isn't 0?
[14:55] <jam> since it only waits 1 second before starting the next process
[14:57] <vila> jam: no, as explained in the cover letter (updated before asking for re-review) during the grace period no kills are issued but the mass_import script doesn't wait either
[14:57] <jam> vila: I saw the update, but probably missed the details in the 5-pages-of-text
[14:58] <vila> the discussion then went about how long it takes for the mass_import to stop
[14:58] <jam> vila: so only ImportDriver is using the new kill_with_escalation, and mass-import is doing?
[14:59] <vila> 61 lines == 5 pages ? a page = 12 lines ?
[14:59] <jam> anyway, it isn't very clear how your first comment how it ties in with the last comment. since you seem to say it should switch, but then say it doesn't
[14:59] <vila> jam: sorry I don't understand your question
[14:59] <jam> or maybe just doesn't fast enough?
[15:00] <jam> vila: I'll try to start at the top
[15:00] <jam> "For the first case, we don't really care about what is currently
[15:00] <jam> going on since this denotes a bug"
[15:00] <jam> that sounds exactly like the case we care about
[15:00] <jam> s/the case/a case/
[15:01] <vila> except we can't any data from a process that doesn't respond to SIGTERM (as shown with nexuiz-data)
[15:01] <jam> vila: certainly
[15:01] <vila> and we *currently* generate log files 1GB/day with attempts to kill it
[15:01] <jam> I think martin and my point is that under load, 2s is actually pretty short for something to even generate a backtrace
[15:02] <jam> I'm happy to have the SIGTERM end up with SIGKILl
[15:02] <vila> well, not *currently* because it's seen as failing but still
[15:02] <jam> after a reasonable time
[15:02] <jam> 10s seems good to me
[15:02] <jam> a bit long for "die now please"
[15:02] <jam> but good for most situations
[15:02] <vila> jam: which is what the proposal implements hence asking for a re-review
[15:02] <jam> vila: which is the part I've certainly approved already
[15:03] <vila> meh, there are currently 2 NeedsFixing vote and no Approve
[15:03] <jam> vila: reload
[15:04] <jam> mgz: why is "delta_data" a "void **" rather than a "delta_index **" ?
[15:04] <jam> (in the pyrex header)
[15:05] <mgz> it was a straight change from returning void* to taking void**, but it could be unsigned char** instead given the actual value
[15:05] <jam> mgz: and in the docs, I would say "when DELTA_OK "fresh" contains a struct ..."
[15:05] <mgz> was it some cython being to clever with strings workaround thing?
[15:05] <jam> rather than "outparam" which isn't defined
[15:06] <jam> mgz: the actual value is a delta_index pointer
[15:06] <jam> at least from what I'm reading in delta.h
[15:06] <mgz> possibly the header is misleading?
[15:06] <mgz>     unsigned char *out;
[15:06] <mgz> ...
[15:06] <jam> https://code.launchpad.net/~gz/bzr/create_delta_index_api_change_633336/+merge/54130
[15:06] <mgz>     *delta_data = out;
[15:07] <jam> line 285
[15:07] <jam> you added a new parameter, it should be called "fresh" not "delta_data", or whatever you want to do with it
[15:07] <mgz> create_delta and create_delta_index have different signatures.
[15:08] <jam> mgz: ah, just misreading it
[15:09] <mgz> 282 in diff-delta.c is 197 in delta.h
[15:10] <mgz> adding to the function descriptions in the header might help things, the similar names are confusing to start with.
[15:11] <jam> mgz: overall approve, just needs a news entry
[15:11] <jam> something about getting better error messages when things fail
[15:11] <jam> is probably enough
[15:13] <mgz> I'll do that and take another pass at the comments.
[15:15] <mgz> which news heading should it be under? :)
[15:15] <jam> mgz: probably either internals or bugfixes
[15:17] <mgz> I'm just having a closer look at your tar export branch now, the push fixed the broken tests clearly.
[17:15] <vila> jelmer: what do you mean in bug #739481 ? Repository has too many methods - iter_reverse_revision_history " ... "in favor of Repository.iter_reverse_revision_history" ?
[17:16] <fullermd> Obviously, he means there's madness in its methods   ;)
[17:31] <gypsymauro> hi
[17:32] <gypsymauro> suppose my shared repository is offline, can I commits locally and then when I can reach my serve again move all changes to the shared repository?
[17:37] <maxb> gypsymauro: Yes, but a little advice on terminology - a "shared repository" in bzr terms usually refers to a location on disk created with "bzr init-repo" which exists to share one copy of history between multiple branches within it.
[17:37] <maxb> Whereas I assume you are talking about a remote server hosting branches.
[17:39] <gypsymauro> maxb: no I'm talking about a shared repository in bzr terms :)
[17:39] <maxb> How can a directory on disk be offline?
[17:55] <sidnei> vila, is anyone running the bzr benchmarks that ian was running?
[17:56] <sidnei> or jam ^^
[18:34] <jelmer> g'morning poolie
[18:42] <santagada> sidnei: I think you will have to run them
[18:42] <santagada> :D
[18:42] <sidnei> santagada, yeah, why not
[18:43] <sidnei> santagada, you could too :)
[18:44] <santagada> sidnei: if you can get the scripts used, I can try
[18:44] <sidnei> santagada, yay!
[18:51] <sidnei> jelmer, would you know anything about ian's benchmark scripts?
[18:55] <santagada> if it is a simple shell or python we could run it on my mac on windows and osx, you could do it on ubuntu
[18:55] <jelmer> sidnei: I think it's on Launchpad as lp:bzr-usertest
[18:57] <santagada> jelmer: yep it is in there but the docs http://people.canonical.com/~ianc/plugins/usertest/doc/ are 404
[18:59] <jelmer> santagada: I think the docs are probably in the branch too
[19:00] <sidnei> yeah, looks like it
[19:00] <sidnei> santagada, see http://bazaar.launchpad.net/~bzr/bzr-usertest/trunk/view/head:/scripts/script_network.py for example
[19:03] <cody-somerville> jelmer, Hey.
[19:03] <cody-somerville> jelmer, I got that information you requested: https://pastebin.canonical.com/44973/
[19:03] <cody-somerville> jelmer, It... looks like a bigger issue at hand. And the fact that someone else also reported this is rather concerning.
[19:05] <jelmer> cody-somerville: who did?
[19:05] <jelmer> cody-somerville: that all looks reasonable
[19:06] <cody-somerville> jelmer, Why is the group owner of somethings users and not jagosta?
[19:07] <cody-somerville> jelmer, LP #661678
[19:08] <jelmer> cody-somerville: I don't know, but that shouldn't really be an issue
[19:09] <jelmer> cody-somerville: or maybe that breaks the ownership copying
[19:10] <jelmer> cody-somerville: what groups is he in ? is he in both jagosta and users?
[19:12] <cody-somerville> jelmer, weird... no. users but not jagosta
[19:14] <jelmer> That would explain why bzr is errorring out - as it probably can't set the group for that file
[19:14]  * jelmer reopens the bug
[19:17] <cody-somerville> I think this might be a regression in Ubuntu.
[19:20] <jelmer> cody-somerville: yeah, looks like it
[20:39] <Pilky> does anyone have any experience pushing a bzr branch to a new github repository?
[20:41] <Pilky> I'm trying to do a dpush but it's giving a respository not found error
[21:31] <rockstar> abentley, you around?
[22:02] <AfC> Shame about bzr-git only using 1 CPU
[22:06]  * jelmer waves to AfC
[22:06] <AfC> Hi jelmer
[22:07] <jelmer> AfC: It could very well use more in theory, we just haven't put the work in yet and I imagine the GIL would be problematic in this case.
[22:08] <AfC> jelmer: I've been trying to get a checkout of Cairo. It's been 20 minutes so far. Might be a good test repository for you (especially seeing as how it's probably the third oldest Git respository out there).
[22:09] <AfC> jelmer: $ bzr checkout git://anongit.freedesktop.org/git/cairo
[22:09] <AfC> jelmer: is the command I ran...
[22:10] <AfC> Perhaps one to add to the "large foreign repos we performance test" collection.
[22:10] <jelmer> AfC: ENOSUCHCOLLECTION ;-)
[22:11] <jelmer> AfC: There probably should be one, though..
[22:11] <AfC> heh
[22:11] <jelmer> Among other things I'm currently working on getting all the Bazaar interface tests passing against the foreign formats. After that, I hope to take a look at further improvements, including performance.
[22:15] <AfC> jelmer: doesn't John maintain some large family of test repos, ie Open Office?
[22:16] <AfC> jelmer: but anyway
[22:16] <AfC> jelmer: yeah, I saw you remark about that. Very cool indeed.
[22:18] <jelmer> AfC: Yeah, I think he has something like that, but he tests the converted trees, not the conversion itself.
[22:50] <IceGuest_77> hi, quick question, hoping someone can help me. I am having a look at the stats plugin, and trying to understand how it works. Why are the numbers of revisions it reports more than from bzr log -rsomerev -n0 | grep revno | wc -l. What revisions is log not showing, and why?
[22:52] <kingos> stats gets the revisions by doing : ancestry = a_repo.get_ancestry(revision)[1:]
[23:01] <jelmer> hi kingos
[23:01] <spiv> kingos: off the top of my head I'd expect the ancestry of a revision to match the log -n0
[23:02] <jelmer> spiv beat me to it, that's what I'd say as well
[23:02] <jelmer> get_ancestry() is a bit weird as the first entry it returns is always None, hence the "[1:]" bit.
[23:03] <spiv> ('bzr ancestry' is a simpler way to see the revisions in the ancestry of a branch)
[23:05] <spiv> kingos: "bzr ancestry" and "bzr log -n0 --line" give the same number of lines for me.
[23:06] <spiv> (on the two branches I tried, one with 34k revs the other with 688 revs)
[23:06] <kingos> hmmm
[23:07] <spiv> (the stats plugin is not working for me atm)
[23:07] <jelmer> spiv: hmm?
[23:07] <spiv> jelmer: AttributeError: 'ProgressTask' object has no attribute 'note'
[23:08] <spiv> jelmer: with trunk lp:bzr and trunk lp:bzr-stats
[23:08] <kingos> spiv: yeah you can't specify an initial range I htink
[23:09] <spiv> kingos: to bzr ancestry?  No, unfortunately.  You could always do 'bzr branch --no-tree -rSOMEREV' (maybe add '--stacked' if you aren't using a shared repo) to work around that :/
[23:10] <kingos> spiv: I meant with stats
[23:10] <spiv> Oh ok.
[23:14] <kingos> spiv: bzr stats -r2..5 fails, where as bzr stats -r5 works
[23:19] <jelmer> kingos: please file a bug about that
[23:19] <jelmer> kingos: does it simply ignore the range or does it crash?
[23:22] <kingos> jelmer: It fails with that progress note error
[23:23] <kingos> jelmer: do I file it under bzr, or is there a plugin specific bug page?
[23:23] <spiv> kingos: oh, I'm not passing any args to bzr-stats at all
[23:23] <spiv> kingos: bugs.launchpad.net/bzr-stats I expect
[23:24] <jelmer> it works happily here with both trunks afaik
[23:24] <spiv> jelmer: a puzzle!
[23:25] <jelmer> spiv: I'm only getting that error when I specify a range
[23:27] <spiv> jelmer: ah, hmm, pebkac in my ~/.bazaar/plugins symlinks
[23:27] <jelmer> kingos: can you try with trunk?
[23:28] <spiv> Whee, 'ln -s ~/code/bzr-stats/trunk stats' does something confusingly different if you already have a 'stats' directory...
[23:28] <jelmer> spiv: heh
[23:29] <kingos> jelmer: still fails
[23:29] <jelmer> kingos: do you have r46?
[23:30] <jelmer> can you pastebin the backtrace?
[23:30] <kingos> jelmer: backtrace on the ticket
[23:30] <kingos> Bug #739823
[23:31] <spiv> kingos: By 'r46' he means "the revision I committed 3 minutes ago
[23:31] <kingos> of stats?
[23:31] <spiv> kingos: yes
[23:31] <spiv> jelmer: thanks, r46 fixes the -r2..5 bug for me
[23:32] <kingos> jelmer: no I didn't, that fixes it :(
[23:32] <kingos> jelmer: what should I close the bug report with?
[23:33] <kingos> jelmer: fix committed, or something else?
[23:33] <jelmer> kingos: yeah, fix committed
[23:33] <jelmer> it'll be fix released after the next bzr-stats release
[23:44] <poolie> hi spiv, jelmer, all
[23:47] <spiv> Hi poolie
[23:48] <jelmer> hi poolie


[07:05] <snowie> hello
[09:30] <dragon_> do you know if Quassel will be updated in lubuntu 21.10?
[09:31] <dragon_> last week 14 was launched
[09:31] <dragon_> it is pretty new
[10:23] <guiverc> dragon_, Only security patches maybe backported to 21.10; for Quassel 14 you'll likely have to wait till jammy/22.04
[11:14] <arrrow_> I see
[11:15] <arrrow_> I though the nostable version had software updates
[12:25] <dragon_> what type of software is updated in lubuntu non-stable version?
[12:41] <dragon_> I`m almost I have latest libre office
[12:42] <dragon_> and firefox
[12:43] <dragon_> even lxqt has copy right signed 2020
[12:44] <dragon_> sorry, 2022*
[12:50] <Maik> besides firefox  none
[12:50] <Maik> !latest
[12:51] <Maik> dragon_: if you really want the lastest/newest packages compile them yourself from source or go rolling release
[13:21] <dragon_> I`m not complaining at all, I just try to pick up the state of things
[13:48] <cgs> Ola
 Is there a rough release date for 22.04 yet?
 Yes
[16:09] <Maik> @heysoundude April 21st https://discourse.ubuntu.com/t/jammy-jellyfish-release-schedule/23906
 Thank you. I’m looking forward to stepping up from 20.04 for some reason…
[16:15] <Maik> @heysoundude know that Ubuntu LTS flavors are supported for 3 years. Main Ubuntu LTS 5 years.