[00:40] <ScottL> Len-nb, ah, thanks
[00:41] <micahg> ScottL: please see http://irclogs.ubuntu.com/2012/06/13/%23ubuntustudio-devel.html#t23:06
[02:25] <ScottL> gah, i'm an idiot sometimes! i made change in the natty seeds for some reason for the xfce4-util change :|
[02:25] <ScottL> i'll fix it in a bit
[02:27] <micahg> ScottL: ooh :), still won't fix anything until a meta upload is done (and no ISO until libav-extra is uploaded and gimp-plugin-registry are fixed)
[02:28] <micahg> and probably ubuntustudio-default-settings is fixed as well
[02:41] <len-dt> anybody know much about the abit MBs? I have an ic7-g. It is supposed to take up to 4G ram.
[02:42] <len-dt> It had 4 256m sticks in it. I got 2 1G sticks.
[02:44] <len-dt> There are 4 slots, I can not use slots 1 or 2 with the new ram. I can put them in 3 and 4 so long as at least one of the 256M sticks is in 1 or 2.
[02:47] <len-dt> It shows all the ram, but somewhere in the kernel load it reboots. I can have one 1G in slot 3 or 4 and fill the rest with my 256M sticks for 1.75G.
[02:50] <len-dt> It is not easy finding an Abit website that works. Finding bios updates seems to be problematic...
[02:55] <len-dt> ailo, I have gotten myself a UM-1G USB midi interface (cakewalk/roland)
[02:55] <len-dt> I will test for timing problems.
[02:56] <len-dt> It has two modes (dumb and smart, or standard and advanced) I will try both.
[03:06] <ScottL> micahg, reverted change to natty seeds (i realize nothing really needs to be done further to that), updated quantal seeds, updated -default-settings, and downloading bzr branch for libav-extra
[03:06] <ScottL> is the gimp-plugin-registry breaking because of libav-extra?
[03:06] <ScottL> and aren't we using a special libav-extra for studio?
[03:08] <len-dt> ScottL, gimp-plugin-registry was broken before the extra problem showed up.
[03:08] <micahg> ScottL: nothing to do for libav-extra, I just need to test and upload from pkg-multimedia, if you can work on gimp-plugin-registry, that would be good
[03:08] <micahg> gimp-plugin-registry was broken before, yes
[03:12] <ScottL> okay, can i look at qa.ubuntuwire.com/ftbfs for the gimp-plugin-registry logs, micahg?
[03:12] <ScottL> or is there a more expedient or practical place to look
[03:13] <micahg> ScottL: yes, that's fine
[03:18] <scott-upstairs> micahg, it looks like this is the problem, but i haven't a clue where to go from here
[03:18] <scott-upstairs> collect2: error: ld returned 1 exit status
[03:18] <scott-upstairs> collect2: error: ld returned 1 exit status
[03:18] <scott-upstairs> hold on...
[03:19] <scott-upstairs> build/buildd/gimp-plugin-registry-5.20120523/resynthesizer/bootchk-resynthesizer-28cade5/src/resynthesizer.c:314: undefined reference to `g_thread_init'
[03:19] <scott-upstairs> collect2: error: ld returned 1 exit status
[03:19] <scott-upstairs> the first line had a leading backslash that was causing it not to show
[03:19] <micahg> that's the issue, g_thread_init needs to be removed
[03:25]  * scott-upstairs is getting bzr branch for gimp-plugin-registry now and a glass of water
[03:31] <scott-upstairs> micahg, i'm guessing that " g_thread_init(NULL);  // Init threading system, not necessary after glib 2.32" line can be removed or commented out?
[03:32] <scott-upstairs> from the refinerThreaded.h file
[03:32] <micahg> scott-upstairs: yes
[03:32] <scott-upstairs> micahg, do you use schroot to test build packages?
[03:33] <micahg> scott-upstairs: yes
[03:33] <scott-upstairs> is there a good tutorial for that?
[03:33] <scott-upstairs> i know the wiki.ubuntu.com has a page on schroots
[03:34] <micahg> scott-upstairs: https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
[03:36] <scott-upstairs> micahg, thanks!  i'm got to get up in about 7.5 hours so i'm going to start shutting down, i'll continue work on this tomorrow
[05:20] <astraljava> Is it not possible to let the image build status emails directly to the list? Or failing that, can't the credentials be shared for the mailing list? Is there something we could do to speed up the queue?
[05:22] <astraljava> ScottL: Oh so that's why the natty seeds were updated so recently. I kinda wondered about it, but didn't stop to really think about why. :)
[05:28] <micahg> someone just needs to whitelist the from address
[05:36] <astraljava> micahg: Thanks. Now who can do that? Apparently Scott can, but is there anyone else? Should there be someone else?
[05:36] <micahg> astraljava: that's up to ScottL
[05:37] <astraljava> Ok, I'll have a word with him. :) Thanks!
[13:23] <scott-work> micahg: i shall read that schroot today at some point at work. if you wouldn't mind sharing your work flow (pastebin of an existing one or just a categorical list of the process) i would greatly appreciate it
[13:24] <scott-work> my current process has been to load the code locally on my production (audio) machine and then build in pbuilder to test build, but then i typically only use my ppa to build when i am familiar with the applicaiton and then after it builds i install it on a development machine running the dev release
[13:24] <scott-work> as you can see, that is a complicated and not very elegant solution and i greatly desire to streamline it
[18:56] <scott-work> oooh, micahg, this appears to be what i was looking for:  https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment#Typical_package_build_procedure
[18:56] <micahg> scott-work: yeah, but you don't need umt
[18:56] <scott-work> i think i can minimize my development setup to a single 64 bit machine this way
[18:56] <scott-work> micahg: what would you recommend then, just sbuild via schroot?
[18:56] <micahg> scott-work: I actually have aliases set up for the chroots
[18:57] <micahg> sbuild -c quantal-i386-shm -d quantal --arch i386 -A (for quantal i386, remove -shm if you didn't set up the overlay to build in RAM)
[18:58] <micahg> sbuild -d quantal-amd64-shm (for quantal amd64)
[18:58] <micahg> just put the .dsc file after those calls
[22:32]  * len-dt has figured out his memory problem
[22:32] <len-dt> ailo, I need to know which setup you used that had midi problems.
[22:33] <len-dt> So far I have not had any midi timing errors, internal or USB.
[22:34] <ailo> len-dt: The problem only arises when I use my xv-5050
[22:35] <ailo> It has its' own midi port through usb
[22:35] <ailo> The problem went away if I used my firewire device with jack midi
[22:35] <ailo> Firewire devices only support jack midi, as you might know
[22:36] <ailo> So, I connected the firewire device with a midi cable to my Roland xv-5050
[22:36] <len-dt> Ya, I have a cakewalk usb midi. So far it has just worked fine.
[22:37] <ailo> Can't remember if I had my m-audio usb midi device in the mix. It needs firmware to work
[22:37] <ailo> I need to go through that stuff again
[22:37] <len-dt> I was just wondering if there was some way I could stress test it.
[22:37] <ailo> How I noticed my problem was when I recorded the output from the xv-5050
[22:38] <len-dt> ailo, the machine I was using it in has two midi IFs
[22:38] <ailo> Not even a single bar was even close to being in sync
[22:38] <len-dt> So that would be qtracktor?
[22:38] <ailo> I also tried Ardour3
[22:39] <len-dt> Hmm, I wonder if that is because the highres timers are not accessible to user space as US 12.04 ships.
[22:39] <ailo> jack midi worked just fine
[22:40] <ailo> jack midi was more or less precisely accurate
[22:41] <ailo> len-dt: Do you have a external synth device?
[22:41] <len-dt> Yes, but I haven't tried it with the new IF yet.
[22:42] <len-dt> I will record an external KB and play it back to an external synth then.
[22:42] <ailo> len-dt: Better you write the midi, or at least make sure it's quantisized
[22:43] <ailo> Send a loop to the synth using alsa midi, and record the output
[22:43] <len-dt> ailo, I was thinking of using a beat box.
[22:43] <ailo> One way to hear the result directly is to just copy the result, and paste it at a different position, so the audio overlaps
[22:44] <ailo> I mean copy the newly recorded audio file
[22:44] <len-dt> Ok.
[22:45] <ailo> For me, each instance of the loop was different, and I was unable to get even one that was usable for the song I was recording
[22:47] <len-dt> ailo, I tried inputting from a beat box and then outputting to the same beat box. I could hear the slight delay from the original to the processed, but the delay seemed to be consistent
[22:48] <len-dt> That was alsa in to alsa out.
[22:48] <len-dt> I think recording it is the key.
[22:49] <len-dt> ailo, in other news... Got more ram for the desktop. Now have 2.5G
[22:50] <len-dt> I had to take one stick back... it was missing a bit.
[22:51] <knome> hooray
[22:53] <ailo> len-dt: Delay was not the problem for me. Just that each note was randomly out of sync with some +/- ms
[22:53] <len-dt> The YC20 synth almost works for me now.
[22:54] <len-dt> Ya, I remember that. I suspect it has something to do with the software not having timing.
[22:54] <ailo> If it's fixable, then we should really get it done :)
[22:55] <len-dt> Alsa, has access to the hirez timer because it is not user space, but kenrnel module.
[22:56] <len-dt> I would like to think it is a simple as changing the settings so that the hirez timer is part of the audio group.
[22:57] <len-dt> We went to the trouble of making it a part of the kernel, now we need to make sure the SW can use it...
[22:57] <ailo> Wasn't this what did that? http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_timers
[22:58] <len-dt> Ya that looks right. But we don't ship tha way.
[22:58] <ailo> I'll test that once I get a chance
[23:02] <len-dt> ScottL, ailo and others, I may not be available at all this weekend. I am gone from tomorrow morning till Sunday evening. My oldest son is getting married.
[23:04] <ailo> May he stay in love with his wife and not grow a "ölmage" (beer belly)
[23:05] <len-dt> They have been seeing each other a number of years. It looks good.
[23:06] <ailo> And if there's not at least one corpse after the wedding fiest, it was not a real wedding (Finnish joke, related to fighting with knives)
[23:07] <len-dt> from back when _everyone_ carried a blade (or four).
[23:08]  * len-dt is from good celt blood.