[06:59] <zequence> Had the most wonderful memory leak. 8GB was flooded awesomely quickly
[07:00] <zequence> Seems to be Java related
[07:02] <falktx> nice :S
[09:59] <zequence> hmm. upload to ppa seems to succeed, but nothing happens for hours, and no error mail
[10:00] <zequence> ..nothing happens in the PPA I created
[10:22] <falktx> it takes time for things to build
[10:22] <falktx> have you checked the ppa page?
[10:23] <falktx> if the package is built successfully, you won't get any email saying so
[10:23] <zequence> falktx: Nothing in the ppa. No activity at all
[10:24] <zequence> falktx: Do you have a nice workflow for patching packages and uploading to ppa?
[10:24] <zequence> falktx: This is what I did https://wiki.ubuntu.com/ubuntustudio/UploadingToPPA
[10:25] <falktx> I usually do it like this:
[10:25] <falktx> 1. create package
[10:25] <falktx> 2. edit changelog as needed
[10:25] <falktx> 3. create source package for upload -> "debuild -S -sa"
[10:26] <falktx> 4. upload -> "dput ppa:kxstudio-team/ppa *.changes"
[10:26] <zequence> falktx: But isn't that for when you create a new package?
[10:26] <zequence> How about patching an existing one?
[10:26] <falktx> on that case you skip 1.
[10:26] <falktx> and for 2, do:
[10:26] <falktx> dch -i
[10:26]  * persia usually uses edit-patch or checks the patch system in use, and uses that directly
[10:27] <falktx> then do 3. and 4. as usual
[10:27] <falktx> zequence: do you have your debian-sources somewhere? I can test the upload
[10:28]  * persia also generally generates local binary packages with sbuild prior to testing, as testing source directly sometimes has unexpected consequences when the changes end up in the package
[10:29] <persia> For current PPA issues, also see Bug 1071562
[10:29] <persia> This has apparently caused the PPAs to be out of space (see #launchpad /topic)
[10:32] <zequence> persia: falktx: thanks for those tips. I'm writing all this stuff down for docs
[10:37]  * persia thought LP had a PPA page with instructions to patch a package for a PPA
[10:38] <persia> Also, I generally don't use PPAs as part of development: I don't generally see the point: if the change is good, it ought go into the distro, and if it's not good, then it needs fixing.  Test-building locally is almost always faster than waiting for the PPA queue
[10:42] <zequence> persia: Having it on a PPA does make it easier for multiple people to test it, if needed
[10:42] <astraljava> One more perk is that when you're without internet connection, your [s]chroot won't mind. :)
[10:43] <zequence> persia: Actually, I'm thinking of what would be the right procedure for this. Patching jackd2, testing, and then doing an SRU
[10:44] <astraljava> zequence: If you intend to do SRUs, then PPA won't qualify as the testbed anyway. You'd be better off with creating the chroot with buildd option.
[10:44] <persia> FOr multiple testers, if it's a SRU, I'd rather get their test reports in the SRU bug so the SRU team considers them, and if it's not, that's why they call it a development release :)
[10:45] <persia> So, for jackd2: I'd apply the patch to the development release first, and if that seems to work, port the patch to quantal, test locally, and push as an SRU candidate.  Once it gets published to -proposed, call for testers to the bug, and the SRU team can make an informed decision.
[10:46] <zequence> persia: Ah, right. -proposed. In this case, the development release is the same as Quantal, so no change there. But, I'm doing SRU on both 12.10 and 12.04, and those are a bit different
[10:47] <zequence> Well, naturally
[10:48] <zequence> I should go to making the SRU requests, then
[10:48] <persia> zequence: The point of the upload to raring is twofold: firstly you get to test the patch in an environment where nobody minds a bit of bugginess, and secondly because you can't SRU somthing that isn'T fixed in the development release.
[10:48] <persia> The porting of the patch to precise will naturally involve some potential for it not working properly: that's why we stage SRUs in -proposed, so that they can be tested.
[10:49] <persia> If it turns out that your local testing of the precise version wasn't enough, that gets caught in -proposed, the SRU team removes it from the archive, and you get to try again.
[10:49] <zequence> persia: Aha, I need to patch the development version first. How do I do that?
[10:49] <zequence> I mean, how do I request to get the patch added?
[10:49] <persia> Your wiki page has a good procedure, except change the dput line to a sponsor request :)
[10:50] <persia> I'm not up on current sponsoring procedures, but the way we did it when I was last paying close attention to this was that one prepared a new candidate version (integrated patch, changelog, etc.) all set for dput.
[10:50] <persia> Then one ran `debdiff current-revision candidate-revision` and generated a package patch (as opposed to the software patch)
[10:51] <persia> One then attached that to a bug in LP, and subscribed the ubuntu-sponsors LP team.
[10:51] <persia> A sponsor would then catch it in the next few days (depending on sponsor availability) and upload it.
[10:51] <persia> If you want to get information about the current procedure, you can ask in #ubuntu-devel
[10:52] <persia> Alternately, put the debdiff somewhere I can find it, and ask me to review/sponsor.
[10:52] <zequence> persia: Thanks. I'll do that
[10:53] <zequence> But, now it's lunch time :)
[10:53] <persia> zequence: To be clear, my goal here is to get you enough sponsored uploads that you have access to upload to all Ubuntu Studio packages (not all the packages we use, but all the packages we use that other flavours don't use)
[10:53] <persia> Enjoy your lunch :)
[10:53] <zequence> persia: Ah. I didn't know that was a merit needed for that. 
[10:55] <persia> I'm no longer one of the folk that decides who can upload to Ubuntu, but generally one needs to 1) have been working in development for at least one release cycle, 2) demonstrate familiarity with the set of packages one intends to upload, and 3) be suitable as an Ubuntu Member
[10:55] <persia> And if one intends to work as a developer in the Ubuntu project, one may as well be able to upload: otherwise one is stuck with out-of-archive flavours or PPAs alone
[10:56]  * persia looks at astraljava and falktx 
[10:57] <astraljava> persia: Aww... making me feel guilty for real? :)
[10:57] <astraljava> I am not even a Ubuntu member. Yeah, I guess I should do something about that.
[10:58] <persia> astraljava: Only a little: I never know if it's that you don't have the time or if you just don't get around to it :)
[10:58] <falktx> persia: I have some packages in universe
[10:59] <falktx> https://launchpad.net/ubuntu/+source/dssi-vst/0.9.2-1ubuntu3
[10:59] <falktx> :)
[10:59] <astraljava> persia: Mostly it's my instability. :) I lack persistence.
[10:59] <falktx> and this - https://launchpad.net/ubuntu/+source/zyn/1-0ubuntu2
[11:02] <persia> falktx: I know: I'm hoping you'll get enough to be confident applying for developer status at some point
[11:03] <persia> astraljava: Given enough time, one is declared to persist, even if one is inconstant along the way: it all averages out
[11:03] <persia> (although I can't speak for the current DMB, so I can't be sure)
[11:03] <falktx> persia: afaik I can fix packages as I am right now. just need to get a debdiff
[11:04] <falktx> persia: I think I'm able to apply for maintainership of specific packages too. but i'm not sure...
[11:04] <persia> falktx: Main differences are just 1) you need a sponsor and 2) you can't vote for the TB, support a flavour, or do other governance things
[11:05] <persia> falktx: You could, but there should be a consistent theme for the packages you're maintaining, and it's preferred if you're one member of a team co-maintaining a set of packages.
[11:05] <falktx> well, considering that I'm against some debian policies... I stop worrying about this long ago
[11:05] <persia> Which sorts of policies?  Do they also apply in Ubuntu?
[11:05] <falktx> but now that my little cadence tools are getting ready, I'm starting to worry again
[11:06] <falktx> persia: mostly about license issues
[11:06] <persia> Oh, yeah.  Ubuntu is a bit more flexible than Debian, but those hosting our mirrors only allow so much.
[11:06] <falktx> linuxsampler example is the best one
[11:06] <astraljava> persia: Right, I do understand that. I guess I'm also a bit insecure. It made me look other commitments, which in turn made me burn out a little. I suppose that maybe during 13.10 dev cycle, I could seriously get back to development duties again.
[11:06] <astraljava> Now is the time to get my music-related skills polished. :)
[11:06] <falktx> persia: but main reason is that I'm just too busy
[11:07] <persia> Technically, PPAs are supposed to have the same limits as Ubuntu, but they aren't as carefully policied (I think Canonical just removes any PPA that gets a compliant and doesn't do anything else)
[11:07] <falktx> persia: I'm learning that I need to backoff sometimes, too much work is bad for the mind...
[11:07] <persia> astraljava: My recommendation is just do a bit every week: don't worry about doing lots and lots: this prevents burnout.
[11:07] <persia> falktx: Indeed :)
[11:08] <astraljava> persia: True, this was indeed my problem.
[11:08] <astraljava> I hogged all responsibility I could get. :) But I was in a very dark place in other ways, too, so I'm guessing I might be more balanced in the future.
[11:09] <astraljava> I still haven't given up my dream of becoming a Ubuntu dev, some day. :)
[11:09]  * falktx wants falktx@ubuntu.com :)
[11:11] <astraljava> Oh you're not a Ubuntu member, yet, either?
[11:11] <persia> As long as you're both motivated, I'm happy: that was the point of my look.
[11:11] <persia> Remember that by getting the LP badges, you're also setting an example for those that follow, so they don't feel like it's impossible (Hey, that person has been doing this for *years* and still can't upload: I'll never get there)
[11:11] <astraljava> persia: No way, I'm not losing that very easily. I still intend to get more active on debian-front, as well.
[11:12] <persia> Cool!
[11:12] <astraljava> True, never thought of that.
[11:12] <falktx> persia: I hate how debian wants to build everything in debug mode though, I still don't get that
[11:13] <persia> falktx: The idea is that one builds in debug mode, and splits out the debug symbols later in the build process, stripping the binaries like if one hadn't built in debug mode.
[11:13] <persia> One then produces two packages: the regular package and the debug symbols package.
[11:14] <persia> If a user has an error, they can install the debug symbols package, and debug it directly, without a rebuild.
[11:14] <persia> But normal users don't waste space or execution speed on the debug symbols.
[11:14] <persia> Best of both worlds, ideally.
[11:15] <falktx> persia: that idea is plain wrong
[11:15] <falktx> it just shows they know don't how programming works
[11:15] <falktx> it makes me very sad
[11:15] <falktx> like it's a toy/joke to them
[11:15] <falktx> debug symbols != debug mode
[11:17] <persia> Indeed, that sounds wrong, and I've never been told that is how it had to be done in Debian.
[11:17] <persia> I suspect someone was confused.
[11:19] <falktx> that is very bad for a pro-audio distro
[11:19] <persia> And I suspect that if such an issue was brought up for discussion on the debian-multimedia list, others would agree that one only needs to expose debug symbols
[11:19] <persia> It's bad for a toy distro.  Bad for everything, if it requires extra cycles.
[11:20] <persia> Are we inheriting anything from Debian built in such a way?
[11:20] <falktx> some packages, yes
[11:21] <falktx> most recent ones are like that
[11:21] <persia> Is there a way to build them to expose only the debug symbols?  I think we want to patch them that way (and probably want to discuss with debian-multimedia about doing it that way)
[11:21] <falktx> for example: https://launchpad.net/ubuntu/+source/lv2/1.2.0~dfsg1-1
[11:22] <falktx> debian/rules has there: '--debug'
[11:22] <falktx> :(
[11:22] <falktx> persia: debug symbols are there by default when there's no stripping
[11:22] <falktx> the sentence "debug symbols" sounds wrong though
[11:22] <falktx> there's nothing about debug in the symbols
[11:23] <falktx> they're just symbols
[11:23] <persia> Yeah, but folk mostly use them for debugging, and the phrase has stuck
[11:23] <falktx> a debug build always has symbols
[11:23] <falktx> otherwise it's useless
[11:24] <persia> Depends on what else debug does
[11:24] <falktx> no optimizations
[11:32] <persia> Hrm.  waf is confusing.  Has anyone asked alessio why it's this way?
[11:34] <falktx> astraljava asked on debian-multimedia mailing list I believe
[11:34] <falktx> no response
[11:36] <persia> No response probably means everyone was too busy.  I haven't seen quadrispro around for some time, but he usually had reasons to do things.
[11:37] <astraljava> Alessio is in Aberdeen as an Erasmus student, probably too much partying to pay attention to us mere mortals currently. :)
[11:41] <ttoine> falktx, thanks for fixing the ardour lv2 problem in you repo for 12.10
[11:42] <zequence> ttoine: What problem was that?
[11:42] <zequence> Is there a bug report onit?
[11:42] <falktx> ttoine: no prob
[11:42] <falktx> zequence: the 12.10 package doesn't show gui for some plugins
[11:42] <falktx> it might be fixed in 13.04, https://launchpad.net/ubuntu/+source/ardour/1:2.8.14-2
[11:43] <falktx> I don't know how to request a backport for that... :S
[11:43] <zequence> falktx: Ok. I'd like to fix that in the main repo too, if possible. I'll need to see what does not work, and would be greatful for a patch for this
[11:44] <falktx> zequence: that package should have the fix, you just need to request a backport
[11:44] <falktx> it's same package as in 12.10
[11:44] <zequence> ok
[11:44] <falktx> I can make a debdiff
[11:45] <falktx> but I forgot how things work...
[11:47] <astraljava> falktx: Backporting requires no debdiffs. It wants the package as-is, and needs to be tested by a few volunteers, forget how many, probably two.
[11:47] <astraljava> There's a tool for that, request-backport (I believe, not on an ubuntu machine now).
[11:48] <falktx> I'm not on 12.10, so I can't even test
[11:48] <astraljava> falktx: Doesn't have to be you, though. :)
[11:48] <persia> Needs two testers.  Testing on VM counts, for those with kvm or virtualbox
[11:49] <astraljava> I can do it, now that I still have 12.10 on the desktop. Won't be long, though, as I hear raring will be even more stable during the dev cycle than quantal was.
[11:57] <ttoine> I am on 12.10
[11:58] <ttoine> the ardour package in the kxstudio repo works with lv2 gui
[12:06] <zequence> persia: I was able to backport qjackctl to 12.04 with only me testing it
[12:07] <zequence> ttoine: It doesn't help Ubuntu Studio to have working packages in ppa's 
[12:07] <zequence> ttoine: If there's a bug, someone should file a bug report
[12:07] <zequence> Then, someone should see about fixing it
[12:07] <zequence> This is something we need to get much better at. Probably more bugs out there, if we start looking
[12:09] <astraljava> zequence: Most definitely. This is actually the area where I want to focus nowadays; I stepped down from the "managerial" position, now I just need to roll up the sleeves in the "hands-dirty" position. :)
[12:10] <zequence> astraljava: Sounds good. You having some experience in this. We definately don't have enough of that right now
[12:20] <astraljava> zequence: I'm a little out of touch, been for the past couple years. I used to do lots more a few years back.
[12:20] <astraljava> But maybe it isn't too big of a hurdle to get back in the game.
[12:21] <astraljava> The music hobby certainly does wonders to my mental health, so who knows, maybe I'll heal quicker than I thought. :) Yesterday was the best day in such a long while.
[12:25] <zequence> astraljava: For me, exercise was the only thing to change my ship around
[12:25] <zequence> Seems like http://developer.ubuntu.com will be a good resource to link to
[12:26] <zequence> I know it's probably more tuned towards other developers than flavor devs atm, but it'll hopefully be a bit better formatted than the wiki
[12:30] <astraljava> zequence: Yeah, I'm doing that too. Badminton, walking/jogging and gym/hand-weights.
[12:31] <astraljava> I think that'll be a good reference for anybody wanting to get into Ubuntu dev.
[13:35] <smartboyhw> Hi scott-work
[13:42] <scott-work> morning smartboyhw , how are you today?
[13:43]  * smartboyhw wants to restart the dev of linux-rt kernel
[13:43] <scott-work> i'm curious to why you want to do that
[13:43] <smartboyhw> scott-work: good
[13:44] <scott-work> smartboyhw: this is my view on the rt kernel:
[13:44] <smartboyhw> ok
[13:44] <scott-work> i believe for most computers and applications the lowlatency kernel provides plenty of "oomph" (i.e. low enough latency and little-to-no xruns)
[13:45] <scott-work> btw, "most computers" != 286 machines or atom processors
[13:45] <smartboyhw> yeah.
[13:45] <zequence> smartboyhw: Any evidence of that -rt is better than -lowlatency? I think not
[13:45] <scott-work> some 386 machines do well with onboard audio, some don't. but if you are serious about audio then you shouldn't be using onboard audio then
[13:46] <zequence> Also, -lowlatency is good enough, so no need for -rt
[13:46] <scott-work> even within that subset (386 machines and above) you probably should have plenty of memory, say 2g minimum (making up a nice number), but even more if possible
[13:47] <scott-work> so, given that even reduced subset, there are going to be people who continue to have problems with xruns/latency....like ralph
[13:47] <scott-work> two things to mention about people like this: they are a minority most likely and it is probably hardware specific
[13:48] <smartboyhw> zequence, scott-work: call this a sideline project, main focus is testing (+ testing docs)
[13:48] <scott-work> rt kernel _might_ fix their problems, but then again it might not....especially if there are interrrupt problems
[13:48] <smartboyhw> my sideline
[13:48] <scott-work> and then you start coupling the invasive nature of the patch, the need to recompile for video drivers....
[13:48] <scott-work> the lowlatency kernel is an outstanding success compared to the -rt kernel
[13:49] <scott-work> it's just a matter of educating the public, IMO
[13:49] <scott-work> like holstein says, "people just _think_ they need the -rt kernel because that is what they read/hear....but they don't"
[13:49] <zequence> Also, you might not get -rt patches for every kernel version, so some releases would either need an older kernel, or no -rt at all
[13:49] <scott-work> zequence: yes, yes. i forgot about that 
[13:50] <scott-work> good points as well
[13:50] <zequence> It's just more work for no gain
[13:50] <smartboyhw> yeah. Just want to see whether it works for now....
[13:50] <smartboyhw> zequence: I don't gain anything:-P
[13:51] <scott-work> smartboyhw: please, don't forget about the additional testing things i mentioned. if you want to brainstorm together, i would be gladly available to do so, even if all we do currently is establish topic that should be fleshed out
[13:52] <smartboyhw> scott-work: Add it to the blueprint then
[13:54] <scott-work> smartboyhw: add which part to the blueprint, the brainstorming? the topics i think should be there?
[13:54] <smartboyhw> scott-work: yes
[13:56] <ttoine> zequence, for all my trials, the ardour package don't support the lv2 gui, and it has always been the case. That's why I am using the package in kxstudio, and was not thinking it was a bug in Ubuntu Studio 
[13:56]  * smartboyhw is applying to become a #ubuntustudio IRC o
[13:57] <smartboyhw> *op
[13:57] <smartboyhw> channel op I mean
[13:57] <smartboyhw> zequence: Interested?
[13:58] <scott-work> right, i will add items to the blueprint
[13:59] <smartboyhw> :-D
[14:01] <zequence> ttoine: Still, it won't help Ubuntu Studio, if 1. no one is informed there is a bug 2. Therefor no one can do anything about the bug
[14:02] <zequence> ttoine: The activity on solving bugs has not been very high, something we would like to change now
[14:02] <zequence> ttoine: So, if you do find a bug, please report it
[14:02] <smartboyhw> lol it triggered the bot
[14:03] <zequence> ttoine: And if you know of a solution, like knowing the kxstudio has this fixed, please do tell about that too (as you did)
[14:03] <zequence> Somehow, we need to get the fix into the Debian package -> Ubuntu
[14:03] <zequence> It doesn't help us if the fix is in a PPA
[14:03] <zequence> We are not a PPA distribution
[14:03] <zequence> This is an official flavor of Ubuntu
[14:05] <zequence> And Ubuntu relies on Debian
[14:05] <falktx> the fix is there, just needs a backport
[14:06] <falktx> zequence: this was a different case since the package he was running was not from Ubuntu
[14:06] <falktx> by concidence the problem is present in Ubuntu too
[14:07] <zequence> falktx: Your build of ardour is different, right?
[14:07] <zequence> falktx: vst? What else?
[14:07] <scott-work> falktx: where is the fix? just in your PPA? a patch from ardour?
[14:07] <zequence> falktx: You mentioned no debug symbols
[14:08] <scott-work> if it is a patch from paul then we can just ask debian multimedia to update ardour, no?
[14:08] <scott-work> and then have ubuntu sync it
[14:08] <falktx> zequence: not different per say, but the libs it builds upon are not the same
[14:08] <zequence> scott-work: It seems the raring version should be ok
[14:08] <micahg> zequence: for backports, there's a requestbackport script in ubuntu-dev-tools
[14:08] <zequence> micahg: Yep. I've done one backport already.
[14:08] <falktx> scott-work: it's already fixed in 13.04, and the package is the same. it just needs a backport
[14:10] <falktx> zequence: I have updated libs of several stuff (mostly lv2 related), and since this was an lv2 related issue it might not happen in Ubuntu itself
[14:12] <zequence> falktx: Ok, so the bug was perhaps only in the kx version then..
[14:12] <zequence> ttoine: Sorry about the noise.
[14:12] <falktx> zequence: yep
[14:13] <zequence> I still haven't had the time to check this myself. 
[14:15] <zequence> Of course, we should not be considering kx bugs Ubuntu bugs anyway
[14:15] <zequence> And I have the feeling falktx is quite active on fixing and reporting bugs on that front, as it is
[14:15] <zequence> At least against the software developers (as in the case with jackd)
[14:15] <falktx> yes, things like these are easy to fix
[14:21] <ttoine> falktx, it is not a coincidence, actually
[14:22] <ttoine> LV2 GUI don't works with the current ardour in Ubuntu
[14:23] <ttoine> And I reported to you because your package for 12.04 works with LV2 GUI, and I was disapointed with 12.10 don't working
[14:24] <zequence> ttoine: Which Ubuntu?
[14:24] <zequence> ttoine: I mean, which Ubuntu is it where ardour does not work (the stock package)
[14:31] <falktx> zequence: the bug is in 12.10
[14:31] <ttoine> 12.10
[14:31] <ttoine> but I am not sure that the package in 12.04 works better
[14:32] <falktx> the 12.04 version uses old lv2 libs, so it's not affected
[14:33] <falktx> plus, it's an older ardour version
[14:36] <zequence> ttoine: Thanks.
[14:37] <ttoine> you are welcome
[14:38] <zequence> ttoine: Could you give me an example plugin that does not work. I will try on 12.04
[14:38] <ttoine> falktx, I use your repo for Ardour with my 12.04 workstation, to get LV2 support
[14:38] <ttoine> zequence, invada lv2
[14:39] <ttoine> the matter is there are not a lot of lv2 plugins in Ubuntu repo
[14:40] <ttoine> zequence, you may try too this
[14:40] <ttoine> http://www.linuxdsp.co.uk/download/lv2/download_dsr500/index.html
[14:40] <falktx> linuxdsp work fine
[14:40] <falktx> the issue is with gtk2 uis, linuxdsp use external-ui
[14:40] <falktx> so as lv2fil, so those will work even with the bug
[14:40] <ttoine> falktx, even on 12.04 ubuntu ardour ?
[14:41] <falktx> 12.04 shouldn't have this bug at all
[14:43] <zequence> Nope. I don't seem to have any problems with the guis
[14:43] <zequence> ttoine: I have the linuxdsp plugins
[14:43] <zequence> Also mixbus
[14:43] <zequence> Had I more time, I would be using it a lot more :)
[14:43] <zequence> Invada was new to me (but then I haven't really been searching).
[14:43] <zequence> Cool guis (haven't yet heard them in action)
[15:02] <ttoine> it is not the better plugins I heard... but for free software it is not so bad
[15:06] <scott-work> what lv2 gui are we speaking about? i have used the calf stuff in ardour on 12.04 without any problems
[15:07] <scott-work> so i'm surprised that ttoine is saying that he is using kxstudio version of ardour for lv2 support
[15:28] <zequence> scott-work: I'm sure ttoine has other reasons for using kxstudio, but it does seem like only 12.10 was affected. Going to try now
[15:37] <zequence> Right, so the lv2 guis do not show. Instead you get the standard guis that you always get
[16:09] <scott-work> oh, okay. i understand, i believe
[16:09] <scott-work> the lv2 gui's are very much nicer than the standard ones :P