[15:00] <falktx> hi abogani
[15:00] <falktx> abogani: you there?
[15:00] <abogani> falktx: yes
[15:01] <falktx> abogani: i have a favour to ask you
[15:01] <falktx> abogani: can you update the lucid lowlatency kernel on your ppa?
[15:01] <falktx> it's the default kernel on my kxstudio distro
[15:02] <abogani> falktx: As reported to all our Studio mailing-list lowlatency lucid is dropped.
[15:02] <falktx> abogani: maybe just a last update?
[15:02] <falktx> please..?
[15:04] <abogani> falktx: No I can't. I have already delete all files. I would happy to help you but there is no way. Sorry
[15:04] <falktx> ah, ok
[15:04] <falktx> i'm not sure about using the realtime kernel as default
[15:04] <abogani> falktx: Could you inform me when you use my package? So I avoid to delete these without alert you.
[15:05] <abogani> falktx: .33 seems a lot stable, at me at least
[15:06] <falktx> abogani: usually I copy your packages into my PPA, the version I now have is 2.6.32-24.42
[15:06] <falktx> I guess I'll be back to generic
[15:07] <abogani> falktx: Yes an other good choise.
[15:07] <abogani> choice
[15:10] <falktx> abogani: so the lowlatency kernel will be dropped for good?
[15:13] <falktx> abogani: what about natty? will you make lowlatency for it or it's not decided yet?
[15:18] <astraljava> falktx: More information regarding kernels can be found on: https://wiki.ubuntu.com/RealTime
[15:19]  * falktx reads
[15:22] <falktx> ok
[15:48] <falktx> hey I just found AutoStatic in IRC
[15:48] <falktx> he's coming here
[15:49] <falktx> hey AutoStatic
[15:49] <AutoStatic> Hi
[15:50] <falktx> me and AutoStatic were discussing about the PPA
[15:52] <falktx> from what I understand, this is the official us dev team: https://launchpad.net/~ubuntustudio-dev
[15:52] <falktx> and this is the PPA for it - https://launchpad.net/~ubuntustudio-dev/+archive/ppa
[15:54] <falktx> to all devs here: What is the best choice for a new studio PPA:
[15:54] <falktx> 1 - the official ubuntustudio-dev
[15:54] <falktx> 2 - a new team
[15:54] <falktx> ?
[15:55] <abogani> What type of packages should go into that new PPA?
[15:55] <astraljava> A new studio PPA? What for?
[15:55] <AutoStatic> For Ubuntu Studio
[15:56] <AutoStatic> atm there are multiple multimedia PPA's
[15:56] <astraljava> I mean, what apps should go there, and why couldn't they go into the official repos?
[15:56] <AutoStatic> philip5, falktx, tangostudio etc
[15:57] <falktx> astraljava: for example wineasio and VSTs
[15:57] <falktx> astraljava: also svn builds of ardour3.0, hydrogen, etc
[15:57] <AutoStatic> Apps that are not in Debian testing or the official repo's
[15:57] <falktx> AutoStatic: maybe we should split into 2 ppas, 1 stable and 1 testing
[15:57] <AutoStatic> So not even necessarily svn builds
[15:58] <AutoStatic> Yes, good idea
[15:58] <astraljava> falktx: Okay. If Ubuntu Studio devs are supposed to offer support for them, it would make sense for them to be in ubuntustudio-dev PPA. And one PPA can offer several repositories.
[16:00] <abogani> The best thing should be: Create a PPA into ubuntustudio. Place there all stable packages. Use the ubuntustudio-dev's PPA for development packages (like svn builds).
[16:00] <abogani> IMHO obviously :-)
[16:00] <falktx> seems good to me
[16:01] <falktx> but afaik, everyone is allowed to be part of the ubuntustudio team
[16:02] <astraljava> Yeah, the idea of providing support for such packages make me cringe a bit. :)
[16:02] <astraljava> +s
[16:02] <falktx> so maybe it could be better if the team is kinda not official
[16:03] <AutoStatic> now orries I think astraljava
[16:03] <AutoStatic> no worries I mean
[16:04] <astraljava> Are there licensing issues why some of the packages couldn't go to official repos?
[16:04] <falktx> AutoStatic: the way I currently build svn packages, they dont conflict with the stable ones
[16:04] <falktx> AutoStatic: maybe they should go too into the stable ppa too, and leave the test ppa just for testing of new packages
[16:05] <AutoStatic> I haven't build that much of those kind of packages
[16:05] <falktx> astraljava: most packages are ok
[16:05] <AutoStatic> I second that, i don't foresee any big support issues
[16:05] <falktx> astraljava: but VSTs require non-free headers to compile
[16:05] <astraljava> falktx: Gotcha.
[16:05] <falktx> astraljava: my way of doing it is to compile them myself and only include the source in the package
[16:06] <falktx> astraljava: I never touch the non-free headers at anytime in the PPA
[16:06] <astraljava> Ok.
[16:08] <falktx> astraljava: here's an example of restricted package - https://launchpad.net/~falk-t-j/+archive/lucid/+sourcepub/1343380/+listing-archive-extra
[16:08] <AutoStatic> falktx: with a good set-up on your won machine one doesn't really need a test PPA I think
[16:09] <falktx> astraljava: all source is included, but not the non-free header
[16:09] <falktx> astraljava: the folder 'build' contains the binary I compiled
[16:09] <falktx> astraljava: please check it and tell me if this should be ok
[16:09] <falktx> AutoStatic: you too please
[16:10] <falktx> AutoStatic: for testing I guess I could just use my own testing PPA
[16:11] <AutoStatic> just a sec
[16:14] <AutoStatic> Looks good to me
[16:15] <falktx> this is the method I use for VSTs too
[16:15] <falktx> I spoke to the launchpad guys about this too, they said it was ok
[16:16] <AutoStatic> But isn't wieasio a lib? 
[16:16] <AutoStatic> wineasio
[16:17] <astraljava> falktx: I'm not an expert on these matters, but IMO that's fine.
[16:17] <falktx> AutoStatic: yes, it goes to /usr/lib/wine
[16:18] <falktx> AutoStatic: but it uses ASIO, non-free stuff from the Windows world...
[16:18] <falktx> astraljava: thanks
[16:19] <AutoStatic> Yes I know falktx, but I was hinting at the fact that it seems to be packaged as a single binary while it is actually a library
[16:19] <AutoStatic> But then I'm not a packaging expert
[16:20] <falktx> AutoStatic: ah, that
[16:20] <AutoStatic> That will come when we start packaging for Natty
[16:20] <AutoStatic> ;)
[16:20] <falktx> AutoStatic: everyone was using the name 'wineasio' for the package, so I just continue the tradition
[16:20] <falktx> btw, I also have an external repo for really non-free stuff (closed source apps), these I know can't be on launchpad
[16:22] <AutoStatic> I don't mean the package name but apparently it's created with dh_make -s instead of dh_make -l
[16:22] <AutoStatic> Nah, letś not go into details
[16:22] <AutoStatic> It works :)
[16:23] <falktx> AutoStatic: what is the diff between '-s' and '-l' ?
[16:24] <AutoStatic> -s = single binary and -l = library
[16:24] <AutoStatic> I think package managers rely on this too
[16:25] <AutoStatic> Synaptic - Sections
[16:25] <AutoStatic> wineasio is now in sound while it shoudl be in libraries
[16:25] <AutoStatic> I think
[16:26] <falktx> hm... not sure
[16:26] <falktx> anyway, it's not a big issue
[16:26] <AutoStatic> Nope
[16:26] <AutoStatic> That kind of stuff is debatable
[16:26] <falktx> AutoStatic: when we make a PPA, you can easily fix it if you want
[16:28] <AutoStatic> Yes, but we'll see
[16:28] <falktx> so how should we name the team?
[16:28] <AutoStatic> It's still all a bit vague
[16:30] <AutoStatic> Ok, gotta go
[18:48] <scott-work> i realize that autostatic and falktx are not here but i wanted to add my opinion to this as well
[18:49] <scott-work> i would like to try to avoid implying that the ubuntu studio developer team would be responsible for maintaining or responsible for any packages in falktx/autostatic's group PPA
[18:50] <scott-work> perhaps calling the team "Ubuntu Studio Packaging Team" with a clear explanation that this is not part of the official Ubuntu Studio Dev team
[18:51] <scott-work> also mentioning that the purpose of the team is to package applications that cannot be in the official repositories due to licensing or too experimental as well
[18:52] <scott-work> hopefully falktx and autostatic can also focus on getting packages into the repos when possible, rather than take the quick satisfaction of putting everything into a PPA
[18:53] <scott-work> we will get much longer benefits if packages that *can* go into the repos actually see the work to *get* them into the repos
[18:53] <scott-work> preferrably into debian first though ;)
[19:04] <astraljava>                  modules see ya
[19:04] <astraljava> [20:33] < clave> hello?
[19:05] <astraljava> sorry